15. Jun 2020
Lesedauer 12 Min.
Azure-Monitoring
Azure Monitor, Application Insights, Log Analytics
Webservices, Apps und Systeme überwachen.

Dieser Beitrag will in Form einer Anleitung mit vielen Screenshots zeigen, welche Möglichkeiten Microsoft Azure bietet, wichtige Daten Ihrer Webservices, Apps und Systeme zu überwachen. Anhand von zwei simplen Beispielen erhalten Sie einen tiefen Einblick in Azure Application Insights und Log Analytics.Um Missverständnissen vorzubeugen, muss vorweg erwähnt werden, dass Microsoft im Jahr 2018 mehrere existierende Monitoring-Services umbenannt und unter dem Oberbegriff Azure Monitor zusammengeführt hat. Im April 2018 wurde zudem die Operations Management Suite (OMS) eingestellt, folgende Services sind nun Teil von Azure Monitor:
- Application Insights
- Azure Automation
- Azure Backup
- Log Analytics – der Service heißt nun Azure Monitor Logs, das Tool weiterhin Log Analytics und der Speicherdienst Log Analytics Workspace.
- Site Recovery
- Management Solutions heißt jetzt Monitoring Solutions.
Azure Monitor
Azure Monitor [1] ist Microsofts zentrale Monitoring-Plattform (Bild 1). Sie kann Daten (Metriken oder Logs) aus unterschiedlichen Quellen empfangen (Applikationen, Betriebssysteme, Azure-Ressourcen/-Abonnements/-Mandanten), diese Daten werden gespeichert (Workspaces) und können mit diversen Services/Tools verarbeitet und visualisiert werden. Über das Azure-Monitor-Hauptportal haben Sie Zugriff auf alle Tools und Quellen.
Azure Monitorim Überblick(Bild 1)
Autor
Services/Apps versenden Daten entweder als Metrik oder Logs an Azure. Metriken sind numerische Werte, welche einen bestimmten Aspekt des Systems zu einem Zeitpunkt widerspiegeln (zum Beispiel die CPU-Last). Die Daten werden in regulären Intervallen erhoben, sind sehr leichtgewichtig und eignen sich daher zur Near-Realtime-Überwachung eines Systems.Logs sind strukturierte Einträge, die meist nicht regelmäßig, sondern auf Basis eines Ereignisses erhoben werden. Log-Einträge können sich voneinander unterscheiden und enthalten numerische Werte und/oder Textdaten. Logs bieten sich für komplexere Analysen an, da sie kontextspezifische Informationen eines Service enthalten können (Fehler, Start- und Endzeitpunkt eines Prozesses).
Application Insights
Application Insights ist ein Application Performance Management (APM)-Service, mit dem Webanwendungen an Azure Monitor angebunden und somit relevante Daten überwacht und analysiert werden können [2]. Dafür wird die Applikation mithilfe eines SDK instrumentiert. Folgende Plattformen werden dabei unterstützt: ASP.NET, ASP.NET Core, Java, Mobile, Node.js, JavaScript sowie mobile Apps (iOS, Android, Xamarin, Universal Windows und React Native) durch eine App-Center-Anbindung.Die SDKs versenden die erhobenen Daten an Azure. Im Portal der zugehörigen Application-Insights-Ressource können diese dann visualisiert und analysiert werden. Die Application-Insights-Ressource kann beim Hinzufügen des SDK zum Visual-Studio-Projekt automatisch angelegt werden, manuell im Azure-Portal oder automatisiert durch PowerShell- sowie Azure-CLI-Skripten. Folgende Metriken und Daten sind dabei verfügbar (Standard):- Request Rates, Response Times, Failure Rates
- Dependency Rates, Response Times, Failure Rates
- Exceptions
- Page Views, Load Performance
- AJAX Calls
- User Counts, Session Counts
- Metriken der Systemumgebung (Performance Counters, Docker/Azure Diagnostics)
- Trace Logs

Application Insightsim Überblick(Bild 2)
Autor
Das Application-Insights-Portal bietet viele Funktionen, um die empfangenen Daten zu verarbeiten: Es ermöglicht, Warnungen zu konfigurieren, Anfragen mittels Profiler zu analysieren und nach konkreten Event-Instanzen zu suchen (Diagnostic Search).Sie können die verfügbaren Daten entweder im Dashboard als Diagramme in einer Kachelstruktur visualisieren lassen – wie es in Bild 3 gezeigt wird – oder definierte Anfragen nach Power BI [3] exportieren und von dort aus ausführen und visualisieren, siehe Bild 4.

AzureDashboard(Bild 3)
Autor

Power BIDashboard(Bild 4)
Autor
Die Ansicht Live Metrics Stream [4] zeigt Metriken in Echtzeit an. Damit ist es einfach, die wichtigsten KPIs einer Applikation auf einen Blick zu erfassen oder zum Beispiel die Performance bei Bugfixing oder Load-Tests zu beobachten. Diese Livedaten sind jedoch sehr kurzlebig (Zeitrahmen der Visualisierung) und erlauben keine Abfragen.Zusätzlich müssen folgende Beschränkungen bezüglich der im Live Metrics Stream sichtbaren Leistungsindikatoren (Performance Counter) berücksichtigt werden: ASP.NET- und ASP.NET-Core-Applikationen, die in Azure Web Apps laufen, haben nur Zugriff auf eine Untermenge der Indikatoren, die über spezielle Umgebungsvariablen freigegeben sind.Für ASP.NET Core sind die Leistungsindikatoren noch weiter eingeschränkt – abhängig von SDK-Version, Laufzeitplattform (Azure Web Apps oder Windows) und Ziel-Framework (ab .NET Standard 2.0).ASP.NET-Core-Applikationen mit .NET als Ziel-Framework stehen allerdings unabhängig von der SDK-Version alle Leistungsindikatoren zur Verfügung.Für komplexere Analysen eignen sich der Metrics Explorer [5] oder Log Analytics [6] besser, da die Daten dort 90 Tage lang (Standard) aufbewahrt werden – insgesamt sind bis zu 730 Tage möglich, per Storage Account sogar noch mehr. Der Metrics Explorer erlaubt es Ihnen, Metriken für definierbare Zeiträume anzuzeigen und das Diagramm per Filter zu konfigurieren.Log Analytics ermöglicht die Analyse der Log-Daten einer Applikation: Mit dem Kusto-Service [7] und dessen Abfragesprache können Sie komplexe Zusammenhänge ermitteln. Das Resultat lässt sich in einem Diagramm visualisieren oder kann als Anlass genommen werden, weitere Prozesse zu starten, zum Beispiel per Automation Runbooks [8] oder Microsoft Flow.Dank eines REST API [9] sind auch externe Systeme, wie etwa Nagios oder Icinga, in der Lage, auf die in Application Insights vorhandenen Daten zuzugreifen – mehr dazu erfahren Sie im weiteren Verlauf dieses Artikels.Mit Visual Studio lässt sich Application Insights sehr einfach in ASP.NET- oder ASP.NET-Core-Applikationen installieren. Ähnliches gilt für die Integration von Application Insights in eine Azure-DevOps-Release-Pipeline oder die Verbindung per Connector [10] mit einem IT-Service-Management-Produkt oder -Service.
Ein einfaches Beispiel
Anhand eines simplen Beispiels soll nun gezeigt werden, wie Sie Application Insights einrichten und wie schnell Sie erste Daten damit erheben können. Dafür wurde eine kleine ASP.NET-Webanwendung erstellt, die den Service eines Telefonanbieters simuliert und mehrere REST-Methoden für Testzwecke anbietet, zum Beispiel die Verwaltung einer Favoriten-Liste. Innerhalb der Methoden wird Thread.Sleep verwendet, um eine zufällige Zeitspanne für die Response-Time zu simulieren. Veröffentlicht wurde die Beispielanwendung auf einem lokalen IIS-Server.In Visual Studio wird Application Insights beim Erstellen eines neuen ASP.NET-Projekts automatisch hinzugefügt. Es lässt sich jedoch auch noch im Nachhinein einrichten, und zwar per Rechtsklick auf Project | Add | Application Insights Telemetry.Für ASP.NET-Applikationen gibt es eine weitere, sehr bequeme Option, um Application Insights zu aktivieren, ohne das Projekt und dessen Code modifizieren zu müssen: eine Instrumentierung mithilfe des PowerShell-Moduls Application Insights Agent (ehemals Status Monitor v2). Voraussetzung dafür sind PowerShell ab Version 5.1, der NuGet PackageProvider, die Module PowerShellGet und Application Insights Agent sowie der Instrumentation Key Ihrer Application-Insights-Ressource [11].Haben Sie Application Insights aus einem ASP.NET-Projekt entfernt, um es mittels Insight Agent zu instrumentieren, müssen Sie darauf achten, dass verschiedene relevante DLLs im bin-Ordner und aus der Datei web.config gelöscht worden sind, um keine Konflikte zu verursachen – mehr dazu lesen Sie unter [11] im Abschnitt Troubleshooting. Der Application Insights Agent hat die Status-Monitor-Desktop-Applikation abgelöst, die jedoch noch weiterhin verfügbar ist, siehe [11] unter Status Monitor (legacy).Um erhöhte Zugriffszahlen für die Beispielanwendung zu simulieren, wurde mittels SoapUI ein Load-Test über einen Zeitraum von fünf Minuten durchgeführt und dabei alle REST-Methoden der Webanwendung aufgerufen.In der Gesamtansicht der Application Insights Resource, siehe Bild 5, werden einige Standard-Metriken (Failed Requests, Server Response Time, Server Requests, Availability) in Form von Diagrammen angezeigt. Die Aktualisierungszeit ist dabei abhängig vom gewählten Zeitfenster.
Azure Application Insights– Resource Overview(Bild 5)
Autor
Das Application Dashboard lässt sich individuell konfigurieren. In der Standardeinstellung sind vier Kategorien ausgewählt: Usage, Reliability, Responsiveness und Browser. Jede dieser Kategorien hat auch schon vorkonfigurierte Standarddiagramme (Bild 6). Besonders interessant ist jetzt die Server Response Time (Avg): Der Ausschlag, von null auf über drei Sekunden, wurde durch die plötzlichen Anfragen des SoapUI-Load-Tests verursacht. Die Failed Requests entstanden durch manuelle Anfragen auf nicht existente Ressourcen (Error 404). Mit Klick auf das Diagramm Server Response Time oder auf Performance gelangen Sie zur Performance-Ansicht, in der Sie die individuelle Antwortzeit (Response Time) jeder Operation (REST-Methode) noch genauer untersuchen können (Bild 7). Per Klick auf View in Analytics lassen sich die ausgewählten Daten auch in Application Insights Analytics analysieren (Bild 8). Die erforderliche Kusto-Anfrage wird automatisch generiert.

Azure Application Insights– Application Dashboard(Bild 6)
Autor

Azure Application Insights– Analytics View(Bild 8)
Autor

Azure Application Insights– Performance Panel(Bild 7)
Autor
Um die Antwortzeit (Response Time) der Webanwendung kontrollieren zu können, können Sie eine Warnung (Alert) einrichten. Das klappt entweder in der Ansicht Analytics per Klick auf + New alert rule oder im Hauptportal der Application Insights Resource per Mausklick auf Configure | Alerts | New alert rule.Für die Beispielanwendung wurde eine Warnung definiert, bei der eine Mail versendet werden soll, sobald die durchschnittliche Antwortzeit aller Anfragen über einen Zeitraum von fünf Minuten größer als drei Sekunden ist. Diese Bedingung soll einmal pro Minute überprüft werden (Bild 9).

Azure Application Insights– Alert Condition(Bild 9)
Autor
In der Beispielanwendung wird der SLA-Verstoß durch den Load-Test verursacht. Bild 10 zeigt, dass die Warnung ausgelöst worden ist, zudem wurde die Warn-E-Mail verschickt.

Azure Application Insights– Alert Email Action(Bild 10)
Autor
Application Insights REST API
Application Insights erlaubt es auch, Daten per REST API abzufragen [9]. Das zurückgelieferte JSON-Ergebnis kann verwendet werden, um zum Beispiel Reports und Dashboards in Power BI zu erstellen. Wie auf der Webseite REST API Quickstart erklärt, können Sie über das folgende HTTP-API auf Ihre Daten zugreifen:
https:<span class="hljs-regexp">//</span>api.applicationinsights.io<span class="hljs-regexp">/{version}/</span>
apps<span class="hljs-regexp">/{app-id}/</span>{operation}<span class="hljs-regexp">/[path]?[parameters] </span>
Dabei stehen die in spitzen Klammern eingefügten Platzhalter für die Version (etwa v1), die Application-ID aus dem Azure-Portal und die Operation (metrics, events oder query). Als path legen Sie unabhängig von der Operation fest, welche Metrik oder welcher Event-Typ angefragt wird.Anstelle des Platzhalters [parameters] wird abhängig von der Operation festgelegt, was angefordert wird und wie. Zusätzlich muss ein API-Key als X-API-Key-HTTP-Header angegeben werden.Es gibt drei Arten von Operationen: Metrics, Events und Analytics Query mit jeweils eigenen Parametern. Es folgen einige Beispiele für Abfragen.Metrics: Gesucht ist die Gesamtanzahl an Requests des vergangenen Tages:
GET <span class="hljs-regexp">/v1/</span>apps<span class="hljs-regexp">/{app-id}/</span>
metrics<span class="hljs-regexp">/requests/</span>
<span class="hljs-keyword">count</span>?timespan=P1D
Events: Gesucht sind alle GET-Events, die gänzlich fehlgeschlagen sind oder länger als eine halbe Sekunde gebraucht haben:
GET /v1/apps/{app-id}/
events/requests?<span class="hljs-symbol">$</span>filter=
startswith(request/name,
<span class="hljs-string">'GET'</span>) <span class="hljs-keyword">and</span> (request/
resultCode <span class="hljs-keyword">ne</span> <span class="hljs-string">'200'</span> <span class="hljs-keyword">or</span>
request/duration <span class="hljs-keyword">gt</span> <span class="hljs-number">500</span>)
Analytics Query: Gesucht sind die Antwortzeiten der letzten Stunde im 50er- und 95er-Perzentil:
GET /v1/apps/{<span class="hljs-keyword">app</span>-id}/<span class="hljs-keyword">query</span>?<span class="hljs-keyword">query</span>=requests |
where timestamp >= ago(1h) |
<span class="hljs-keyword">summarize</span> percentiles(duration, 50, 95)
Des Weiteren brauchen Sie für eine Abfrage noch Ihre App-ID und einen API-Key (als HTTP-Header). Den API-Key können Sie unter Ihrer Application-Insight-Ressource generieren.Das REST API können Sie von einer beliebigen Anwendung/Sprache aus aufrufen, zum Beispiel mittels C#, curl oder aus SOAP UI.Als kleines Proof-of-Concept-Beispiel soll hier ein Load-Test für zehn Minuten auf die REST-Operation GetFavoriteNumbers der Mock-Webapplikation abgefeuert werden. Im Performance Dashboard sieht dies aus wie in Bild 11 zu sehen (Average Request Count).

Azure Application Insights – REST API– Performance Dashboard(Bild 11)
Autor
Für schnelle Tests bietet Application Insights auch einen eigenen API Explorer [12] an, in dem Sie passende HTTP-Abfragen bequem erstellen können. Zusätzlich lassen sich die erhaltenen JSON-Daten visualisieren. Bild 12 zeigt wieder die gleiche Abfrage über den Average Request Count der letzten Stunde. Die gleiche HTTP-Abfrage lässt sich natürlich auch per Programm in C# stellen und so in eigene Applikationen einbauen, siehe Listing 1.

Azure Application Insights – REST API– API Explorer(Bild 12)
Autor
Listing 1: Die Abfrage in C#
<span class="hljs-keyword">private</span> <span class="hljs-keyword">const</span> <span class="hljs-keyword">string</span> URL = <br/> <span class="hljs-string">"https://api.applicationinsights.io/v1/ </span><br/><span class="hljs-string"> apps/{0}/{1}/{2}?{3}"</span>; <br/><br/><span class="hljs-function"><span class="hljs-keyword">public</span> <span class="hljs-keyword">static</span> <span class="hljs-keyword">string</span> <span class="hljs-title">GetTelemetry</span>(<span class="hljs-params"> </span></span><br/><span class="hljs-function"><span class="hljs-params"> <span class="hljs-keyword">string</span> appId, </span></span><br/><span class="hljs-function"><span class="hljs-params"> <span class="hljs-keyword">string</span> apiKey, </span></span><br/><span class="hljs-function"><span class="hljs-params"> <span class="hljs-keyword">string</span> queryType, </span></span><br/><span class="hljs-function"><span class="hljs-params"> <span class="hljs-keyword">string</span> queryPath, </span></span><br/><span class="hljs-function"><span class="hljs-params"> <span class="hljs-keyword">string</span> parameterString</span>) </span><br/>{ <br/> HttpClient client = <span class="hljs-keyword">new</span> HttpClient(); <br/> client.DefaultRequestHeaders.Accept.Add( <br/> <span class="hljs-keyword">new</span> MediaTypeWithQualityHeaderValue( <br/> <span class="hljs-string">"application/json"</span>)); <br/><br/> client.DefaultRequestHeaders.Add( <br/> <span class="hljs-string">"x-api-key"</span>, apiKey); <br/><br/> <span class="hljs-keyword">var</span> req = <span class="hljs-keyword">string</span>.Format(URL, appId, <br/> queryType, queryPath, parameterString); <br/><br/> HttpResponseMessage response = <br/> client.GetAsync(req).Result; <br/><br/> <span class="hljs-keyword">if</span> (response.IsSuccessStatusCode) { <br/> <span class="hljs-keyword">return</span> response.Content <br/> .ReadAsStringAsync().Result; <br/> } <br/> <span class="hljs-keyword">else</span> { <br/> <span class="hljs-keyword">return</span> response.ReasonPhrase; <br/> } <br/>} <br/>... <br/><br/><span class="hljs-keyword">var</span> json = GetTelemetry(<span class="hljs-string">"DEMO_APP"</span>, <span class="hljs-string">"DEMO_KEY"</span>, <br/> <span class="hljs-string">"metrics"</span>, <span class="hljs-string">"requests/count"</span>, <br/> <span class="hljs-string">"timespan=PT3H&amp;interval=PT1M"</span>);
Log Analytics
Log Analytics [6] ist ein mächtiges Tool im Azure-Monitor-Portfolio: Es ermöglicht in Azure vorhandene Log-Daten mit dem Kusto-Service [7] zu analysieren und zu verarbeiten, siehe Bild 13. Log Analytics können Sie aus dem Azure-Monitor-Hauptportal (via Portal Menu | Monitor | Logs) oder direkt aus Application Insights heraus erreichen.
Azure MonitorLog Analytics(Bild 13)
Autor
Um Logs an Azure zu versenden, muss auf dem Windows-/Linux-Rechner der Log Analytics Agent [13] (auch Microsoft Monitoring Agent, MMA, genannt) installiert werden. Dieser Agent muss an einen Log Analytics Workspace angebunden werden und versendet die konfigurierten Logs mittels TCP über Port 443.Ein kleines Beispiel soll zeigen, wie einfach das Einrichten von Log Analytics auf einem Windows Server ist und wie schnell erste Daten erhoben werden können. Zunächst wird ein Log Analytics Workspace erstellt [14]. Danach lässt sich der Log Analytics Agent laden: Im Menü des Log Analytics Workspace wählen Sie dazu Overview | Connect a data source | Windows, Linux and other sources | Connected Sources | Windows Servers | Download Windows Agent.Auf der Download-Seite (Bild 14) sind Workspace-ID und Primary Key bereits aufgeführt, die beide für die Einrichtung des Log Analytics Agent benötigt werden. Nach der Installation des Agents ist dieser im Control Panel unter Microsoft Monitoring Agent zu finden. Im Tab Azure Log Analytics (OSM) lässt sich der Agent mit dem vorher erstellten Workspace verknüpfen.

Azure Log Analytics– Download Windows Agent(Bild 14)
Autor
Danach kann im Log Analytics Workspace konfiguriert werden, welche Datenquellen vom Agenten empfangen werden sollen, zum Beispiel Windows Event Logs oder Performance Counter. Als konkretes Beispiel soll eine benutzerdefinierte Log-Datei [15] dienen.Dazu wird unter Connect a data source | Windows, Linux and other sources | Data | Custom Logs eine exemplarische Log-Datei hochgeladen, der Record delimiter gesetzt (New Line oder Timestamp), der Dateipfad angegeben und der Name der Datenquelle gewählt.Zu Testzwecken dient ein kleines PowerShell-Skript, welches HTTP-Requests und -Responses auf diverse Aktionen der Webanwendung simuliert und einige Parameter (Zeitstempel, Aktions-Typ, Request oder Response, GUID) in eine Log-Datei schreibt.Sobald das PowerShell-Skript ausgeführt wird und Einträge in die Log-Datei schreibt, werden diese vom Microsoft Monitoring Agent an den Log Analytics Workspace versendet. Aufgrund von Verzögerungen im Agenten und Latenz bei der Aufnahme der Logs dauert es oft einige Minuten, bis diese in Log Analytics verfügbar sind.Zurück im Log Analytics Workspace reicht ein Mausklick auf das definierte Log-Schema aus, um eine einfache Kusto-Anfrage zu generieren: Zeige 50 Log-Einträge der letzten 24 Stunden (Bild 15).

Log Analytics– Sample Query(Bild 15)
Autor
Ohne weitere Konfiguration werden die Log-Zeilen aber nur als RawData-Feld geführt. Die Struktur einer Log-Zeile lässt sich jedoch über Custom Fields [16] genauer definieren. So werden beliebige Felder (etwa StartTime und StopTime) automatisch erkannt und ausgelesen, und die Werte können anschließend in Anfragen verwendet werden.
Log-Anfragen mit Kusto
Dieser Abschnitt beschäftigt sich näher mit der Abfragesprache Kusto. Als Beispielanwendung wird eine etwas komplexere Abfrage auf die Log-Daten der Beispiel-Webapplikation erstellt. Das Ziel ist, herauszufinden, wie lang die internen Bearbeitungszeiten der verschiedenen Aktionen der Webapplikation innerhalb der letzten Stunde waren. Das Ergebnis soll in einem Diagramm angezeigt werden.Dazu wird wieder auf die generierten Log-Daten zugegriffen, die nützlicher Weise ja bereits im Log Analytics Workspace vorhanden sind. Zur Erinnerung: Jeder Log-Eintrag hat einen Zeitstempel, einen Aktions-Typ (zum Beispiel GetBalance), einen RequestResponse-Typ und eine SessionId. Um eine neue Kusto-Abfrage zu erstellen, klicken Sie im Azure-Portal auf Monitor, dann auf Logs und editieren dann Ihre Anfrage im geöffneten Fenster New Query 1. Zwar unterstützt Kusto eine Untermenge von T-SQL für Abfragen, mächtiger ist jedoch die Kusto-eigene Abfragesprache [17].Kusto-Abfragen bestehen aus Verkettungen von Anweisungen für tabellarische Ausdrücke, die durch einen senkrechten Strich (auf einer deutschen Tastatur links neben dem Y) verbunden werden. Jede Anweisung erhält als Input die bisher verarbeitete Tabelle, bearbeitet diese mithilfe der definierten Anweisung und der Parameter und reicht das Ergebnis dann an die nächste Anweisung weiter. Am Ende steht meist eine Anweisung zum Visualisieren der Ergebnistabelle. Hier wird eine solche Abfrage Zeile für Zeile analysiert:
<span class="hljs-regexp">//</span> DataSource: Name der Tabelle, die abgefragt
<span class="hljs-regexp">//</span> werden soll
TigoCustomLog_CL
<span class="hljs-regexp">//</span> Hole alle Einträge, bei denen der Zeitstempel
<span class="hljs-regexp">//</span> <span class="hljs-string">"TigoLog_DateTime_CF"</span> weniger als eine Stunde alt ist
| where TigoLog_DateTime_CF > ago(<span class="hljs-number">1</span>h)
<span class="hljs-regexp">//</span> Hole alle Einträge, bei denen das Feld
<span class="hljs-regexp">//</span> <span class="hljs-string">"TigoLog_RequestResponse_CF"</span> gleich <span class="hljs-string">"REQUEST"</span> ist
| where TigoLog_RequestResponse_CF == <span class="hljs-string">"REQUEST"</span>
<span class="hljs-regexp">//</span> Wähle folgende Spalten, ggf. mit neuem Namen
| project TigoLog_Action_CF, TigoLog_ID_CF,
TigoLog_RequestResponse_CF,
StartTime=TigoLog_DateTime_CF
<span class="hljs-regexp">//</span> Verbinde die Input-Tabelle mit der
<span class="hljs-regexp">//</span> definierten Tabelle ...
| join
(
<span class="hljs-regexp">//</span> DataSource
TigoCustomLog_CL
<span class="hljs-regexp">//</span> Hole alle RESPONSE-Einträge
| where TigoLog_RequestResponse_CF == <span class="hljs-string">"RESPONSE"</span>
<span class="hljs-regexp">//</span> Wähle folgende Spalten, ggf. mit neuem Namen
| project StopTime=TigoLog_DateTime_CF, TigoLog_ID_CF
)
<span class="hljs-regexp">//</span> ... über das Feld <span class="hljs-string">"TigoLog_ID_CF"</span> (verbinde
<span class="hljs-regexp">//</span> alle Zeilen beider Tabellen, bei denen die
<span class="hljs-regexp">//</span> SessionID gleich ist)
on TigoLog_ID_CF
<span class="hljs-regexp">//</span> Füge eine neue Spalte <span class="hljs-string">"duration"</span> hinzu (die
<span class="hljs-regexp">//</span> Bearbeitungszeit der Aktion, vom Zeitpunkt des
<span class="hljs-regexp">//</span> Requests bis zur Response)
| extend duration = StopTime - StartTime
<span class="hljs-regexp">//</span> Füge eine neue Spalte <span class="hljs-string">"durationSec"</span> hinzu
<span class="hljs-regexp">//</span> duration <span class="hljs-regexp">/ 1s: konvertiert den Zeitstempel in </span>
<span class="hljs-regexp">/</span><span class="hljs-regexp">/ eine Zahl (Sekunden) </span>
<span class="hljs-regexp">/</span><span class="hljs-regexp">/ bin(value, roundTo): rundet den Wert zum Zielwert </span>
<span class="hljs-regexp">| extend durationSec = bin(duration/</span><span class="hljs-number">1</span>s, <span class="hljs-number">1</span>)
<span class="hljs-regexp">//</span> Visualisiere die Tabelle als Säulendiagramm
| render barchart
Dieses Kusto-Abfrageskript liefert ein Diagramm, welches die Bearbeitungszeit in Sekunden für alle Aktionen der letzten Stunde anzeigt – siehe Bild 16. Schön zu erkennen ist darin die lineare Ausführung der Aktionen, bedingt durch die Schleife im PowerShell-Skript.

Log Analytics – Kusto Query– Dauer der Aktionen der letzten Stunde(Bild 16)
Autor
Die Kusto-Anfrage lässt sich nun speichern und mithilfe des Befehls Pin to Dashboard an ein Dashboard anheften, das von mehreren Usern (zum Beispiel Admins oder DevOps) eingesehen werden kann.Alternativ lässt sich ein neuer Alert definieren, welcher eine Warnung als E-Mail verschickt, sofern eine oder mehrere Aktionen länger als beispielsweise acht Sekunden gedauert haben. Dafür müsste obige Kusto-Anfrage nur leicht modifiziert werden: Hinzugefügt wird eine weitere where-Abfrage, welche die Variable DurationSec auf einen Schwellwert prüft, entfernt wurde die Anweisung render barchart, wodurch anstelle eines Diagramms die generierte Tabelle angezeigt wird, siehe Bild 17.

Log Analytics – Kusto Query– Aktionen, die länger als acht Sekunden gebraucht haben(Bild 17)
Autor
Mittels Azure Logic Apps [18] und Microsoft Flow kann die Analyse noch weiter automatisiert werden, zum Beispiel indem Anfragen in Zeitintervallen oder durch einen Event ausgeführt werden und das Resultat dann an weitere Services weitergeleitet wird.Hat Ihnen dieser kurze Einblick in das Azure-Monitoring Spaß gemacht? Dann sollten Sie es gleich mal ausprobieren! Ich hoffe, dass Sie einige Denkanstöße gewonnen haben, wie Sie Ihre Daten und KPIs anhand von Application Insights und Log Analytics ab sofort besser erheben, verarbeiten und visualisieren können.
Fussnoten
- Azure Monitor, http://www.dotnetpro.de/SL2007Monitoring1
- Application Insights, http://www.dotnetpro.de/SL2007Monitoring2
- Export nach Power BI, http://www.dotnetpro.de/SL2007Monitoring3
- Ansicht Live Metrics Stream, http://www.dotnetpro.de/SL2007Monitoring4
- Azure Metrics Explorer, http://www.dotnetpro.de/SL2007Monitoring5
- Log Analytics queries, http://www.dotnetpro.de/SL2007Monitoring6
- Kusto, http://www.dotnetpro.de/SL2007Monitoring7
- Action groups in Azure, http://www.dotnetpro.de/SL2007Monitoring8
- REST API, http://www.dotnetpro.de/SL2007Monitoring9
- Connect Azure to ITSM tools, http://www.dotnetpro.de/SL2007Monitoring10
- Application Insights Agent for on-premises servers, http://www.dotnetpro.de/SL2007Monitoring11
- API Explorer, http://www.dotnetpro.de/SL2007Monitoring12
- Log Analytics Agent, http://www.dotnetpro.de/SL2007Monitoring13
- Log Analytics Workspace, http://www.dotnetpro.de/SL2007Monitoring14
- Custom Logs, http://www.dotnetpro.de/SL2007Monitoring15
- Custom Fields, http://www.dotnetpro.de/SL2007Monitoring16
- Kusto query, http://www.dotnetpro.de/SL2007Monitoring17
- Logic Apps, http://www.dotnetpro.de/SL2007Monitoring18