Freshness review

PatAltimore · PatAltimore · commit 6418e471654e · 2025-05-08T10:52:09.000-07:00
diff --git a/articles/iot-edge/how-to-access-built-in-metrics.md b/articles/iot-edge/how-to-access-built-in-metrics.md
@@ -1,11 +1,11 @@
 ---
 title: Access built-in metrics in Azure IoT Edge
-description: Remote access to built-in metrics from the IoT Edge runtime components
+description: Access built-in metrics from IoT Edge runtime components to monitor device health.
+#customer intent: As a system administrator, I want to access built-in metrics in Azure IoT Edge so that I can monitor and understand the health of my IoT Edge devices.  
 author: PatAltimore
-
 ms.author: patricka
-ms.date: 04/08/2024
-ms.topic: conceptual
+ms.date: 05/08/2025
+ms.topic: concept-article
 ms.reviewer: veyalla
 ms.service: azure-iot-edge
 services: iot-edge
@@ -17,11 +17,11 @@ services: iot-edge
 
 The IoT Edge runtime components, IoT Edge hub, and IoT Edge agent, produce built-in metrics in the [Prometheus exposition format](https://prometheus.io/docs/instrumenting/exposition_formats/). Access these metrics remotely to monitor and understand the health of an IoT Edge device.
 
-You can use your own solution to access these metrics. Or, you can use the [metrics-collector module](https://mcr.microsoft.com/artifact/mar/azureiotedge-metrics-collector), which handles collecting the built-in metrics and sending them to Azure Monitor or Azure IoT Hub. For more information, see [Collect and transport metrics](how-to-collect-and-transport-metrics.md).
+Use your own solution to access these metrics, or use the [metrics-collector module](https://mcr.microsoft.com/artifact/mar/azureiotedge-metrics-collector), which collects the built-in metrics and sends them to Azure Monitor or Azure IoT Hub. For more information, see [Collect and transport metrics](how-to-collect-and-transport-metrics.md).
 
-Metrics are automatically exposed by default on **port 9600** of the **edgeHub** and **edgeAgent** modules (`http://edgeHub:9600/metrics` and `http://edgeAgent:9600/metrics`). They aren't port mapped to the host by default.
+Metrics are exposed by default on **port 9600** of the **edgeHub** and **edgeAgent** modules (`http://edgeHub:9600/metrics` and `http://edgeAgent:9600/metrics`). They aren't mapped to the host by default.
 
-Access metrics from the host by exposing and mapping the metrics port from the module's `createOptions`. The example below maps the default metrics port to port 9601 on the host:
+Access metrics from the host by exposing and mapping the metrics port in the module's `createOptions`. The following example maps the default metrics port to port 9601 on the host:
 
 ```json
 {
@@ -40,36 +40,36 @@ Access metrics from the host by exposing and mapping the metrics port from the m
 }
 ```
 
-Choose different and unique host port numbers if you are mapping both the edgeHub and edgeAgent's metrics endpoints.
+Choose different and unique host port numbers when mapping both the edgeHub and edgeAgent metrics endpoints.
 
 > [!NOTE]
-> The environment variable `httpSettings__enabled` should not be set to `false` for built-in metrics to be available for collection.
+> The environment variable `httpSettings__enabled` must not be set to `false` for built-in metrics to be available for collection.
 >
 > Environment variables that can be used to disable metrics are listed in the [azure/iotedge repo doc](https://github.com/Azure/iotedge/blob/main/doc/EnvironmentVariables.md).
 
 ## Available metrics
 
-Metrics contain tags to help identify the nature of the metric being collected. All metrics contain the following tags:
+Metrics include tags that identify the nature of the metric being collected. All metrics include the following tags:
 
 | Tag | Description |
 |-|-|
-| iothub | The hub the device is talking to |
+| iothub | The hub the device communicates with |
 | edge_device | The ID of the current device |
 | instance_number | A GUID representing the current runtime. On restart, all metrics are reset. This GUID makes it easier to reconcile restarts. |
 
-In the Prometheus exposition format, there are four core metric types: counter, gauge, histogram, and summary. For more information about the different metric types, see the [Prometheus metric types documentation](https://prometheus.io/docs/concepts/metric_types/).
+The Prometheus exposition format includes four core metric types: counter, gauge, histogram, and summary. For more information about the different metric types, see the [Prometheus metric types documentation](https://prometheus.io/docs/concepts/metric_types/).
 
-The quantiles provided for the built-in histogram and summary metrics are 0.1, 0.5, 0.9 and 0.99.
+The quantiles for the built-in histogram and summary metrics are 0.1, 0.5, 0.9, and 0.99.
 
-The **edgeHub** module produces the following metrics:
+The **edgeHub** module generates the following metrics:
 
 | Name | Dimensions | Description |
 |-|-|-|
 | `edgehub_gettwin_total` | `source` (operation source)<br> `id` (module ID) | Type: counter<br> Total number of GetTwin calls |
 | `edgehub_messages_received_total` | `route_output` (output that sent message)<br> `id` | Type: counter<br> Total number of messages received from clients |
 | `edgehub_messages_sent_total` | `from` (message source)<br> `to` (message destination)<br>`from_route_output`<br> `to_route_input` (message destination input)<br> `priority` (message priority to destination) | Type: counter<br> Total number of messages sent to clients or upstream<br> `to_route_input` is empty when `to` is $upstream |
 | `edgehub_reported_properties_total` | `target`(update target)<br> `id` | Type: counter<br> Total reported property updates calls |
-| `edgehub_message_size_bytes` | `id`<br> | Type: summary<br> Message size from clients<br> Values may be reported as `NaN` if no new measurements are reported for a certain period of time (currently 10 minutes); for `summary` type, corresponding `_count` and `_sum` counters are emitted. |
+| `edgehub_message_size_bytes` | `id`<br> | Type: summary<br> Message size from clients<br> Values might be reported as `NaN` if no new measurements are reported for 10 minutes. For the `summary` type, corresponding `_count` and `_sum` counters are emitted. |
 | `edgehub_gettwin_duration_seconds` | `source` <br> `id` | Type: summary<br> Time taken for get twin operations |
 | `edgehub_message_send_duration_seconds` | `from`<br> `to`<br> `from_route_output`<br> `to_route_input` | Type: summary<br> Time taken to send a message |
 | `edgehub_message_process_duration_seconds` | `from` <br> `to` <br> `priority` | Type: summary<br> Time taken to process a message from the queue |
@@ -84,7 +84,7 @@ The **edgeHub** module produces the following metrics:
 | `edgehub_operation_retry_total` | `id`<br> `operation` (operation name) | Type: counter<br> Total number of times edgeHub operations were retried |
 | `edgehub_client_connect_failed_total` | `id` <br> `reason` (not authenticated)<br> | Type: counter<br> Total number of times clients failed to connect to edgeHub |
 
-The **edgeAgent** module produces the following metrics:
+The **edgeAgent** module generates the following metrics:
 
 | Name | Dimensions | Description |
 |-|-|-|
@@ -109,7 +109,7 @@ The **edgeAgent** module produces the following metrics:
 | `edgeAgent_total_network_out_bytes` | `module_name` | Type: gauge<br> The number of bytes sent to network |
 | `edgeAgent_total_disk_read_bytes` | `module_name` | Type: gauge<br> The number of bytes read from the disk |
 | `edgeAgent_total_disk_write_bytes` | `module_name` | Type: gauge<br> The number of bytes written to disk |
-| `edgeAgent_metadata` | `edge_agent_version`, `experimental_features`, `host_information` | Type: gauge<br> General metadata about the device. The value is always 0, information is encoded in the tags. Note `experimental_features` and `host_information` are json objects. `host_information` looks like ```{"OperatingSystemType": "linux", "Architecture": "x86_64", "Version": "1.2.7", "Provisioning": {"Type": "dps.tpm", "DynamicReprovisioning": false, "AlwaysReprovisionOnStartup": false}, "ServerVersion": "20.10.11+azure-3", "KernelVersion": "5.11.0-1027-azure", "OperatingSystem": "Ubuntu 20.04.4 LTS", "NumCpus": 2, "Virtualized": "yes"}```. Note `ServerVersion` is the Docker version and `Version` is the IoT Edge security daemon version. |
+| `edgeAgent_metadata` | `edge_agent_version`, `experimental_features`, `host_information` | Type: gauge<br> General metadata about the device. The value is always 0, and information is encoded in the tags. Note that `experimental_features` and `host_information` are JSON objects. `host_information` looks like ```{"OperatingSystemType": "linux", "Architecture": "x86_64", "Version": "1.2.7", "Provisioning": {"Type": "dps.tpm", "DynamicReprovisioning": false, "AlwaysReprovisionOnStartup": false}, "ServerVersion": "20.10.11+azure-3", "KernelVersion": "5.11.0-1027-azure", "OperatingSystem": "Ubuntu 20.04.4 LTS", "NumCpus": 2, "Virtualized": "yes"}```. Note `ServerVersion` is the Docker version and `Version` is the IoT Edge security daemon version. |
 
 ## Next steps
 
diff --git a/articles/iot-edge/how-to-edgeagent-direct-method.md b/articles/iot-edge/how-to-edgeagent-direct-method.md
@@ -1,50 +1,54 @@
 ---
-title: Built-in edgeAgent direct methods - Azure IoT Edge
-description: Monitor and manage an IoT Edge deployment using built-in direct methods in the IoT Edge agent runtime module
+title: Communicate with IoT Edge Agent Using Direct Methods
+description: Discover how to use IoT Edge agent direct methods to monitor device status, restart modules, and troubleshoot deployments remotely.
 author: PatAltimore
-
 ms.author: patricka
-ms.date: 03/02/2020
-ms.topic: conceptual
+ms.date: 05/08/2025
+ms.topic: concept-article
 ms.reviewer: veyalla
 ms.service: azure-iot-edge
 services: iot-edge
+ms.custom:
+  - ai-gen-docs-bap
+  - ai-gen-title
+  - ai-seo-date:05/08/2025
+  - ai-gen-description
 ---
 
 # Communicate with edgeAgent using built-in direct methods
 
 [!INCLUDE [iot-edge-version-all-supported](includes/iot-edge-version-all-supported.md)]
 
-Monitor and manage IoT Edge deployments by using the direct methods included in the IoT Edge agent module. Direct methods are implemented on the device, and then can be invoked from the cloud. The IoT Edge agent includes direct methods that help you monitor and manage your IoT Edge devices remotely.
+Monitor and manage IoT Edge deployments using the direct methods in the IoT Edge agent module. Direct methods are implemented on the device and can be invoked from the cloud. The IoT Edge agent includes direct methods to monitor and manage IoT Edge devices remotely.
 
 For more information about direct methods, how to use them, and how to implement them in your own modules, see [Understand and invoke direct methods from IoT Hub](../iot-hub/iot-hub-devguide-direct-methods.md).
 
-The names of these direct methods are handled case-insensitive.
+The names of these direct methods are case insensitive.
 
 ## Ping
 
-The **ping** method is useful for checking whether IoT Edge is running on a device, or whether the device has an open connection to IoT Hub. Use this direct method to ping the IoT Edge agent and get its status. A successful ping returns an empty payload and **"status": 200**.
+The **ping** method checks if IoT Edge is running on a device or if the device has an open connection to IoT Hub. Use this method to ping the IoT Edge agent and check its status. A successful ping returns an empty payload and a **"status": 200**.
 
 For example:
 
 ```azurecli
 az iot hub invoke-module-method --method-name 'ping' -n <hub name> -d <device name> -m '$edgeAgent'
 ```
 
-In the Azure portal, invoke the method with the method name `ping` and an empty JSON payload `{}`.
+In the Azure portal, invoke the method using the method name `ping` and an empty JSON payload `{}`.
 
-:::image type="content" source="./media/how-to-edgeagent-direct-method/ping-direct-method.png" alt-text="Screenshot showing how to invoke the direct method ping in Azure portal.":::
+:::image type="content" source="./media/how-to-edgeagent-direct-method/ping-direct-method.png" alt-text="Screenshot of how to invoke the direct method ping in Azure portal.":::
 
 ## Restart module
 
-The **RestartModule** method allows for remote management of modules running on an IoT Edge device. If a module is reporting a failed state or other unhealthy behavior, you can trigger the IoT Edge agent to restart it. A successful restart command returns an empty payload and **"status": 200**.
+The **RestartModule** method lets you remotely manage modules running on an IoT Edge device. If a module reports a failed state or unhealthy behavior, trigger the IoT Edge agent to restart it. A successful restart command returns an empty payload with **"status": 200**.
 
-The RestartModule method is available in IoT Edge version 1.0.9 and later.
+The RestartModule method is available starting with IoT Edge version 1.0.9.
 
 >[!TIP]
->The IoT Edge troubleshooting page in the Azure portal provides a simplified experience for restarting modules. For more information, see [Monitor and troubleshoot IoT Edge devices from the Azure portal](troubleshoot-in-portal.md).
+>The IoT Edge troubleshooting page in the Azure portal simplifies restarting modules. For more information, see [Monitor and troubleshoot IoT Edge devices from the Azure portal](troubleshoot-in-portal.md).
 
-You can use the RestartModule direct method on any module running on an IoT Edge device, including the edgeAgent module itself. However, if you use this direct method to shut down the edgeAgent, you won't receive a success result since the connection is disrupted while the module restarts.
+Use the RestartModule direct method on any module running on an IoT Edge device, including the edgeAgent module. If you use this direct method to shut down the edgeAgent, you don't receive a success result because the connection is disrupted during the module restart.
 
 For example:
 
@@ -58,7 +62,7 @@ az iot hub invoke-module-method --method-name 'RestartModule' -n <hub name> -d <
 '
 ```
 
-In the Azure portal, invoke the method with the method name `RestartModule` and the following JSON payload:
+In the Azure portal, use the method name `RestartModule` with the following JSON payload:
 
 ```json
 {
@@ -67,14 +71,14 @@ In the Azure portal, invoke the method with the method name `RestartModule` and
 }
 ```
 
-:::image type="content" source="./media/how-to-edgeagent-direct-method/restartmodule-direct-method.png" alt-text="Screenshot showing how to invoke direct method RestartModule in the Azure portal.":::
+:::image type="content" source="./media/how-to-edgeagent-direct-method/restartmodule-direct-method.png" alt-text="Screenshot of invoking the direct method RestartModule in the Azure portal.":::
 
 ## Diagnostic direct methods
 
-* [GetModuleLogs](how-to-retrieve-iot-edge-logs.md#retrieve-module-logs): Retrieve module logs inline in the response of the direct method.
-* [UploadModuleLogs](how-to-retrieve-iot-edge-logs.md#upload-module-logs): Retrieve module logs and upload them to Azure Blob Storage.
-* [UploadSupportBundle](how-to-retrieve-iot-edge-logs.md#upload-support-bundle-diagnostics): Retrieve module logs using a support bundle and upload a zip file to Azure Blob Storage.
-* [GetTaskStatus](how-to-retrieve-iot-edge-logs.md#get-upload-request-status): Check on the status of an upload logs or support bundle request.
+* [GetModuleLogs](how-to-retrieve-iot-edge-logs.md#retrieve-module-logs): Retrieve module logs in the response of the direct method.
+* [UploadModuleLogs](how-to-retrieve-iot-edge-logs.md#upload-module-logs): Retrieve module logs and upload to Azure Blob Storage.
+* [UploadSupportBundle](how-to-retrieve-iot-edge-logs.md#upload-support-bundle-diagnostics): Retrieve module logs with a support bundle and upload a zip file to Azure Blob Storage.
+* [GetTaskStatus](how-to-retrieve-iot-edge-logs.md#get-upload-request-status): Check the status of an upload logs or support bundle request.
 
 These diagnostic direct methods are available as of the 1.0.10 release.
 
