Protokollbasierte und vorab aggregierte Metriken in Application Insights

Dieser Artikel erläutert den Unterschied zwischen „traditionellen“ Application Insights-Metriken, die auf Protokollen basieren, und vorab aggregierten Metriken. Beide Arten von Metriken stehen den Benutzern von Application Insights zur Verfügung. Jeder Metriktyp stellt einen eindeutigen Wert für die Überwachung der Anwendungsintegrität, für die Diagnose und für die Analyse bereit. Die Entwickler können bei der Instrumentierung von Anwendungen entscheiden, welche Art von Metrik für ein bestimmtes Szenario am besten geeignet ist. Die Entscheidungen basieren auf der Anwendungsgröße, dem erwarteten Telemetriedatenvolumen und den geschäftlichen Anforderungen an die Genauigkeit der Metriken und Warnmeldungen.

Protokollbasierte Metriken

In der Vergangenheit basierte das Telemetriedatenmodell für die Anwendungsüberwachung in Application Insights ausschließlich auf einer kleinen Anzahl von vordefinierten Ereignistypen, darunter Anforderungen, Ausnahmen, Abhängigkeitsaufrufe und Seitenaufrufe. Entwickler können diese Ereignisse mithilfe des SDK manuell ausgeben, indem sie Code schreiben, der das SDK explizit aufruft. Alternativ können Sie sich auf die automatische Erfassung von Ereignissen durch die automatische Instrumentierung verlassen. In beiden Fällen speichert das Application Insights-Back-End alle erfassten Ereignisse als Protokolle. Die Application Insights-Bereiche im Azure-Portal fungieren als Analyse- und Diagnosetool zur Visualisierung ereignisbasierter Daten aus Protokollen.

Die Verwendung von Protokollen zur Erhaltung eines vollständigen Satzes von Ereignissen kann einen großen analytischen und diagnostischen Wert darstellen. So können Sie beispielsweise eine genaue Anzahl von Anforderungen an eine bestimmte URL mit der Anzahl der verschiedenen Benutzer abrufen, die diese Aufrufe getätigt haben. Oder Sie können detaillierte Diagnoseablaufverfolgungsdaten, einschließlich Ausnahmen und Aufrufe von Abhängigkeiten für jede Benutzersitzung abrufen. Mit dieser Art von Informationen können Sie sich einen besseren Überblick über die Integrität und Nutzung der Anwendung verschaffen. Außerdem kann so die benötigte Zeit zur Diagnose von Problemen mit einer App verkürzt werden.

Gleichzeitig kann es für Anwendungen, die eine große Menge an Telemetriedaten erzeugen, unzweckmäßig oder sogar unmöglich sein, einen vollständigen Satz von Ereignissen zu erfassen. Für Situationen, in denen die Menge der Ereignisse zu groß ist, implementiert Application Insights verschiedene Techniken zur Verringerung des Telemetriedatenvolumens, indem die Anzahl der erfassten und gespeicherten Ereignisse reduziert wird. Zu diesen Techniken gehören die Stichprobenerstellung und die Filterung. Leider senkt die Verringerung der Anzahl gespeicherter Ereignisse auch die Genauigkeit der Metriken, die hinter den Kulissen Abfragezeitaggregationen der in Protokollen gespeicherten Ereignisse durchführen müssen.

Voraggregierte Metriken

Zusätzlich zu den protokollbasierten Metriken hat das Application Insights-Team Ende 2018 eine öffentliche Vorschau von Metriken veröffentlicht, die in einem speziellen, für Zeitreihen optimierten Repository gespeichert sind. Die neuen Metriken werden nicht mehr als einzelne Ereignisse mit vielen Eigenschaften, Stattdessen werden sie als vorab aggregierte Zeitreihen gespeichert, die nur die wichtigsten Dimensionen enthalten. Dadurch sind die neuen Metriken hinsichtlich der Abfragezeit überlegen: Der Abruf von Daten erfolgt schneller und erfordert weniger Computeleistung. Dies ermöglicht neue Szenarien wie etwa Warnungen zu Metrikdimensionen in Quasi-Echtzeit und reaktionsfähigere Dashboards.

Die neueren SDKs (SDK Application Insights 2.7 oder höher für .NET) aggregieren die Metriken während der Auflistung vorab. Dies gilt für Standardmetriken, die standardmäßig gesendet werden, sodass die Genauigkeit nicht durch die Stichprobenentnahme oder eine Filterung beeinträchtigt wird. Dies gilt auch für benutzerdefinierte Metriken, die mit GetMetric gesendet werden, was zu einer geringeren Datenerfassung und geringeren Kosten führt.

Bei SDKs, die keine Vorabaggregation implementieren (d. h. ältere Versionen von Application Insights SDKs oder SDKs zur Browserinstrumentierung), füllt das Application Insights-Back-End weiterhin die neuen Metriken auf, indem es die Ereignisse aggregiert, die vom Application Insights-Endpunkt zur Ereignissammlung empfangen werden. Sie profitieren zwar nicht von dem reduzierten Datenvolumen, das über die Leitung übertragen wird, können die vorab aggregierten Metriken aber dennoch mit SDKs nutzen, die Metriken während der Erfassung nicht vorab aggregieren. Auf diese Weise erzielen Sie eine bessere Leistung und Unterstützung für dimensionsbezogene Warnungen in Quasi-Echtzeit.

Der Sammlungsendpunkt aggregiert Ereignisse vor der Erfassungs-Stichprobenerstellung. Aus diesem Grund beeinträchtigt die Erfassungs-Stichprobenerstellung niemals die Genauigkeit von vorab aggregierten Metriken – unabhängig davon, welche SDK-Version Sie mit Ihrer Anwendung verwenden.

Tabelle mit vorab aggregierten Metriken (mit SDK-Unterstützung)

Tabelle mit vorab aggregierten Metriken (Unterstützung ohne Code)

1. ASP.NET automatische Instrumentierung auf virtuellen Computern/vm-Skalierungssätzen und lokalen Standardmetriken ohne Dimensionen ausgibt. Dies gilt auch für Azure App Service, allerdings muss die Sammlungsebene auf „Empfohlen“ festgelegt werden. Das SDK ist für alle Dimensionen erforderlich.
2. ASP.NET Core-Autoinstrumentierung on App Service gibt Standardmetriken ohne Dimensionen aus. Ein SDK ist für alle Dimensionen erforderlich.

Verwenden der Vorabaggregation mit benutzerdefinierten Application Insights-Metriken

Sie können die Vorabaggregation mit benutzerdefinierten Metriken verwenden. Die beiden Hauptvorteile sind:

• Konfigurieren und Benachrichtigen für eine Dimension einer benutzerdefinierten Metrik
• Reduzieren der Datenmenge, die vom SDK an den Application Insights-Sammlungsendpunkt gesendet wird

Es gibt mehrere Möglichkeiten zum Senden benutzerdefinierter Metriken aus dem Application Insights SDK. Wenn Ihre SDK-Version GetMetric und TrackValue bereitstellt, sind dies die bevorzugten Methoden zum Senden von benutzerdefinierten Metriken. In diesem Fall erfolgt die Vorabaggregation innerhalb des SDK. Dieser Ansatz verringert die in Azure gespeicherte Datenmenge und auch das Volumen der vom SDK an Application Insights übertragenen Daten. Andernfalls verwenden Sie die Methode trackMetric, die Metrikereignisse während der Datenerfassung vorab aggregiert.

Benutzerdefinierte Metrikdimensionen und Vorabaggregation

Alle Metriken, die Sie mit den API-Aufrufen OpenTelemetry, trackMetric oder GetMetric und TrackValue senden, werden automatisch in Protokollen und Metrikspeichern gespeichert. Diese Metriken finden Sie in der Tabelle „customMetrics“ in Application Insights und im Metrik-Explorer unter dem benutzerdefinierten metrischen Namespace mit dem Namen „azure.applicationinsights“. Obwohl die protokollbasierte Version Ihrer benutzerdefinierten Metrik immer alle Dimensionen beibehält, wird die vorab aggregierte Version der Metrik standardmäßig ohne Dimensionen gespeichert. Die Beibehaltung von Dimensionen für benutzerdefinierte Metriken ist eine Previewfunktion, die auf der Registerkarte Nutzung und geschätzte Kosten durch Auswahl von Mit Dimensionen unter Benutzerdefinierte Metriken an den Azure Metrikspeicher senden aktiviert werden kann.

Kontingente

Vorab aggregierte Metriken werden als Zeitreihen in Azure Monitor gespeichert. Es gelten die Azure Monitor-Kontingente für benutzerdefinierte Metriken.

Warum ist die Sammlung benutzerdefinierter Metrikdimensionen standardmäßig deaktiviert?

Die Erfassung von benutzerdefinierten Metrikdimensionen ist standardmäßig deaktiviert, da in Zukunft die Speicherung von benutzerdefinierten Metriken mit Dimensionen getrennt von Application Insights abgerechnet wird. Die Speicherung der benutzerdefinierten Metriken ohne Dimensionen bleibt (bis zu einem bestimmten Kontingent) kostenfrei. Weitere Informationen zu den bevorstehenden Änderungen des Preismodells finden Sie auf unserer offiziellen Seite mit der Preisübersicht.

Erstellen von Diagrammen und Erkunden von protokollbasierten und vorab aggregierten Standardmetriken

Verwenden Sie den Metrik-Explorer von Azure Monitor, um Diagramme aus vorab aggregierten und protokollbasierten Metriken darzustellen, und um Dashboards mit Diagrammen zu erstellen. Nachdem Sie die gewünschte Application Insights-Ressource ausgewählt haben, können Sie mit der Namespaceauswahl zwischen Standard- und protokollbasierten Metriken wechseln. Sie können auch einen benutzerdefinierten Metriknamespace auswählen.

Preismodelle für Application Insights-Metriken

Die Erfassung von Metriken in Application Insights – unabhängig davon, ob diese protokollbasiert oder vorab aggregiert erfolgt – erzeugt Kosten. Diese Kosten hängen vom Umfang der erfassten Daten ab. Weitere Informationen finden Sie unter Azure Monitor-Protokolle: Preise. Ihre benutzerdefinierten Metriken, einschließlich aller Dimensionen, werden immer im Application Insights-Protokollspeicher gespeichert. Darüber hinaus wird standardmäßig eine vorab aggregierte Version Ihrer Standardmetriken (ohne Dimensionen) an den Metrikspeicher weitergeleitet.

Die Auswahl der Option Dimensionswarnungen für benutzerdefinierte Metriken aktivieren zum Speichern aller Dimensionen vorab aggregierter Metriken im Metrikspeicher kann zusätzliche Kosten basierend auf den Preisen für benutzerdefinierte Metriken verursachen.

Nächste Schritte

• Metriken – Get – REST-API
• Application Insights-API für benutzerdefinierte Ereignisse und Metriken
• Warnungen in Quasi-Echtzeit
• GetMetric und TrackValue