Monitoring in der Azure Cloud
Dieser Artikel liefert einen Überblick über die verschiedenen Monitoring-Optionen für Telemetriedaten in der Azure Cloud. Nach einer kurzen Standorteinordnung erfolgt die Erläuterung der Möglichkeiten, beginnend von Datentypen über die Datensammlung bis hin zur Verwendung.

Tools zum Systemmonitoring gab und gibt es in der Azure Cloud unzählige. Für einen kleinen Überblick wird kurz ein Blick in die Vergangenheit geworfen. Die Zeitreise beginnt im Jahr 2007. Damals wurde der System Center Operations Manager (SCOM) von Microsoft eingeführt. Damit konnten Informationen von On-premise-Umgebungen über den Zustand von virtuellen Maschinen und der Netzwerke dargestellt werden und Log-Daten eingesehen werden.
Nachfolger des Systems war die Operations Management Suite (OMS) im Jahre 2015, welche als Monitoringtool bereits als Cloudlösung verfügbar war, jedoch in einem separaten Portal, nicht im Azure-Hauptportal. In dieser Lösung tauchte der Term Log Analytics zum ersten Mal auf, dazu später mehr. Im gleichen Jahr erschien auch Application Insights (App Insights) als gesonderte Ressource zum Tracken von Web-Applikationen.
2018 wurde dann versucht, mit dem Azure Monitor die Erfahrung für den User im Portal zu vereinheitlichen, um Applikationen, Infrastruktur und Netzwerk an einer zentralen Stelle zu überwachen.
Azure Monitor: Überblick
Beim Azure Monitor handelt es sich um einen Standardservice, der immer vorhanden ist und nicht extra als Ressource in einer Ressourcengruppe provisioniert werden muss bzw. kann. Der Azure Monitor bietet ein umfassendes Set an Optionen für das Monitoring an, u. a.:
- Datenanbindung verschiedenster Quellen,
- Umfangreiche Analyseoptionen und
- Diverse Weiterverarbeitungsmöglichkeiten im Business-Prozess.
Bei der weiteren Verarbeitung können beispielsweise Azure Functions oder Logic Apps zum Einsatz kommen. Die nebenstehende Grafik ist aus drei Bereichen aufgebaut: Links die möglichen Quellen für Daten, in der Mitte die Datentypen und rechts die Möglichkeiten, mit diesen Daten zu arbeiten [1].
Datentypen und Herkunft
Vereinfacht gesagt, kennt die Monitor-Welt als Datentypen numerische, dezimale Werte und Texteinträge, die dann Metriken und Logs genannt werden. Bei Metriken handelt es sich um Daten in Time-series-Datenbanken, die sehr leichtgewichtig und für Echtzeitszenarios entwickelt sind. Metrische Daten geben z. B. Auskunft über die Auslastung von CPU oder Memory einer virtuellen Maschine, hier muss etwa im Falle von Grenzwertüberschreitungen der Last schnell mit Skalierung reagiert werden können. Etwas weniger zeitkritisch sind die Logs, welche durch Data Rows in einer relationalen Tabelle mit Spalte dargestellt werden. Viele Spalten enthalten Text im JSON-Format und können so noch weiter in den Analyse-Queries aufgebrochen werden [2,3].
Levels der Betrachtung
Die Daten können auch bezüglich der Herkunft kategorisiert werden. Beispielsweise gibt es die Active Directory Logs, die auf Tenant-Ebene anfallen, wie zum Beispiel Sign-in-Aktivitäten der User. Bei Betrachtung der Subscription-Ebene wird von Activity Logs gesprochen. Hier wären administrative Operationen auf selbiger, security-bezogene Meldungen oder Informationen über Skalierungsvorhänge zu nennen. Außerdem werden Daten über den allgemeinen Zustand der Azure Services in diesem Scope erfasst. Diese könnte z. B. eine Meldung über einen temporären Ausfall eines Dienstes sein. Auf dem Ressource-Level finden sich relevante Metriken und Konfigurationsänderungen der Ressourcen. Ein kleiner Sonderfall sind hier noch die Guest-OS-Daten von virtuellen Maschinen wie etwa performance counters, event logs und boot diagnostics. Mehr dazu gibt es im Abschnitt über VMs. Auf Applikationsebene, beispielsweise einer .Net-Core-Webanwendung, können Daten über das Verhalten des Codes erfasst werden – mit den üblichen Verdächtigen wie Exceptions, Requests oder Debugger Informationen.
Data Collection
Standard-Monitoring
Einige Daten werden out-of-the-box erfasst und können dann im Rahmen ihrer retention time abgefragt werden. Diese wiederum ist sehr unterschiedlich. Während Activity Logs per default 90 Tage und Metriken 93 Tage in der Azure-Umgebung aufbewahrt werden, sind Tenant Logs nur 30 Tage verfügbar. Wird hier ein längerer Zugriff benötigt, müssen diese im Rahmen des erweiterten Monitorings auf einen anderen data store übertragen werden.
Wird beispielsweise ein 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.
Erweitertes Monitoring
Bei dem erweiterten Monitoring kommt dann der Begriff Diagnostic Settings zum Tragen, was den Namen einer Konfigurationseinstellung entspricht. Hier kann auf Ressourcenebene eingestellt werden, welche der erfassbaren Daten entweder zu einem Storage Account, an einen Log Analytics Workspace oder einer Event Hub Ressource gesendet werden sollen, je nach gewünschter Aufbewahrungsdauer.
Welche Daten erfasst werden können, hängt von der Ressource ab. Ein Storage Account liefert zusätzliche Telemetrie über Anzahl der Transaktionen und deren Quelle, eine Web Application Firewall kann detaillierten Einblick über erfasste Requests, matching rules und Blockieraktionen geben.
Virtuelle Maschinen
VMs nehmen in einer Cloud-Umgebung häufig eine zentrale Rolle ein. Beim Monitoring dieser sind natürlich performance counter wie CPU- oder RAM-Nutzung interessant, aber auch Diagnosedaten vom Bootvorgang, Dumps von Abstürzen oder Windows Event Logs bzw. Linux Sys Logs. Letztere sind sehr wichtig für die weitere Auswertung in Securitylösungen wie dem Azure Security Center oder Azure Sentinel. Sollen die Telemetriedaten verwenden werden, kann auch hier schnell der Überblick verloren gehen. Es stehen aktuell 5 verschiedene Softwaremodule (Agents) zur Verfügung, um System Logs, Prozessinformationen oder Netzwerkverkehr zu erfassen. In der Regel kommt ein Log Analytics Workspace zur Anwendung. Die Agents überlappen sich auch zum Teil bzgl. der Daten [4].
Log Analytics Workspace und Applications Insights
Bei einem Log Analytics Workspace handelt sich um einen zentralen Datenspeicher für Log- und Telemetriedaten, welcher auf der Azure-Explorer-Datenbank basiert. Je nach konfigurierter Quelle finden sich hier verschiedene Tabellen, in der die Daten nach eingestellter Retention verfügbar sind. Mindestens ein Workspace ist für die Nutzung des Log Analytics Features nötig – oder eine Application-Insights-Instanz. An den Workspace können beispielsweise Daten von virtuellen Maschinen direkt von Azure oder on-premises gesendet, oder auch über eine SCOM-Lösung angebunden werden. Gängig ist in aktuellen Umsetzungen auch die Einbindung der Storage Accounts, wo VMs performance counter oder boot diagnostics schreiben.
Der andere im Zusammenhang mit dem Monitoring zu erwähnende Datentopf kommt von der Application Insights Ressource. Auch hier liegt der Data Explorer zu Grunde und die spezifischen Daten werden in den jeweiligen Tabellen abgelegt. Da AppInsights als einfach zu integrierende Monitoring-Lösung für Webanwendungen konzipiert wurde, finden sich Tabellen für Requests, Exceptions und Traces. Mittlerweile wurde auch hier eine Verschmelzung angefangen, es kann inzwischen gewählt werden zwischen der "Classic"-Variante, was dem eigenständigen Datentopf entspricht, oder der Workspace-Variante. In diesem Fall verwendet AppInsights ebenfalls Tabellen in einem vorhandenen Workspace. Dabei sollte aber beachtet werden, dass die Tabellen und Felder andere Namen haben [5].
Kosten
Die Kosten setzen sich größtenteils aus Daten-Input und deren Aufbewahrungsdauer zusammen. Sowohl der Log Analytics Workspace als auch AppInsights bieten erste 5 GB kostenlosen Input und 31 Tage bzw. 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. Szenarien für unvorhergesehene Kosten sind z. B. schleifenähnliche Fehler einer Anwendung, welche wiederum sehr viele Logdaten produzieren. Für den Workspace sind außerdem Kapazitätsreservierungen wie bei virtuellen Maschinen möglich. Diese sind aber nur bei großen Datenmengen sinnvoll [6].
Arbeiten mit den Daten
Log Analytics
Bei der zentralen Frage, was mit den gesammelten Daten gemacht werden kann, taucht zwangsläufig der Begriff Log Analytics auf, welcher aufgrund seiner Historie und Quellen im Netz etwas verwirrend sein kann. In diesem Kontext bezieht er sich auf den Teil des Azure Portals, in dem KQL Queries verwendet und verwaltet werden können und sollte nicht verwechselt werden mit dem Log Analytics Workspace oder Log Analytics als Teil einer OMS Suite. 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 großer Datenmengen. DDL Operationen wie das Erstellen von eigenen Tabellen sind ressourcenbedingt auf den Data Explorer oder die Data Collector API vom Workspace beschränkt. KQL findet außerdem 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
Bekannte Strukturen wie Konditionen, Gruppierungen und Suchoptionen sind ebenfalls verfügbar. Sehr interessant sind auch diverse Möglichkeiten, aus den Abfrageresultaten Charts zu generieren [7].
Workbooks
Eine Option zur Gestaltung übersichtlicher Dashboards sind Azure Monitor Workbooks. Hier kann eine Seite in Sektionen aufgeteilt und Ergebnisse der KQL-Abfragen in der gewünschten Anordnung zusammen dargestellt werden, als Tabellen oder Charts. Außerdem kann mit Parametern zur Suchmanipulation gearbeitet werden und es sind diverse Filter- und Sortieroptionen verfügbar. Abfrageergebnisse können verkettet werden, der Klick auf einen Balken eines Charts kann beispielsweise die Resultate einer Detailtabelle ändern.
Alarmierungen
Ein weiterer essentieller Bestandteil der Datenverarbeitung ist die Möglichkeit, darauf basierend mit Alarmierungen zu arbeiten. Ein Alarm besteht aus drei Bereichen:
- Signalquelle,
- Bedingung und
- Aktionen.
Bei dem Signal stellt sich die Frage, was im Fokus sein soll. Bezogen auf eine Ressource muss der Signaltyp gewählt werden. Das könnte eine Metrik, ein administrativer Vorgang auf dieser oder eine definierte KQL-Query sein.
Beim zweiten Schritt, der Bedingung, wird im Wesentlichen der Grenzwert des Signals, das Abfrageintervall sowie der zu berücksichtigende Zeitraum definiert. Hier ist daher beispielsweise die Anzahl der Ergebnisse einer Query oder die gewünschte Warnschwelle der CPU-Auslastung bezogen auf die zurückliegenden zwei Stunden relevant. An dieser Stelle lauern ein paar Fallstricke, denn es kann zwar eine in Log Analytics verwaltete Query verwendet werden, allerdings wird diese nur kopiert und nicht referenziert. Außerdem wird durch die Konfiguration des Abfragezeitraums im Alert bereits eine Vorfilterung der Daten vorgenommen – ob die verwendete Query eigentlich viel länger in die Vergangenheit schaut, ist dann irrelevant.
Beim dritten Baustein, den Action Groups, wird der Kreis der zu benachrichtigenden Personen definiert und auf welchem Weg sie die Notification bekommen sollen. Durch die Konfiguration von Actions kann bei Auftreten des Alarms z. B. Code durch eine Azure Function und ein Runbook ausgeführt werden, außerdem könnte eine Logic App getriggert oder auch ein Ticket eines angebundenen ITSM erzeugt werden.
Wie fast alles in Azure sind auch Action Groups und Alert Rules Ressourcen, diese sind allerdings per default versteckt und müssen gegebenenfalls, etwa für einen Ressourcenumzug, durch die entsprechende Checkbox sichtbar gemacht werden [8].
Insights
Unter dem Namen Insights werden weitere vielfältige Monitoring Optionen zusammengefasst. Ein Kandidat ist schon etwas "älter": Applications Insights. Ein Werkzeug, welches wohl allein ein ganzes Buch füllen könnte. In Abgrenzung zu den anderen Insights-Optionen wird es als extra Ressource provisioniert und mit Webanwendungen in der Cloud und on premises oder z. B. mit Azure Functions verknüpft. Vieles bringt AppInsights schon standardmäßig mit, beispielsweise das Erfassen von Exceptions aus dem Code, Tracken von Page views und deren Lade- bzw. Responsezeiten und Fehlercodes. Erweiterte Host diagnostics oder die Darstellung der Request-Herkünfte wären weitere Features. Mithilfe von distributed tracing können Application Maps gezeichnet werden, anhand derer ein User request vom Frontend bis hin zur Datenbank oder Storage-Aufruf nachverfolgt werden kann.
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.
Seit einiger Zeit gibt es auch andere 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 u. a. 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 [9,10].
Einfache Beispiele aus der Praxis
Die Möglichkeiten, Monitoringdaten zu erfassen und zu verarbeiten sind vielfältig. Simple, aber sehr effiziente Alarme werden gefeuert, wenn der Break-Glass Account (MFA-Notfallkonzept) verwendet wurde. Dies wird in den Tenant Logs vermerkt und kann das zuständige Securityteam benachrichtigen. Vorfälle, wo auf Ebene einer Subscription ein Azure Service Health Issue generiert wurde, sind für Operationteams interessant.
Anwendungsspezifisch wurde für den Fall, das ein File nicht ordnungsgemäß verarbeitet wurde, selbiges in einen Blob Storage geladen und ein entsprechender Logeintrag im AppInsights mit Fehlercode und Pfad geschrieben. Das in dem Prozess per Mail alarmierte Entwicklerteam bekommt so direkt Zugriff auf das File. In einem anderen Fall wurden Dynamics 365 Plugins erweitert, in dem Trace Log Daten aus der Plugin Sandbox über einen Service Endpoints an eine Service Bus Queue gesendet wurden. Das Verarbeiten der Messages aus der Queue übernimmt eine Logic App, welche schlussendlich auch einen AppInsights-Trace-Eintrag erzeugt. Ein mit Parametern konfigurierbares Workbook ermöglicht dann die Performance- und Troubleshooting-Analyse für die Plugins.
Ausblick
Die Vereinheitlichung der Überwachungsoptionen von Telemetriedaten für Azure Cloud oder On-premises-Umgebungen im Azure-Monitor schreitet voran. Ressourcen werden zusammengeführt bzw. 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.
- Microsoft: Azure Monitor overview
- Microsoft: Azure Monitor Metrics overview
- Microsoft: Azure Monitor Logs overview
- Microsoft: Overview of Azure Monitor agents
- Microsoft: Workspace-based resource changes
- Microsoft: Azure Monitor pricing
- Microsoft: Getting started with Kusto
- Microsoft: Overview of alerts in Microsoft Azure
- Microsoft: What is Application Insights?
- Microsoft: What is monitored by Azure Monitor?
Neuen Kommentar schreiben