Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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
Application Insights erfasst und überwacht automatisch Standardmetriken. Diese vordefinierten Metriken decken eine vielzahl von Leistungs- und Nutzungsindikatoren ab, z. B. CPU-Auslastung, Arbeitsspeicherverbrauch, Anforderungsraten und Reaktionszeiten. Sie müssen nichts konfigurieren, um mit der Verwendung zu beginnen. Während der Datenerfassung präaggregiert der Dienst Standardmetriken und speichert sie als Zeitreihe in einem spezialisierten Repository mit nur Schlüsseldimensionen. Dieses Design verbessert die Abfrageleistung. Aufgrund ihrer Geschwindigkeit und Struktur funktionieren Standardmetriken am besten für nahezu Echtzeitwarnungen und reaktionsfähige Dashboards.
Protokollbasierte Metriken
Protokollbasierte Metriken in Application Insights sind ein Abfragezeitkonzept. Das System stellt sie als Zeitreihe dar, die aus den Protokolldaten Ihrer Anwendung erstellt wurde. Die zugrunde liegenden Protokolle werden während der Sammlung oder des Speichers nicht vorab aggregiert. Stattdessen werden alle Eigenschaften jedes Protokolleintrags beibehalten.
Diese Aufbewahrung ermöglicht ihnen die Verwendung von Protokolleigenschaften als Dimensionen beim Abfragen von protokollbasierten Metriken. Sie können metrische Diagrammfilterung und metrische Aufteilung anwenden, wodurch diese Metriken einen starken analytischen und diagnostischen Wert erhalten.
Telemetrie-Verfahren zur Volumenreduzierung wirken sich jedoch auf protokollbasierte Metriken aus. Techniken wie Sampling - und Telemetriefilterung, die häufig verwendet werden, um Daten aus Anwendungen mit hohem Volumen zu reduzieren, verringern die Anzahl der gesammelten Protokolleinträge. Durch diese Reduzierung wird die Genauigkeit protokollbasierter Metriken verringert.
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 einige Application Insights SDKs (Classic API) voraggregieren Metriken während der Datenerfassung, um das Volumen der vom SDK an den Endpunkt des Telemetriekanals 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.
Einige SDKs implementieren keine Voraggregation. Beispiele sind ältere Versionen des Application Insights SDK und browserbasierte Instrumentierung. In diesen Fällen erstellt das Back-End die neuen Metriken, indem die ereignisse aggregiert werden, die über den Telemetriekanal empfangen wurden.
Verwenden Sie die TrackMetric-Methode , um benutzerdefinierte Metriken zu senden.
Diese SDKs verringern nicht die Menge der gesendeten Daten. Sie können jedoch weiterhin die vordefinierten Metriken verwenden, die sie erzeugen. Dieses Setup bietet Ihnen eine bessere Leistung und unterstützt fast die echtzeitdimensionale Benachrichtigung, auch ohne vorab aggregierte Daten während der Erfassung.
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
Das Application Insights Java 2.x SDK wird nicht mehr empfohlen. Verwenden Sie stattdessen das OpenTelemetry-basierte Java-Angebot.
Das OpenCensus Python SDK wurde eingestellt. Wir empfehlen das auf OpenTelemetry basierende Python-Angebot und bieten Migrationsanleitungen.
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
- 1ASP.NET Core-Autoinstrumentierung auf App Service gibt Standardmetriken ohne Dimensionen aus. Manuelle Instrumentierung ist für alle Dimensionen erforderlich.
- 2ASP.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. Manuelle Instrumentierung ist für alle Dimensionen erforderlich.
- 3 Der mit der Autoinstrumentation verwendete Java-Agent erfasst Metriken, die von beliebten Bibliotheken ausgegeben werden, und sendet sie als benutzerdefinierte Metriken an Application Insights.
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.
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?
Application Insights deaktiviert standardmäßig die Sammlung benutzerdefinierter Metrikabmessungen. Das Speichern von benutzerdefinierten Metriken mit Dimensionen verursacht eine separate Abrechnung von Application Insights. Das Speichern nichtdimensionaler benutzerdefinierter Metriken bleibt bis zu einem Kontingent frei. Ausführliche Informationen finden Sie auf der Azure Monitor-Preisseite.
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.
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.
Wenn Sie die Option "Warnung für benutzerdefinierte Metrikabmessungen aktivieren " auswählen, um alle Dimensionen der voraggregierten Metriken im Metrikspeicher zu speichern, kann dies zu erhöhten Gebühren basierend auf benutzerdefinierten Metrikenpreisen führen.
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 reached
ersetzt.Kardinalitätsgrenzwert: Jede Dimension unterstützt eine begrenzte Anzahl eindeutiger Werte innerhalb eines siebentägigen Zeitraums. Wenn der Grenzwert erreicht ist, ersetzt Azure Monitor alle neuen Werte durch die Konstante
Other values
. In den folgenden Tabellen wird die Kardinalitätsgrenze für jede Dimension 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 niedrigste mögliche Wert ist 0, der angibt, dass alle Webtests fehlgeschlagen 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
Das Application Insights JavaScript SDK sammelt Browsermetriken von echten Endbenutzerbrowsern. Diese Metriken geben Ihnen wertvolle Einblicke in die Erfahrung Ihrer Benutzer mit Ihrer Web-App. Das SDK verwendet in der Regel keine Browsermetriken, sodass sie eine höhere Genauigkeit in Verwendungszahlen bieten. Im Gegensatz dazu verwenden serverseitige Metriken häufig Samplings, die ergebnisse verzerren 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)
Der Hostingprozess der überwachten App verbraucht einen Teil der gesamten Prozessorkapazität, und die Metrik zeigt, wie viel sie verwendet.
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 200% die volle Auslastung von zwei CPU-Kernen oder einer halben Auslastung von vier CPU-Kernen usw. darstellen. Die Prozess-CPU Normalized ist eine alternative Metrik, die von vielen SDKs gesammelt wird, die denselben Wert darstellt, teilt sie jedoch durch die Anzahl der verfügbaren CPU-Kerne. 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 zeigt die Anzahl der eingehenden Serveranforderungen an, die Ihre Webanwendung empfängt.
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 für Benutzer nützlich sein, die 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_KEY
nicht 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
Dieses Beispiel zeigt eine KQL-Rückgabe-Anweisung für die Metrik Authenticated Users
. In diesem Beispiel "users/authenticated"
ist die Metrik-ID angegeben.
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)"
}