Der Umstieg auf den Azure Monitor Agent muss bis August erledigt sein

In vielen Tenants, die ich mir anschaue, läuft der alte Log Analytics Agent – auch als MMA oder OMS Agent bekannt – noch auf fast jedem Server. Dabei hat Microsoft die Migration auf den Azure Monitor Agent schon vor über zwei Jahren angekündigt, und das Supportende ist inzwischen nicht mehr weit. Am 31. August 2024 ist endgültig Schluss. Wer bis dahin nicht auf den Azure Monitor Agent (AMA) umgestellt hat, muss mit fehlenden Logs und Metriken rechnen. Im schlimmsten Fall fallen auch wichtige Security- und Management-Lösungen aus.

Viele Lösungen hängen noch am alten MMA

Gerade in größeren Umgebungen ist der MMA tief verwurzelt. Zuerst muss man also klären, welche Lösungen den alten Agenten überhaupt noch brauchen. Am häufigsten stoße ich bei VM Insights auf den MMA, außerdem in Microsoft Sentinel (etwa für bestimmte Datenconnectors), in Defender for Cloud und bei klassischen Funktionen wie Change Tracking oder Update Management. Vor allem Update Management war lange fest an den MMA gekoppelt. Wie die moderne Variante ohne Automation Account funktioniert, habe ich in meinem Artikel zum Azure Update Manager beschrieben.

Auch manche Drittanbieterlösung und so manches selbst geschriebene Skript greift noch auf den MMA zurück, etwa um bestimmte Events oder Performance Counter zu erfassen. Bevor die Migration beginnt, sollte man deshalb alle installierten Agenten vollständig erfassen und die jeweiligen Abhängigkeiten dokumentieren.

Das Workbook „AMA Migration Helper“ zeigt den Stand der Umstellung

Für diese Bestandsaufnahme stellt Microsoft den „AMA Migration Helper“ als Workbook für Azure Monitor bereit. Darin sieht man sofort, welche Server noch mit dem MMA laufen, auf welchen Ressourcen der AMA schon installiert ist und welche Data Collection Rules (DCRs) fehlen oder unvollständig sind. In gemischten Landschaften aus Azure-VMs und Arc-fähigen Servern ist das eine große Erleichterung. Die Auswertungen decken zudem Parallelinstallationen auf, die man im Zuge der Migration gezielt bereinigen sollte. Praktisch finde ich auch die Übersicht zum Migrationsfortschritt und die Empfehlungen, die das Workbook gleich mitliefert.

Data Collection Rules geben die Kontrolle über die erfassten Daten zurück

Dreh- und Angelpunkt der Migration auf den AMA sind die Data Collection Rules (DCRs). Früher wurde pauschal alles erfasst. Heute legt man fein abgestuft fest, welche Datenquellen (z. B. Windows Events, Syslog, Performance Counter) und welche Ziele (Log-Analytics-Workspaces, Event Hubs, Storage) gelten sollen. Sogar Transformationen sind möglich, beispielsweise KQL-Ausdrücke, die bestimmte Felder herausfiltern oder Daten aggregieren. So landen weniger Daten im Workspace, was die Kosten senkt und die Auswertung übersichtlicher macht. Wer sich in das Thema einlesen möchte, findet in der Microsoft-Dokumentation einen guten Einstieg: Übersicht zu Data Collection Rules.

Angenommen, man will nur bestimmte Security-Events abholen. Das lässt sich direkt in der DCR mit einem passenden Filter erledigen. Der folgende Ausschnitt aus dem DCR-JSON beschränkt die Erfassung auf die EventID 4625:

{
  "dataSources": {
    "windowsEventLogs": [
      {
        "name": "SecurityEvents",
        "streams": [ "Microsoft-Windows-Security-Auditing" ],
        "xPathQueries": [ "*[System[(EventID=4625)]]" ]
      }
    ]
  }
}

Azure Policy verteilt die DCRs auch auf viele Server zuverlässig

Bei vielen Maschinen und mehreren Abteilungen wird schnell die Frage laut, wie man die DCRs mit vertretbarem Aufwand zuweist. Meine Antwort darauf ist Azure Policy. Mit der passenden Initiative werden DCRs automatisch allen oder ausgewählten Servern einer Subscription oder Management Group zugewiesen. Microsoft hat das ordentlich dokumentiert (Grundlagen zum Azure Monitor Agent), und im Alltag lässt sich die Zuweisung gut steuern und auditieren. Für Arc-fähige Server führt an diesem Weg kaum etwas vorbei, sonst verliert man bei Maschinen außerhalb von Azure leicht den Überblick.

Das Diagramm zeigt den grundsätzlichen Ablauf: Ein Server wird mit dem AMA über eine DCR angebunden, egal ob er in Azure läuft oder per Arc verbunden ist.

flowchart TD
  Server["Server (VM oder Arc)"] --> AMA["Azure Monitor Agent"]
  AMA --> DCR["Data Collection Rule"]
  DCR --> Target["Log Analytics Workspace"]

Abbildung: Die Komponenten der Datenerfassung mit AMA und DCR, unabhängig vom Serverstandort.

Während des Parallelbetriebs drohen doppelt erfasste Daten

Für die Übergangszeit rate ich dazu, MMA und AMA nebeneinander zu betreiben. Dann lassen sich die Lösungen nach und nach auf den AMA umziehen, und man kann die Datenströme beobachten, ohne Datenverluste oder Lücken im Monitoring zu riskieren. Allerdings dürfen in dieser Phase keine doppelten Daten (Duplicate Ingestion) entstehen. Das passiert etwa, wenn MMA und AMA dieselbe Quelle an den Workspace liefern. Man sollte also genau prüfen, welcher Agent welche Log-Typen sammelt, und bei Bedarf Filter in den DCRs oder im MMA setzen.

Mein Tipp: In meinen Projekten fahre ich gut damit, zunächst einzelne Workloads auf den AMA umzustellen und die parallel gesammelten Logs in getrennte Workspaces zu schicken. Die Analyse wird dadurch einfacher, und die Gefahr sinkt, versehentlich Daten zu verlieren oder doppelt zu erfassen.

Sobald die Migration abgeschlossen ist, sollte der MMA von allen Servern verschwinden. Das schließt mögliche Sicherheitslücken und erspart dem Betrieb und dem Monitoring überflüssige Altlasten.

Der Umstieg lohnt sich gerade wegen der Log-Analytics-Kosten

Wer heute noch mit dem alten Log Analytics Agent arbeitet, sollte jetzt wechseln. Für mich ist die Migration auf den Azure Monitor Agent mehr als ein Infrastruktur-Upgrade. Sie bietet die Chance, die eigene Telemetrie- und SIEM-Strategie neu zu durchdenken. DCRs, fein abgestufte Filter und Azure Policy erweitern die Möglichkeiten und machen die Datenerfassung besser steuerbar. Da die Kosten für Log Analytics weiter steigen, zahlt sich der Aufwand schnell aus. Allen, die noch zögern, empfehle ich, das Workbook „AMA Migration Helper“ einzurichten und nach den ersten Quick Wins zu suchen. Je früher man anfängt, desto entspannter wird der Sommer.