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

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.