Monitoring mit Graylog: Logs zentral auswerten und gezielt alarmieren

Monitoring mit Graylog hilft IT-Teams, Ereignisse aus verteilten Systemen an einem Ort zu untersuchen. Statt bei einer Störung nacheinander Serverprotokolle, Firewall-Logs und Anwendungsmeldungen zu öffnen, können Administrator:innen die Daten zeitlich und inhaltlich zusammenführen. Der Nutzen entsteht allerdings nicht schon durch das Sammeln möglichst vieler Nachrichten: Erst sauber benannte Felder, passende Suchabfragen und überprüfte Alarmregeln machen aus Logs ein brauchbares Monitoring-Werkzeug.

Dieser Artikel erklärt die Architektur und zeigt, wie Unternehmen Graylog für operatives Monitoring, Fehleranalyse und sicherheitsbezogene Ereignisse einführen. Die Beschreibung orientiert sich an der Graylog-7.1-Dokumentation. Einzelne Funktionen hängen vom eingesetzten Produkt – Graylog Open, Enterprise oder Security – und von der jeweiligen Version ab.

Was ist Graylog?

Graylog ist eine Plattform zur zentralen Erfassung und Analyse von Logdaten. Sie nimmt beispielsweise Syslog-Meldungen von Netzwerkgeräten, Anwendungslogs im GELF-Format oder Ereignisse von Windows- und Linux-Systemen entgegen. Eingehende Nachrichten können strukturiert, angereichert, bestimmten Streams zugeordnet und anschließend durchsucht werden. Dashboards visualisieren ausgewählte Ergebnisse; Event-Definitionen können bei erfüllten Bedingungen Benachrichtigungen auslösen.

Der Fokus liegt auf Ereignissen und ihren Zusammenhängen. Eine CPU-Auslastung von 95 % ist zunächst eine Metrik. Eine Anwendungsfehlermeldung unmittelbar nach einem fehlgeschlagenen Datenbankverbindungsversuch ist dagegen ein Logereignis, das Graylog analysieren kann. Zwar lassen sich aus Logs auch Zählwerte und Trends ableiten, doch für regelmäßige Messungen von Ressourcenauslastung und Erreichbarkeit bleibt ein klassisches Metrik- oder Check-Monitoring eine sinnvolle Ergänzung.

Wie funktioniert die Graylog-Architektur?

Der Graylog-Stack besteht im dokumentierten Standardmodell aus drei Kernkomponenten: Graylog verarbeitet und visualisiert Nachrichten, der Graylog Data Node übernimmt Speicherung und Suche, und MongoDB hält Konfigurationen sowie Metadaten vor. Graylog empfiehlt Data Node als verwaltetes Such-Backend; ein selbst verwaltetes OpenSearch ist möglich, bringt jedoch eigene Betriebsaufgaben mit sich. MongoDB speichert nicht die eigentlichen Lognachrichten. Diese Trennung ist für Backup, Kapazitätsplanung und Fehlerdiagnose wichtig.

Der typische Weg einer Nachricht sieht so aus:

1. Eine Quelle erzeugt einen Logeintrag, etwa ein Webserver, eine Firewall oder eine Anwendung.
2. Ein Collector oder das Quellsystem sendet die Nachricht an einen passenden Graylog-Input.
3. Graylog parst die Nachricht und kann Felder extrahieren oder ergänzen.
4. Streams ordnen die Nachricht einem fachlichen Bereich zu; Pipelines transformieren oder filtern sie.
5. Der Suchspeicher indexiert die Nachricht gemäß den vorgesehenen Index- und Aufbewahrungsregeln.
6. Suchabfragen, Dashboards und Event-Definitionen werten die gespeicherten Daten aus.

Zusätzlich besitzt Graylog ein Message Journal als Puffer vor der weiteren Verarbeitung. Es kann kurzfristige Störungen des Such-Backends abfangen, ist aber kein unbegrenzter Ersatz für Speicherkapazität. Erreicht es die konfigurierte Größen- oder Altersgrenze, können Nachrichten verloren gehen. Neben der Verfügbarkeit der Graylog-Oberfläche müssen daher auch Eingangsrate, Journal-Füllstand und Zustand des Data Node überwacht werden.

Welche Logquellen eignen sich für Graylog?

Ein guter Einstieg sind Quellen, bei denen Logs eine konkrete betriebliche Frage beantworten. Für einen Pilotbetrieb reicht es oft, eine Anwendung, ihre Datenbank, die vorgeschaltete Infrastruktur und die zugehörigen Authentifizierungsereignisse zu betrachten. So kann das Team einen vollständigen Fehlerweg untersuchen, ohne sofort alle Systeme anzubinden.

Graylog unterstützt unter anderem Inputs für Syslog, GELF, CEF, HTTP, Beats und Rohdaten. Nicht jedes Gerät erzeugt jedoch formal korrekte Syslog-Nachrichten. Wenn Felder fehlen oder Zeitstempel falsch interpretiert werden, sollten Teams bereits die Ausgabe der Quelle und den gewählten Input prüfen, bevor sie komplexe Suchregeln aufbauen.

Für Hosts mit mehreren Logdateien kann Graylog Sidecar die Konfiguration geeigneter Collectors zentral verwalten. Entscheidend ist die Rollenverteilung: Sidecar steuert den Collector; der Collector liest die Logs und sendet sie an einen zuvor eingerichteten Graylog-Input. Ein korrekt registrierter Sidecar allein beweist daher noch nicht, dass Nachrichten in Graylog ankommen.

Wie werden Logs zu nutzbaren Monitoring-Daten?

Rohtexte erschweren belastbare Abfragen. Wenn ein Dienst beispielsweise „Database connection failed“ meldet, sollte nach Möglichkeit nicht nur der vollständige Nachrichtentext vorliegen. Hilfreich sind getrennte Felder wie service, environment, host, error_code oder request_id. Damit kann ein Team gezielt Produktionsfehler eines Dienstes zählen, statt nach einem Wort zu suchen, das auch in harmlosen Meldungen vorkommt. Graylog nutzt solche Felder für Suche, Filter und Aggregationen.

Streams fassen passende Nachrichten zusammen, etwa „Produktionsanwendungen“ oder „Firewall-Ereignisse“. Pipelines wenden Regeln auf Nachrichten an und können Felder extrahieren, umbenennen, anreichern oder Nachrichten in weitere Streams leiten. Eine Pipeline verarbeitet allerdings nur Nachrichten, wenn sie mit einem passenden Stream verbunden ist. Auch die Reihenfolge der Nachrichtenprozessoren kann beeinflussen, ob eine Regel die benötigten Felder bereits vorfindet.

Für ein wartbares Datenmodell sollten Unternehmen Feldnamen und Datentypen früh festlegen. Wenn beispielsweise derselbe Fehlercode in einer Quelle als Zahl und in einer anderen als Text ankommt, werden gemeinsame Auswertungen unnötig schwierig. Ebenso sollten Test-, Entwicklungs- und Produktionslogs eindeutig unterscheidbar sein. Ein kleiner Satz konsistenter Felder ist für Dashboards und Alarme nützlicher als viele unterschiedlich benannte Felder ohne gemeinsame Bedeutung.

Wie funktionieren Dashboards und Alarmierung?

Dashboards zeigen Ergebnisse gespeicherter Suchabfragen in Widgets, etwa Fehlerzahlen im Zeitverlauf oder die Verteilung von Meldungen auf Anwendungen. Sie eignen sich für Lagebilder und wiederkehrende Betriebsbesprechungen. Ein Dashboard allein alarmiert jedoch niemanden: Für eine Benachrichtigung benötigt Graylog eine Event-Definition und eine dazu passende Notification.

Ein einfaches Anwendungsszenario ist die Häufung fehlgeschlagener Anmeldungen. Statt jede einzelne Fehlanmeldung zu melden, kann eine Event-Definition mehrere passende Ereignisse innerhalb eines Zeitfensters auswerten und nur bei Erreichen eines festgelegten Schwellwerts alarmieren. Die passende Zahl ist keine allgemeingültige Produkteinstellung: Sie sollte aus Normalbetrieb, Benutzerverhalten und Risiko der konkreten Umgebung abgeleitet werden. Grace Periods können verhindern, dass identische Ereignisse in kurzer Folge einen Benachrichtigungsstau auslösen.

Eine brauchbare Alarmmeldung nennt mindestens betroffenes System, Ereignis, Zeitraum und einen Weg zur Untersuchung der zugrunde liegenden Logs. Vor dem Produktivbetrieb sollten Teams testen, ob der Alarm bei einem bekannten Fehler tatsächlich ausgelöst wird und ob er im Normalbetrieb unnötige Benachrichtigungen erzeugt. Dabei ist die Lizenz zu beachten: Script- und PagerDuty-Benachrichtigungen sind Enterprise-Funktionen.

Wo liegen die Grenzen von Graylog-Monitoring?

Graylog beantwortet besonders gut Fragen wie „Was ist wann passiert?“ und „Welche Meldungen traten gemeinsam auf?“. Ein klassisches Monitoring-System prüft dagegen regelmäßig Zustände: Läuft der Dienst? Antwortet der Endpunkt? Wie hoch sind CPU-Auslastung oder Speichernutzung? Diese Perspektiven ergänzen sich. Ein Erreichbarkeitsalarm kann eine Störung melden; Graylog hilft anschließend, die begleitenden Fehler- und Änderungsereignisse zu untersuchen.

Wer Graylog als „Monitoring für alles“ einführt, riskiert blinde Flecken. Besonders kritisch ist das Ausbleiben erwarteter Logs: Keine Fehlermeldung kann bedeuten, dass alles funktioniert – oder dass ein Collector ausgefallen ist. Die Datenlieferung selbst gehört deshalb in das Überwachungskonzept.

Wie dimensioniert man Graylog für den Betrieb?

Die Architektur sollte zur täglichen Datenmenge, Suchlast und gewünschten Aufbewahrungsdauer passen. Graylog unterscheidet in seiner Planung unter anderem kleinere Core-Deployments und mehrknotige Modelle für größere produktive Umgebungen. Ein kompaktes Deployment ist leichter aufzubauen, bietet aber nicht automatisch Ausfallsicherheit. Wer Logdaten für die Störungsanalyse zwingend benötigt, sollte die Verfügbarkeit aller drei Kernkomponenten und des Eingangswegs betrachten.

Für die Planung nennt Graylog als grobe Orientierung für den durchsuchbaren Datenspeicher: tägliche Datenmenge × Aufbewahrungstage × 120 %. Diese Formel ist eine erste Schätzung, keine Kapazitätsgarantie. Parsing, Indexstruktur, Replikate, Suchverhalten und Lastspitzen können den tatsächlichen Bedarf verändern. Auch das Message Journal braucht eigenen, ausreichend schnellen Speicher. Die Voreinstellung für den Journal-Puffer beträgt maximal 5 GB beziehungsweise 12 Stunden; seine Größe sollte an die erwartete Datenmenge angepasst werden.

Beispiel: Werden täglich 20 GB Logs aufgenommen und sollen sie 30 Tage direkt durchsuchbar sein, ergibt die genannte Faustformel zunächst rund 720 GB für die Planung des Suchspeichers. Hinzu kommen Architektur- und Betriebsreserven, etwa für Replikate und Spitzenlast. Ein Pilot mit repräsentativen Quellen zeigt genauer, welche Datenmenge, Feldzahl und Suchlast tatsächlich entstehen.

Wie schützt man sensible Logdaten?

Logs können Benutzernamen, IP-Adressen, Fehlermeldungen mit personenbezogenen Angaben oder sogar versehentlich protokollierte Geheimnisse enthalten. Daher sollte ein Graylog-Projekt nicht nur Suchbarkeit, sondern auch Zugriff und Datenminimierung planen. Fachliche Verantwortliche müssen entscheiden, welche Ereignisse gebraucht werden, wer sie sehen darf und wann sie gelöscht werden. Die technische Aufbewahrung über Index-Sets sollte diese Entscheidungen umsetzen.

Netzwerkzugriffe sollten auf notwendige Ports und vertrauenswürdige Bereiche begrenzt und die Kommunikation zwischen Komponenten sowie Clients verschlüsselt werden. Insbesondere MongoDB und das Such-Backend gehören nicht offen ins öffentliche Internet. Für übertragene Logs sollten passende TLS-fähige Inputs und vertrauenswürdige Zertifikate eingesetzt werden. Rollen und Berechtigungen sollten sich an den tatsächlichen Aufgaben der Teams orientieren.

Auch Backups sind mehrteilig: Konfigurationen und Metadaten in MongoDB, Graylog-Konfigurationsdateien sowie Logdaten im Such-Backend erfüllen unterschiedliche Aufgaben. Ein Wiederherstellungstest muss zeigen, ob diese Bestandteile nach einem Ausfall zusammenpassen. Ein gesichertes Dashboard ohne die benötigten Logs – oder erhaltene Logs ohne zugehörige Konfiguration – reicht für den Betrieb nicht aus.

Wie startet ein Unternehmen mit Graylog?

1. Anwendungsfall wählen. Beginnen Sie mit einer konkreten Frage, etwa der Analyse von Anmeldeproblemen oder wiederkehrenden Fehlern eines Geschäftsdienstes.
2. Quellen und Datenbedarf festlegen. Erfassen Sie die nötigen Systeme, Logformate, erwarteten Mengen und verantwortlichen Teams.
3. Architektur und Schutzbedarf planen. Dimensionieren Sie Graylog, Data Node, MongoDB, Journal und Aufbewahrung; definieren Sie Zugriffsrechte und Transportverschlüsselung.
4. Inputs und Collectors einrichten. Prüfen Sie mit Testnachrichten, ob Daten vollständig, zeitlich korrekt und im passenden Stream ankommen.
5. Felder und Pipelines entwickeln. Normalisieren Sie die für Suche und Alarmierung wichtigen Werte zuerst für wenige Quellen.
6. Dashboard und Event-Definition testen. Lösen Sie ein bekanntes Testereignis aus und prüfen Sie Benachrichtigung, Kontext und Fehlalarmrate.
7. Graylog selbst überwachen. Kontrollieren Sie unter anderem Datenzufluss, Journal, Indexzustand, Speicherkapazität und den Zustand der Komponenten.

Dieser Ablauf verhindert, dass ein großes Logarchiv ohne klare betriebliche Nutzung entsteht. Erst wenn der Pilot einen Fehler nachvollziehbar erkennt und das Team den Alarm bearbeiten kann, lohnt sich die schrittweise Anbindung weiterer Quellen.

Benötigt Graylog zwingend OpenSearch?

Graylog benötigt ein geeignetes Such-Backend für die Speicherung und Abfrage der Lognachrichten. Der empfohlene Weg ist Graylog Data Node, der das Such-Backend verwaltet und dessen Cluster- und Zertifikatsverwaltung vereinfacht. Ein selbst betriebenes OpenSearch ist möglich, erfordert aber zusätzliche Verantwortung für Kompatibilität, Absicherung und Betrieb. Unabhängig davon bleibt MongoDB eine separate Komponente für Metadaten und Konfigurationen. Eine Planung, die lediglich „Graylog plus Datenbank“ vorsieht, bildet den tatsächlichen Stack deshalb nicht ausreichend ab.

Wie lange sollten Logs in Graylog aufbewahrt werden?

Dafür gibt es keine pauschale Zahl. Die passende Aufbewahrung ergibt sich aus Störungsanalyse, Sicherheitsanforderungen, internen Vorgaben, Schutzbedarf und verfügbarer Speicherkapazität. Graylog kann Daten über Index-Sets und Aufbewahrungsregeln organisieren; für längerfristige Speicherung kommen je nach Produkt und Lizenz weitere Funktionen infrage. Entscheidend ist, dass die festgelegte Frist technisch umgesetzt und regelmäßig überprüft wird. Wer alle Logs gleich lange behält, speichert möglicherweise unnötige Daten oder löscht wichtige Ereignisse zu früh.

Wie erkennt Graylog, dass keine Logs mehr ankommen?

Das Ausbleiben von Nachrichten muss ausdrücklich als Betriebsrisiko betrachtet werden. Ein Sidecar kann erreichbar sein, obwohl der Collector keine Dateien mehr liest oder der zugehörige Graylog-Input keine Nachrichten erhält. Umgekehrt können Daten Graylog erreichen, aber wegen Routing-, Pipeline- oder Indexproblemen nicht in der Suche erscheinen. Verantwortliche sollten deshalb den gesamten Weg vom Quellsystem bis zum Suchergebnis prüfen und für wichtige Quellen eine erwartete Datenlieferung überwachen. Die konkreten Schwellenwerte hängen vom normalen Nachrichtenaufkommen der jeweiligen Quelle ab.

Welche Logquellen sollte ein Unternehmen zuerst anbinden?

Am sinnvollsten sind Quellen, die gemeinsam eine konkrete Störung oder ein Sicherheitsereignis erklären können. Für eine Webanwendung wären das beispielsweise Anwendungslog, Webserver, Datenbank und der relevante Anmeldeweg. So lassen sich Zeitstempel, Kennungen und Fehlermeldungen miteinander abgleichen. Die sofortige Anbindung aller Geräte vergrößert dagegen Datenmenge und Pflegeaufwand, ohne automatisch bessere Erkenntnisse zu liefern. Vor dem Rollout sollten Verantwortliche auch prüfen, ob Nachrichten sensible Inhalte enthalten und ob die benötigten Felder zuverlässig extrahiert werden.

Gibt es Graylog kostenlos?

Graylog Open wird als kostenlose Open-Source-Variante für zentrales Logmanagement angeboten. Graylog Enterprise erweitert sie um zusätzliche Funktionen, unter anderem für anspruchsvollere Analysen, Archivierung, Berichte und Support. Graylog Security ist ein gesondert lizenzierter Sicherheitsbereich. Eine Architekturentscheidung sollte deshalb die tatsächlich benötigten Funktionen mit dem konkreten Lizenzmodell abgleichen. Insbesondere sollten Teams nicht voraussetzen, dass jede in einer Produktdokumentation beschriebene Benachrichtigungs-, Archivierungs- oder Sicherheitsfunktion bereits in Graylog Open verfügbar ist.

Ist Graylog ein vollständiger Ersatz für Icinga oder Nagios?

Nein, nicht ohne eine bewusste Änderung des Überwachungskonzepts. Graylog konzentriert sich auf Logs, Suche, Ereignisse und daraus abgeleitete Alarme. Icinga und Nagios stehen typischerweise für aktive Checks und die Zustandsüberwachung von Hosts und Diensten. Eine Kombination ist oft sinnvoll: Ein Check meldet beispielsweise, dass ein Dienst nicht erreichbar ist; Graylog zeigt die zuvor protokollierten Fehler. Welche Informationen ein Unternehmen benötigt, sollte es pro Dienst festlegen, statt zwei Werkzeuge allein anhand ihrer Dashboards zu vergleichen.

Welche Weiterbildung ergänzt Graylog?

Ein Graylog-Projekt verbindet Logmanagement mit Netzwerk- und Systemmonitoring. Für die Grundlagen angrenzender Monitoring-Verfahren führt allskills-training.com die Seminare „Monitoring mit Icinga 2 Grundlagen“ und „Monitoring und Netzwerkmanagement mit Nagios“. Ein Wiki-Artikel von allskills Training Berlin zu Proxmox VE und Security zeigt ein praktisches Beispiel für die Ergänzung von zentralem Logging durch Metrik-Monitoring. Diese Angebote sind thematisch verwandt; sie sind nicht als Graylog-Schulung ausgewiesen.