Freigeben über


Sammeln und Übertragen von Metriken

Gilt für: Häkchen für IoT Edge 1.5 IoT Edge 1.5 IoT Edge 1.4 Häkchen IoT Edge 1.4

Wichtig

IoT Edge 1.5 LTS und IoT Edge 1.4 LTS sind unterstützte Releases. Das Ende der Lebensdauer von IoT Edge 1.4 LTS wird am 12. November 2024 erreicht. Wenn Sie ein früheres Release verwenden, finden Sie weitere Informationen unter Aktualisieren von IoT Edge.

Sie können Ihre IoT Edge-Flotte mithilfe von Azure Monitor und den integrierten Metriken remote überwachen. Um diese Funktion auf Ihrem Gerät zu aktivieren, fügen Sie Ihrer Bereitstellung das Modul „Metrikensammler“ hinzu, und konfigurieren Sie es so, dass Modulmetriken gesammelt und an Azure Monitor übertragen werden.

Informationen zum Konfigurieren der Überwachung für Ihr IoT Edge-Gerät finden Sie unter Tutorial: Überwachen von IoT Edge-Geräten. Sie erfahren, wie Sie dem Gerät das Metriksammlermodul hinzufügen. In diesem Artikel erhalten Sie eine Übersicht über die Überwachungsarchitektur, und es werden Ihre Optionen zum Konfigurieren von Metriken auf Ihrem Gerät erläutert.

IoT Edge-Integration in Azure Monitor (4:06)

Aufbau

Screenshot: Architektur für die Überwachung von Metriken mit IoT Hub

Hinweis Beschreibung
1 Alle Module müssen mithilfe des Prometheus-Datenmodells Metriken ausgeben. Integrierte Metriken ermöglichen zwar standardmäßig eine umfassende Sichtbarkeit von Workloads, aber es können zusätzlich benutzerdefinierte Module verwendet werden, um szenariospezifische Metriken auszugeben und somit die Überwachungslösung zu verbessern. Informationen über das Instrumentieren benutzerdefinierter Module mithilfe von Open-Source-Bibliotheken finden Sie im Artikel Hinzufügen benutzerdefinierter Metriken.
2️ Das Metrikensammler-Modul ist ein von Microsoft bereitgestelltes IoT Edge-Modul, das Modulmetriken von Workloads sammelt und diese von den Geräten abtransportiert. Der Metrikensammler verwendet ein Pullmodell. Die Sammlungshäufigkeit sowie Endpunkte und Filter können so konfiguriert werden, dass die vom Modul ausgegebenen Daten kontrolliert werden. Weitere Informationen finden Sie im Abschnitt Konfiguration des Metrikensammlers weiter unten in diesem Artikel.
3️ Sie haben zwei Optionen, um Metriken aus dem Metrikensammler-Modul an die Cloud zu senden. Option 1 sendet die Metriken an Log Analytics. 1 Die gesammelten Metriken werden mithilfe einer festen, nativen Tabelle namens InsightsMetrics im angegebenen Log Analytics-Arbeitsbereich erfasst. Das Schema dieser Tabelle ist mit dem Prometheus-Metrikdatenmodell kompatibel.

Diese Option erfordert Zugriff auf den Arbeitsbereich am ausgehenden Port 443. Die ID und der Schlüssel des Log Analytics-Arbeitsbereichs müssen im Rahmen der Modulkonfiguration angegeben werden. Informationen über das Aktivieren in eingeschränkten Netzwerken finden Sie weiter unten in diesem Artikel unter Aktivieren in Szenarien mit eingeschränktem Netzwerkzugriff.
4️ Jeder Metrikeintrag enthält die ResourceId, die als Teil der Modulkonfiguration angegeben wurde. Diese Zuordnung verknüpft die Metrik automatisch mit der angegebenen Ressource (z. B. IoT Hub). Auf diese Weise können die kuratierten IoT Edge-Arbeitsmappenvorlagen Metriken abrufen, indem sie Abfragen für die Ressourcen ausführen.

Mit diesem Ansatz ist es ebenfalls möglich, dass mehrere IoT Hubs einen einzelnen Log Analytics-Arbeitsbereich als Metrikdatenbank sicher gemeinsam nutzen.
5️ Option 2 sendet die Metriken an IoT Hub. 1 Das Sammlermodul kann so konfiguriert werden, dass die gesammelten Metriken über das Modul edgeHub als UTF-8-codierte JSON-Gerät-zu-Cloud-Nachrichten gesendet werden. Diese Option ermöglicht die Überwachung von gesperrten IoT Edge-Geräten, die externen Zugriff nur auf den IoT Hub-Endpunkt erhalten. Außerdem wird auf diese Weise die Überwachung von untergeordneten IoT Edge-Geräten in einer geschachtelten Konfiguration ermöglicht, bei der untergeordnete Geräte nur auf ihr jeweils übergeordnetes Gerät zugreifen können.
6️ Wenn Metriken über IoT Hub weitergeleitet werden, muss ein (einmaliger) Cloudworkflow eingerichtet werden. Der Workflow verarbeitet Nachrichten, die vom Metrikensammler-Modul eintreffen und sendet diese an den Log Analytics-Arbeitsbereich. Der Workflow ermöglicht die Funktionen kuratierte Visualisierungen und Warnungen auch für Metriken, die über diesen optionalen Pfad eintreffen. Weitere Informationen über das Einrichten dieses Cloudworkflows finden Sie im Abschnitt Routen von Metriken durch IoT Hub.

1 Derzeit ist der Einsatz von Option 1 für eine direkte Übertragung von Metriken vom IoT Edge-Gerät an Log Analytics der einfachere Weg, bei dem nur ein minimaler Setup-Aufwand erforderlich ist. Die erste Option wird demnach bevorzugt, es sei denn, Ihr spezifisches Szenario erfordert Option 2, bei der das IoT Edge-Gerät nur mit IoT Hub kommuniziert.

Metrikensammler-Modul

Ein von Microsoft bereitgestelltes Metrikensammler-Modul kann einer IoT Edge-Bereitstellung hinzugefügt werden, um Modulmetriken zu sammeln und an Azure Monitor zu senden. Der Code des Moduls ist ein Open-Source-Code und im IoT Edge GitHub-Repository verfügbar.

Das Metrikensammler-Modul wird als Docker-Containerimage mit mehreren Arches bereitgestellt, das Linux X64, ARM32, ARM64 und Windows X64 (Version 1809) unterstützt. Es ist über mcr.microsoft.com/azureiotedge-metrics-collector öffentlich verfügbar.

Konfiguration des Metrikensammlers

Die Konfiguration des Metrikensammlers erfolgt mithilfe von Umgebungsvariablen. Die in der folgenden Tabelle als Erforderlich gekennzeichneten Variablen müssen in jedem Fall angegeben werden.

Environment variable name Beschreibung
ResourceId Ressourcen-ID des IoT Hubs, mit dem das Gerät kommuniziert. Weitere Informationen finden Sie im Abschnitt Ressourcen-ID.

Erforderlich

Standardwert: none
UploadTarget Steuert, ob Metriken über HTTPS direkt an Azure Monitor oder als D2C-Nachrichten an IoT Hub gesendet werden. Weitere Informationen finden Sie unter Uploadziel.

Kann entweder AzureMonitor oder IoTMessage sein.

Nicht erforderlich

Standardwert: AzureMonitor
LogAnalyticsWorkspaceId ID des Log Analytics-Arbeitsbereichs

Nur erforderlich, wenn UploadTarget AzureMonitor ist

Standardwert: none
LogAnalyticsSharedKey Schlüssel des Log Analytics-Arbeitsbereichs

Nur erforderlich, wenn UploadTarget AzureMonitor ist

Standardwert: none
ScrapeFrequencyInSecs Wiederkehrendes Zeitintervall in Sekunden, in dem Metriken erfasst und transportiert werden sollen.

Beispiel: 600

Nicht erforderlich

Standardwert: 300
MetricsEndpointsCSV Durch Trennzeichen getrennte Liste mit Endpunkten, von denen Prometheus-Metriken gesammelt werden. Alle Modulendpunkte, von denen Metriken gesammelt werden sollen, müssen in dieser Liste aufgeführt werden.

Beispiel: http://edgeAgent:9600/metrics, http://edgeHub:9600/metrics, http://MetricsSpewer:9417/metrics

Nicht erforderlich

Standardwert: http://edgeHub:9600/metrics, http://edgeAgent:9600/metrics
AllowedMetrics Liste der zu erfassenden Metriken. Alle anderen Metriken werden ignoriert. Legen Sie diese auf eine leere Zeichenfolge fest, wenn Sie sie deaktivieren wollen. Weitere Informationen finden Sie unter Listen zulassen oder nicht zulassen.

Beispiel: metricToScrape{quantile=0.99}[endpoint= http://MetricsSpewer:9417/metrics ]

Nicht erforderlich

Standardwert: empty
BlockedMetrics Liste der zu ignorierenden Metriken. Setzt AllowedMetrics außer Kraft, sodass eine in beiden Listen enthaltene Metrik nicht gemeldet wird. Weitere Informationen finden Sie unter Listen zulassen oder nicht zulassen.

Beispiel: metricToIgnore{quantile=0.5}[endpoint=http://VeryNoisyModule:9001/metrics], docker_container_disk_write_bytes

Nicht erforderlich

Standardwert: empty
CompressForUpload Steuert, ob Komprimierung beim Hochladen von Metriken verwendet werden sollte. Gilt für alle Uploadziele.

Beispiel: true

Nicht erforderlich

Standardwert: true
AzureDomain Gibt die Azure-Domäne der obersten Ebene an, die beim Erfassen von Metriken direkt in Log Analytics verwendet werden soll.

Beispiel: azure.us

Nicht erforderlich

Standardwert: azure.com

Ressourcen-ID

Das Metrikensammler-Modul benötigt die Azure Resource Manager-ID des IoT Hubs, zu dem das IoT Edge-Gerät gehört. Geben Sie diese ID als Wert für die ResourceID-Umgebungsvariable an.

Die Ressourcen-ID hat das folgende Format:

/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Devices/IoTHubs/<iot hub name>

Sie finden die Ressourcen-ID auf der Seite Eigenschaften des IoT Hubs im Azure-Portal.

Screenshot: Abrufen der Ressourcen-ID aus den IoT Hub-Eigenschaften

Oder Sie rufen die ID mit dem Befehl az resource show ab:

az resource show -g <resource group> -n <hub name> --resource-type "Microsoft.Devices/IoTHubs"

Uploadziel

Die Konfigurationsoption UploadTarget steuert, ob Metriken direkt an Azure Monitor oder an IoT Hub gesendet werden.

Wenn Sie UploadTarget auf IoTMessage festlegen, werden Ihre Modulmetriken als IoT-Nachrichten veröffentlicht. Diese Nachrichten werden als UTF8-codierter JSON-Code vom /messages/modules/<metrics collector module name>/outputs/metricOutput-Endpunkt ausgegeben. Wenn Ihr IoT Edge-Metriksammlermodul beispielsweise IoTEdgeMetricsCollector heißt, ist der Endpunkt /messages/modules/IoTEdgeMetricsCollector/outputs/metricOutput. Das Format ist wie folgt:

[{
    "TimeGeneratedUtc": "<time generated>",
    "Name": "<prometheus metric name>",
    "Value": <decimal value>,
    "Label": {
        "<label name>": "<label value>"
    }
}, {
    "TimeGeneratedUtc": "2020-07-28T20:00:43.2770247Z",
    "Name": "docker_container_disk_write_bytes",
    "Value": 0.0,
    "Label": {
        "name": "AzureMonitorForIotEdgeModule"
    }
}]

Listen zulassen oder nicht zulassen

Die Konfigurationsoptionen AllowedMetrics und BlockedMetrics enthalten durch Leerzeichen oder Komma getrennte Listen mit Metrikselektoren. Wenn eine Metrik mit der Liste übereinstimmt, wird sie einbezogen. Wenn sie mit einer oder mehreren Metriken in einer der Listen übereinstimmt, wird sie ausgeschlossen.

Metrikselektoren verwenden ein Format, das einer Untergruppe der PromQL-Abfragesprache ähnelt.

metricToSelect{quantile=0.5,otherLabel=~Re[ge]*|x}[http://VeryNoisyModule:9001/metrics]

Metrikselektoren bestehen aus drei Teilen:

Metrikname (metricToSelect).

  • Platzhalter * (beliebige Zeichen) und ? (beliebiges einzelnes Zeichen) können in Metriknamen verwendet werden. Z. B. würde *CPU mit maxCPU und minCPU übereinstimmen, aber nicht mit CPUMaximum. ???CPU würde mit maxCPU und minCPU übereinstimmen, aber nicht mit maximumCPU.
  • Diese Komponente ist bei einem Metrikselektor erforderlich.

Bezeichnungsbasierte Selektoren ({quantile=0.5,otherLabel=~Re[ge]*|x}).

  • In den geschweiften Klammern können mehrere Metrikwerte enthalten sein. Die Werte sollten durch Trennzeichen getrennt werden.
  • Eine Metrik wird entsprechend zugeordnet, wenn alle Bezeichnungen des Selektors vorhanden sind und übereinstimmen.
  • Wie bei PromQL sind die folgenden Operatoren für den Abgleich zulässig.
    • = Abgleich von Bezeichnungen, die genau mit der angegebenen Zeichenfolge übereinstimmen (Groß- und Kleinschreibung wird beachtet).
    • != Abgleich von Bezeichnungen, die nicht genau mit der angegebenen Zeichenfolge übereinstimmen.
    • =~ Abgleich von Bezeichnungen mit einem bereitgestellten RegEx. Bsp.: label=~CPU|Mem|[0-9]*
    • !~ Abgleich von Bezeichnungen, die zu einem bereitgestellten RegEx nicht passen.
    • RegEx ist vollständig verankert (^ und $ werden automatisch am Anfang und am Ende jedes regulären Ausdrucks hinzugefügt.)
    • Diese Komponente ist bei einem Metrikselektor optional.

Endpunktselektor ([http://VeryNoisyModule:9001/metrics]).

  • Die URL sollte genau mit einer URL übereinstimmen, die in MetricsEndpointsCSV aufgelistet ist.
  • Diese Komponente ist bei einem Metrikselektor optional.

Eine Metrik muss mit allen Teilen eines jeweiligen Selektors übereinstimmen, um ausgewählt zu werden. Sie muss mit dem Namen übereinstimmen und über dieselben Bezeichnungen mit übereinstimmenden Werten verfügen und vom angegebenen Endpunkt stammen. So würde beispielsweise mem{quantile=0.5,otherLabel=foobar}[http://VeryNoisyModule:9001/metrics] mit dem Selektor mem{quantile=0.5,otherLabel=~foo|bar}[http://VeryNoisyModule:9001/metrics] nicht übereinstimmen. Es sollten mehrere Selektoren verwendet werden, damit die Auswahl nicht eingeschränkt (AND-Operatoren) sondern erweitert wird (OR-Operatoren).

Um z. B. die benutzerdefinierte Metrik mem mit einer Bezeichnung aus dem Modul module1 zuzulassen, aber die gleiche Metrik aus module2 nur mit der Bezeichnung agg=p99 zuzulassen, kann AllowedMetrics der folgende Selektor hinzugefügt werden:

mem{}[http://module1:9001/metrics] mem{agg="p99"}[http://module2:9001/metrics]

Oder fügen Sie AllowedMetrics Folgendes hinzu, um die benutzerdefinierten Metriken mem und cpu unabhängig von den Bezeichnungen oder Endpunkten zuzulassen:

mem cpu

Aktivieren in Szenarien mit eingeschränktem Netzwerkzugriff

Wenn Sie Metriken direkt an den Log Analytics-Arbeitsbereich senden, lassen Sie einen ausgehenden Zugriff auf die folgenden URLs zu:

  • https://<LOG_ANALYTICS_WORKSPACE_ID>.ods.opinsights.azure.com/*
  • https://<LOG_ANALYTICS_WORKSPACE_ID>.oms.opinsights.azure.com/*

Proxy-Aspekte

Das Metrikensammler-Modul ist in .NET Core geschrieben. Verwenden Sie daher die gleiche Anleitung wie für Systemmodule, um die Kommunikation über einen Proxyserver zu ermöglichen.

Für die Metriksammlung aus lokalen Modulen wird das HTTP-Protokoll verwendet. Schließen Sie eine lokale Kommunikation vom Proxyserver aus, indem Sie die NO_PROXY-Umgebungsvariable einstellen.

Legen Sie den NO_PROXY-Wert auf eine durch Trennzeichen getrennte Liste von Hostnamen fest, die ausgeschlossen werden sollen. Verwenden Sie Modulnamen als Hostnamen. Beispiel: edgeHub,edgeAgent,myCustomModule.

Routen von Metriken

Manchmal ist es erforderlich, Metriken über IoT Hub zu erfassen, statt sie direkt an Log Analytics zu senden. Dies ist z. B. der Fall, wenn Sie IoT Edge-Geräte in einer geschachtelten Konfiguration überwachen, bei der untergeordnete Geräte nur Zugriff auf den IoT Edge-Hub ihres übergeordneten Geräts haben. Ein weiteres Beispiel ist die Bereitstellung eines IoT Edge-Geräts, das nur über ausgehenden Netzwerkzugriff auf IoT Hub verfügt.

Um die Überwachung in diesem Szenario zu ermöglichen, kann das Metrikensammler-Modul so konfiguriert werden, dass Metriken als D2C-Nachrichten (Device-to-Cloud) über das edgeHub-Modul gesendet werden. Die Funktion wird aktiviert, indem die UploadTarget-Umgebungsvariable bei der Konfiguration des Sammlers auf IoTMessagefestgelegt wird.

Tipp

Denken Sie daran, eine edgeHub-Route hinzuzufügen, um Metriknachrichten aus dem Sammlermodul an IoT Hub zu übermitteln. Dieser entspricht dem Format FROM /messages/modules/replace-with-collector-module-name/* INTO $upstream.

Bei dieser Option ist eine zusätzliche Einrichtung (ein Cloudworkflow) erforderlich, damit die bei IoT Hub eintreffenden Metriknachrichten an den Log Analytics-Arbeitsbereich übermittelt werden können. Ohne diese Einrichtung funktionieren die anderen Bestandteile der Integration wie kuratierte Visualisierungen und Warnungen nicht.

Hinweis

Bei dieser Option treten zusätzliche Kosten auf. Metriknachrichten werden auf Ihr IoT Hub-Nachrichtenkontingent angerechnet. Außerdem werden Ihnen die Log Analytics-Erfassung und die Cloudworkflowressourcen in Rechnung gestellt.

Beispiel für einen Cloudworkflow

Ein Cloudworkflow, der Metriknachrichten von IoT Hub an Log Analytics übermittelt, ist als Bestandteil des IoT Edge-Protokollierungs- und -Überwachungbeispiels verfügbar. Das Beispiel kann in vorhandenen Cloudressourcen bereitgestellt werden oder als Referenz für eine Produktionsbereitstellung dienen.

Nächste Schritte

Erfahren Sie mehr über die verschiedenen Arten von kuratierten Visualisierungen, die mit Azure Monitor möglich sind.