Freigeben über

Sammeln von Windows-Ereignissen von virtuellen Computern mit Azure Monitor

Windows-Ereignisprotokolle sind einige der am häufigsten verwendeten Quellen für den Zustand des Clientbetriebssystems und arbeitslasten von Windows-Computern. Sie können Ereignisse aus Standardprotokollen, wie z. B. „System“ und „Anwendung“, und aus benutzerdefinierten Protokollen sammeln, die von zu überwachenden Anwendungen erstellt wurden. Sammeln Sie Windows-Ereignisprotokolle von virtuellen Computern mithilfe einer Datensammlungsregel (Data Collection Rule, DCR) mit einer Windows-Ereignisdatenquelle .

Details zur Erstellung des DCR werden in " Sammeln von Daten vom VM-Client mit Azure Monitor" bereitgestellt. Dieser Artikel enthält zusätzliche Details für den Datenquellentyp "Windows-Ereignisse".

Hinweis

Informationen zum direkten Arbeiten mit der DCR-Definition oder zur Bereitstellung mit anderen Methoden wie ARM-Vorlagen finden Sie in Den Beispielen zur Datensammlungsregel (Data Collection Rule, DCR) in Azure Monitor.

Konfigurieren der Windows-Ereignisdatenquelle

Erstellen Sie den DCR mithilfe des Prozesses in "Sammeln von Daten vom virtuellen Maschinen-Client mit Azure Monitor". Wählen Sie auf der Registerkarte " Sammeln und Übermitteln " des DCR die Option "Windows-Ereignisprotokolle " aus der Dropdownliste " Datenquellentyp " aus. Wählen Sie aus einer Reihe von zu erfassenden Protokollen und Schweregraden aus. Es werden nur Protokolle mit dem ausgewählten Schweregrad für jedes Protokoll erfasst.

Tipp

Wenn Sie das Sicherheitsprotokoll im DCR auswählen, werden die Ereignisse in Ihrem Log Analytics-Arbeitsbereich mit Ereignissen aus anderen Protokollen wie System und Anwendung an die Ereignistabelle gesendet. Eine weitere Option besteht darin, Microsoft Sentinel im Arbeitsbereich zu aktivieren und die Windows-Sicherheitsereignisse über den AMA-Connector für Microsoft Sentinel zu aktivieren. Dies verwendet denselben Azure Monitor-Agent und sammelt dieselben Ereignisse, aber sie werden an die SecurityEvent-Tabelle gesendet, die von Sentinel verwendet wird.

Screenshot: Konfiguration einer Windows-Ereignisdatenquelle in einer Datensammlungsregel

Wählen Sie Benutzerdefiniert aus, um Ereignisse mithilfe von XPath-Abfragen zu filtern. Auf diese Weise können Sie die von Ihnen gesammelten Ereignisse genauer steuern, indem Sie ein XPath verwenden, um die zu sammelnden Ereignisse anzugeben. Details und Beispiele für XPath-Abfragen finden Sie unter "Filterereignisse mit XPath-Abfragen ".

Screenshot: Benutzerdefinierte Konfiguration einer Windows-Ereignisdatenquelle in einer Datensammlungsregel

Hinzufügen von Zielen

Windows-Ereignisdaten können nur an einen Log Analytics-Arbeitsbereich gesendet werden, in dem es in der Ereignistabelle gespeichert ist. Fügen Sie ein Ziel vom Typ Azure Monitor Logs hinzu, und wählen Sie einen Log Analytics-Arbeitsbereich aus. Sie können zwar mehrere Arbeitsbereiche hinzufügen, beachten Sie jedoch, dass dadurch doppelte Daten an jedes gesendet werden, was zu zusätzlichen Kosten führt.

Screenshot: Konfiguration eines Azure Monitor-Protokollziels in einer Datensammlungsregel

Überprüfen der Datensammlung

Um zu überprüfen, ob Daten gesammelt werden, überprüfen Sie in der Tabelle "Ereignis " nach Datensätzen. Wählen Sie auf dem virtuellen Computer oder im Log Analytics-Arbeitsbereich im Azure-Portal Protokolle aus, und klicken Sie dann auf die Schaltfläche "Tabellen ". Klicken Sie unter der Kategorie Virtuelle Maschinen auf Ausführen neben Ereignis.

Screenshot, der Datensätze zeigt, die aus der Ereignistabelle zurückgegeben wurden.

Filtern von Ereignissen mithilfe von XPath-Abfragen

Die grundlegende Konfiguration im Azure-Portal bietet Ihnen eine eingeschränkte Möglichkeit, Ereignisse basierend auf Protokoll und Schweregrad zu filtern. Verwenden Sie zum Angeben einer präziseren Filterung eine benutzerdefinierte Konfiguration, und geben Sie einen XPath an, der nur nach den benötigten Ereignissen filtert.

XPath-Einträge haben folgende Form: LogName!XPathQuery. Angenommen, Sie möchten aus dem Anwendungsereignisprotokoll nur Ereignisse mit der Ereignis-ID 1035 abrufen. In diesem Fall würde die XPathQuery-Abfrage für diese Ereignisse *[System[EventID=1035]] lauten. Da Sie die Ereignisse aus dem Anwendungsereignisprotokoll abrufen möchten, lautet die XPath-Abfrage Application!*[System[EventID=1035]].

Hinweis

Der Azure Monitor-Agent verwendet die EvtSubscribe-System-API , um Windows-Ereignisprotokolle zu abonnieren. Das Windows-Betriebssystem lässt das Abonnieren von Windows-Ereignisprotokollen vom Typ „Analyse-/Debugkanäle“ nicht zu. Daher können Sie keine Daten aus Analyse- und Debugkanälen sammeln oder in einen Log Analytics-Arbeitsbereich exportieren.

Extrahieren von XPath-Abfragen aus der Windows-Ereignisanzeige

Sie können die Ereignisanzeige in Windows verwenden, um XPath-Abfragen zu extrahieren, wie in den folgenden Screenshots gezeigt.

Wenn Sie die XPath-Abfrage in das Feld auf dem Bildschirm Datenquelle hinzufügen einfügen (wie in Schritt 5 gezeigt), müssen Sie die Protokolltypkategorie gefolgt von einem Ausrufezeichen (!) anfügen.

Screenshot: Schritte zum Erstellen einer XPath-Abfrage in der Windows-Ereignisanzeige.

Tipp

Sie können das PowerShell-Cmdlet Get-WinEvent mit dem Parameter FilterXPath verwenden, um die Gültigkeit einer XPath-Abfrage zunächst lokal auf Ihrem Computer zu testen. Weitere Informationen finden Sie im Tipp in den Anweisungen unter Auf Windows-Agent-basierende Verbindungen. Das PowerShell-Cmdlet Get-WinEvent unterstützt bis zu 23 Ausdrücke. Azure Monitor-Datensammlungsregeln unterstützen eine Zahl von bis zu 20. Das folgende Skript ist ein Beispiel hierfür:

$XPath = '*[System[EventID=1035]]'
Get-WinEvent -LogName 'Application' -FilterXPath $XPath
  • Im obigen Cmdlet ist der Wert des Parameters -LogName der erste Teil der XPath-Abfrage bis zum Ausrufezeichen (!). Der Rest der XPath-Abfrage kommt in den Parameter $XPath.
  • Wenn das Skript Ereignisse zurückgibt, ist die Abfrage gültig.
  • Wenn Sie die Meldung erhalten, dass keine Ereignisse gefunden wurden, die mit den angegebenen Auswahlkriterien übereinstimmen, ist die Abfrage möglicherweise gültig, aber es sind keine übereinstimmenden Ereignisse auf dem lokalen Computer vorhanden.
  • Wenn Sie die Meldung „Die angegebene Abfrage ist ungültig“ erhalten, ist die Abfragesyntax ungültig.

Die folgende Tabelle enthält Beispiele für XPath-Abfragen zum Filtern von Ereignissen:

BESCHREIBUNG XPath
Es werden nur Systemereignisse mit der Ereignis-ID 4648 gesammelt. System!*[System[EventID=4648]]
Es werden nur Ereignisse des Sicherheitsprotokolls mit der Ereignis-ID 4648 und dem Prozessnamen „consent.exe“ gesammelt. Security!*[System[(EventID=4648)]] and *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\consent.exe']]
Es werden alle kritischen, Fehler-, Warnungs- und Informationsereignisse aus dem Systemereignisprotokoll mit Ausnahme der Ereignis-ID 6 (Treiber geladen) gesammelt. System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]]
Alle erfolgreichen und fehlerhaften Sicherheitsereignisse außer Ereignis-ID 4624 (Erfolgreiche Anmeldung) werden gesammelt. Security!*[System[(band(Keywords,13510798882111488)) and (EventID != 4624)]]

Hinweis

Eine Liste der Einschränkungen in XPath, die vom Windows-Ereignisprotokoll unterstützt werden, finden Sie unter Einschränkungen für XPath 1.0. Sie können beispielsweise die Funktionen „position“, „Band“ und „timediff“ innerhalb der Abfrage verwenden, aber andere Funktionen wie „starts-with“ und „contains“ werden derzeit nicht unterstützt.

Nächste Schritte