Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The metrics-collector module relies on Docker's embedded DNS resolver for user-defined networks. The DNS resolver provides the IP address for metrics endpoints that include module name. For example, http://edgeHub:9600/metrics.
When modules aren't running in the same network namespace, this mechanism will fail. For instance, some scenarios require running modules on the host network. Collection fails in such scenarios if metrics-collector module is on a different network.
The built-in metrics endpoints exposed by IoT Edge system modules use http protocol. They won't be available, even within the module network, if http is explicitly disabled via the environment variable setting on Edge Hub or Edge Agent modules.
On Linux hosts, ensure you're using a recent version of the container engine. We recommend updating to the latest version by following the installation instructions.
You could use built-in log pull features. A sample solution that uses the built-in log retrieval features is available at https://aka.ms/iot-elms.
Azure Monitor's native metrics technology doesn't yet support Prometheus data format directly. Log-based metrics are currently better suited for IoT Edge metrics because of:
- Native support for Prometheus metrics format via the standard InsightsMetrics table.
- Advanced data processing via KQL for visualizations and alerts.
The use of Log Analytics as the metrics database is the reason why metrics appear in the Logs page in Azure portal rather than Metrics.
The metrics collector doesn't have any service discovery functionality. We recommend including the module in the base or lower deployment layer. Include all metrics endpoints that the module might be deployed with in the module's configuration. If a module doesn't appear in a final deployment but its endpoint appears in the collection list, the collector will try to collect, fail, and move on.
See the custom metrics article.
Encode device information in the metric labels. For more information, see Naming conventions.
When creating an alert rule, you can change its scope to a resource group or subscription. The alert rule will then apply to all IoT hubs in that scope.
When creating an alert rule, verify the alert logic will trigger by checking the preview graph.
If you aren't able to find the problem, create a technical support incident for the Log Analytics service.
The workbook relies on device metrics being linked to the correct IoT hub or IoT Central application using ResourceId. Confirm that the metrics-collector is configured with the correct ResourceId.
Using metrics-collector module logs, confirm that the device sent metrics during the selected time range.
Keep in mind, there can be an ingestion delay of a few minutes before metrics show up.
Open an issue on the Azure IoT Edge GitHub repo with '[monitor-workbook]' in the title.
The template for the workbooks is publicly available on GitHub. Pull requests with improvements or fixes are very welcome!
Ensure that you're looking at the Workbooks page in your IoT hub or IoT Central application page in the portal, not in your Log Analytics workspace.
If you still can't see the workbooks, try using the pre-production Azure portal environment: https://portal.azure.cn. Sometimes workbook updates take additional time to show up in the production environment, but will be available in pre-production.