Enterprise Monitoring

Beim Betrieb einer IT-Landschaften werden sehr viele "Meldungen" generiert, die jedes System in seiner Welt verwaltet. Als Firma haben Sie aber den Bedarf, dass Sie Warnungen und Fehler nicht nur mitbekommen, sondern auch speichern, durchsuchbar machen und vieleicht sogar miteinander in Bezug setzen. Wer sich schon mal einen Crypto-Trojaner (Emotet) eingefangen hatte oder durch den Hafnium: Exploit die Spuren der Einbrecher nachverfolgen durfte, weiß um den Bedarf an einem leistungsfähigen Logging.

Ich habe diese Seite bei Windows/Security eingeordnet, da ein zentrales Logging meist von der IT-Security angeführt wird.

Die Nachrichtenkette

Zwischen der Quelle einer Meldung und der Auswertung am Ende kommen aber einige Zwischenstationen ins Spiel.

  • Quelle
    Die meisten Systeme protokollieren ihre Meldungen irgendwie auf dem System. Zwar gibt es schon lange mit "SYSLOG" eine Art Standard zur zentralisierten Protokollierung aber oft nutze gerade mal Netzwerkgeräte diesen Weg. Alle anderen Systeme schreiben lokale Datenbanken, Text-Dateien o.ä., die Sie nach einiger Zeit auch wieder überschreiben. Übrigens können auch die Ergebnisse von "Überwachungen", z.B. DiskFree, CPU-Last, LooksAlive/IsAlive-Meldung auch als "Meldung" definiert und über die weiteren Prozess übertragen werden. Damit streut ein Enterprise Logging auch in den Bereich "Monitoring" mit rein.
  • Sammler/Präprozessor
    Daher braucht es ein Werkzeug, welches diese Datenquellen anzapft und an eine zentrale Stelle sendet. Allerdings wäre es unmöglich alle Meldungen aller Quellen zu übermitteln. Hier sollte schon eine Vorfilterung auf die relevanten Informationen erfolgen. Der lokale Service kann ja gerne die detaillierten Logs einige Tage vorhalten. Der Agent kümmert sich dann um die sichere Weiterleitung der Daten und puffert diese, wenn der nächste Abschnitt ein Problem hat.
  • Übertragungsweg
    SYSLOG ohne Verschlüsselung übe den Port 514 mag in einem Management-LAN für Switches noch OK sein aber schon im internen LAN ist es zu anfällig gegen Störungen, Ausspähungen etc. heute ist eine per TLS gesicherte und authentifizierte Übertragung Standard. Das kann SYSLOG sein oder natürlich HTTPS, womit der lokale Agent auch weiter entfernt vom Backend  z.B. in der Cloud stehen können.
  • Empfänger
    Das Backend muss die Daten natürlich annehmen und da die Agenten besser nicht direkt in eine Datenbank schreiben sollten, gibt es einen Sammelprozess. Dieser kann sogar mehrere Schnittstellen unterstützen, die angekommenen Daten noch weiter parsen um sie dann letztendlich in eine Datenbank zu schreiben.
  • Speicherung
    Alle Meldungen landen in einem Datenspeicher. Größere Systeme erlauben die Ablage auf mehreren redundanten Servern und unterscheiden sogar Hot/Warm/Cold-Daten, d.h. aktuelle Daten landen vielleicht nur im Speicher oder SSDs während ausgewählte Daten auch in einem historischen Langzeitspeicher verbleiben.
  • Aufbereitung/Auswertung Manuell/automatisch
    Die Inforationen in der Datenbank können von Administratoren interaktiv, z.B. eine Webseite ausgewertet werden. Interessant ist aber auch der Ansatz über "Wissen" diese Daten automatisch zu bewerten und Aktionen daraus abzuleiten. Das ist ein weites Feld und zukünftig wird hier KI sicher eine große Rolle spielen. Auch die Analyse auf "Angriffe" durch ein SIEM setzt auf solche Meldungsketten auf.
  • Anzeige
    Der Empfänger der Informationen ist natürlich ein Administrator oder auch der Prozess-Verantwortliche, der über verschiedene Wege die Daten einsehen kann. Meist ist es ein Browser oder Meldung per Mail o.a.

Schauen wir uns die verschiedenen Bereich etwas an, denn sie müssen hier nichts selbst entwickeln. Es gibt gleich mehrere kommerzielle Anbieter und kostenfreie Open Source Lösungen. Die Herausforderung "Enterprise Logging" ist nicht neu und größere Firmen oder Hoster haben hier schon lange entsprechende Lösungen umgesetzt.

Mit der zunehmenden Bedeutung von IT, der Nachvollziehbarkeit von Vorgängen und der Abwehr von Cyber-Angriffen wird das Thema aber auch für mittlere und kleinere Firmen relevant.

Klassifizierung

Seit vielen Jahren nutze ich PRTG zuhause, bei Net at Work und anderen Kunden und es macht ziemlich viel richtig. Aber natürlich gibt es auch fehlende Funktionen wie z.B. die nicht vorhandene Log-Verarbeitung und die vielleicht in die Jahre gekommene Datenbank. Andere Tools sind besser bei der Logverarbeitung aber schwächeln bei den Diagrammen und wieder andere sind wahre Zahlenfresser, an für deren Visualisierung man sich aber erst entsprechende Filter und Dashboards bauen kann. Ich schaue mir verschiedene Tools nach folgenden Kriterien an:

Bereich Vertreter

Aktive Funktionstests mit Checks, Messwerten, Statusanzeige und Charts

PRTG, CheckMK, Nagios, WhatsUp u.a.

Verarbeitung von "Events" mit Quelle, Nachricht und ggfls. parsen und extrahieren von Feldern und Werten

Graylog, Splunk, Syslog, Azure Log Analystics

Sammeln aller möglicher Werte in eine Datenbank mit Visualisierungsdashboards

 Telegraf/Influx/Grafana (TIG)
Elastic/LogBeat/Kibana (ELK)

Es gibt natürlich immer Produkte, die mit Kompromissen in auch in den anderen Bereichen wildern. Wenn ich es drauf anlege, dann kann ein Logging-System die zeilenweisen Meldungen natürlich parsen und in eine Datenbank so schreiben, dass ein anderes Framework drauf Bilder macht und ein "Testsystem" schreibt auch Werte und Logs.

Quellen

Wenn alles eine Meldung ist, dann solle jeder Administrator auch ohne Spickzettel gleich mehrere Quellen aufführen können. Es sind genau die Datentöpfe, in die Sie bei einem Fehler schauen. Hier eine unvollständige Liste:

  • Netzwerk-Geräte
    z.B. Router und Switches, die lokal nur wenig Speicher haben und üblicherweise ihre Meldungen per SYSLOG loswerden wollen. z.B. neu gelernte MAC-Adressen mit Port, 802.1x-Authentifizierungen oder regelmäßige numerische Meldungen zu übertragenen Paketen und Bytes, Anmeldeversuche an der Konsole und Konfigurationsänderungen.
  • Netzwerk-Dienste: DNS, DHCP, Routing
    Auch die Vergabe von IP-Adressen per DHCP oder Änderungen am DNS-Server sind relevant. Aus der Information, welcher Client welche Namen abruft, können Rückschlüsse auf Fehlkonfigurationen oder Kontaktversuche zu einem Command&Control-Server nachverfolgt werden.
  • Windows Eventlog
    Wenn ich an meine Windows Server denken, dann fällt hier direkt das Eventlog ein, welches umfangreiche Informationen protokolliert. Sie können Windows sogar anweisen, noch mehr Daten (An/Abmeldungen, Netzwerkverbindungen, Prozess-Starts, etc.) zu erfassen. Das macht aber nur Sinn, wenn Sie die Daten dann auch auswerten.
  • WebServerlogs (IIS/Apache, NGIX)
    Beliebtes Ziel sind natürlich Webserver und die Zugriffe auf Informationen. Für das Tracking der Anwender gibt es andere Werkzeuge aber eine Überwachung der Zugriffe auf ungültige URLs liefern Hinweise auf Angriffe oder auch Probleme einer gehosteten Anwendung. Ich denke nur an die Felder "Bytes-In/Bytes-Out/Time-Taken" beim IIS, über den Sie indirekt die Reaktionsgeschwindigkeit ihrer Applikationen auf dem Client abschätzen können.
    Mit etwas mehr Logik könnten Sie eine "Allowlist" der erlaubten Seiten führen und Zugriffe auf "nicht existente Seiten" als Angriff erkennen. Insbesondere, wenn diese dann mit einem 200-Code beantwortet würden.
  • Firewall/Proxy-Server
    Hoffentlich protokolliert ihr Firewall alle verbotenen Verbindungen, speziell von Innen nach Außen aber schauen Sie sich diese Protokolle regelmäßig an? Noch interessanter sind aber erlaubte Wege von intern nach extern, die nach einen Einbruch einer genaueren Analyse unterzogen werden sollten.
  • NetFlow/Paketsniffer
    Auch im internen LAN (Siehe Interne Firewalls) sollten sie nicht blind vertrauen sondern zumindest schützenswerte oder direkt von extern erreichbare Server abtrennen und die Verbindungen erfassen.
  • Exchange Message Tracking
    Jeder Exchange Server protokolliert übertragene Nachrichten und natürlich können Sie diese per OWA oder PowerShell bei Bedarf auch auswerten. Es kann aber auch interessant sein, eine Teilmenge davon, z.B. die "Losgeschickt" und "Zugestellt"-Meldungen gesondert zu erfassen.
  • Skype SDN-Logging
    Auf der Seite SDN 3.0 habe ich beschrieben, wie A/V-Verbindungen in Realtime erfasst und zur Steuerung von Netzwerkgeräten verwendet werden könnten. Solche Daten könnten aber auch für Fehlersuche und Visualisierung nützlich sein.
  • Teams Call-Logging
    Es muss nicht immer ein lokaler Service sein. Auch Cloud-Dienst erlauben bestimmte "Erfassungen" von Daten und die Cloud meldet diese aktiv per Webhook an ihre Plattform.
  • AD-Änderungen
    Mit dem Skript Get-USNChanges habe ich exemplarisch gezeigt, wie ich Änderungen im Active Directory überwachen kann. Bis auf Feldebene geht es sogar mit GET-ADChanges. Solche Daten können bei der Fehlersuche und nach Angriffen Gold wert sein.
  • Konfigurationsänderungen
    Generell können Sie mit dem passenden Agenten sogar Konfigurationsänderungen erfassen und damit das Change-Management unterstützen. Das gilt für Änderungen auf Routern und Switches genauso wie PowerShell oder ganze Konfigurationsdateien. Vielleicht wollen Sie auch ausgeführte Shell-Befehle oder die PowerShell-History einsammeln, damit sie später Vorgänge nachvollziehen können.

Sie sehen aber, dass einige Quellen nicht nur einfaches "Logging auf Vorrat" sind, sondern bestimmte Daten auch von einem SIEM erfasst werden können und auch das Monitoring von Systemen davon profitieren kann. Wenn ein Prozess regelmäßig Kennzahlen oder auch einfach nur seine "Gesundheit" erfasst, dann kann dies per Logging ebenfalls eingesammelt und beim Ausbleiben alarmiert werden. Die Grenzen sind hier fließend.

Es gibt noch viele weitere Quellen und sie müssen schon drauf achten, dass schon die Erfassung "im Rahmen" bleibt. Datenschutz, Datensparsamkeit und Mitbestimmung sind wichtig und auch die Verarbeitung der Datenmenge erfordert entsprechende Systeme, Konfigurationen und sind eine zusätzliche Belastung.

In einem modernen Auto fahren wir alle Airbags, ABS und andere Helfer umher, die wie hoffentlich nie brauchen aber dennoch bezahlt, betrieben und gewartet werden müssen. Das zusätzliche Gewicht reduziert die Leistung und kostet mehr Treibstoff. Auch beim Logging gilt es sinnvolle Dinge zu erfassen.

Programme und Produkte

Wie so oft gibt es nicht nur genau eine Software für die verschiedenen Aufgaben neben den kommerziellen Programmen gibt es sehr viele "Open Source"-Lösungen, die sogar noch miteinander kombiniert werden können. Damit haben wir aber wieder das Problem, dass es nicht "ein" Produkt sondern ganz viele Programme mit überlappenden Fähigkeiten gibt und bestimmte Konstellationen haben eigene Communities. Mir sind bislang folgende "Stacks" über den Weg gelaufen.

  • ELK-Stack
    Dahinter verstecken sich die Programme "Elasticsearch", "Logstash" und "Kibana"
  • TIG-Stack
    Dieses Kürzel steht für "Telegraf, InfluxDB und Grafana".
  • Graphite/StatsD
    Hat keine Agenten sondern nur "Carbon" um Meldungen anzunehmen und in "Whisper" abzulegen und mit Graphite-Web auszuwerten
  • Microsoft Sentinel
    Microsoft hat selbst und in der Cloud natürlich auch ein SIEM und Event-Management. Unter dem Namen Sentinel könenn Sie es für ihre eigene Firma einsetzen.
    What is Microsoft Sentinel? https://learn.microsoft.com/en-us/azure/sentinel/overview

Das sind aber noch nicht alle Begriffe, die in dem Umfeld immer wieder auftauchen. Nicht alle Programme lassen sich auch immer klar in eine Bereich einsortieren.

Viele Programme sind "Open Source" aber damit nicht automatische kostenfrei. Die Anbieter finanzieren sich meist über eine "Cloud-Version", so dass Sie selbst nur wenig installieren müssen und selbst betriebene Versionen haben nicht immer alle Funktionen (Cloud First-Ansatz)

Das Problem bei der Vielzahl ist, dass die Code-Qualität durchaus unterschiedlich ist und auch einige Projekte aktiver sind und andere vielleicht bald eingestellt werden.

Da Windows Administratoren "gerne" auch mit Windows Diensten arbeiten, habe ich die Systeme mit Windows Binaries gekennzeichnet

Als Spickzettel habe ich mir folgende Tabelle gebaut:

Baustein Beispiele

Agenten

Auf der Quelle braucht es meinst einen Agenten, der die Daten einsammelt. Einige Systeme können aber selbst z.B. Syslog-Meldungen senden oder werden von einem Agenten auf einem anderen Server "aus der Ferne" abgefragt. Hier kann auch schon die erste Filterung stattfinden, um die Datenmenge zu reduzieren.

Die meisten Agenten unterstützen nativ oder über Plug-ins verschiedene Quellen aber auch Ziele.

Gegenstelle

Meist dürfen die Agenten nicht direkt in eine zentrale Datenbank schreiben. Eine Middleware nimmt daher die Verbindung der Agenten an und schreibt die Daten in das Backend, welches je nach Plattform auch redundant und mit Hot/Warm/Cold-Storage ausgestatte sein kann. Diese Zwischenstelle übernimmt auch das Parsing der Eingaben, um diese mit mehr "Struktur" in eine Datenbank zu schreiben. Wenn in den Meldungen z.B. Werte in Form von "Zahlen" enthalten sind, dann kann man sie "sparsamer" als Zahl speichern und später auch einfacher damit rechnen. Es lohnt sich also beim Empfang die Zahl zu erfassen und nicht später in String zu suchen.

Datenbank

Bei der Speicherung vieler Logs kommen erst einmal nur "Zeilen" unterschiedlicher Länge an, die mit einer Quelle und einem Zeitstempel versehen werden. Der Begriff dafür ist "Zeitreihendatenbank" (Time Series Database), weil quasi immer nur vorne reingeschrieben wird. Das Nutzungsmodell ist also nicht mit einer klassischen SQL-Datenbank zu vergleichen, bei der Wahlfrei mehrere Tabellen mit Verlinkungen durch eine Buchhaltung beschrieben und gelesen werden. Besonders interessant sind "Continuous Queries", bei der neue Daten dem abfragenden Prozess nachgeliefert werden.

  • ElasticSeach (ELK)
  • InfluxDB (TIG)
    TimeseriesDB in GO geschrieben.
    Kommerzielle Version erlaubt Scaling und Cluster (?)
  • Azure Log Analytics Workspace
  • Whisper (Graphite)
    Im Stiel einer RRD-Datenbank mit eigener Datei pro Zeitserie
  • LevelDB - Datenbank hinter Prometheus
    https://github.com/syndtr/goleveldb
  • Redis
    Wird z.B.: von Statsman (vormals LyncDash) genutzt.
  • Apache Kafka
  • MongoDB
  • OpenTSDB (U)

Auswertung

Die Auswertung der Daten ist auch sehr unterschiedlich zu z.B. einem ERP oder CRM-System. Meist sind große Datenmengen zu durchsuchen.

  • Kibana (ELK)
  • Grafana (TIG)
  • Graphite-Web (Graphite)

Diese Liste ist sicher nicht vollständig und erst reicht kein qualifizierter Produktvergleich.

Weitere Dienste

Natürlich gibt es noch andere "Spezialisten", auf die sie noch stoßen könnten.

Programm/Produkt

Beschreibung

Prometheus (W/U/andere)

Angeblich das meist genutzte System für Docker und Microservices, die von Prometheus aktiv per HTTPS abgefragt, in eine Datenbank gespeichert und die Ergebnisse per Webseite unter folgender URL bereitgestellt werden.

https(s)://<hostaddress>/metrics

Das zu überwachende System muss also von Prometheus erreichbar sein und die passende Schnittstelle anbieten oder ein "Exporter" muss diesen HTTP-Punkt bereitstellen oder sie addieren dies in ihre eigene Software.

How Prometheus Monitoring works | Prometheus Architecture explained
https://www.youtube.com/watch?v=h4Sl21AKiDg

Prometheus: The Documentary
https://www.youtube.com/watch?v=rT4fJNbfe14

Bei Prometheus pollt der Service die zu überwachenden Server. es ist kein "Push" und hat auch wenig mit Logs-Messages am Hut.

Prometheus ist um 2012 durch die Firma "SoundCloud" entstanden, weil es aus Sicht der Entwickler keine Überwachungslösung für ihren Fall gegeben hat. Die zu überwachenden Systeme müssen selbst eine API bereitstellen, mit der die Daten abgefragt werden können. Eine gängige URL ist dabei:

http://<servername>:9090/metrics

Die Services sollten sich auch z.B. im DNS registrieren da in Prometheus dann die Hostnamen als abzufragenden Dienste konfiguriert werden. Wenn Sie also viele Docker-Container u.a. Services dynamisch starten, beenden oder auch zwischen Servern verschieben, dann werden die entsprechenden DNS-Einträge addiert, aktualisiert oder entfernt und die Überwachung passt sich dynamisch dran an.

Prometheus besteht natürlich nicht nur aus der Schnittstelle zum Agenten sondern enthält eine Zeitreihen-Datenbank mit pfiffiger Abfragespache. Darum gehe ich aber hier nicht weiter ein.

Introduction to Logging with the ELK Stack
https://www.elastic.co/pdf/introduction-to-logging-with-the-elk-stack

Einschätzung

Bei der Vielzahl an Bausteinen, Produkten und Lösungen gibt es von mir keine Empfehlung. Nur den Ratschlag sich mit der Thematik zu beschäftigen und das Potential zu erkennen. Ich möchte einen Administrator oder IT-Betreiber nicht mit einem Geheimdienst vergleichen, die möglichst viel auf Verdacht sammeln ohne zu wissen, wozu es gut ist. Aber in der IT sollten Sie auch nicht zu wenig Daten für den Eigenbedarf erheben.

Auch wenn Sie mit einem solchen Monitoring den Status von Diensten und sogar numerische Werte erfassen können, ersetzt so eine Lösung erst einmal nicht das klassische "Netzwerkmanagement" per SNMP und die Availability-Überwachung in Form eines PRTG, WhatsUp, Hostmon o.ä. Die Kosten für so ein System müssen sich aber die verschiedenen Gruppierungen einer Firma teilen:

  • IT-Security
    Weil viele Vorgänge und Meldungen essentiell für die Erkennung von Angriffen und deren Reichweite sind.
  • Compliance
    Weil Änderungen an Rechten, Benutzern, Kennworten, Dateien, Datensätzen etc. gefordert sein können
  • Marketing und Vertrieb
    Die Zugriffe auf Webseiten aber auch z.B. Bestellseiten eines Webshops liefern bessere Einblicke in die Nutzung
  • Entwickler
    Wenn Sie ihn ihrem Code entsprechende Diagnoseausgaben und Perfomance-Werte an das System übergeben, können Sie Störungen und Leistungseinbußen leichter dingfest machen.
  • Administratoren
    Zuletzt haben natürlich auch die klassischen IT-Administratoren einen Vorteil von einer zentralen Stelle bei der Suche nach Abhängigkeiten, Fehlern, Meldungen

Aber sie werden sich irgendwie zusammenraufen müssen, wenn Sie wirklich eine gemeinsame Basis nutzen wollen.

Weitere Links