Zabbix Logfiles ueberwachen

Logfiles mit aktiven Checks überwachen

Mit Zabbix können Sie Logfiles oder das Windows-Eventlog auf das Vorkommen bestimmter Stichworte überwachen. In einem vorgegebenen Intervall überprüft der Zabbix-Agent Logfiles und sucht über einen Regulären Ausdruck nach Stichworten. Dabei untersucht der Agent immer nur den Teil eines Logfiles, der sich seit dem letzten Check geändert hat.

Das Monitoren von Logfiles ist ein sogenannter aktiver Check. Der Agent ruft beim Server ab, welches Logfile nach welchem Stichwort in welchem Intervall durchsucht werden soll. Sobald diese Konfiguration den Agenten erreicht hat, stößt der Agent die Prüfung selbstständig an. Die „normalen“ – nicht aktiven – Checks werden im Gegensatz zu den aktiven immer vom Zabbix-Server angestoßen. Zum Ausführen von aktiven Checks müssen einige Voraussetzungen erfüllt sein, die für die passiven Checks nicht gelten. Mehr Details über aktive Checks finden Sie im Kapitel Daten mit dem Zabbix-Agenten sammeln.

Den Agent vorbereiten

Hostname im Agenten konfigurieren

In der Datei zabbix_agent.conf muss der Wert „Hostname“ korrekt ausgefüllt sein. Dabei muss der Hostname exakt dem Hostnamen entsprechen, den Sie im Zabbix-Server in der Hostkonfiguration im Feld „Host Name“ angegeben haben.
Der in der Konfiguration des Agenten angegebene Hostname muss nicht dem im Betriebssystem konfigurierten Hostnamen entsprechen. Es müssen auch keine passenden Einträge im DNS existieren.

Der hinterlegte Hostname in der zabbix_agentd.conf muss mit dem Hostnamen im Zabbix-Server übereinstimmen.

Zabbix-Serveradresse im Agenten konfigurieren

Der erste Eintrag in der Konfiguration des Agenten für den Wert „Server“ muss den Hostnamen oder die IP-Adresse des Zabbix-Servers enthalten. Sollten Sie aufgrund Ihrer Netzwerktopologie (NAT-Routing) mehrere zulässigen Serveradressen für den Agenten eingetragen haben, achten Sie darauf, dass der Agent den Server über den ersten Eintrag erreicht. Liegt zwischen Server und Agent ein NAT, müssen Sie nicht die wahre Adresse des Servers, sondern die IP-Adresse des NAT-Routers als Server eintragen. Der Router muss dann alle Anfragen an den Port 10051 an den Zabbix-Server weiterleiten.

Netzwerk, Routing und NAT prüfen

Der Zabbix-Server muss vom Zabbix-Agenten aus über den TCP-Port 10051 erreichbar sein. Prüfen Sie dazu den Wert „ListenIP“ in der zabbix_server.conf des Servers. Solange Sie keine aktiven Checks verwenden, reicht der Eintrag „ListenIP=127.0.0.1“. Für die aktiven Checks sollten Sie die IP-Adressen mit Komma getrennt eintragen, über die der Server die Anfragen der Clients entgegennimmt. Alternativ können Sie auch „ListenIP=0.0.0.0“ verwenden. Dann nimmt der Server die Verbindungen der Agenten aus allen verfügbaren IP-Adressen entgegen. Testen Sie vom überwachten Host aus, ob der Zabbix-Agent Verbindungen zum Server aufbauen kann, zum Beispiel mit dem Kommando

nc -z <IP-Zabbix-Server> 10051&&echo OK

Leserechte für Logfiles einräumen

Damit der Zabbix-Agent Logfiles überwachen kann, muss der Zabbix-User diese lesen dürfen. Üblicherweise wird der Zabbix-Agent nicht mit den Berechtigungen des Root-Users gestartet. Benutzer ohne Root-Rechte haben auf fast allen Distributionen keine Leserechte auf Logdateien. Prüfen Sie mit ls -l, wer Leserechte auf die entsprechende Datei hat. Auf einem Standard-Debian-System schreibt Syslog fast alle Meldungen in die Datei /var/log/syslog. Nur Root und Mitglieder der Gruppe adm dürfen diese Datei lesen. Der Benutzer „zabbix“ hat erst einmal keinen Zugriff.

ls -l /var/log/syslog
-rw-r----- 1 root adm 117744 Sep 21 18:50 /var/log/syslog

Sie können nun den Benutzer „zabbix“ der Gruppe „adm“ hinzufügen, denn diese hat Leserechte auf die Logdatei.

adduser zabbix adm
Adding user `zabbix' to group `adm' ...
Adding user zabbix to group adm
Done.

SUSE-, Red Hat- und CentOS-Systeme verwenden /var/log/messages als Hauptlogfile. Diese Datei darf nur vom User Root und Mitgliedern der Gruppe root gelesen werden.

ls -l /var/log/messages 
-rw-r----- 1 root root 483083 Okt 14 07:11 /var/log/messages

Sie könnten nun den Benutzer „zabbix“ der Gruppe root hinzufügen. Damit würden Sie aber über das Ziel hinausschießen und Zabbix zu viele Rechte geben. Legen Sie besser eine neue Gruppe an, zum Beispiel „adm“, und sorgen Sie dafür, dass die Logdatei mit Leserechten für die neue Gruppe angelegt wird. Folgende Kommandos legen unter SUSE eine Gruppe adm an und fügen die Benutzer root und zabbix der neuen Gruppe hinzu:

groupadd adm
groupmod -A root adm
groupmod -A zabbix adm

Auf Red Hat- und CentOS-Systemen existiert die Gruppe adm schon. Sie brauchen nur den User zabbix hinzufügen.

usermod -a -G adm zabbix

Öffnen Sie nun die Konfigurationsdatei des Syslog-Dienstes /etc/rsyslog.conf und fügen Sie folgende Zeilen im oberen Bereich hinzu:

# All new files belong to group adm. This is not the SUSE default!
$FileGroup adm
$FileCreateMode 0640
$Umask 0022

Starten Sie Rsyslog nach den Änderungen neu.

/etc/init.d/syslog restart

Der Syslog-Dienst ändert die Berechtigungen vorhandener Dateien nicht. Dies müssen Sie manuell erledigen. Alle neuen Dateien werden der Gruppe adm gehören.

chgrp adm /var/log/messages

Die Zugriffsberechtigungen für Logfiles sollten Sie nicht per chmod a+r o.Ä. ändern, denn beim nächsten Rotieren der Logs gehen diese Änderungen verloren.

Sie sollten Logfiles nicht für alle Benutzer lesbar machen! Denken Sie an die Auswirkungen bezüglich der Sicherheit Ihres Systems.
Es hat einen guten Grund, dass Logfiles nur für root und die Gruppe „adm“ lesbar sind. Viele Applikationen, wie zum Beispiel Apache und Mailserver, loggen sensible Daten wie Benutzernamen und Passwörter im Klartext. Diese Informationen sollten nicht für alle Benutzer zugänglich sein.

Items zur Logfile-Überwachung einrichten

Zur Überwachung von Logfiles oder des Eventlogs legen Sie für einen Host oder ein Template ein neues Item an, wobei Sie „Description“ wie gewohnt frei wählen können.

Als Type müssen Sie „Zabbix agent (active)“ auswählen.

Der Key wird bei Logfiles wie folgt gebildet:

log[file,<regexp>,<encoding>,<maxlines>,<mode>].

Der Key „log“ akzeptiert folgende Optionen:

file
Der Pfad zum Logfile muss als absoluter Pfad angegeben werden.
regexp
Mit regexp geben Sie einen Regulären Ausdruck an, nach dem im Logfile gesucht werden soll. Die Groß- und Kleinschreibung wird beachtet.
encoding
Wenn der gesuchte Begriff Sonderzeichen enthält, ist es ratsam, auch das Encoding anzugeben.
maxlines
Mit maxlines legen Sie fest, wie viele Zeilen, die eine Fundstelle enthalten, vom Agenten an den Server zurückgegeben werden. Je nachdem, wie Sie das Item später mit einem Trigger auswerten wollen, ist es ratsam, nicht alle Fundstellen an den Server zu schicken. Das spart Netzwerkverkehr und Rechenarbeit. Wenn Sie maxlines nicht angeben, wird der in der Datei zabbix_agentd.conf angegebene Wert MaxLinesPerSecond verwendet.

Im Dropdown-Menü Type of information wählen Sie bei der Analyse von Logfiles immer Log aus.

Der Zabbix-Agent sucht alle 30 Sekunden nach einem Stichwort in einem Logfile.

Wenn Sie ein neu eingerichtetes Item testen wollen, können Sie mit dem Kommando logger einen Eintrag ins Syslog schreiben:

logger zabbixtest
tail /var/log/syslog
Oct 14 21:14:21 zabbix root: zabbixtest

Nun sollten Sie auch auf der Zabbix-Weboberfläche sehen, dass Zabbix den Logeintrag mitbekommen hat. In den „Latest Data“ des überwachten Hosts sollten Sie den Logeintrag ebenfalls finden. Der Agent liefert die komplette Zeile mit der Fundstelle an den Server.

Da das Prüfen von Logfiles ein aktiver Check ist, werden Änderungen in der Zabbix-Weboberfläche nicht sofort an den Agenten kommuniziert. In der Datei zabbix_agentd.conf legen Sie mit der Einstellung RefreshActiveChecks fest, in welchem Rhythmus der Agent die Konfigurationsänderungen vom Zabbix-Server abruft. Es kann also etwas dauern, bis Daten im Zabbix-Server ankommen.
Ein Logeintrag wurde gefunden und im Zabbix-Server gespeichert.

Wenn Sie zum Beispiel beobachten wollen, dass es einen fehlgeschlagenen SSH-Login-Versuch für den User Root gab, könnte der Item-Key so aussehen:

log[/var/log/auth.log,"sshd.*authentication failure.*user=root"]

Rotierende Logfiles

Viele Logfiles werden in zeitlichen Abständen rotiert. Die schreibende Software oder Logrotate-Cronjobs archivieren und komprimieren das Logfile. Anschließend wird mit einem neuen Logfile begonnen.

Die meisten Distributionen verwenden Logrotate. In /etc/logrotate.conf und /etc/logrotate.d/ finden Sie die Regeln, nach denen Logfiles umbenannt und komprimiert werden. Die Datei /var/log/syslog wird in der Regel alle vier Tage rotiert und nach weiteren vier Tagen komprimiert.

ls -l /var/log/syslog*
-rw-r----- 1 root adm 10227196 Oct 15 18:53 /var/log/syslog
-rw-r----- 1 root adm   144655 Oct  5 13:42 /var/log/syslog.1
-rw-r----- 1 root adm      328 Sep 30 18:11 /var/log/syslog.2.gz

Wenn Sie einen Logfile mit Zabbix beobachten, kann es passieren, dass kurz bevor der Zabbix-Agent die Datei einliest, diese rotiert wurde. Alles, was zwischen dem letzten Lesevorgang von Zabbix und dem Rotieren geschrieben wurde, kann dann Zabbix nicht lesen.

Wenn Sie Logfiles im 30-Sekunden-Takt prüfen, entgehen Ihnen in der Regel nur sehr wenige oder keine Informationen. Prüfen Sie einen Logfile hingegen nur einmal pro Stunde, erfasst der Zabbix-Agent wichtige Informationen unter Umständen nicht.

Doch für solche Fälle können Sie den Item-Key logrt[path to log file with filename format,<pattern>,<encoding>,<max lines>] verwenden. Der Pfad zu den Logdateien wird als Regulärer Ausdruck angeben, zum Beispiel:

logrt["/var/log/syslog(\.[0-9])*",zabbxitest,"UTF-8",100]

Zabbix liest einmal alle Dateien ein, die dem Muster entsprechen. Bei jeder weiteren Prüfung ignoriert der Agent Dateien ohne Änderungen, so dass nur noch die Dateien mit dem jüngsten Änderungsdatum gelesen werden.

Komprimierte Logfiles können nicht eingelesen werden. Wenn Sie rotierende Logfiles mit Zabbix analysieren, dann achten Sie darauf, dass die Dateien nach dem Rotieren nicht sofort komprimiert werden. Geben Sie dazu in den Logrotate-Regeln die Option „delaycompress“ an. Dann bleibt die rotierte Datei bis zum nächsten Rotationszyklus unkomprimiert.

Teilen Sie Logrotate mit, dass Logfiles nicht sofort komprimiert werden sollen.

Zeitstempel erhalten

Beim Einrichten eines Items vom Type „log“ oder „logrt“ gibt es ein Eingabefeld „Log Time Format“. Wenn Sie an dieser Stelle angeben, wie das Datum in einer Logmeldung formatiert ist, dann wird der Original-Zeitstempel der Logmeldung an den Zabbix-Server übertragen. Wenn Sie das Datumsformat nicht angeben, werden die Meldungen ohne Zeitstempel zum Zabbix-Server geschickt. Sie sehen dann alle Logmeldungen mit dem Zeitstempel, an dem die Meldungen den Zabbix-Server erreicht haben. Je nach Update-Intervall kann dieser Zeitstempel erheblich von der Uhrzeit abweichen, zu der die Meldung auf dem überwachten System generiert wurde.

Damit der Original-Zeitstempel gelesen werden kann, geben Sie im Feld „Log Time Format“ folgende Platzhalter an:

  • y: Year (0001-9999)
  • M: Month (01-12)
  • d: Day (01-31)
  • h: Hour (00-23)
  • m: Minute (00-59)
  • s: Second (00-59)

Wenn eine Logmeldung zum Beispiel mit folgendem Datum beginnt:

2011-10-15 21:12:59 zabbix root: This is a log message

dann tragen Sie als „Log Time Format“ Folgendes ein:

yyyy-MM-dd hh:mm:ss

Zabbix kann das Format eines Datums nur dann erkennen, wenn das Datum aus Jahr, Monat, Tag, Stunde, Minute und Sekunde besteht. Fehlt eine dieser Angaben, wird das Datum nicht erkannt.

Logmeldungen, bei denen der Original-Zeitstempel (Local time) erkannt wurde

Unglücklicherweise ist das Standard-Datumsformat von rsyslog nicht mit Zabbix kompatibel. Logmeldungen enthalten kein Jahr, und der Monat ist nicht als Zahl angegeben. Möchten Sie das Datumsformat so ändern, dass Zabbix es lesen kann, dann fügen Sie in die Datei /etc/rsyslog.conf ein neues Logformat (Template) ein. Sie können das neue Template dann auf jede Logdatei anwenden, indem Sie dieses hinter dem Dateinamen mit Semikolon getrennt angeben.

# Define template with zabbix compatible date format
$template ZabbixCompatible,"%timereported:::date-pgsql% %HOSTNAME% %syslogtag%%msg:::drop-last-lf%\n"

#/var/log/syslog uses ZabbixCompatible format
*.*;auth,authpriv.none          -/var/log/syslog;ZabbixCompatible
Beachten Sie, dass vielleicht andere Programme ebenfalls Logfiles auswerten. Prüfen Sie, ob diese Programme mit einem geänderten Datumsformat zurechtkommen.
Rsyslog verwendet ein Zabbix-kompatibles Datumsformat.

Überwachen des Windows-Eventlogs

Was für Linux der Syslog ist, nennt sich unter Windows System-Events. Hier laufen alle Meldungen des Betriebssystems und vieler Applikationen auf. Der Zabbix-Agent kann das Eventlog von Windows beobachten und bestimmte Meldungen an den Zabbix-Server schicken.

Windows teilt die System-Events in verschiedene Eventlogs auf. Die Standard-Eventlogs sind Application, Security, Setup und System.

Zur Überwachung des Eventlogs richten Sie ein neues Item ein und wählen Sie als Typ „Zabbix-Agent (active)“. Der Key wird nach folgendem Muster angelegt:

eventlog[logtype,<pattern>,<severity>,<source>,<eventid>,<maxlines>,<mode>]

Dabei geben Sie im Key folgende Optionen an:

logtype
Als logtype geben Sie an, welches Eventlog durchsucht werden soll, zum Beispiel Application. Diese Angabe ist Pflicht. Das Durchsuchen aller Eventlogs ist nicht möglich. Die Angabe der Eventlogs ist je nach Sprache des Betriebssystems unterschiedlich. Für ein deutsches Windows tragen Sie zum Beispiel „Anwendung“ anstatt „Application“ ein.
pattern
Der Suchbegriff als Regulärer Ausdruck. Die Groß- und Kleinschreibung wird berücksichtigt.
Severity
Wenn eine Severity angegeben wird, werden nur Einträge mit diesem Schweregrad durchsucht. Im Windows Eventviewer wird diese Angabe als „Level“ bezeichnet. Mögliche Severities (Level) sind Error, Warning, Information, Successaudit und Failureaudit.
Source
Über die Option Source können Sie die Suche im Eventlog auf Einträge bestimmter Programme beschränken.
EventID
Die EventIDs sind keine fortlaufenden Nummern, sondern eindeutige Kennungen für bestimmte Probleme. Der Zabbix-Agent kann gezielt nach Event-IDs suchen.
maxlines
maxlines gibt an, wie viele gefundene Zeilen an den Zabbix-Server gesendet werden.
Mode
mögliche Werte: all (default), skip (Überspringe das Verarbeiten alter Daten.).
Durchsuchen des Eventlogs System nach dem Stichwort „Zabbix“

Zum Testen eines Items können Sie mit dem Kommando eventcreate einen Eintrag in das Eventlog schreiben.

c:\>eventcreate /l APPLICATION /t INFORMATION /id 1 /d "zabbix is cool"
SUCCESS: An event of type 'INFORMATION' was created in the 'APPLICATION' log with 'EventCreate' as the source.

Trigger einrichten für die Logfile-Überwachung

Beim Einrichten von Triggern stellt sich ein grundsätzliches Problem: Einträge in Logfiles haben keinen Status. Wenn ein Eintrag im Syslog einen Fehler anzeigt, gibt es danach in der Regel keinen Eintrag, der anzeigt, dass der Fehler behoben wurde. Würden Sie einen Trigger einrichten, der den Status „Problem“ annimmt, sobald ein bestimmtes Wort in einem Logfile gefunden wird, so wird dieser Trigger immer den Status „Problem“ behalten. Trigger werden nur in dem Moment ausgeführt, in dem der Item-Value aktualisiert wird. Solange der gesuchte Begriff nicht gefunden wird, sendet der Agent aber keine Daten an den Server. Das Item und damit auch der Trigger werden nicht aktualisiert.

Sie müssen den Zabbix-Server also dazu bewegen, den Trigger zu aktualisieren, obwohl keine neue Daten für das Item gesendet werden. Das erreichen Sie durch die Verwendung der Funktion nodata(). Eine Trigger-Expression könnte wie folgt definiert werden:

{Productive Webserver 01:log[/var/log/syslog,zabbixtest].nodata(120)}=0

nodata(120) liefert 0 zurück, wenn in den letzten 120 Sekunden neue Daten eingetroffen sind. Mit der genannten Expression schlägt der Trigger Alarm, sobald das Suchwort gefunden wurde. Wird das Wort in den dann folgenden 120 Sekunden nicht mehr gefunden, schaltet sich der Alarm automatisch wieder ab.

Mit der Funktion nodata() aktualisieren sich Trigger, obwohl keine neuen Daten eintreffen.

Sie können die Funktion nodata() mit anderen Funktionen kombinieren. Dazu gibt es folgende Beispiele:

{Productive Webserver 01:log[/var/log/syslog,zabbixtest].count(180)}>3&
{Productive Webserver 01:log[/var/log/syslog,zabbixtest].nodata(180)}=0

Dieser Trigger löst aus, wenn innerhalb der letzten 180 Sekunden der Begriff "zabbixtest" mindestens vier Mal ins Logfile geschrieben wurde.

{Productive Webserver 01:log[/var/log/syslog,zabbixtest].str("zweiter Begriff")}=1&
{Productive Webserver 01:log[/var/log/syslog,zabbixtest].nodata(180)}=0

Dieser Trigger löst aus, wenn der Zabbix-Agent innerhalb der letzten 180 Sekunden eine Logzeile mit dem Wort "zabbixtest" an den Server liefert und wenn in dieser Zeile zusätzlich noch die Wörter "zweiter Begriff" gefunden wurden.

In einer Trigger-Expression werden mehrere Funktionen mit einem einfachen Kaufmanns-Und oder einem einfachen Pipe-Zeichen verbunden. Ab Zabbix 2.4 müssen die Expressions mit and oder or verbunden werden. Die Trigger-Expressions werden in eine Zeile geschrieben. Der Übersichtlichkeit halber wurden in den Beispielen Zeilenumbrüche eingefügt, die Sie nicht übernehmen.