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 die beste Wahl für nahezu Echtzeitwarnungen in Dimensionen von Metriken und reaktionsfähigeren 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.
Application Insights bietet auch ein Feature namens Live Metrics-Stream, das eine nahezu echtzeitbasierte Überwachung Ihrer Webanwendungen ermöglicht und keine Telemetriedaten speichert.
Metrikvergleich
Funktion
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 Protokoll-Sampling 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.
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 Telemetriekanalendpunkt voraggregiert 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.
In den folgenden Tabellen ist aufgeführt, in welcher Voraggregation voraggregiert wird.
Metrikvoraggregation mit Azure Monitor OpenTelemetry Distro
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.
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.
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.
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.
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.
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. Zur Vereinfachung verwendet jede Abfrage Standardwerte für Zeitgranularität, Diagrammtyp und manchmal auch Teilungsdimensionen, was die Verwendung der Abfrage in Log Analytics vereinfacht, ohne dass Änderungen erforderlich sind.
Wenn Sie die gleiche Metrik im Metrik-Explorer darstellen, gibt es keine Standardwerte – die Abfrage wird dynamisch entsprechend Ihren Diagrammeinstellungen angepasst:
Der ausgewählte Zeitbereich wird in eine zusätzliche where timestamp...-Klausel übersetzt, um nur die Ereignisse aus dem ausgewählten Zeitbereich auszuwählen. Beispielsweise enthält ein Diagramm, in dem Daten der letzten 24 Stunden angezeigt werden, die Abfrage | where timestamp > ago(24 h).
Die ausgewählte Zeitgranularität wird in die endgültige summarize ... by bin(timestamp, [time grain])-Klausel eingefügt.
Alle ausgewählten Filter-Dimensionen werden in zusätzliche where-Klauseln übersetzt.
Die ausgewählte Teilungsdiagramm-Dimension wird in eine zusätzliche Zusammenfassungseigenschaft übersetzt. Wenn Sie ihr Diagramm z. B. nach location teilen und mit einer Granularität von 5 Minuten darstellen, wird die summarize-Klausel zusammengefasst ... by bin(timestamp, 5 m), location.
Hinweis
Wenn Sie noch nicht mit der Kusto-Abfragesprache vertraut sind, müssen Sie zunächst die Kusto-Anweisungen kopieren und in den Log Analytics-Abfragebereich einfügen, ohne Änderungen vorzunehmen. Klicken Sie auf Ausführen, um das grundlegende Diagramm anzuzeigen. Wenn Sie mit der Syntax der Abfragesprache vertraut sind, können Sie damit beginnen, kleine Änderungen vorzunehmen und die Auswirkung Ihrer Änderung anzuzeigen. Das Untersuchen Ihrer eigenen Daten ist eine gute Möglichkeit, um die volle Leistungsfähigkeit von Log Analytics und Azure Monitor zu erkennen.
Wichtig
Wenn mehrere Aggregationen unterstützt werden, wird für die folgenden protokollbasierten Metriken die Aggregation kursiv im Kusto-Abfragebeispiel verwendet.
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.
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.
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.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Millisekunden
Avg, Max, Min
Run location, Test name, Test result
Verfügbarkeitstests (availabilityResults/count)
Die Metrik Verfügbarkeitstests spiegelt die Anzahl der von Azure Monitor ausgeführten Webtests wider.
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.
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.
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.
Zeit zwischen dem Empfang des letzten Byte eines Dokuments und dem Laden des DOM. Asynchrone Anforderungen werden möglicherweise immer noch verarbeitet.
Diese Metrik spiegelt die Anzahl der ausgelösten Ausnahmen von Ihrem Anwendungscode im Browser wider. Nur Ausnahmen, die mit einem trackException() Application Insights API-Aufruf verfolgt werden, sind in der Metrik enthalten.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Anzahl
Cloud role name
Fehler bei Abhängigkeitsaufrufen (dependencies/failed)
Die Anzahl fehlerhafter Abhängigkeitsaufrufe.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Anzahl
Cloud role instance, Cloud role name, Dependency performance, Dependency type, Is traffic synthetic, Result code, Target of dependency call
Ausnahmen (exceptions/count)
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.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Anzahl
Cloud role instance, Cloud role name, Device type
Fehlerhafte Anforderungen (requests/failed)
Die Anzahl der verfolgten Serveranforderungen, die als fehlgeschlagen markiert wurden. Standardmäßig markiert das Application Insights SDK automatisch jede Serveranforderung, die den HTTP-Antwortcode 5xx oder 4xx zurückgegeben hat, als fehlerhafte Anforderung. Sie können diese Logik anpassen, indem Sie die Eigenschaft Erfolg des Anforderungstelemetrieelements in einem benutzerdefinierten Telemetrieinitialisierer ändern.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Anzahl
Cloud role instance, Cloud role name, Is synthetic traffic, Request performance, Result code
Serverausnahmen (exceptions/server)
Diese Metrik zeigt die Anzahl der Serverausnahmen.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Anzahl
Cloud role instance, Cloud role name
Browserausnahmen (exceptions/browser)
Diese Metrik spiegelt die Anzahl der ausgelösten Ausnahmen von Ihrem Anwendungscode im Browser wider. Nur Ausnahmen, die mit einem trackException() Application Insights API-Aufruf verfolgt werden, sind in der Metrik enthalten.
Hinweis
Bei Verwendung des Samplings gibt itemCount an, wie viele Telemetrieelemente einen einzelnen Protokolldatensatz darstellen. Bei einem Sampling von 25 % stellt jeder Protokolldatensatz beispielsweise 4 Elemente dar (1 gehalten + 3 abgesampelt). Protokollbasierte Abfragen summieren alle itemCount-Werte, um sicherzustellen, dass die Metrik die Gesamtanzahl der tatsächlichen Ereignisse und nicht nur die Anzahl der gespeicherten Protokolldatensätze widerspiegelt.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Summe
Alle Telemetriefelder
exceptions
| where client_Type == 'Browser'
| summarize ['exceptions/browser_sum'] = sum(itemCount) by bin(timestamp, 15m)
| render barchart
Fehler bei Abhängigkeitsaufrufen (dependencies/failed)
Die Anzahl fehlerhafter Abhängigkeitsaufrufe.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Summe
Alle Telemetriefelder
dependencies
| where success == 'False'
| summarize ['dependencies/failed_sum'] = sum(itemCount) by bin(timestamp, 15m)
| render barchart
Ausnahmen (exceptions/count)
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.
Die Anzahl der verfolgten Serveranforderungen, die als fehlgeschlagen markiert wurden. Standardmäßig markiert das Application Insights SDK automatisch jede Serveranforderung, die den HTTP-Antwortcode 5xx oder 4xx zurückgegeben hat, als fehlerhafte Anforderung. Sie können diese Logik anpassen, indem Sie die Eigenschaft Erfolg des Anforderungstelemetrieelements in einem benutzerdefinierten Telemetrieinitialisierer ändern.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Summe
Alle Telemetriefelder
requests
| where success == 'False'
| summarize ['requests/failed_sum'] = sum(itemCount) by bin(timestamp, 15m)
| render barchart
Serverausnahmen (exceptions/server)
Diese Metrik zeigt die Anzahl der Serverausnahmen.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Summe
Alle Telemetriefelder
exceptions
| where client_Type != 'Browser'
| summarize ['exceptions/server_sum'] = sum(itemCount) by bin(timestamp, 15m)
| render barchart
Die Metrik zeigt, wie viel der gesamten Prozessorleistung von dem Prozess genutzt wird, der Ihre überwachte App hostet.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Prozentsatz
Avg, Max, Min
Cloud role instance
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)
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Bytes pro Sekunde
Durchschnitt, Minimum, Maximum
Cloud role instance
Private Bytes des Prozesses (performanceCounters/processPrivateBytes)
Menge des nicht gemeinsam genutzten Arbeitsspeichers, die der überwachte Prozess für seine Daten reserviert hat.
CPU-Auslastung durch alle Prozesse, die auf der überwachten Serverinstanz ausgeführt werden.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Prozentwert
Durchschnitt, Minimum, Maximum
Cloud role instance
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.
Ausführungszeit der ASP.NET-Anforderung (performanceCounters/requestExecutionTime)
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Millisekunden
Durchschnitt, Min, Max
Alle Telemetriefelder
performanceCounters
| where ((category == "ASP.NET Applications" and counter == "Request Execution Time") or name == "requestExecutionTime")
| extend performanceCounter_value = iif(itemType == 'performanceCounter', value, todouble(''))
| summarize ['performanceCounters/requestExecutionTime_avg'] = sum(performanceCounter_value) / count() by bin(timestamp, 15m)
| render barchart
Die Metrik zeigt, wie viel der gesamten Prozessorleistung von dem Prozess genutzt wird, der Ihre überwachte App hostet.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Prozentsatz
Durchschnitt, Min, Max
Alle Telemetriefelder
performanceCounters
| where ((category == "Process" and counter == "% Processor Time Normalized") or name == "processCpuPercentage")
| extend performanceCounter_value = iif(itemType == 'performanceCounter', value, todouble(''))
| summarize ['performanceCounters/processCpuPercentage_avg'] = sum(performanceCounter_value) / count() by bin(timestamp, 15m)
| render timechart
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.
CPU-Auslastung durch alle Prozesse, die auf der überwachten Serverinstanz ausgeführt werden.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Prozentsatz
Durchschnitt, Min, Max
Alle Telemetriefelder
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.
performanceCounters
| where ((category == "Processor" and counter == "% Processor Time") or name == "processorCpuPercentage")
| extend performanceCounter_value = iif(itemType == 'performanceCounter', value, todouble(''))
| summarize ['performanceCounters/processorCpuPercentage_avg'] = sum(performanceCounter_value) / count() by bin(timestamp, 15m)
| render timechart
Diese Metrik bezieht sich auf die Anzahl der Abhängigkeitsaufrufe.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Anzahl
Cloud role instance, Cloud role name, Dependency performance, Dependency type, Is traffic synthetic, Result code, Successful call, Target of a dependency call
Dauer der Abhängigkeit (dependencies/duration)
Diese Metrik bezieht sich auf die Dauer von Abhängigkeitsaufrufen.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Millisekunden
Avg, Max, Min
Cloud role instance, Cloud role name, Dependency performance, Dependency type, Is traffic synthetic, Result code, Successful call, Target of a dependency call
Serveranforderungsrate (Anforderungen/Rate)
Diese Metrik spiegelt die Anzahl der eingehenden Serveranforderungen wider, die von Ihrer Webanwendung empfangen wurden.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl pro Sekunde
Avg
Cloud role instance, Cloud role name, Is traffic synthetic, Request performanceResult code, Successful request
Serveranforderungen (requests/count)
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Anzahl
Anzahl
Cloud role instance, Cloud role name, Is traffic synthetic, Request performanceResult code, Successful request
Serverantwortzeit (requests/duration)
Diese Metrik spiegelt die Zeit wider, die die Server für die Verarbeitung eingehender Anforderungen benötigt haben.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Millisekunden
Avg, Max, Min
Cloud role instance, Cloud role name, Is traffic synthetic, Request performanceResult code, Successful request
Abhängigkeitsaufrufe (dependencies/count)
Diese Metrik bezieht sich auf die Anzahl der Abhängigkeitsaufrufe.
Die Anzahl der unterschiedlichen Benutzer, die auf Ihre Anwendung zugegriffen haben. Die Genauigkeit dieser Metrik kann durch die Verwendung von Telemetriestichproben und Filtern erheblich beeinträchtigt werden.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Count
Eindeutig
Alle Telemetriefelder
union traces, requests, pageViews, dependencies, customEvents, availabilityResults, exceptions, customMetrics, browserTimings
| where notempty(user_Id)
| summarize ['users/count_unique'] = dcount(user_Id) by bin(timestamp, 15m)
| render barchart
Benutzer, Authentifiziert (users/authenticated)
Die Anzahl der unterschiedlichen Benutzer, die sich bei Ihrer Anwendung authentifiziert haben.
Unit of measure
Unterstützte Aggregationen
Unterstützte Dimensionen
Count
Eindeutig
Alle Telemetriefelder
union traces, requests, pageViews, dependencies, customEvents, availabilityResults, exceptions, customMetrics, browserTimings
| where notempty(user_AuthenticatedId)
| summarize ['users/authenticated_unique'] = dcount(user_AuthenticatedId) by bin(timestamp, 15m)
| render barchart
Benutzerdefinierte Metriken werden sowohl im Metrikspeicher als auch in Protokollen gespeichert, sodass sie mithilfe von Kusto-Abfragen abgerufen werden können.
Wenn Sie Ihre Anwendung beispielsweise mit _telemetryClient.GetMetric("Sales Amount").TrackValue(saleAmount);GetMetric und TrackValue zum Nachverfolgen der benutzerdefinierten Metrik Umsatzbetrag instrumentieren, können Sie die folgenden Kusto-Abfragen für jede verfügbare Aggregation verwenden.
Durchschnitt (avg)
customMetrics
| where name == "Sales Amount"
| extend
customMetric_valueSum = iif(itemType == 'customMetric', valueSum, todouble('')),
customMetric_valueCount = iif(itemType == 'customMetric', valueCount, toint(''))
| summarize ['customMetrics/Sales Amount_avg'] = sum(customMetric_valueSum) / sum(customMetric_valueCount) by bin(timestamp, 15m)
| order by timestamp desc
| render timechart
Minimum (min)
customMetrics
| where name == "Sales Amount"
| extend customMetric_valueMin = iif(itemType == 'customMetric', valueMin, todouble(''))
| summarize ['customMetrics/Sales Amount_min'] = min(customMetric_valueMin) by bin(timestamp, 15m)
| render timechart
Maximum (max)
customMetrics
| where name == "Sales Amount"
| extend customMetric_valueMax = iif(itemType == 'customMetric', valueMax, todouble(''))
| summarize ['customMetrics/Sales Amount_max'] = max(customMetric_valueMax) by bin(timestamp, 15m)
| render timechart
Summe (sum)
customMetrics
| where name == "Sales Amount"
| extend customMetric_valueSum = iif(itemType == 'customMetric', valueSum, todouble(''))
| summarize ['customMetrics/Sales Amount_sum'] = sum(customMetric_valueSum) by bin(timestamp, 15m)
| render barchart
Anzahl (count)
customMetrics
| where name == "Sales Amount"
| extend customMetric_valueCount = iif(itemType == 'customMetric', valueCount, toint(''))
| summarize ['customMetrics/Sales Amount_count'] = sum(customMetric_valueCount) by bin(timestamp, 15m)
| render barchart
Eindeutig (unique)
customMetrics
| where name == "Sales Amount"
| extend customMetric_value = iif(itemType == 'customMetric', value, todouble(''))
| summarize ['customMetrics/Sales Amount_unique'] = dcount(customMetric_value) by bin(timestamp, 15m)
| render barchart
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
Um die zugrunde liegende Protokollabfrage abzurufen 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.
Nachfolgend sehen Sie ein Beispiel für eine KQL-Rückgabe-Anweisung für die Metrik „Authentifizierte Benutzer“. (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)"
}
