Protokollbasierte und vorab aggregierte Metriken in Application Insights
Hinweis
Die folgende Dokumentation basiert auf der klassischen Application Insights-API. Der langfristige Plan für Application Insights besteht darin, Daten mithilfe von OpenTelemetry zu sammeln. Weitere Informationen finden Sie unter Aktivieren von Azure Monitor OpenTelemetry für .NET-, Node.js-, Python- und Java-Anwendungen und unserer OpenTelemetry Roadmap. Migrationsleitfaden sind für .NET, Node.js und Python verfügbar.
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.
Hinweis
In Application Insights werden die Metriken, die auf der Abfragezeitaggregation von Ereignissen und Messungen basieren, die in Protokollen gespeichert sind, als protokollbasierte Metriken bezeichnet. Diese Metriken umfassen in der Regel viele Dimensionen der Ereigniseigenschaften, wodurch sie sich hervorragend für Analysen eignen. Die Genauigkeit dieser Metriken wird durch Stichproben und Filterung negativ beeinflusst.
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.
Wichtig
Protokollbasierte und vorab aggregierte Metriken können in Azure Application Insights parallel verwendet werden. Zur Unterscheidung der beiden Typen werden die vorab aggregierten Metriken in der Application Insights-Benutzeroberfläche jetzt als Standardmetriken bezeichnet. Die traditionellen Metriken aus den Ereignissen wurden in protokollbasierte Metriken umbenannt.
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)
| Aktuelle Produktions-SDKs | Standardmetriken (SDK-Vorabaggregation) | Benutzerdefinierte Metriken (ohne SDK-Vorabaggregation) | Benutzerdefinierte Metriken (mit SDK-Vorabaggregation) |
|---|---|---|---|
| .NET Core und .NET Framework | Unterstützt (V2.13.1+) | Unterstützt über TrackMetric | Unterstützt (V2.7.2+) über GetMetric |
| Java | Nicht unterstützt | Unterstützt über TrackMetric | Nicht unterstützt |
| Node.js | Unterstützt (V2.0.0+) | Unterstützt über TrackMetric | Nicht unterstützt |
| Python | Nicht unterstützt | Unterstützt | Teilweise unterstützt über OpenCensus.stats |
Hinweis
Die Metrikimplementierung für Python unter Verwendung von OpenCensus.stats unterscheidet sich von GetMetric. Weitere Informationen finden Sie in der Python-Dokumentation zu Metriken.
Tabelle mit vorab aggregierten Metriken (Unterstützung ohne Code)
| Aktuelle Produktions-SDKs | Standardmetriken (SDK-Vorabaggregation) | Benutzerdefinierte Metriken (ohne SDK-Vorabaggregation) | Benutzerdefinierte Metriken (mit SDK-Vorabaggregation) |
|---|---|---|---|
| ASP.NET | Unterstützt 1 | Nicht unterstützt | Nicht unterstützt |
| ASP.NET Core | Unterstützt 2 | Nicht unterstützt | Nicht unterstützt |
| Java | Nicht unterstützt | Nicht unterstützt | Unterstützt |
| Node.js | Nicht unterstützt | Nicht unterstützt | Nicht unterstützt |
- 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.
- 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.
Hinweis
Ein Überschreiten des Kontingents kann unbeabsichtigte Folgen haben. Azure Monitor könnte in Ihrem Abonnement oder Ihrer Region unzuverlässig werden. Um zu lernen, wie Sie ein Überschreiten des Kontingents vermeiden können, siehe Design-Einschränkungen und Überlegungen.
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.