Monitoring-Software steht nicht selten vor dem Problem, dass die Applikation, die sie im Auge behalten soll, sich nicht auf Befragen zu ihrem Befinden äußern mag. Die rettende Alternative ist ein Blick in ihr Logfile. Dem Nagios-Plugin »check_logfiles« entgeht dabei keine Zeile.

Nur neue Zeilen

Da »check_logfiles« immer nur Zeilen im Logfile untersucht, die seit dem letzten Lauf des Plugins hinzukamen, führen wiederholte Aufrufe zu unterschiedlichen Resultaten. Wurde beim ersten Mal ein »Critical«-Ergebnis geliefert, dann ist beim nächsten Durchlauf in der Regel wieder mit einem »OK« zu rechnen, wie in Listing 1 demonstriert. Eine passende Service-Definition für Nagios ist in Listing 2 zu sehen.

01 $ logger "test1 das ist doch 0815"
02 $ logger "das nicht, weil 0916"
03 $
04 $ check_logfiles -logfile=/var/log/suelzomat.log
     --tag=0815 -criticalpattern='.*0815.*' 
     --rotation='loglog0log1' 
05 CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-15-10-02) - Oct 1015:09:56 localhost lausser: test1 das ist doch 0815 |0815_lines=2
06 0815_warnings=0 0815_criticals=1 0815_unknowns=0
07 $
08 $ echo $?
09 2
10 $
11 $ logger "geblubber"
12 $ check_logfiles -logfile=/var/log/suelzomat.log --tag=0815 -criticalpattern='.*0815.*' --rotation='loglog0log1'
13 
14 OK - no errors or warnings |0815_lines=1 0815_warnings=0 0815_criticals=0
15 0815_unknowns=0
16 $ echo $?
17 0

01 define service {
02  service_description check_0815msgs
03  host_name logserver
04  max_check_attempts 1
05  is_volatile 1
06  check_command
07  check_logfiles_critical!0815!/var/log/ suelzomat.log!loglog0log1!.*0815.*
08 }
09 define command {
10  command_name check_logfiles_critical
11  command_line $USER1$/check_logfiles 
12  --logfile=”$ARG2$
13  --criticalpattern="$ARG4$" --tag="$ARG1$" 
14  --rotation="$ARG3$"
15 }

Seine Stärken kann »check_logfiles« allerdings erst dann ausspielen, wenn es statt Kommandozeilenparameter eine Konfigurationsdatei verwendet. Das erste Beispiel benötigt die Konfigurationsdatei »gesuelze.cfg«:

@searches = ({
 tag => '0815',
 logfiles => '/var/log/suelzomat.log',
 criticalpatterns => '.*0815.*',
 rotation => 'loglog0log1',
 options => 'noprotocol'
});

Das Plugin ruft der Anwender dann mit »check_logfiles -f gesuelze.cfg« auf. Wie unschwer zu erkennen ist, besteht diese Konfigurationsdatei aus Perl-Code. Die Elemente des »@searches«-Array (im Weiteren Search genannt) sind Hashreferenzen, die Logdatei und Suchmuster zusammenfassen.

Das Tag ist dabei ein eindeutiger Bezeichner, der diese Kombination identifiziert. Das Plugin benötigt ihn unter anderem, um jene Dateien voneinander zu unterscheiden, die die Statusinformation für den nächsten Lauf von »check_logfiles« speichern.

Durch die Verwendung eines Array an dieser Stelle ist es möglich, in einem Lauf von »check_logfiles« gleich mehrere Logdateien zu durchsuchen. Als Perl-Code sieht die beschriebene Konfiguration des ersten Beispiels so aus, wie in Listing 3 dargestellt.

01 @searches = (
02 {
03  tag => 'lamp-apache'
04  logfile => '/var/log/apache/error.log',
05  criticalpatterns => ['.*error.*,  '.*fatal.'],
06  rotation => 'solaris'
07 },
08 {
09  tag => 'lamp-mysql',
10  logfile => '/var/log/mysql.log',
11  criticalpatterns => ['corruption',  'you hit a bug']
12 }
13 );

Soll das Plugin umgekehrt einen Alarm auslösen, wenn ein bestimmtes Muster gerade nicht im Logfile auftaucht, dann beginnt das entsprechende Pattern mit »!«. So lässt sich beispielsweise jeden Morgen prüfen, ob die nächtliche Sicherung gelaufen ist:

criticalpatterns => ['!backup successful']

Hier sind auch Ausnahmen definierbar, die zwar zunächst wie eine der gesuchten Meldungen aussehen, aber einen Sonderfall darstellen:

criticalpatterns => ['SCSI Error'],
criticalexceptions => ['SCSI Error.*disk0 .*'],

Diese Einträge bewirken, dass die Meldung »SCSI Error /dev/disk5 I/O Timeout« einen Nagios-Alarm auslöst, das Plugin hingegen »SCSI Error /dev/disk0 I/O Timeout« ignoriert.

Am Ende jedes Laufs speichert das Plugin, bis zu welcher Position es ein Logfile gelesen hat und welches Änderungsdatum und welche Inode-Nummer diese Datei hat. Diese Informationen landen in einem so genannten Seekfile. Beim nächsten Lauf vergleicht das Plugin diese Daten mit den Eigenschaften des aktuellen Logfile und ermittelt, ob es gewachsen ist oder gelöscht, rotiert oder neu angelegt wurde oder ob nichts von alledem passierte.

Es geht rund

Im Falle einer Rotation sucht das Plugin die wegrotierte Archivdatei, die es ja erst noch zu Ende lesen muss, um eine lückenlose Überwachung zu gewährleisten. Je nachdem, wie lange der letzte Lauf zurückliegt, können zwischenzeitlich auch mehrere Rotationen stattgefunden haben. Anhand des Zeitstempels findet das Plugin alle Archivdateien, die in Frage kommenden.

In den meisten Fällen ist das Logfile lediglich um einige Zeilen gewachsen. »check_logfiles« fährt dann an der Stelle fort, die beim letzten Lauf das Dateiende markierte, und liest die folgenden Zeilen, bis es wiederum auf das Dateiende stößt (Abbildung 2). Dies hat insbesondere bei großen und schnell wachsenden Logfiles erhebliche Geschwindigkeitsvorteile gegenüber anderen Verfahren, die mittels »diff« die Unterschiede zwischen dem aktuellen Logfile und einer Kopie des alten suchen.

Abbildung 2: Der Log-Checker merkt sich das File und die Position, bis zu der er das Log beim letzten Aufruf gelesen hatte, und fährt genau an dieser Stelle fort.

Das Verzeichnis für die Seekfiles lässt sich mit »./configure with-seekfile-dir« vorgeben, aber auch noch zur Laufzeit über die Variable »$seekfilesdir« in der Konfigurationsdatei ändern. Per Default benutzt das Plugin »/tmp«. Es empfiehlt sich allerdings, dies in »/var/tmp« zu ändern, da bei manchen Betriebssystemen der Inhalt von »/tmp« einen Reboot nicht überlebt.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Monitoring-Software steht nicht selten vor dem Problem, dass die Applikation, die sie im Auge behalten soll, sich nicht auf Befragen zu ihrem Befinden äußern mag. Die rettende Alternative ist ein Blick in ihr Logfile. Dem Nagios-Plugin »check_logfiles« entgeht dabei keine Zeile.