Teilen über


Migrieren vom Log Analytics-Agent zum Azure Monitor-Agent

Der Azure Monitor-Agent (AMA) ersetzt den Log Analytics-Agent (auch als Microsoft Monitoring Agent (MMA) und OMS bezeichnet) in Azure- und Nicht-Azure-Umgebungen, lokalen Clouds sowie anderen Clouds sowohl für Windows- als auch für Linux-Computer. Er führt eine vereinfachte, flexible Methode zum Konfigurieren der Datensammlung mithilfe von Datensammlungsregeln (Data Collection Rules, DCRs) ein. Dieser Artikel enthält Anleitungen zum Implementieren einer erfolgreichen Migration vom Log Analytics-Agent zum Azure Monitor-Agent.

Die Migration ist eine komplexe Aufgabe. Beginnen Sie mit der Planung der Migration zum Azure Monitor-Agent, indem Sie die Informationen in diesem Artikel als Leitfaden verwenden.

Wichtig

Der Log Analytics-Agent wird am 31. August 2024 außer Betrieb genommen. Die Abschreibung gilt nicht für MMA-Agent, der ausschließlich mit einer lokalen SCOM-Installation verbunden ist.

Sie können Folgendes erwarten, wenn Sie den MMA- oder OMS-Agent nach dem 31. August 2024 verwenden.

  • Datenupload: Clouderfassungsdienste verringern schrittweise die Unterstützung für MMA-Agents, was im Laufe der Zeit zu geringerem Support für sowie potenziellen Kompatibilitätsproblemen mit MMA-Agents führen kann. Die Datenerfassung für MMA bleibt bis zum 1. Februar 2025 unverändert.
  • Installation: Die Option wird entfernt, Legacy-Agents aus dem Azure-Portal zu installieren. Außerdem werden Installationsrichtlinien für Legacy-Agents entfernt. Sie können die MMA-Agents-Erweiterung sowie die Offlineinstallationen weiterhin installieren.
  • Kundensupport: Es wird kein Support mehr für Probleme mit Legacy-Agents angeboten.
  • Betriebssystemunterstützung: Die Unterstützung für neue Linux- oder Windows-Distributionen (einschließlich Service Packs) wird nach dem Einstellen der Unterstützung für Legacy-Agents nicht hinzugefügt.
  • Log Analytics Agent kann mit Azure Monitor Agent koexistieren. Es kann vorkommen, dass duplizierte Daten angezeigt werden, wenn beide Agents dieselben Daten sammeln.

 

Vorteile

Wenn Sie den Azure Monitor-Agent verwenden, erhalten Sie sofortigen Nutzen, wie unten dargestellt:

Diagramm der Vorteile des Azure Monitor-Agents auf einen Blick. Dies wird unten in weiteren Details beschrieben.

  • Kosteneinsparungen durch Verwendung von Datensammlungsregeln:
    • Ermöglicht eine gezielte und präzise Datensammlung für einen Computer oder eine Teilmenge von Computern im Vergleich zum „Alles oder Nichts“-Ansatz von Legacy-Agents.
    • Ermöglicht Filterregeln und Datentransformationen, um das hochgeladene Gesamtdatenvolumen zu reduzieren, wodurch die Kosten für Erfassung und Speicherung erheblich gesenkt werden
  • Sicherheit und Leistung
    • Verbesserte Sicherheit durch verwaltete Identität und Microsoft Entra-Token (für Clients)
    • Höherer Ereignisdurchsatz, der um 25 % besser ist als die Legacy-Log Analytics (MMA/OMS)-Agents.
  • Einfachere Verwaltung, einschließlich effizienter Problembehandlung:
    • Unterstützt Datenuploads zu mehreren Zielen (mehrere Log Analytics-Arbeitsbereiche, d. h. Multihoming auf Windows und Linux), einschließlich regions- und mandantenübergreifender Datensammlung (mithilfe von Azure LightHouse)
    • Wenn sie zentralisiert ist, skaliert die Agent-Konfiguration „in der Cloud“ für Unternehmen während des gesamten Lebenszyklus der Datensammlung – vom Onboarding über die Bereitstellung bis hin zu Updates und Änderungen im Laufe der Zeit.
    • Alle Änderungen in der Konfiguration werden automatisch für alle Agents bereitgestellt, ohne dass eine clientseitige Bereitstellung erforderlich ist
    • Höhere Transparenz und Kontrolle über mehr Funktionen und Dienste wie Microsoft Sentinel, Defender for Cloud und VM-Erkenntnisse.
  • Ein einziger Agent, der alle Datenerfassungsanforderungen für unterstützte Server und Clientgeräte erfüllt Ein einzelner Agent ist das Ziel, obwohl der Azure Monitor-Agent derzeit mit den Log Analytics-Agents zusammenläuft.

Voraussetzungen

  • Informieren Sie sich über die Voraussetzungen für die Installation des Azure Monitor-Agents. Um Nicht-Azure- und lokale Server zu überwachen, müssen Sie den Azure Arc-Agent installieren. Der Arc-Agent macht Ihre lokalen Server als Ressource sichtbar, auf die er abzielen kann. Für die Installation des Azure Arc-Agents entstehen keine zusätzlichen Kosten.

  • Stellen Sie sicher, dass der Azure Monitor-Agent alle Ihre Anforderungen erfüllen kann. Der Azure Monitor-Agent ist für die Datensammlung allgemein verfügbar (General Availability, GA) und wird von verschiedenen Azure Monitor-Features und anderen Azure-Diensten für die Datensammlung verwendet.

  • Stellen Sie sicher, dass Sie über die erforderlichen Berechtigungen zum Installieren des Azure Monitor-Agents verfügen. Sie müssen über die erforderlichen Berechtigungen zum Installieren des Agents auf den Computern verfügen, die Sie überwachen möchten. Weitere Informationen finden Sie unter Verwalten des Azure Monitor-Agents.

Allgemeiner Leitfaden

Verwenden Sie die folgenden Anleitungen, um Ihre Migration zu planen und durchzuführen:

  • Grundlegendes zu Ihren Agents und Informationen zur Anzahl der zu migrierenden Agents
  • Informationen zur Verwendung Ihrer Arbeitsbereiche
  • Informationen zu den Lösungen, Erkenntnissen und Datensammlungen, die konfiguriert werden
  • Konfigurieren von Datensammlungen und Überprüfen der Sammlungen
  • Informationen zu zusätzlichen Abhängigkeiten und Diensten
  • Entfernen von Legacy-Agents

Die Arbeitsmappe für die Migrationshilfe für den Azure Monitor-Agent ist eine arbeitsmappenbasierte Azure Monitor-Lösung, die Ihnen bei den zuvor erwähnten Schritten helfen kann. In diesem Leitfaden finden Sie in jeder Phase des Migrationsprozesses Verweise auf die Arbeitsmappe und andere Tools. Weitere Informationen finden Sie im Artikel zur Arbeitsmappe für die Migrationshilfe für den Azure Monitor-Agent.

Grundlegendes zu Ihren Agents

Verwenden Sie den DCR-Generator, um Ihre Legacy-Agent-Konfiguration automatisch in Datensammlungsregeln zu konvertieren.1 Um Ihre Agenten zu verstehen, lesen Sie die folgenden Fragen:

Frage Aktionen
Wie viele Agents müssen Sie migrieren? Ermitteln Sie die Anzahl der Agents, die Sie migrieren müssen.
Verfügen Sie über Agents, die außerhalb von Azure bereitgestellt werden?

Werden diese Agents in Ihrem eigenen Rechenzentrum oder in einer anderen Cloudumgebung bereitgestellt?

Für Server, die sich außerhalb von Azure befinden, müssen Sie zuerst den Azure ARC Connected Machine-Agent bereitstellen. Weitere Informationen finden Sie unter Übersicht über den Azure Connected Machine-Agent.
Verwenden Sie System Center Operations Manager (SCOM)?

Wie sieht Ihr beabsichtigter Plan für SCOM aus?

Wenn Sie planen, SCOM weiterhin zu verwenden, beginnen Sie mit der Auswertung der verwalteten SCOM-Instanz. Weitere Informationen finden Sie unter Verwaltete SCOM-Instanz.
Wie stellen Sie Ihre Agents heute bereit? Wenn Sie automatisierte Methoden zum Bereitstellen des Legacy-Agents verwenden, sollten Sie überlegen, wann diese automatisierten Bereitstellungen für neue Server beendet werden sollen, und konzentrieren Sie sich auf die Bereitstellung des neuen Agents. Wenn Sie die automatisierte Bereitstellung für neue Server beenden, können Sie sicherstellen, dass kein weiterer Migrationsaufwand anfällt, und Sie können den Fokus auf den vorhandenen Bestand der zu migrierenden Agents lenken.

Die Arbeitsmappe für die Migrationshilfe für den Azure Monitor-Agent kann Ihnen helfen, zu verstehen, wie viele Agents Sie migrieren müssen. Weitere Informationen finden Sie im Artikel zur Arbeitsmappe für die Migrationshilfe für den Azure Monitor-Agent – Agents.

Grundlegendes zu Arbeitsbereichen, Lösungen, Erkenntnissen und Datensammlungen

Informieren Sie sich vor der Migration, wie Ihre Log Analytics-Arbeitsbereiche verwendet werden. Überprüfen Sie, ob sie alle verwendet werden und welche Agents Telemetriedaten an welche Arbeitsbereiche senden. Im Laufe der Zeit werden viele Arbeitsbereiche erstellt, und es wird möglicherweise unklar, welche Arbeitsbereiche tatsächlich verwendet werden, welche Arbeitsbereiche zum Erfassen von Telemetriedaten verwendet werden und von welchen Servern diese Telemetriedaten stammen. Die Migration ist eine gute Gelegenheit, Ihre Arbeitsbereiche zu bereinigen und zu konsolidieren.

Beachten Sie beim Überprüfen Ihrer Arbeitsbereiche, welche Lösungen konfiguriert sind. Diese Informationen sind wichtig, um zu verstehen, welche Daten Sie sammeln und wie Sie sie verwenden.

Die Arbeitsmappe für die Migrationshilfe für den Azure Monitor-Agent kann Ihnen helfen, zu verstehen, welche Arbeitsbereiche Sie haben, welche Lösungen in die jeweiligen Arbeitsbereiche implementiert sind und wann Sie die Lösung zuletzt verwendet haben. Für jede Lösung gibt es eine Migrationsempfehlung. Weitere Informationen finden Sie im Artikel zur Arbeitsmappe für die Migrationshilfe für den Azure Monitor-Agent – Arbeitsbereiche.

Sie können auch die Arbeitsmappe für die Azure Monitor-Arbeitsbereichsüberwachung verwenden, um Informationen zu Ihren Arbeitsbereichen zu erhalten. Um die Arbeitsmappe für die Azure Monitor-Arbeitsbereichsüberwachung zu verwenden, kopieren Sie die Arbeitsmappe aus dem GitHub-Repository, und importieren Sie sie in Ihren Log Analytics-Arbeitsbereich.

Diese Arbeitsmappe erfasst alle Ihre Log Analytics-Arbeitsbereiche und zeigt Folgendes für jeden Arbeitsbereich an:

  • Alle Datenquellen, die Daten an den Arbeitsbereich senden
  • Agents, die Takte an den Arbeitsbereich senden
  • Ressourcen, die Daten an den Arbeitsbereich senden
  • Alle Application Insights-Ressourcen, die Daten an den Arbeitsbereich senden

Weitere Informationen finden Sie im Artikel zur Arbeitsmappe für die Azure Monitor-Arbeitsbereichsüberwachung.

Konfigurieren von Datensammlungen und Überprüfen der Sammlungen

Berücksichtigen Sie beim Konfigurieren Ihrer Datensammlungen die folgenden Schritte:

  • Identifizieren Sie eine Pilotgruppe von Servern, die Sie für diesen Prozess verwenden können. Verwenden Sie die Pilotserver, um die Daten vor umfassenden Bereitstellungen zu überprüfen.

  • Verwenden Sie den DCR-Konfigurations-Generator, um die im Arbeitsbereich konfigurierten Datensammlungen zu transformieren und als Datensammlungsregeln wieder in Ihrer Umgebung bereitzustellen. Weitere Informationen zum DCR-Konfigurations-Generator finden Sie im Artikel zum DCR-Konfigurations-Generator.

  • Migrieren Sie VM Insights oder Azure Monitor für virtuelle Computer zum Azure Monitor-Agent. Überprüfen Sie die migrierten Datensammlungen für die Pilotgruppe der Server im Vergleich zu den vor der Migration gesammelten Datensammlungen. Um eine doppelte Erfassung zu vermeiden, können Sie die Datensammlung von Legacy-Agents während der Testphase deaktivieren, ohne sie zu deinstallieren. Entfernen Sie dazu die Arbeitsbereichskonfigurationen für Legacy-Agents. Weitere Informationen finden Sie unter Konfigurieren von Datenquellen.

  • Überprüfen Sie die neuen Daten, um sicherzustellen, dass keine Lücken vorhanden sind. Vergleichen Sie die vom Azure Monitor-Agent erfassten Daten mit den von Legacy-Agents erfassten Daten. Verwenden Sie KQL, um entsprechende Daten von jedem Agent basierend auf dem Agent-Typ zu vergleichen.

  • Planen Sie die Bereitstellung im großen Maßstab mithilfe von Azure Policy. Verwenden Sie integrierte Richtlinien, um Erweiterungen und DCR-Zuordnungen im großen Stil bereitzustellen. Die Verwendung einer Richtlinie stellt auch die zukünftige automatische Bereitstellung von Erweiterungen und DCR-Zuordnungen für neue Computer sicher. Weitere Informationen zur Bereitstellung im großen Maßstab finden Sie unter Verwalten des Azure Monitor-Agents – Verwenden von Azure Policy.

Informationen zu zusätzlichen Abhängigkeiten und Diensten

Vor der Migration sollten Sie verstehen, wie sich die Migration auf Ihre anderen Dienste auswirkt.

Dienst Auswirkung
Updateverwaltung Wenn Sie die Updateverwaltung in Azure Automation verwenden, müssen Sie zu Azure Update Manager migrieren.

Azure Update Manager verfügt über einen eigenen Agent und ist vom Azure Monitor-Agent entkoppelt.

Die Updateverwaltung wird ab Ende August 2024 nicht mehr unterstützt. Es wird empfohlen, zu Azure Update Manager zu migrieren.

Weitere Informationen finden Sie unter Migrieren von der Azure Automation-Updateverwaltung zu Azure Update Manager.

In der Arbeitsmappe für die Migrationshilfe für den AMA wird erläutert, welche Ihrer Computer aktuell die Updateverwaltungslösung verwenden und wie Sie sie migrieren. Weitere Informationen finden Sie im Artikel zur Arbeitsmappe für die Migrationshilfe für den Azure Monitor-Agent – Updateverwaltung.

Änderungsnachverfolgung und Bestand Wenn Sie das Feature „Änderungsnachverfolgung und Bestand“ verwenden, müssen Sie zu Azure Automation migrieren.

Das Feature „Änderungsnachverfolgung und Bestand“ ist auch Teil von Azure Automation. Der Azure Monitor-Agent verfügt zwar über eine Lösung für Änderungsnachverfolgung und Bestand, allerdings müssen Sie eine Datensammlungsregel erstellen. Weitere Informationen finden Sie unter Verwalten von Änderungsnachverfolgung und Bestand mit dem Azure Monitor-Agent.

Defender for Cloud Wenn Sie Defender for Cloud für Ihren Dienst oder Defender for Servers verwenden und P2 für Ihre Server aktiviert ist oder Sie die Aktivierung von P2 für Ihre Server planen, ändern Sie die Agent-Bereitstellung in Defender for Cloud von der Legacy-Agent-Bereitstellung in die Überprüfung ohne Agent.

Wenn Sie Defender for Cloud zum Erfassen von Sicherheitsereignissen verwenden, erstellen Sie eine benutzerdefinierte Datensammlungsregel, um diese Ereignisse zu erfassen.

Microsoft Sentinel Wenn Sie Microsoft Sentinel verwenden, wurden die Lösungen, die den Legacy-Agent verwendeten, in auf dem Azure Monitor-Agent basierende Lösungen konvertiert und können nicht aktualisiert werden.

Entfernen der Legacy-Agents

Planen Sie im Rahmen der Migrationsplanung, den Legacy-Agent zu entfernen, sobald die Migration abgeschlossen ist, um Duplikate der Datensammlung zu vermeiden.

Wenn Sie den MMA auf keinem Ihrer Computer beibehalten müssen, verwenden Sie das Tool „MMA Discovery and Removal“, um den Agent umfassend zu entfernen. Weitere Informationen zum Tool „MMA Discovery and Removal“ finden Sie im Artikel zum Tool „MMA Discovery and Removal“.

Wenn Sie jedoch System Center Operations Manager (SCOM) verwenden, behalten Sie den MMA auf den Computern bei, die Sie weiterhin mit System Center Operations Manager verwalten.

Ein SCOM Admin Management Pack ist vorhanden und kann Ihnen helfen, die Arbeitsbereichskonfigurationen umfassend zu entfernen, während die SCOM-Verwaltungsgruppenkonfiguration beibehalten wird. Weitere Informationen zum SCOM Admin Management Pack finden Sie unter SCOM Admin Management Pack.

Bekannte Migrationsprobleme

  • IIS-Protokolle: Wenn die IIS-Protokollsammlung aktiviert ist, füllt der AMA die Spalte sSiteName der Tabelle W3CIISLog möglicherweise nicht auf. Dieses Feld wird standardmäßig erfasst, wenn die IIS-Protokollsammlung für den Legacy-Agent aktiviert ist. Wenn Sie das Feld sSiteName mithilfe von AMA erfassen müssen, aktivieren Sie das Feld Service Name (s-sitename) in der W3C-Protokollierung von IIS. Schritte zum Aktivieren dieses Felds finden Sie unter Auswählen der W3C-Felder zur Protokollierung.
  • SQL-Bewertungslösung: Dies ist jetzt Teil der SQL-Best-Practices-Bewertung. Die Bereitstellungsrichtlinien erfordern einen Log Analytics-Arbeitsbereich pro Abonnement, was nicht die vom AMA-Team empfohlene Best Practice ist.
  • Microsoft Defender for Cloud: Wechsel zu einer Lösung ohne Agent. Einige Features am Ablaufdatum nicht einsatzbereit. Kunden sollten weiterhin MMA für Computer nutzen, wenn sie File Integrity Monitoring (FIM), Empfehlungen zur Erkennung von Endpunktschutz, Betriebssystem-Fehlkonfigurationen (Azure Security Benchmark-Empfehlungen (ASB)) und adaptive Anwendungssteuerungen verwenden.
  • Die Updateverwaltung wechselt zu einer Lösung ohne Agent, ist aber zum Ablaufdatum von MMA noch nicht einsatzbereit. Kunden, die die Updateverwaltung verwenden, sollten weiterhin MMA nutzen, bis der neue Dienst Automated Update Manager bereit ist.

Nächste Schritte