Online Magazine
Monitoring in der Azure Cloud: Wie geht’s und was nützt’s?

In der Azure Cloud lassen sich alle möglichen Daten überwachen und analysieren. Doch wie genau funktioniert dies und was ist der Nutzen?
von Thomas Hafermalz

Tools zum System-Monitoring gab und gibt es in der Azure Cloud unzählige: 2007 wurde der System Center Operations Manager (SCOM) von Microsoft eingeführt, darauf folgte 2015 der Operations Management Suite (OMS) und im gleichen Jahr erschien auch Application Insights (App Insights) als gesonderte Ressource zum Tracken von Web-Applikationen.
Diese Tools waren allerdings alle für spezifische Zwecke konzipiert und für die User bestand noch keine Möglichkeit, Applikationen, Infrastruktur und Netzwerk an einer zentralen Stelle im Portal zu überwachen. Dies wurde 2018 mit dem Azure Monitor geändert.
Azure Monitor ist ein Standardservice, der nicht als extra Ressource in einer Ressourcengruppe provisioniert werden muss. Im Azure Monitor ist es möglich, …
- … Daten verschiedenster Quellen anzubinden.
- … umfangreiche Analysen zu vollziehen.
- … Daten für den Business-Prozess vielfältig weiterzuverarbeiten, beispielsweise mit Azure Functions oder Logic Apps.
Grundsätzlich funktioniert es wie in folgender Grafik zu sehen: Links sind die möglichen Datenquellen aufgeführt, in der Mitte die Datentypen und rechts die Möglichkeiten, die Daten zu nutzen.
Azure Monitor Überblick © Microsoft
Datentypen und Herkunft verstehen
Die Datentypen bestehen aus numerischen und dezimalen Werten sowie Texteinträgen, welche Metriken und Logs genannt werden:
Den Metriken werden Daten aus Zeitreihendatenbanken zugeordnet, die für Echtzeit-Szenarios entwickelt sind, wie beispielsweise die Auslastung von CPU oder Memory einer virtuellen Maschine anzuzeigen. Bei diesen muss etwa im Falle von Grenzwertüberschreitungen rasch reagiert werden können. Etwas weniger zeitkritisch sind die Logs. Sie werden durch Data Rows in einer Tabelle mit Spalten dargestellt. Viele Spalten enthalten Text im JSON-Format und können so noch weiter in den Analyse-Queries aufgebrochen werden.
Unterschieden werden kann aber auch die Herkunft der Daten:
Bei Sign-in-Aktivitäten der User auf der Tenant-Ebene wird von Active Directory Logs gesprochen, bei beispielsweise administrativen Operationen oder Security-Meldungen auf Subscription-Ebene von Activity Logs. Auf der Ressourcen-Ebene finden sich relevante Metriken und Konfigurationsänderungen der Ressourcen. Auf Applikations-Ebene, beispielsweise einer .Net Core Webanwendung, können Daten über das Verhalten des Codes erfasst werden – mit Exceptions, Requests oder Debugger-Informationen.
So funktioniert das Standard-Monitoring
Bei gewissen Daten geschieht das Monitoring Out of the box. Sie können während einer gewissen Retention time abgefragt werden. Diese beläuft sich bei den Activity-Logs per default auf 90 Tage, 93 Tage bei Metriken. Tenant-Logs sind 30 Tage verfügbar. Der Zugriff kann aber durch das Übertragen auf einen anderen Data Store auch verlängert werden.
Wird beispielsweise eine Service Bus mit einer Queue provisioniert, kann über das Menü der Ressource selbst oder über den Monitor-Service mit entsprechendem Scope eingesehen werden, wie viele Messages den Bus im zeitlichen Verlauf passiert haben. Von einem App-Service oder einer virtuellen Maschine kann über das Portal ein Einblick in die Performance-Metriken genommen werden.
Azure Service Bus Metriken © Thomas Hafermalz
So funktioniert das erweiterte Monitoring
Unter den Konfigurationseinstellungen, den sogenannten „Diagnostic Settings“, kann das erweiterte Monitoring gemanaged werden. In der Ressourcen-Ebene wird eingestellt, welche Daten an einen Storage Account, einen Log Analytics Workspace oder eine Event Hub Ressource gesendet werden sollen, je nach gewünschter Aufbewahrungsdauer.
Welche Daten erfasst werden können, ist abhängig von der Ressource. Ein Storage Account liefert zusätzliche Telemetrie über die Anzahl der Transaktionen und deren Quelle, eine Web Application Firewall kann detaillierten Einblick über erfasste Requests, Matching Rules und Blockieraktionen geben.
Der Blick auf virtuelle Maschinen
Ein wichtiger Punkt in der Cloud ist das Monitoring von virtuellen Maschinen. Dabei sind insbesondere Performance Counter wie CPU oder RAM-Nutzung interessant, aber auch Diagnose-Daten vom Bootvorgang, Dumps von Abstürzen oder Windows Event Logs oder Linux Sys Logs. Letztere sind sehr wichtig für die weitere Auswertung in Security-Lösungen wie dem Azure Security Center oder Azure Sentinel.
Bei der Verwendung von Telemetriedaten ist es auch hier schwierig, den Überblick zu behalten. Es gibt fünf verschiedene Softwaremodule (Agents) zur Erfassung von System Logs, Prozessinformationen oder Netzwerkverkehr. Oft wird ein Log Analytics Workspace eingesetzt. Die Agents können sich bezüglich Daten auch überschneiden.
Log Analytics Workspace und Applications Insights
Ein Log Analytics Workspace ist ein zentraler Datenspeicher für Log- und Telemetriedaten. Je nach konfigurierter Quelle gibt es verschiedene Tabellen, in denen die Daten nach eingestellter Retention verfügbar sind. Für die Nutzung des Log Analytics Features ist im Minimum ein Workspace nötig – oder eine Application-Insights-Instanz. An einen Workspace können beispielsweise Daten von virtuellen Maschinen direkt gesendet oder über eine SCOM-Lösung angebunden werden. Es ist auch gängig, Storage Accounts einzubinden, wo virtuelle Maschinen Performance Counter oder Boot Diagnostics schreiben.
Eine wichtige Datenquelle für das Monitoring ist zudem die Application-Insights-Ressource. Auch dabei werden Daten in Tabellen abgelegt. Da für Webanwendungen konzipiert, finden sich Tabellen für Requests, Exceptions und Traces. Es kann zwischen einer eigenständigen Datenquelle („Classic“ Variante) und der Workspace Variante ausgewählt werden. Dabei sollte aber beachtet werden, dass die Tabellen und Felder andere Namen haben.
Entstehung der Kosten
Die Kosten setzen sich hauptsächlich aus Daten-Input und Aufbewahrungsdauer zusammen. Sowohl der Log Analytics Workspace als auch AppInsights bieten erste 5 GB kostenlosen Input und 31 Tage beziehungsweise 90 Tage freie Retention. Damit die Kosten nicht unbemerkt aus dem Ruder laufen, können tägliche Datenlimits festgelegt werden oder für längerfristige Aufbewahrung der Daten ein Storage-Account zur Archivierung konfiguriert werden.
Arbeit mit den Daten
Was kann nun mit den gesammelten Daten gemacht werden? Bei dieser Frage spielt der Begriff „Log Analytics“ eine wesentliche Rolle. Dieser kann je nach Quelle verschiedene Bedeutungen haben. In diesem Kontext bezieht er sich auf den Teil des Azure Portals, in dem KQL-Queries verwendet und verwaltet werden können.
KQL bezeichnet die Kusto Query Language, die für den Data Explorer konzipiert wurde. Sie ist SQL ähnlich und ist optimiert für lesende Abfragen grosser Datenmengen. KQL findet ausserdem bei Abfragen im Resource-Graph Anwendung. Eine KQL-Abfrage folgt dabei dem Schema der Wahl einer Tabelle oder eines Joins, optional erweitert („gepiped“) über Bedingungen und Projektionen (selects). Der pipe Operator reicht Zwischenergebnisse weiter.
Beispielsweise wäre das Äquivalent zur MSSQL Query:
SELECT operation_Name, type, method
FROM exceptions
WHERE operation_Name = “Myfunction”
in KQL:
exceptions
| where operation_Name == “Myfunction”
| project operation_Name, type, method
Azure Web Application Fireall Logs © Thomas Hafermalz
Gestaltung von Dashboards
Ein übersichtliches Dashboard lässt sich mit Azure Monitor Workbooks erstellen. Es können Sektionen festgelet und Ergebnisse der KQL-Abfragen nach Wunsch angeordnet und als Tabellen oder Charts dargestellt werden. Weiter gibt es Parameter zur Suchmanipulation und diverse Filter- und Sortieroptionen. Auch lassen sich Abfrageergebnisse verketten und beispielsweise einstellen, dass mittels Klick auf einen Balken Detailtabellen ändern.
Daten für Alarmierungen nutzen
Ein weiterer grosser Nutzen der Daten ist, dass basierend darauf Alarmierungen erstellt werden können. Ein Alarm setzt sich aus drei Komponenten zusammen:
- Signalquelle
- Bedingung
- Aktionen
Zunächst muss also die Signalquelle bezogen auf eine Ressource gewählt werden: Das könnte eine Metrik, ein administrativer Vorgang auf dieser oder eine definierte KQL-Query sein.
Danach wird die Bedingung definiert, mit anderen Worten der Grenzwert des Signals inklusive Abfrageintervall und -zeitraum. Das können die Anzahl Ergebnisse einer Query oder die gewünschte Warnschwelle der CPU-Auslastung bezogen auf die zurückliegenden zwei Stunden sein. Es gilt allerdings zu beachten, dass zwar eine in Log Analytics verwaltete Query verwendet werden kann, diese aber nur kopiert und nicht referenziert wird. Auch wird durch die Konfiguration des Abfragezeitraums im Alert bereits eine Vorfilterung der Daten vorgenommen.
Im letzten Schritt geht es dann noch um die Aktionen respektive Action Groups. Dabei sollen die zu benachrichtigenden Personen bestimmt werden und die Art der Notification an sie. Durch die Konfiguration von Actions kann beim Auftreten eines Alarms beispielsweise auch Code durch eine Azure Function und ein Runbook ausgeführt werden, auch könnten eine Logic App getriggert oder ein Ticket eines angebundenen ITSM erzeugt werden.
Action Groups und Alert-Rules-Ressourcen sind allenfalls per default versteckt und müssten in diesem Fall für einen Ressourcenumzug durch die entsprechende Checkbox sichtbar gemacht werden.
Insights
Der Begriff „Insights“ fasst vielfältige Monitoring-Optionen zusammen. Das Tool Applications Insights ist dabei schon etwas älter. Es wird als extra Ressource provisioniert und mit Webanwendungen in der Cloud und On-Premises oder beispielsweise mit Azure Functions verknüpft. Damit können standardmässig Exceptions aus dem Code erfasst sowie Pageviews und deren Lade- beziehungsweise Responsezeiten und Fehlercodes getrackt werden. Weitere Features sind Host Disgnostics oder die Darstellung von Request-Herkünften. Mithilfe von Distributed Tracing können auch Application-Maps gezeichnet werden, anhand derer ein User Request vom Frontend bis hin zur Datenbank oder Storage-Aufruf nachverfolgt werden kann.
AppInsights Application Map © Microsoft
Es sind diverse SDKs verfügbar, mithilfe derer individuelle Business-Events und Metriken getrackt werden können. Damit können dann auch erweiterte Funktionen wie die Darstellung einer User-Rückkehr und die Konfiguration von Funnels (Trichtern) zur Bemessung von Erfolgsquoten einer User Journey – sinnvoll etwa bei einem Online-Shop – ermöglicht werden.
Es existieren auch noch weitere Insights für verschiedene Ressourcen, die automatisch zur Verfügung stehen, wobei einige etwas Konfigurationsarbeit und einen Log Analytics Workspace benötigen, beispielsweise Container Insights zur Überwachung eines AKS-Clusters oder VM Insights. Zentraler Bestandteil dieser Lösungen sind Workbooks, welche anhand von Metriken und Logs die Analysen der Ressourcen erleichtern. Storage Insights kann auf diese Weise einen schnellen Überblick über Transaktionen, Speicherbelegung und Zugriffslatenz sämtlicher Storage Accounts im Tenant liefern. Das Pendant für den Key Vault liefert unter anderem Zugriffsmengen und Fehlerraten. Das macht diese beiden Insights Varianten auch interessant, wenn die Aktivierung des zusätzlichen Azure Defender Schutzes für die Ressourcen abgewogen wird, da sich auf diese Art die Kosten dafür schnell und einfach abschätzen lassen.
Die Vereinheitlichung der Überwachungsoptionen von Telemetriedaten für die Azure Cloud oder On-Premises-Umgebungen im Azure Monitor schreitet voran. Ressourcen werden zusammengeführt beziehungsweise vereinfacht und sinnvolle Erweiterungen im Bereich der Insights sind auch auf dem Weg. Es wird daher spannend sein, zu beobachten, wo die Reise noch hinführt.
