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.

Aktionen

Die Option »script« sorgt dafür, dass ein Treffer Code ausführt:

script => 'Name_eines_Programms'

Seit Neuestem ist auch die folgende Form möglich:

script => sub { Perl-Code }

Beispiele für solche Aktionen sind der Restart von Applikationen oder das Versenden von SNMP-Traps oder NSCA-Messages. Dadurch kann »check_logfiles« auch als Standalone-Anwendung laufen und ist nicht auf die Eventhandler von Nagios angewiesen.

Mit den Parametern »scriptparams« und »scriptstdin« lassen sich die externen Skripte auch mit Kommandozeilenparametern aufrufen und sogar mit Eingaben von Stdin versorgen. Ein Beispiel gibt das Listing 5. Dort würde jedes Mal, wenn eine Fehlermeldung in einer Zeile der »messages«-Datei erscheint, diese mit dem »send_nsca«-Kommando an den Nagios-Server geschickt.

Im einfachsten Fall ist der Exitcode des externen Skripts nicht relevant, er beeinflusst den endgültigen Exitcode von »check_logfiles« selbst daher nicht. Sollte also im Beispiel von Listing 4 der Restart der Suelzomat-Applikation erfolgreich verlaufen sein, dann meldet »check_logfiles« trotzdem »Critical« an Nagios weiter.

01 $ cat gesuelze.cfg
02 @searches = ({
03  tag => '0815',
04  logfile => '/var/log/suelzomat.log',
05  archivedir => '/var/log/archives',
06  rotation => 'loglog0gzlog1gz',
07  criticalpatterns => '.*0815.*',
08  criticalexceptions => '.*0815 macht aber nix.*',
09  warningpatterns => ['.*failure.*', '!successful'],
10  warningthreshold => 10,
11  okpatterns => '.*cleared.*',
12  options => 'case,noprotocol,script'
13  script => 'restart_suelzomat'
14 });

01 $scriptpath = '/usr/bin/nagios/libexec:/usr/local/nagios/contrib';
02 $MACROS = {
03   CL_NSCA_HOST_ADDRESS => "lpmon1.muc",
04   CL_NSCA_PORT => 5778
05 };
06 
07 @searches =(
08 {
09  tag => 'suelz',
10  logfile => '/var/log/suelzomat.log',
11  criticalpatterns => ['ERROR', 'crashed'],
12  script => 'restart_suelzomat',
13  scriptparams => '--suelzprefix=bla',
14  options => 'script'
15 },
16 {
17  tag => 'san',
18  logfile => '/var/adm/messages',
19  criticalpatterns => [
20    'Link Down Event received',
21    'Loop OFFLINE',
22    'fctl:.*disappeared from fabric',
23    '.*Lun.*disappeared.*'
24  ],
25  options => 'script',
26  script => 'send_nsca',
27  scriptparams => '-H $CL_NSCA_HOST_ADDRESS$ -p $CL_NSCA_PORT$ -to $CL_NSCA_TO_SEC$ -c $CL_NSCA_CONFIG_FILE$',
28  scriptstdin => '$CL_HOSTNAME$t$CL_SERVICEDESC$t$CL_SERVICESTATEID$t$CL_SERVICEOUTPUT$n',
29 });

Der Admin kann nun mit der Option »smartscript« dafür sorgen, dass der Exitcode des externen Skripts in das Endergebnis einfließt. Dabei tut das Plugin so, als fände es unmittelbar nach der auslösenden Trefferzeile eine weitere Zeile, deren Text der ersten Zeile der Skriptausgabe und deren Bewertung dem Exitcode des Skripts entspricht. Damit lässt sich jedoch nur ein zusätzlicher Fehler erzeugen, nicht aber die ursprüngliche Meldung im Logfile ungeschehen machen oder neu bewerten.

Die dritte Möglichkeit ist die Option »supersmartscript«. Solche Skripte ersetzen mit ihrem Exitcode und Output den auslösenden Treffer im Logfile, anstatt ihn zu ergänzen. Dem Skript stehen dazu mehrere Environment-Variablen zur Verfügung:

• »CHECK_LOGFILES_SERVICEOUTPUT«: Inhalt der
  auslösenden Zeile
• »CHECK_LOGFILES_SERVICESTATE«:
  »Warning«, »Critical«,
  »Unknown« oder »OK«
• »CHECK_LOGFILES_SERVICESTATEID«: 0, 1, 2 oder
  3

Mit Hilfe dieser Informationen und weiterer Daten wie der Uhrzeit oder dem Ergebnis des Applikationsrestarts lässt sich eine Neubewertung der Fehlermeldung erreichen. Der Logfile-Checker kann auf diese Weise zum Beispiel den Zustand »Critical« auf »Warning« zurückstufen oder mit einem Exitcode von »0« sogar ganz aus der Welt schaffen. Ein Beispiel findet sich in Listing 6.

Aktionen lassen sich auch auslösen, noch bevor die Suche in Logfiles startet oder nachdem alle Suchvorgänge abgeschlossen sind. Dazu gibt es den Parameter »§prescript«, der wie gehabt auf ein externes Skript oder eine Perl-Subroutine verweist.

Prescripts und Postscripts

Supersmart-Prescripts brechen den Lauf von »check_logfiles« komplett ab, wenn der Exitcode größer als null ist. So ließe sich beispielsweise zuerst prüfen, ob ein bestimmter Prozess überhaupt läuft. Läuft er nicht - wozu dann noch im Logfile der zugehörigen Applikation nach Fehlern suchen?

Supersmart-Postscripts können das Endergebnis von »check_logfiles« komplett austauschen, egal wie viele Error-Messages vorher zu finden waren. Auch hier stehen Informationen in Environment-Variablen zur Verfügung:

• »CHECK_LOGFILES_SERVICEOUTPUT« : Output des
  Plugins
• »CHECK_LOGFILES_SERVICEPERFDATA«:
  Performancedaten
• »CHECK_LOGFILES_SERVICESTATE«:
  »Warning«, »Critical«,
  »Unknown« oder »OK«
• »CHECK_LOGFILES_SERVICESTATEID«: 0, 1, 2 oder
  3
• »CHECK_LOGFILES_PROTOCOLFILE«: Name des
  Protokoll-File

Wem die Standardform der Ausgabe von »check_logfiles« nicht gefällt, der kann sie mit Hilfe eines Supersmart-Postscript nach seinen Wünschen umformulieren oder aussagekräftiger gestalten. (jcb)

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.