Azure Monitor versteht sich als Hub für das Zusammenführen verschiedenster Überwachungssignale, als Datenspeicher für Metriken, als Sammelbecken für Analysedienste unterschiedlichster Art und als Visualisierungswerkzeug. Mithilfe seiner intelligenten Alarmierungsfunktion ist das Tool zudem Dreh- und Angelpunkt für Automatisierungen und führt verschiedene Azure-Dienste unter einer gemeinsamen Oberfläche zusammen.

Einer davon ist Log Analytics – die Azure-Weiterentwicklung der Operations Manager Suite. Log Analytics nimmt im Azure-Kosmos die Rolle des Tools ein, das Protokollabfragen von Daten bearbeitet, die von Azure Monitor gesammelt wurden. Es ermöglicht eine interaktive Datenanalyse und bildet die Grundlage für zahlreiche andere Azure-Funktionen und -Dienste wie Microsoft Sentinel, die Azure-Automation-Updateverwaltung oder die Azure Automation Desired State Configuration.

Bei der Arbeit mit Log Analytics ist oft von Metriken und Protokollen die Rede. Bei Metriken handelt es sich um numerische, meist eindimensionale Werte, die einen Aspekt eines Systems zu einem bestimmten Zeitpunkt beschreiben. Logs beziehungsweise Protokolle hingegen enthalten verschiedene Arten von Daten, die in Datensätzen mit unterschiedlichen Eigenschaften für jeden Typ organisiert sind. Das Senden und Speichern von Metriken ist nahezu jeder Azure-Ressource in die Wiege gelegt, sodass sich solche Daten bei PaaS immer und bei IaaS mit Einschränkungen ohne die Installation irgendwelcher Agenten erfassen, speichern und mit dem Metric Explorer direkt in Azure Monitor analysieren lassen.

Plattform- und benutzerdefinierte Metriken speichert Azure für bis zu 93 Tage in einer Zeitreihendatenbank, die für das Analysieren von Zeitstempeldaten optimiert ist. Für das Aufbewahren und Anzeigen mit Azure Monitor Metrics zahlen Unternehmen im Regelfall nichts. Kosten fallen im Zusammenhang mit Metriken frühestens dann an, wenn Sie diese länger als vorgesehen aufbewahren möchten oder Warnungen mit Metriken verknüpfen. Denn Sie können auf Metriken (und auf Protokollen sowie die vom Azure Resource Manager verwalteten Aktivitätsprotokollen) jederzeit benutzerdefinierte Warnungen als Dreh- und Angelpunkt für die Automatisierung einrichten. Möchten Sie dagegen längerfristige Trends ermitteln, müssen Sie auch Plattformmetriken über einen Agenten an einen Log-Analytics-Arbeitsbereich senden.

Bei IaaS – wie zum Beispiel Azure VMs – haben Sie optional die Möglichkeit, mit Hilfe eines "Diagnoseerweiterung" genannten Agenten Leistungsindikatoren auch vom Gastsystem zu erfassen. Dabei steht Ihnen bei der Konfiguration offen, neben der automatischen Lieferung an den Standard-Metrik-Datentopf von Azure Monitor – Azure Monitor Metrics – die Informationen mithilfe von Datensammlungsregeln über den neuen Azure Monitor Agent (AMA) ausliefern zu lassen. Solche Data Collection Rules (DCR) bieten mehr Flexibilität bei der Konfiguration der einzusammelnden Metriken. Die Verweildauer beträgt dann ebenfalls 93 Tage. Bei der Diagnoseweiterung müssen Sie immer ein Speicherkonto als Speicherort angeben, wobei Microsoft die Aufbewahrung von Metriken in einem zugehörigen Speicherkonto für nur 14 Tage garantiert.

Während also der Datentopf für Metriken im Prinzip in Azure Monitor enthalten ist, benötigen Sie für Log Analytics einen Arbeitsbereich als Datensenke für Protokolldaten. Diese ist im Gegensatz zu jener für Metriken standardmäßig nicht im Azure Monitor enthalten und eine eigenständige First-Class-Azure-Ressource, mit der Sie auf den von einem Agenten erfassten Protokollen interaktiv Protokollabfragen erstellen, ausführen und speichern können. Mit Log-Analytics-Abfragen haben Sie die Möglichkeit, zum Beispiel Datensätze abzurufen, die bestimmte Kriterien erfüllen, können Trends identifizieren, Muster analysieren und verschiedene Erkenntnisse aus Ihren Daten gewinnen.

Der Log-Analytics-Arbeitsbereich gibt gewissermaßen das Datenbankschema zum Speichern solcher Datensätze vor, nach denen Protokolldaten strukturiert sind. Gleichsam unterstützt Log Analytics mit KQL (Kusto Query Language) die passende leistungsfähige Abfragesprache, die auch in anderen Azure-Diensten zum Einsatz kommt, etwa beim Analysedienst Data Explorer oder beim SIEM-Tool Microsoft Sentinel. Bezahlen lässt sich Microsoft diese Software letztendlich durch die in einem Arbeitsbereich gespeicherten Datenmengen – und diese können aufgrund der zahlreichen unterstützten Quellen sehr umfangreich ausfallen.

Konfigurieren Sie Log Analytics nicht weiter und verwenden die Standardeinstellungen, gilt eine Aufbewahrungszeit von 31 Tagen. Jeder Log-Analytics-Arbeitsbereich wird nach zwei Faktoren abgerechnet: Zunächst ist die Data Ingestion zu berücksichtigen, also die Datenmenge, die Sie einspeisen. Diese fällt quasi sofort an, wenn Sie Daten an Log Analytics senden. Der zweite Faktor ist die Aufbewahrungsdauer (Retention), die sich nach Zeit und Datenmenge richtet. Dort sind nur die ersten 30 Tage kostenlos beziehungsweise 90 Tage bei aktiviertem Microsoft Sentinel oder im Zusammenhang mit Applications Insights. Möchten Sie die Daten länger aufbewahren, fallen gerade in diesem Punkt zum Teil erhebliche Kosten an, in Deutschland derzeit 0,13 US-Dollar pro GByte pro Monat [1].

Das ist insbesondere dann problematisch, wenn Sie die Daten eigentlich gar nicht mehr benötigen, aber aufbewahren müssen, etwa aufgrund rechtlicher Rahmenbedingungen oder durch Vorgaben von Kunden. In diesem Fall ist die Retention – also die Onlineaufbewahrung der Logs – der deutlich problematischere Kostenanteil, der sich seit einiger Zeit aber durch die Möglichkeit zur Archivierung der Logdaten reduzieren lässt. Hier unterscheidet Azure dann zwischen einer reinen Retention-Phase im Lebenszyklus von Logdaten, während der Sie diese problemlos mittels KQL abfragen können (die maximale mögliche Retention-Time beträgt hier zwei Jahre), und einer sich daran anschließenden Archivphase von maximal fünf Jahren.

Bei Letzterer berechnet Azure deutlich geringere Aufbewahrungskosten von 0,026 US-Dollar pro GByte je Monat. Dann müssen Sie die Daten allerdings bei Bedarf entweder mithilfe eines Search-Jobs (0,007 US-Dollar pro GByte gescannter Informationen) oder durch einen Restore-Vorgang (0,13 US-Dollar pro GByte pro Tag) wieder verfügbar machen, während Sie innerhalb der regulären Retention-Phase für Abfragen nichts extra zahlen. In Summe lässt sich also eine maximale Aufbewahrungszeit von bis zu sieben Jahren konfigurieren.

Die Menge der eingespeisten Daten, also der Ingestion-Anteil, lässt sich durch eine gezielte Konfiguration des eingesetzten Log-Analytics-Agenten insofern reduzieren, als dass Sie entscheiden, welche Daten Sie überhaupt sammeln wollen. Während Sie eine derartige Konfiguration beim alten Log-Analytics-Agenten nur für den gesamten Agenten durchführen können – diese wirkt sich dann für alle verbundenen VMs gleichermaßen aus –, zeigt sich das Setup des Azure-Monitor-Agenten deutlich gezielter, da Sie ihn mithilfe von Datensammlungsregeln feineinstellen und so für jede einzelne VM eine andere Konfiguration vorsehen können.

Zum Sammeln von sicherheitsbezogenen Informationen und Event Logs kommt also entweder der Log Analytics Agent – im Verlauf auch als Legacy-Agent bezeichnet – oder der Azure Monitoring Agent zum Einsatz. Das Ausrollen der beiden Agenten ist auf mehreren Wegen möglich. So können Sie etwa Microsoft Defender for Cloud dazu benutzen, das Verteilen eines der beiden Agenten auf vorhandene und künftige Ressourcen zu automatisieren. Zumindest im Kontext des Defender für Cloud setzt Microsoft aber immer noch den Legacy-Agenten als Default-Einstellung (Bild 1).

Interessanterweise ist dies nicht so, wenn Sie Log Analytics aus Perspektive der jeweiligen Datenquelle konfigurieren. Das generelle Aktivieren von Log Analytics erfolgt bei ausgewählter VM im Abschnitt "Monitoring / Logs", indem Sie auf "Enable" klicken und dann die gewünschte Konfiguration für einen der beiden möglichen Agenten vornehmen. Hier ist aktuell der neue Azure Monitor Agent als Empfehlung gesetzt, der klassische Log-Analytics-Agent ist optional.

Alternativ könnten Sie zuerst den Arbeitsbereich bereitstellen und dann in diesem unter "Workspace Data Sources" bei "Virtual machines" die gewünschten VMs verbinden – dann wiederum über den Legacy-Agenten. Die VM darf sich dabei durchaus in einer anderen Region befinden, ebenso wie der Workspace.

Azure Monitor Agent ersetzt den Log-Analytics-Agenten im Bereich Protokolle, liefert außerdem Diagnosedaten von Windows-Clientbetriebssystemen und lässt sich nicht nur für Azure-VMs, sondern auch für Azure Arc und lokal einsetzen. Er sammelt Ereignisprotokolle, Leistungsdaten, dateibasierte Protokolle sowie IIS-Protokolle und sendet diese nicht nur an Log Analytics, sondern künftig auch an Azure Monitor Metrics sowie an ein Speicherkonto und an ein Event Hub.

Die Integrationsmöglichkeiten werden laut Microsoft künftig die gleichen sein wie bei Log Analytics, also Microsoft Defender for Cloud, Microsoft Sentinel, Azure Updateverwaltung und VM Insights – allerdings sind sämtliche Integrationen derzeit noch als Preview eingestuft. Das Change Tracking findet aktuell sogar nur im alten Log-Analytics-Agenten Unterstützung. Weder der alte noch der neue Agent erfassen ETW-Events, Protokolle von .NET-Anwendungen, Absturzabbilder und Agent-Diagnose-Logs. Hier benötigen Sie auf der betreffenden (Azure)-VM nach wie vor die Diagnoseerweiterung für Windows (WAD) oder Linux (LAD). Linux-VMs unterstützen darüber hinaus noch den Telegraf-Agenten.

Im jeweiligen Log-Analytics-Arbeitsbereich erkennen Sie im Abschnitt "Settings / Agents management" auf einen Blick, ob und über welche Agenten etwaige VMs mit diesem Workspace verbunden sind. Außerdem können Sie hier – allerdings nur für den neuen Azure-Monitor-Agenten – konfigurieren, welche Daten dieser einsammelt, indem Sie auf "Data Collection Rules" klicken und eine solche DCR erstellen und verknüpfen.

Welche Infos der Legacy-Agent genau einsammelt, konfigurieren Sie im zugehörigen Workspace unter "Legacy agent management". Hier bestimmen Sie mithilfe der fünf Reiter "Windows event logs", "Windows performance counters", "Linux performance counters", "Syslog" und "IIS Logs", welche Auskünfte Sie benötigen. Da Ihre Auswahl Kosten verursacht, sollten Sie hier vorab genaue Überlegungen anstellen. Wie schon erwähnt gilt die zentrale Konfiguration des Log-Analytics-Agenten im Unterschied zu dedizierten DCRs für ausnahmslos alle verbundenen VMs, egal ob in Azure, anderen Clouds oder lokal.

Kurz noch einige Worte zu VM Insights, Container Insights, Application Insights et cetera: Aktivieren Sie beispielsweise VM Insights für die gewünschte VM unter "Monitoring / Insights", ist dazu ebenfalls Log Analytics erforderlich und Sie können sich bei der Konfiguration für den alten oder neuen Agenten entscheiden. Aber Achtung: Haben Sie VM Insights in der Vergangenheit bereits mit dem alten Agenten in Betrieb genommen und Sie migrieren auf den neuen, weist das Azure Portal darauf hin, dass es zu einer Duplizierung von Daten kommt, wenn beide installiert sind.

Um eine derartige Doppelkonfiguration zu vermeiden, müssen Sie für die VM zunächst ein Offboarding von VM Insights durchführen und sie dann mit einem Klick auf "Monitoring configuration" zur Verwendung des neuen Agenten bewegen. Sie können übrigens auch die Kusto Query Language nutzen, um herauszufinden, ob und mit welchem Agenten eine VM verbunden ist. Hierzu nutzen Sie das folgende Statement:

Klicken Sie im Dialog "Monitoring configuration" dann erneut auf "Edit", erscheint zunächst der Hinweis, dass VM Insights jetzt zwar die Datensammlung via Azure Monitor Agent unterstützt, dies aber noch als Preview eingestuft ist.

Den Azure-Monitor-Agenten konfigurieren Sie wie erwähnt mithilfe von Data Collections Rules. Sie richten solche DCRs wahlweise im Verlauf der Agent-Bereitstellung für Logs oder Insights ein oder vorab im Azure Portal und weisen diese später zu. Bei Verwendung des neuen Agenten landen DCRs (sofern automatisch angelegt) mit dem Präfix "MSVMI" in der gleichen Default-Ressource-Group wie der jeweilige Arbeitsbereich.

Im Allgemeinen legen Sie neue DCRs am einfachsten dadurch an, dass Sie im Azure-Portal nach "Data collection rules" suchen. In einer neuen Regel haben Sie dann im Abschnitt "Configuration" die Möglichkeit, "Data sources" und "Resources" zu konfigurieren. "Resources" wäre in unserem Beispiel die VM, die über den AMA mit dem entsprechenden Workspace verbunden ist. Die gewünschten Protokolle und Metriken stellen Sie unter "Data sources" ein. Das Einrichten umfasst neben der Data Source auch die "Destination". Diese dürfte in den meisten Fällen "Azure Monitor Logs" sein, also Log Analytics, da Azure Monitor Metrics derzeit noch Preview ist.

Microsoft lässt derzeit keine Chance aus, den Nutzer zur Verwendung des neuen AMA zu bewegen. Auf die zahlreichen noch offenen Baustellen haben wir im Verlauf des Artikels aber bereits hingewiesen. Da Microsoft jedoch langfristig nicht beide Agenten pflegen wird, müssen Sie den Umstieg bis 2024 vollzogen haben. Redmond unterstützt Nutzer bei der Migration mit zwei interessanten Tools [2], dem "AMA Migration Helper" und dem "DCR Config Generator". Beim Migration Helper handelt es sich um eine sogenannte "Azure-Solution", die Arbeitsmappen in Azure Monitor verwendet, um die zu migrierenden Quellen zu identifizieren und den Status laufender Migrationen zu verfolgen. Denn wie bereits beschrieben basiert die Konfiguration des Azure-Monitor-Agenten ausschließlich auf zugewiesenen Datensammlungsregeln, der Legacy-Agent hingegen erbt seine Konfiguration vom Log-Analytics-Arbeitsbereich, mit dem er verbunden ist. Der Migration Helper prüft außerdem noch etwaige Downstream-Abhängigkeiten und entfernt ältere OMS-Agenten.

Das zweite Tool, der "DCR Config Generator", analysiert die bestehende Log-Analytics-Agent-Konfiguration aus Ihren Arbeitsbereichen und generiert daraus automatisch entsprechende Datensammlungsregeln. Diese können Sie anschließend wahlweise manuell VMs zuordnen, auf denen der neue Agent mit integrierten Zuordnungsrichtlinien bereits läuft, oder Sie verwenden vorgefertigte Azure-Policies, die für das Installieren des neuen Agenten und Zuweisen der DCR sorgen.

Um den DCR-Konfigurationsgenerator installieren zu können, benötigen Sie mindestens Azure PowerShell 5.1 oder höher; wie üblich empfiehlt Microsoft die aktuelle 7er-Version. Außerdem brauchen Sie Lesezugriff auf den zuzugebenden Workspace und das az-Modul für die Azure-PowerShell. Zum Erzeugen des DCR-Konfigurationsgenerator müssen Sie lediglich das zugehörige PowerShell-Skript von GitHub [3] herunterladen und in der gewünschten Subskription, Resource Group und mit dem anzugebenden Workspace ausführen:

Das Skript lässt sich unter anderem im Kontext von "VS Code" mit installierter Azure-Erweiterung öffnen. Der obere Teil zeigt das Skript im Editor, der untere Teil des Befehlsaufruf im Terminal mit dem Resultat. Bei den erforderlichen Parametern ist "ResourceGroupName" die Ressourcengruppe, die den Zielarbeitsbereich enthält. "WorkspaceName" benennt den Ziel-Workspace, "DCRName" die neue DCR und "Location" den Standort der Region für die neue DCR.

Lassen Sie den Parameter "FolderPath" weg, verwendet Azure standardmäßig das aktuelle Verzeichnis zum Speichern der ARM-Vorlagendateien nebst zugehöriger Parameter-Dateien, beide im JSON-Format. Das Skript erzeugt in Abhängigkeit zur Konfiguration des Agenten zwei Arten von ARM-Vorlagen nebst der zugehörigen Parameterdateien, nämlich für Windows- und Linux. Im ersten Fall enthält der Zielbereich Windows-Leistungsindikatoren oder Windows-Events, im zweiten Fall Linux-Leistungsindikatoren oder Syslog-Ereignisse.

Sie können nun die generierten ARM-Templates verwenden, um die Bereitstellung der generierten DCR in der angegeben Ressourcengruppe und im angegebenen Abonnement anzustoßen. Verwenden Sie den optionalen Parameter "GetDcrPayload", erzeugt das Skript separate JSON-Dateien für die eigentlichen DCR, falls Sie diese auf andere Art bereitstellen möchten. Letztere können Sie jetzt auf einer der möglichen Arten ins Spiel bringen, zum Beispiel über das Azure-Portal – suchen Sie hier nach "Vorlagen-Bereitstellung" – oder über die Azure PowerShell:

So oder so erhalten Sie damit im Ergebnis die neue Data Collection Rule "New-DCR-windows" mit den Datenquellen "Performance Counters" und "Microsoft Syslog" und dem Auslieferungsziel "Azure Monitor Logs". Diese müssen Sie jetzt nur noch im Abschnitt "Ressourcen" der gewünschten VM zuordnen.

Zum Verfolgen der Migration einer großen Anzahl von Agenten beziehungsweise VMs sollten Sie jedoch den "AMA Migration Helper" einsetzen. Er analysiert Ihr aktuelles Setup, identifiziert dabei die zu berücksichtigenden Quellen wie VMs, Scale Sets oder Nicht-Azure-VMs und zeigt den aktuellen Status laufender Agent-Migrations-Prozesse an.

Für das eigentlichen Durchführen der Migration im größeren Umfang empfiehlt Redmond die Nutzung des Dienstes Azure Policy. Microsoft stellt dazu etwa die Policy-Initiative "Konfigurieren von Win­dows-Computern zum Ausführen des Azure Monitor-Agenten und zum Zuordnen dieser Computer zu einer Datensammlungsregel" zur Verfügung. Diese müssen Sie dem gewünschten Scope zuweisen. In Produktionsumgebungen wäre das Ihre Azure-Subskription oder eine übergeordnete Management Gruppe. Für einen Proof-of-Concept testen Sie die Policy eventuell erst in einer ausgewählten Ressourcengruppe.

Im Abschnitt "Advanced" des Zuweisungsassistenten haben Sie dann mit "Add resource selector" noch einmal die Möglichkeit, den Satz der ausgewerteten Ressourcen weiter einzuschränken, indem Sie geeignete Standorte oder Ressourcentypen auswählen. Dies kann bei der schrittweisen Einführung der Richtlinie helfen. Verwenden Sie mehrere Ressourcenselektoren, werden Ressourcen ausgewertet, die eine der Bedingungen erfüllen. Sie können maximal zehn Selektoren hinzufügen. Das Verknüpfen mit der zuvor generierten Datensammlungsregel erfolgt dann durch Auswahl der gewünschten Policy-Parameter im "Parameter"-Abschnitt. Hier benötigen Sie die "Ressourcen-ID der Datensammlungsregel", was in diesem Fall ihr Name ist. Im Abschnitt "Remediation" erzeugen Sie wie üblich einen Standardisierungs-Task. Damit werden alle nichtkonformen Ressourcen entweder bei der Erstellung oder nachträglich "geheilt", wenn Sie den Remediation-Task auf bestehende Ressourcen anwenden.

Mit "Review and Create" sorgen Sie dann dafür, dass der Azure Monitor Agent auf allen VMs in der angegebenen Subskripton installiert und mit der zuvor generierten Datensammlungsregel verknüpft wird. Prüfen Sie dann noch gegebenenfalls mit Azure Policy im Abschnitt "Remediation", ob und wie viele Azure-Ressourcen eine Standardisierung erfordern. Wenn alles geklappt hat, sollte das bei Ihrer Policy-Definition für null Ressourcen notwendig sein. Prüfen Sie die Übereinstimmung Ihrer Initiative nach angemessener Wartezeit im Abschnitt "Compliance" des Azure-Policy-Dienstes. Dies kann bis zu 30 Minuten dauern. Kontrollieren Sie dann nach angemessener Wartezeit, ob Ihre bestehende Datensammlungsregeln im Abschnitt "Ressourcen" mit Ihren VMs verknüpft wurden.

Der Azure-Monitor- ersetzt den Log-Analytics-Agenten. Zu den Vorteilen gehören mehr Sicherheit und Kosteneffizienz, eine bessere Verwaltbarkeit sowie höhere Zuverlässigkeit. Bis Ende 2024 müssen Sie alle Anwendungen und Services, die auf Log-Analytics basieren, auf AMA umgestellt haben. Helfen kann dabei die AMA-Migrationshilfe und der DCR-Konfigurationsgenerator. Leider unterstützt AMA aktuell noch nicht alle Features des Legacy-Agenten und wer planlos mit der Umstellung beginnt, läuft Gefahr, Daten doppelt zu erfassen und die Kosten in die Höhe zu treiben.