Freigeben über

Metriken in Application Insights

Application Insights unterstützt drei verschiedene Arten von Metriken: Standard (voraggregiert), protokollbasierte und benutzerdefinierte Metriken. Jeder Metriktyp stellt einen eindeutigen Wert für die Überwachung der Anwendungsintegrität, für die Diagnose und für die Analyse bereit. 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. In diesem Artikel wird der Unterschied zwischen allen unterstützten Metriktypen erläutert.

Standardmetriken

Standardmetriken in Application Insights sind vordefinierte Metriken, die automatisch vom Dienst erfasst und überwacht werden. Diese Metriken decken eine Vielzahl von Leistungs- und Nutzungsindikatoren ab, z. B. CPU-Auslastung, Arbeitsspeicherverbrauch, Anforderungsraten und Reaktionszeiten. Standardmetriken bieten einen umfassenden Überblick über die Integrität und Leistung Ihrer Anwendung, ohne dass eine zusätzliche Konfiguration erforderlich ist. Standardmetriken werden während der Sammlung voraggregiert und als Zeitreihe in einem spezialisierten Repository mit nur Schlüsseldimensionen gespeichert, wodurch sie zur Abfragezeit eine bessere Leistung erzielen. Dies macht Standardmetriken zur besten Wahl für nahezu Echtzeitwarnungen über metrische Dimensionen und reaktionsfähigere Dashboards.

Protokollbasierte Metriken

Protokollbasierte Metriken in Application Insights sind ein Abfragezeitkonzept, das als Zeitreihe über den Protokolldaten Ihrer Anwendung dargestellt wird. Die zugrunde liegenden Protokolle werden nicht zur Sammlungs- oder Speicherzeit voraggregiert und behalten alle Eigenschaften jedes Protokolleintrags bei. Diese Aufbewahrung ermöglicht die Verwendung von Protokolleigenschaften als Dimensionen auf protokollbasierten Metriken zur Abfragezeit für die Metrikdiagrammfilterung und metrikbasierte Aufteilung, sodass logbasierte Metriken einen höheren Analyse- und Diagnosewert haben. Telemetrievolumenreduzierungstechniken wie Sampling und Telemetriefilterung, die häufig bei der Überwachung von Anwendungen verwendet werden und große Telemetriemengen generieren, wirken sich jedoch auf die Anzahl der erfassten Protokolleinträge aus und verringern daher die Genauigkeit protokollbasierter Metriken.

Benutzerdefinierte Metriken (Vorschau)

Mit benutzerdefinierten Metriken in Application Insights können Sie spezifische Messungen definieren und nachverfolgen, die für Ihre Anwendung einzigartig sind. Diese Metriken können durch Instrumentieren Ihres Codes erstellt werden, um benutzerdefinierte Telemetriedaten an Application Insights zu senden. Benutzerdefinierte Metriken bieten die Flexibilität, alle Aspekte Ihrer Anwendung zu überwachen, die nicht von Standardmetriken abgedeckt werden, sodass Sie tiefere Einblicke in das Verhalten und die Leistung Ihrer Anwendung erhalten können.

Weitere Informationen finden Sie in Benutzerdefinierte Metriken in Azure Monitor (Vorschau).

Hinweis

Application Insights bietet auch ein Feature namens Live Metrics-Stream, das eine nahezu echtzeitbasierte Überwachung Ihrer Webanwendungen ermöglicht und keine Telemetriedaten speichert.

Metrikvergleich

Merkmal Standardmetriken Protokollbasierte Metriken Benutzerdefinierte Metriken
Datenquelle Voraggregierte Zeitreihendaten, die während der Laufzeit gesammelt wurden. Abgeleitet von Protokolldaten mithilfe von Kusto-Abfragen. Benutzerdefinierte Metriken, die über das Application Insights SDK oder die API gesammelt werden.
Granularität Feste Intervalle (1 Minute). Hängt von der Granularität der Protokolldaten selbst ab. Flexible Granularität basierend auf benutzerdefinierten Metriken.
Genauigkeit Hoch, nicht von der Protokollprobenentnahme betroffen Kann durch Sampling und Filterung beeinflusst werden. Hohe Genauigkeit, insbesondere bei der Verwendung von voraggregierten Methoden wie GetMetric.
Kosten Im Preis von Application Insights enthalten. Basierend auf Protokolldatenerfassung und Abfragekosten. Siehe Preismodell und Aufbewahrung.
Konfiguration Automatisch mit minimaler Konfiguration verfügbar. Erfordert die Konfiguration von Protokollabfragen, um die gewünschten Metriken aus Protokolldaten zu extrahieren. Erfordert eine benutzerdefinierte Implementierung und Konfiguration im Code.
Abfrageleistung Schnell, dank der vorherigen Aggregation. Langsamer, da es das Abfragen von Protokolldaten umfasst. Hängt von der Komplexität des Datenvolumens und der Abfrage ab.
Speicher Als Zeitreihendaten im Azure Monitor-Metrikspeicher gespeichert. Gespeichert als Protokolle im Log Analytics-Arbeitsbereich. In Log Analytics und im Azure Monitor-Metrikspeicher gespeichert.
Warnungen Unterstützt Echtzeitwarnungen. Ermöglicht komplexe Warnungsszenarien basierend auf detaillierten Protokolldaten. Flexible Warnung basierend auf benutzerdefinierten Metriken.
Dienstgrenzwert Vorbehaltlich der Grenzwerte für Application Insights. Vorbehaltlich der Grenzwerte für Log Analytics-Arbeitsbereich. Begrenzt durch das Kontingent für kostenlose Metriken und die Kosten für zusätzliche Dimensionen.
Anwendungsfälle Echtzeitüberwachung, Leistungsdashboards und schnelle Einblicke. Detaillierte Diagnose, Problembehandlung und eingehende Analyse. Maßgeschneiderte Leistungsindikatoren und geschäftsspezifische Metriken.
Beispiele CPU-Auslastung, Arbeitsspeicherauslastung, Anforderungsdauer. Anforderungsanzahl, Ausnahmeablaufverfolgungen, Abhängigkeitsaufrufe Benutzerdefinierte anwendungsspezifische Metriken wie Benutzerbindung, Featureverwendungen.

Metrikvoraggregation

OpenTelemetry-SDKs und neuere Application Insights-SDKs (Classic API) aggregieren vorab Metriken während der Sammlung, um das Volumen der vom SDK an den Telemetriekanalendpunkt gesendeten Daten zu reduzieren. Dies gilt für Standardmetriken, die standardmäßig gesendet werden, sodass die Genauigkeit nicht durch die Stichprobenentnahme oder eine Filterung beeinträchtigt wird. Es gilt auch für benutzerdefinierte Metriken, die mit der OpenTelemetry-API oder GetMetric und TrackValue gesendet werden, was zu weniger Datenerfassung und niedrigeren Kosten führt. Wenn Ihre Version des Application Insights SDK GetMetric und TrackValue unterstützt, ist dies die bevorzugte Methode zum Senden von benutzerdefinierten Metriken.

Bei SDKs, die keine Voraggregation 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 Telemetriekanalendpunkt von Application Insights empfangen werden. Für benutzerdefinierte Metriken können Sie die TrackMetric-Methode verwenden. 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 Endpunkt des Telemetriekanals aggregiert Ereignisse vor der Stichprobenerfassung. 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.

In den folgenden Tabellen ist aufgeführt, in welcher Voraggregation voraggregiert wird.

Metrikvoraggregation mit Azure Monitor OpenTelemetry Distro

Aktuelles Produktions-SDK Standardmetrikvoraggregation Voraggregation benutzerdefinierter Metriken
ASP.NET Core Softwareentwicklungskit (SDK) SDK über die OpenTelemetry-API
.NET (über Exporter) Softwareentwicklungskit (SDK) SDK über die OpenTelemetry-API
Java (3.x) Softwareentwicklungskit (SDK) SDK über die OpenTelemetry-API
Java Native Softwareentwicklungskit (SDK) SDK über die OpenTelemetry-API
Node.js Softwareentwicklungskit (SDK) SDK über die OpenTelemetry-API
Python Softwareentwicklungskit (SDK) SDK über die OpenTelemetry-API

Metrikvoraggregation mit Application Insights SDK (Classic API)

Aktuelles Produktions-SDK Standardmetrikvoraggregation Voraggregation benutzerdefinierter Metriken
.NET Core und .NET Framework SDK (V2.13.1+) SDK (V2.7.2+) über GetMetric
Telemetriekanalendpunkt über TrackMetric
Java (2.x) Telemetriekanalendpunkt Telemetriekanalendpunkt über TrackMetric
JavaScript (Browser) Telemetriekanalendpunkt Telemetriekanalendpunkt über TrackMetric
Node.js Telemetriekanalendpunkt Telemetriekanalendpunkt über TrackMetric
Python Telemetriekanalendpunkt SDK über OpenCensus.stats (zurückgezogen)
Telemetriekanalendpunkt über TrackMetric

Achtung

Metrikvoraggregation mit automatischer Instrumentierung

Bei der automatischen Instrumentierung wird das SDK automatisch zu Ihrem Anwendungscode hinzugefügt und kann nicht angepasst werden. Für benutzerdefinierte Metriken ist eine manuelle Instrumentierung erforderlich.

Aktuelles Produktions-SDK Standardmetrikvoraggregation Voraggregation benutzerdefinierter Metriken
ASP.NET Core SDK 1 Nicht unterstützt
ASP.NET SDK 2 Nicht unterstützt
Java Softwareentwicklungskit (SDK) Unterstützt 3
Node.js Softwareentwicklungskit (SDK) Nicht unterstützt
Python Softwareentwicklungskit (SDK) Nicht unterstützt

Fußnoten

Benutzerdefinierte Metrikdimensionen und Vorabaggregation

Alle Metriken, die Sie mit den API-Aufrufen OpenTelemetry, trackMetric oder GetMetric und TrackValue senden, werden automatisch in Metrikspeichern und Protokollen 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.

Screenshot: Nutzung und geschätzte Kosten

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 Entdecken von Metriken

Verwenden Sie den Metrik-Explorer von Azure Monitor, um Diagramme aus voraggregierten und protokollbasierten und benutzerdefinierten 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 Metriken wechseln.

Screenshot, der den Metrik-Namespace zeigt.

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 Logs Preisdetails. 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.

Verfügbare Metriken

In den folgenden Abschnitten werden Metriken mit unterstützten Aggregationen und Dimensionen aufgelistet. Zu den Details der protokollbasierten Metriken gehören die zugrunde liegenden Kusto-Abfrageanweisungen.

Wichtig

  • Zeitreihenlimit: Jede Metrik kann nur bis zu 5.000 Zeitreihen innerhalb von 24 Stunden haben. Sobald dieser Grenzwert erreicht ist, werden alle Bemaßungswerte dieses metrischen Punkts durch die Konstante Maximum values reachedersetzt.

  • Kardinalitätsgrenzwert: Jede Dimension kann nur eine bestimmte Anzahl eindeutiger Werte innerhalb von 7 Tagen aufweisen. Sobald dieser Grenzwert erreicht ist, wird der Dimensionswert durch die Konstante Other valuesersetzt. Der Kardinalitätsgrenzwert für jede Dimension wird in den folgenden Tabellen aufgeführt.

Verfügbarkeitsmetriken

Metriken der Kategorie „Verfügbarkeit“ ermöglichen es Ihnen, die Integrität Ihrer Webanwendung so anzuzeigen, wie sie an Punkten auf der ganzen Welt zu beobachten ist. Konfigurieren Sie die Verfügbarkeitstests, damit Sie Metriken aus dieser Kategorie verwenden können.

Verfügbarkeit (availabilityResults/availabilityPercentage)

Die Metrik Verfügbarkeit zeigt den Prozentsatz der Webtestläufe, bei denen keine Probleme erkannt wurden. Der kleinstmögliche Wert ist 0 und gibt an, dass bei allen Webtestläufen Fehler aufgetreten sind. Der Wert 100 bedeutet, dass alle Webtestläufe die Überprüfungskriterien erfüllt haben.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Prozentsatz Durchschnitt Run location availabilityResult/location 50
Test name availabilityResult/name 100

Verfügbarkeitstestdauer (availabilityResults/duration)

Die Metrik Verfügbarkeitstestdauer gibt an, wie lange die Ausführung des Webtests gedauert hat. Bei den mehrstufigen Webtests spiegelt die Metrik die gesamte Ausführungszeit aller Stufen wider.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Millisekunden Avg, Max, Min Run location availabilityResult/location 50
Test name availabilityResult/name 100
Test result availabilityResult/success 2

Verfügbarkeitstests (availabilityResults/count)

Die Metrik Verfügbarkeitstests spiegelt die Anzahl der von Azure Monitor ausgeführten Webtests wider.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Run location availabilityResult/location 50
Test name availabilityResult/name 100
Test result availabilityResult/success 2

Browsermetriken

Browsermetriken werden vom Application Insights JavaScript SDK aus echten Endbenutzerbrowsern gesammelt. Sie bieten nützliche Einblicke in die Erfahrungen der Benutzer mit Ihrer Webanwendung. Für Browsermetriken werden in der Regel keine Stichproben verwendet, was bedeutet, dass sie eine höhere Genauigkeit der Nutzungszahlen bieten als serverseitige Metriken, die durch die Verwendung von Stichproben verzerrt sein können.

Hinweis

Um Browsermetriken zu erfassen, muss Ihre Anwendung mit dem Application Insights JavaScript SDK ausgestattet sein.

Browser-Seitenladezeit (browserTimings/totalDuration)

Maßeinheit Unterstützte Aggregationen Unterstützte Dimensionen
Millisekunden Avg, Max, Min Keine

Clientverarbeitungszeit (browserTiming/processingDuration)

Maßeinheit Unterstützte Aggregationen Unterstützte Dimensionen
Millisekunden Avg, Max, Min Keine

Netzwerkverbindungszeit zum Laden der Seite (browserTimings/networkDuration)

Maßeinheit Unterstützte Aggregationen Unterstützte Dimensionen
Millisekunden Avg, Max, Min Keine

Empfangszeit der Antwort (browserTimings/receiveDuration)

Maßeinheit Unterstützte Aggregationen Unterstützte Dimensionen
Millisekunden Avg, Max, Min Keine

Sendeanforderungszeit (browserTimings/sendDuration)

Maßeinheit Unterstützte Aggregationen Unterstützte Dimensionen
Millisekunden Avg, Max, Min Keine

Fehlermetriken

Die Metriken der Kategorie Fehler zeigen Probleme bei der Verarbeitung von Anforderungen, Abhängigkeitsaufrufen und ausgelösten Ausnahmen.

Browserausnahmen (exceptions/browser)

Diese Metrik spiegelt die Anzahl der von Ihrem Anwendungscode im Browser ausgelösten Ausnahmen wider. Nur Ausnahmen, die mit einem trackException() Application Insights API-Aufruf verfolgt werden, sind in der Metrik enthalten.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role name cloud/roleName 100

Fehler bei Abhängigkeitsaufrufen (dependencies/failed)

Die Anzahl fehlerhafter Abhängigkeitsaufrufe

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Dependency performance dependency/performanceBucket 20
Dependency type dependency/type 100
Is traffic synthetic operation/synthetic 10
Result code dependency/resultCode 100
Target of dependency call dependency/target 100

Ausnahmen (Anzahl der Ausnahmen)

Jedes Mal, wenn Sie eine Ausnahme bei Application Insights protokollieren, erfolgt ein Aufruf der trackException()-Methode des SDK. Die Metrik „Ausnahmen“ zeigt die Anzahl der protokollierten Ausnahmen an.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Device type client/type 2

Fehlerhafte Anforderungen (requests/failed)

Die Anzahl der verfolgten Serveranforderungen, die als fehlgeschlagen markiert wurden. Standardmäßig kennzeichnet das Application Insights SDK automatisch jede Serveranforderung, die HTTP-Antwortcode 5xx oder 4xx (mit Ausnahme von 401) als fehlgeschlagene Anforderung zurückgegeben hat. Sie können diese Logik anpassen, indem Sie die Eigenschaft Erfolg des Anforderungstelemetrieelements in einem benutzerdefinierten Telemetrieinitialisierer ändern. Weitere Informationen zu verschiedenen Antwortcodes finden Sie unter Application Insights-Telemetriedatenmodell.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is synthetic traffic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100

Serverausnahmen (exceptions/server)

Diese Metrik zeigt die Anzahl der Serverausnahmen.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100

Leistungsindikatoren

Verwenden Sie Metriken in der Kategorie Leistungsindikatoren, um auf die von Application Insights erfassten Systemleistungsindikatoren zuzugreifen.

Verfügbarer Speicher (performanceCounters/availableMemory)

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Megabytes / Gigabyte (datenabhängig) Avg, Max, Min Cloud role instance cloud/roleInstance 100

Ausnahmerate (performanceCounters/exceptionRate)

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Avg, Max, Min Cloud role instance cloud/roleInstance 100

Ausführungszeit der HTTP-Anforderung (performanceCounters/requestExecutionTime)

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Millisekunden Avg, Max, Min Cloud role instance cloud/roleInstance 100

HTTP-Anforderungsrate (Leistungsindikatoren/Anfragen pro Sekunde)

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anforderungen pro Sekunde Avg, Max, Min Cloud role instance cloud/roleInstance 100

HTTP-Anforderungen in der Anwendungswarteschlange (performanceCounters/requestsInQueue)

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Avg, Max, Min Cloud role instance cloud/roleInstance 100

Prozess-CPU (performanceCounters/processCpuPercentage)

Die Metrik zeigt, wie viel der gesamten Prozessorleistung von dem Prozess genutzt wird, der Ihre überwachte App hostet.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Prozentsatz Avg, Max, Min Cloud role instance cloud/roleInstance 100

Hinweis

Der Metrikbereich liegt zwischen 0 und 100 * n, wobei n für die Anzahl der verfügbaren CPU-Kerne steht. Beispielsweise kann der Metrikwert von 200 % die vollständige Auslastung von zwei CPU-Kernen oder die halbe Auslastung von 4 CPU-Kernen usw. darstellen. Bei normalisierte Prozess-CPU handelt es sich um eine alternative Metrik, die von vielen SDKs erfasst wird und denselben Wert darstellt, diesen jedoch durch die Anzahl der verfügbaren CPU-Kerne dividiert. Daher liegt der Bereich der Metrik normalisierte Prozess-CPU zwischen 0 und 100.

E/A-Rate des Prozesses (performanceCounters/processIOBytesPerSecond)

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Bytes pro Sekunde Durchschnitt, Minimum, Maximum Cloud role instance cloud/roleInstance 100

Private Bytes des Prozesses (performanceCounters/processPrivateBytes)

Menge des nicht gemeinsam genutzten Arbeitsspeichers, die der überwachte Prozess für seine Daten reserviert hat.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Byte Durchschnitt, Minimum, Maximum Cloud role instance cloud/roleInstance 100

Prozessorzeit (performanceCounters/processorCpuPercentage)

CPU-Auslastung durch alle Prozesse, die auf der überwachten Serverinstanz ausgeführt werden.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Prozentsatz Durchschnitt, Minimum, Maximum Cloud role instance cloud/roleInstance 100

Hinweis

Die Prozessorzeitmetrik ist für die in Azure App Services gehosteten Anwendungen nicht verfügbar. Verwenden Sie die Metrik Prozess-CPU, um die CPU-Auslastung der in App Services gehosteten Webanwendungen nachzuverfolgen.

Servermetriken

Abhängigkeitsaufrufe (dependencies/count)

Diese Metrik bezieht sich auf die Anzahl der Abhängigkeitsaufrufe.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Dependency performance dependency/performanceBucket 20
Dependency type dependency/type 100
Is traffic synthetic operation/synthetic 10
Result code request/resultCode 2
Successful call dependency/success 100
Target of a dependency call dependency/target 100

Dauer der Abhängigkeit (Abhängigkeiten/Dauer)

Diese Metrik bezieht sich auf die Dauer von Abhängigkeitsanrufen.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Millisekunden Avg, Max, Min Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Dependency performance dependency/performanceBucket 20
Dependency type dependency/type 100
Is traffic synthetic operation/synthetic 10
Result code request/resultCode 100
Successful call dependency/success 2
Target of a dependency call dependency/target 100

Serveranforderungsrate (Anfragen/Sekunde)

Diese Metrik spiegelt die Anzahl der eingehenden Serveranforderungen wider, die von Ihrer Webanwendung empfangen wurden.

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl pro Sekunde Durchschnitt Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100
Successful call dependency/success 2

Serveranforderungen (Anfragen/Zählung)

Maßeinheit Aggregationen Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100
Successful call dependency/success 2

Serverreaktionszeit (Anfragen/Dauer)

Diese Metrik spiegelt die Zeit wider, die die Server für die Verarbeitung eingehender Anforderungen benötigt haben.

Millisekunden Avg, Max, Min Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Request performance request/performanceBucket 20
Result code request/resultCode 100
Successful call dependency/success 2

Nutzungsmetriken

Ladezeit der Seitenansicht (pageViews/duration)

Diese Metrik bezieht sich auf die Zeit, die für das Laden von PageView-Ereignissen benötigt wurde.

Millisekunden Avg, Max, Min Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Millisekunden Avg, Max, Min Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10

Seitenaufrufe (pageViews/count)

Die Anzahl der PageView-Ereignisse, die mit der TrackPageView() Application Insights API protokolliert wurden.

Anzahl Anzahl Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Millisekunden Avg, Max, Min Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10

Überwachungen (traces/count)

Die Anzahl der mit dem TrackTrace() Application Insights API-Aufruf protokollierten Überwachungsanweisungen.

Anzahl Anzahl Name der Dimension
(Metrik-Explorer)		 Name der Dimension
(Protokollanalyse)		 Kardinalitätsgrenze
Anzahl Anzahl Cloud role instance cloud/roleInstance 100
Cloud role name cloud/roleName 100
Is traffic synthetic operation/synthetic 10
Severity level trace/severityLevel 100

Benutzerdefinierte Metriken

Gilt nicht für Standardmetriken.

Zugreifen auf protokollbasierte Metriken direkt mit der REST-API für Application Insights

Die Application Insights-REST-API ermöglicht das programmgesteuerte Abrufen von protokollbasierten Metriken. Außerdem enthält sie einen optionalen Parameter ai.include-query-payload, der beim Hinzufügen zu einer Abfragezeichenfolge die API auffordert, nicht nur die Daten der Zeitreihen zurückzugeben, sondern auch die Kusto Query Language (KQL)-Anweisung, die zum Abrufen verwendet wird. Dieser Parameter kann besonders für Benutzer nützlich sein, welche die Verbindung zwischen rohen Ereignissen in Log Analytics und der resultierenden protokollbasierten Metrik verstehen möchten.

Um direkt auf Ihre Daten zuzugreifen, übergeben Sie den Parameter ai.include-query-payload in einer Abfrage mithilfe von KQL an die Application Insights-API.

Hinweis

Zum Abrufen der zugrunde liegende Protokollabfrage müssen DEMO_APP und DEMO_KEYnicht ersetzt werden. Wenn Sie nur die KQL-Anweisung und nicht die Zeitreihendaten Ihrer eigenen Anwendung abrufen möchten, können Sie sie direkt in die Suchleiste ihres Browsers kopieren und einfügen.

api.applicationinsights.io/v1/apps/DEMO_APP/metrics/users/authenticated?api_key=DEMO_KEY&prefer=ai.include-query-payload

Im Folgenden sehen Sie ein Beispiel für eine KQL-Rückgabe-Anweisung für die Metrik Authenticated Users. (In diesem Beispiel ist "users/authenticated" die Metrik-ID.)

output
{
    "value": {
        "start": "2024-06-21T09:14:25.450Z",
        "end": "2024-06-21T21:14:25.450Z",
        "users/authenticated": {
            "unique": 0
        }
    },
    "@ai.query": "union (traces | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (requests | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (pageViews | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (dependencies | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (customEvents | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (availabilityResults | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (exceptions | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (customMetrics | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)), (browserTimings | where timestamp >= datetime(2024-06-21T09:14:25.450Z) and timestamp < datetime(2024-06-21T21:14:25.450Z)) | where notempty(user_AuthenticatedId) | summarize ['users/authenticated_unique'] = dcount(user_AuthenticatedId)"
}

Nächste Schritte