In diesem Artikel möchte ich euch zeigen, wie man die Azure Log Analytics in Verbindung mit On-Premises Systemen konfiguriert. Mit Azure Log Analytics können unterschiedliche Logs von unterschiedlichen Servern aggregiert und ausgewertet werden.
In diesem Beispiel konzentrieren wir uns aber auf Windows Servern, die nicht in Azure gehostet werden.
Der Bereich (auch Data-Lake genannt), in dem die aggregierten Daten zur Verfügung stehen nennt sich bei Azure Log Analytics ein Workspace.
Die Azure Log Analytics Workspaces sind recht einfach im Azure Portal zu finden. Wenn wir noch keinen Workspace erstellt haben, ist dies jetzt der richtige Zeitpunkt.
Bei der Erstellung müssen wir ein paar Daten (Name, Subscription, Resource Group, …) angeben, die eigentlich selbsterklärend sein sollten.
Wenn der Workspace erstellt wurde, sollte dies dann folgendermaßen aussehen.
Damit wir jetzt On-Premises Server an unseren Workspace anbinden können, müssen wir einen entsprechenden Agenten auf den Servern installieren. Diesen finden wir hinter dem Menüpunkt Advanced settings.
Alle notwendigen Informationen findet man auf der Management Seite für die Agenten. Dort findet man den Downloadlink für den Agenten (32-bit und 64-bit) und die notwendigen IDs um den Agenten mit dem Workspace zu verbinden.
In diesem Beispiel installieren wir den Agenten auf einem Windows Server 2019.
Sobald der Agent erfolgreich installiert wurde, steht ein neuer Menüpunkt in der Windows Systemsteuerung unter System und Sicherheit zur Auswahl. Dort wird die Verbindung zu unserem Workspace konfiguriert. Damit eine erfolgreiche Konfiguration möglich ist, muss natürlich eine Verbindung zum Internet möglich sein. Theoretisch gibt es natürlich auch noch andere Möglichkeiten, wir beschränken uns hier aber auf eine direkte Internetverbindung. Die notwendigen Endpunkte sind hier aufgelistet.
In den Einstellungen geben wir nun unsere Workspace ID und Key von unserem Workspace (siehe Bild) ein.
Wenn wir die Daten korrekt eingetragen haben und die Verbindung zu unserem Workspace erfolgreich war, sollte folgende Meldung erscheinen.
Auch in Azure kann man das erfolgreiche Verbinden mit unserem Windows Server natürlich prüfen.
Im nächsten Schritt können wir nun festlegen, was für Logs von unserem Agenten eingesammelt werden sollen. Mit diesen Daten können wir dann im Workspace arbeiten. Bei unserem Windows Server 2019 ist noch die Applikation Microsoft SharePoint installiert. Deshalb würde es Sinn machen, die Ereignisanzeige, IIS Logs & SharePoint ULS Logs in unseren Workspace zu übertragen. Die ersten beiden Logs werden nativ von Azure Log Analytics unterstützt. Bei den ULS Logs müssen wir noch einen weiteren Schritt durchführen, dazu aber später mehr.
Die Konfiguration der zu sammelnden Daten wird wieder in den Advanced Settings vorgenommen.
In diesem Beispiel interessieren wir uns nur für Applikation und System Ereignisse. Und man kann noch einstellen, welche Levels (Fehler, Warnung oder Information) übertragen werden sollen. In diesem Beispiel wählen wir einfach alle Levels aus. Um die IIS Logs zu sammeln, reicht ebenfalls ein einfacher Klick.
Mit den Azure Log Analytics können aber auch beliebige Logs gesammelt werden. Nachdem wir einen SharePoint Server zur Verfügung haben, bietet es sich an die SharePoint ULS Logs ebenfalls zu verarbeiten.
Wenn wir ein benutzerdefiniertes Log hinzufügen wollen, muss zuerst ein Beispiellog hochgeladen werden. Dadurch wird das Trennzeichen für neue Einträge festgelegt.
Danach müssen wir noch festlegen, wo dieses Log auf dem Windows Server zu finden ist. Hier kann eine bestimmte Datei angegeben werden, oder es können auch Wildcards zum Einsatz kommen. Wichtig ist dabei nur, dass maximal eine Dateigröße von 50MB unterstützt wird. Weil SharePoint das ULS Log jede halbe Stunde durchrotiert und den Zeitstempel im Dateinamen hinterlegt, nutzen wir an dieser Stelle Wildcards.
Zuletzt muss noch eine Name für unser benutzerspezifisches Log festgelegt werden. Als Suffix wird immer CL festgelegt, was für Custom Log steht.
Und nun können wir mit den gesammelten Logs anfangen zu arbeiten. Dafür gibt es den Log Editor, mit dem man sich Abfragen selbst zusammenbauen kann.
Eine ganz einfache Abfrage ist zum Beispiel, wann der Agent zuletzt Online war und Daten in unseren Workspace geladen hat. Dies funktioniert ganz einfach über den Befehl Heartbeat.
Oder wir lassen uns die gesammelte Ereignisanzeige anzeigen.
Bei benutzerspezifischen Logs ist noch zu beachten, dass hier wirklich die Daten im Rohformat hochgeladen werden. Wenn wir uns das Beispiel mit den SharePoint ULS Logs ansehen, erhalten wir folgendes Ergebnis.
Die eigentlichen Daten befinden sich in der Spalte RawData. Das ist nicht ganz das Ergebnis, was wir wollen. 🙂 Aber dies kann man recht einfach beheben, indem wir die Abfrage ein bisschen anpassen. Wir splitten die Daten einfach mit dem Tabulator als Trennzeichen (das ist bei SharePoint ULS Logs immer das Trennzeichen).
Der genutzt Query zum einfacheren Kopieren lautet so:
SharePointULS_CL | extend CSVFields = split(RawData, '\t') | extend Timestamp = CSVFields[0] | extend Process = CSVFields[1] | extend TID = CSVFields[2] | extend Area = CSVFields[3] | extend Category = CSVFields[4] | extend EventID = CSVFields[5] | extend Level = CSVFields[6] | extend Message = CSVFields[7] | extend Correlation = CSVFields[8]
Dieser kann natürlich gerne angepasst werden. 🙂
Somit ist die grundlegende Konfiguration abgeschlossen und nun geht es darum entsprechende Abfragen zu bauen. Dafür erstelle ich aber vielleicht später noch einen weiteren Blogbeitrag, weil es bei diesem Artikel eigentlich um die initiale Konfiguration geht.