Freigeben über

Benutzerdefinierte Metriken in Azure Monitor (Vorschau)

  • Artikel

Azure stellt Ihnen einige sofort einsetzbare Metriken zur Verfügung. Diese Metriken werden als Standard- oder Plattformmetriken bezeichnet. Benutzerdefinierte Metriken sind Leistungsindikatoren oder geschäftsspezifische Metriken, die über die Telemetrie Ihrer Anwendung, den Azure Monitor Agent, eine Diagnoseerweiterung, die auf Ihren Azure-Ressourcen oder ein externes Überwachungssystem ausgeführt wird, erfasst werden können. Sobald benutzerdefinierte Metriken in Azure Monitor veröffentlicht wurden, können Sie auf dieser Seite die standardmäßigen Azure-Metriken durchsuchen, abfragen und benachrichtigen.

Azure Monitor benutzerdefinierte Metriken sind derzeit in der öffentlichen Vorschau.

Methoden zum Senden benutzerdefinierter Metriken

Benutzerdefinierte Metriken können über verschiedene Methoden an Azure Monitor übermittelt werden:

Preismodell und Aufbewahrung

Generell lässt sich sagen, dass keine Kosten für die Erfassung von Standardmetriken (Plattformmetriken) in einem Azure Monitor-Metrikspeicher anfallen, aber für benutzerdefinierte Metriken fallen Kosten an, sobald sie allgemein verfügbar sind. Abfragen an die Metriken-API sind kostenpflichtig. Details dazu, wann die Abrechnung für benutzerdefinierte Metriken und Metrikabfragen aktiviert wird, finden Sie unter Azure Monitor – Preise.

Benutzerdefinierte Metriken werden genauso lange wie Plattformmetriken aufbewahrt.

Hinweis

Um eine bessere Benutzererfahrung zu bieten, werden benutzerdefinierte Metriken, die von Application Insights Classic API (SDKs) an Azure Monitor gesendet werden, immer sowohl in Log Analytics als auch im Metrikspeicher gespeichert. Die Kosten zum Speichern dieser Metriken basieren nur auf dem von Log Analytics erfassten Volumen. Es gibt keine zusätzlichen Kosten für Daten, die im Metrikspeicher gespeichert werden.

Benutzerdefinierte Metrikdefinitionen

Jeder veröffentlichte Metrikdatenpunkt enthält Informationen zu Namespace, Name und Dimension. Bei der ersten Ausgabe einer benutzerdefinierten Metrik an Azure Monitor wird automatisch eine Metrikdefinition erstellt. Diese neue Metrikdefinition ist dann für jede Ressource auffindbar, für die diese Metrik über die Metrikdefinitionen ausgegeben wird. Es ist nicht erforderlich, eine benutzerdefinierte Metrik in Azure Monitor vorab zu definieren, bevor sie ausgegeben wird.

Hinweis

Application Insights, die Diagnoseerweiterung und der InfluxData Telegraf-Agent sind bereits so konfiguriert, dass sie Metrikwerte für den richtigen regionalen Endpunkt ausgeben und alle oben genannten Eigenschaften in jeder Ausgabe enthalten.

Verwenden benutzerdefinierter Metriken

Nachdem benutzerdefinierte Metriken an Azure Monitor übermittelt wurden, können Sie diese über das Azure-Portal durchsuchen und über die Azure Monitor REST APIs abfragen. Sie können auch Warnungen erstellen, damit Sie benachrichtigt werden, wenn bestimmte Bedingungen erfüllt sind.

Hinweis

Um benutzerdefinierte Metriken anzeigen zu können, müssen Sie eine Leser- oder Beitragszahlerrolle haben. Siehe Überwachungsleser.

Durchsuchen Ihrer benutzerdefinierten Metriken über das Azure-Portal

  1. Öffnen Sie das Azure-Portal.
  2. Wählen Sie den Bereich Überwachen aus.
  3. Klicken Sie auf Metriken.
  4. Wählen Sie eine Ressource aus, für die Sie benutzerdefinierte Metriken erstellt haben.
  5. Wählen Sie den Namespace Ihrer benutzerdefinierten Metrik aus.
  6. Wählen Sie die benutzerdefinierte Metrik aus.

Weitere Informationen zum Anzeigen von Metriken im Azure-Portal finden Sie unter Analysieren von Metriken mit dem Azure Monitor-Metrik-Explorer.

Latenz und Aufbewahrungsdauer im Speicher

Es kann bis zu 3 Minuten dauern, bis eine neu hinzugefügte Metrik oder eine neu hinzugefügte Dimension zu einer Metrik erscheint. Nachdem die Daten im System sind, sollten sie in 99 Prozent der Fälle in weniger als 30 Sekunden erscheinen.

Wenn Sie eine Metrik löschen oder eine Dimension entfernen, kann es eine Woche bis zu einem Monat dauern, bis die Löschung aus dem System erfolgt.

Kontingente und Grenzwerte

Azure Monitor erzwingt die folgenden Nutzungslimits für benutzerdefinierte Metriken:

Category Begrenzung
Gesamtzahl der aktiven Zeitreihen in einem Abonnement pro Region 50.000
Dimensionsschlüssel pro Metrik 10
Zeichenkettenlänge für metrische Namespaces, metrische Namen, Dimensionsschlüssel und Dimensionswerte 256 Zeichen
Die kombinierte Länge aller benutzerdefinierten Metriknamen mit UTF-8-Codierung 64 KB

Eine aktive Zeitreihe ist definiert als eine beliebige eindeutige Kombination aus Metrik, Dimensionsschlüssel oder Dimensionswert, deren Metrikwerte in den letzten 12 Stunden veröffentlicht wurden.

Um die Grenze von 50.000 bei Zeitreihen zu verstehen, betrachten Sie die folgende Metrik:

Serverantwortzeit mit den Dimensionen: Region, Abteilung, Kunden-ID

Wenn Sie 10 Regionen, 20 Abteilungen und 100 Kunden haben, erhalten Sie mit dieser Metrik 10 x 20 x 100 = 20.000 Zeitreihen.

Wenn Sie 100 Regionen, 200 Abteilungen und 2.000 Kunden haben, ergibt das 100 x 200 x 2.000 = 40 Millionen Zeitreihen, was allein für diese Metrik weit über dem Limit liegt.

Auch hier gilt dieser Grenzwert nicht für eine einzelne Metrik. Es handelt sich um die Summe aller derartigen Metriken für ein Abonnement und eine Region.

Führen Sie die folgenden Schritte aus, um Ihre aktuellen aktiven Zeitreihenmetriken und weitere Informationen zur Fehlerbehebung anzuzeigen.

  1. Navigieren Sie im Azure-Portal zum Abschnitt „Monitor“.
  2. Wählen Sie auf der linken Seite Metriken aus.
  3. Überprüfen Sie unter Bereich auswählen die zutreffenden Abonnement- und Ressourcengruppen.
  4. Wählen Sie unter Bereich genauer definieren die Option Nutzung der benutzerdefinierten Metrik und den gewünschten Speicherort aus.
  5. Klicken Sie anschließend auf die Schaltfläche Anwenden.
  6. Wählen Sie entweder Aktive Zeitreihe, Grenzwert für aktive Zeitreihe oder Gedrosselte Zeitreihe aus.

Es gibt eine Grenze von 64 KB für die kombinierte Länge aller benutzerdefinierten Metriknamen. Dabei wird von UTF-8 oder 1 Byte pro Zeichen ausgegangen. Wenn der Grenzwert von 64 KB überschritten wird, stehen keine Metadaten für zusätzliche Metriken zur Verfügung. Die Metriknamen für zusätzliche benutzerdefinierte Metriken werden nicht im Azure-Portal in Auswahlfeldern angezeigt und von der API in Anforderungen für Metrikdefinitionen nicht zurückgegeben. Die Metrikdaten sind weiterhin verfügbar und können abgefragt werden.

Wenn der Grenzwert überschritten wurde, reduzieren Sie die Anzahl der gesendeten Metriken, oder kürzen Sie ihre Namen. Es dauert dann bis zu zwei Tage, bis die Namen der neuen Metriken angezeigt werden.

Um das Erreichen des Grenzwerts zu vermeiden, schließen Sie keine Variablen oder Dimensionen in Ihre Metriknamen ein. Die Metriken für die Server-CPU-Verwendung CPU_server_12345678-319d-4a50-b27e-1234567890ab und CPU_server_abcdef01-319d-4a50-b27e-abcdef012345 sollten als Metrik CPU mit der Dimension Server definiert werden.

Entwurfseinschränkungen und -aspekte

Verwendung von Application Insights zum Zweck des Audits. Die Telemetrie-Pipeline von Application Insights ist für die Minimierung der Leistungsauswirkungen und die Begrenzung des Netzwerkverkehrs bei der Überwachung Ihrer Anwendung optimiert. Daher wird eine Drosselung oder Stichprobenentnahme vorgenommen (nimmt nur einen Prozentsatz Ihrer Telemetriedaten an und ignoriert den Rest), wenn das anfängliche Dataset zu groß wird. Aufgrund dieses Verhaltens können Sie es nicht für Prüfungszwecke verwenden, da einige Datensätze wahrscheinlich gelöscht werden.

Metriken mit einer Variable im Namen. Verwenden Sie keine Variable als Teil des Metriknamens. Verwenden Sie stattdessen eine Konstante. Jedes Mal, wenn die Variable ihren Wert ändert, generiert Azure Monitor eine neue Metrik. Azure Monitor stößt dann schnell an die Grenze der Anzahl von Metriken. Im Allgemeinen, wenn Entwickler eine Variable in den Metriknamen aufnehmen möchten, wollen sie wirklich mehrere Zeitreihen innerhalb einer Metrik nachverfolgen und sollten Dimensionen anstelle von variablen Metriknamen verwenden.

DimensionenMetriken mit hoher Kardinalität. Bei Metriken mit zu vielen gültigen Werten in einer Dimension (hohe Kardinalität) ist es sehr viel wahrscheinlicher, dass die 50.000er Grenze erreicht wird. Im Allgemeinen sollten Sie niemals einen sich ständig ändernden Wert in einer Dimension verwenden. Der Zeitstempel zum Beispiel sollte nie eine Dimension sein. Sie können Server-, Kunden- oder Produkt-IDs verwenden, aber nur, wenn Sie eine geringere Anzahl von jedem dieser Typen haben.

Fragen Sie sich als Test, ob Sie solche Daten in einem Diagramm anzeigen würden. Wenn Sie über 10 oder vielleicht sogar 100 Server verfügen, kann es hilfreich sein, sie für den Vergleich alle in einem Diagramm anzuzeigen. Wenn Sie jedoch 1.000 Werte haben, wäre das resultierende Diagramm wahrscheinlich schwierig oder unmöglich zu lesen. Am besten ist es, die Zahl der gültigen Werte auf weniger als 100 zu beschränken. Bis zu 300 ist ein grauer Bereich. Wenn Sie diese Anzahl übergehen müssen, verwenden Sie Azure Monitor benutzerdefinierte Protokolle.

Wenn Sie eine Variable im Namen oder eine Dimension mit hoher Kardinalität haben, können folgende Probleme auftreten:

  • Metriken werden aufgrund der Drosselung unzuverlässig.
  • Der Metrics Explorer funktioniert nicht mehr.
  • Alerting und Benachrichtigungen werden unvorhersehbar.
  • Die Kosten können unerwartet steigen. Microsoft erhebt keine Gebühren für benutzerdefinierte Metriken mit Dimensionen, solange sich diese Funktion in der öffentlichen Vorschau befindet. Wenn jedoch in Zukunft Gebühren anfallen, werden Sie mit unerwarteten Kosten konfrontiert. Es ist geplant, den Verbrauch von Metriken auf der Grundlage der Anzahl der überwachten Zeitreihen und der Anzahl der API-Aufrufe zu berechnen.

Wenn der Metrikname oder Dimensionswert aus Versehen mit einem Bezeichner oder einer Dimension mit hoher Kardinalität aufgefüllt wird, können Sie dies problemlos beheben, indem Sie den Variablenteil entfernen.

Wenn jedoch eine hohe Kardinalität für Ihr Szenario wichtig ist, sind die aggregierten Metriken wahrscheinlich nicht die richtige Wahl. Wechseln Sie zur Verwendung benutzerdefinierter Protokolle (d. h. trackMetric-API-Aufrufe mit trackEvent). Beachten Sie jedoch, dass Protokolle keine Werte aggregieren, weshalb jeder einzelne Eintrag gespeichert wird. Wenn Sie also in einem kleinen Zeitraum über eine große Menge von Protokollen verfügen (z. B. 1 Million pro Sekunde), kann dies zu Drosselung und Erfassungsverzögerungen führen.

Nächste Schritte

Verwenden Sie benutzerdefinierte Metriken aus verschiedenen Diensten: