SlideShare ist ein Scribd-Unternehmen logo
Überwachung von Logfiles mit
check_logfiles
Wer bin ich?
Gerhard Laußer
aus München
arbeite bei der Firma ConSol
betreue Nagios bei ***
Entstehungsgeschichte
Tivoli musste abgelöst werden.
Tivoli hat einen sog. Logfile-Adapter.
Programme müssen z.T. in Pipes schreiben.
Ein Leseprozess muss ständig laufen.
Schon wieder etwas, das kaputt gehen kann.
Vorhandene Plugins lassen Lücken zu.
Erste Version von Anfang 2006 für den
Eigenbedarf.
Stetige Weiterentwicklung und Zufluss von Ideen.
●
Her damit!
http://www.consol.de/opensource/nagios/check-logfiles
http://sourceforge.net/projects/check-logfiles
Auspacken und
Zusammenbauen
tar zxvf check_logfiles-2.3.tar.gz
cd check_logfiles-2.3
./configure –help
.....
--libexecdir=DIR program executables [PREFIX/libexec]
......
--with-nagios-user=USER set user name to run nagios
--with-nagios-group=GROUP set group name to run nagios
--with-seekfiles-dir=PATH sets directory for the state files
(default=/tmp)
--with-protocols-dir=PATH sets directory for the protocol files
(default=/tmp)
--with-trusted-path=PATH sets trusted path for executables called by
scripts
(default=/bin:/sbin:/usr/bin:/usr/sbin)
--with-perl=PATH sets path to perl executable
--with-gzip=PATH sets path to gzip executable
......
So funktioniert's
$ check_logfiles 
--logfile=/var/log/suelzomat.log 
--tag=gesuelz --criticalpattern='.*suelz.*'
--rotation=debian
OK - no errors or warnings |gesuelz_lines=31 gesuelz_warnings=0
gesuelz_criticals=0 gesuelz_unknowns=0
$ suelzomat –log-msg=”so ein gesuelze”
$ sleep 999999
$ check_logfiles 
--logfile=/var/log/suelzomat.log 
--tag=gesuelz --criticalpattern='.*suelz.*'
--rotation=debian
CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-14-59-05) - so
ein gesuelze |gesuelz_lines=9371 gesuelz_warnings=0 gesuelz_criticals=1
gesuelz_unknowns=0
$
suelzomat.log suelzomat.log.0
suelzomat.log.1.gzsuelzomat.log.0suelzomat.log
so ein gesuelze
So funktioniert's
suelzomat.log suelzomat.log.0
suelzomat.log.1.gzsuelzomat.log.0suelzomat.log
Hier endet der erste Lauf.
Merke: Offset im Logfile und Modification Time
Einige Zeit vergeht.........
Eine Fehlermeldung wird erzeugt
Mehr Zeit vergeht........
suelzomat.0 wird zu suelzomat.1.gz
suelzomat.log wird zu suelzomat.log.0
Ein neues suelzomat.log wird angelegt
Es wurden insges. 9371 Meldungen vom Suelzomat erzeugt
So funktioniert's
suelzomat.log.1.gzsuelzomat.log.0suelzomat.log
2.Lauf: Wo waren wir stehengeblieben? Zeitstempel und Offset
Such mir jetzt alle Logfilekandidaten, die sich seit Zeitstempel geändert haben.
suelzomat.log suelzomat.log.0
Sortier sie so, daß die älteste an erster Stelle kommt.
Das ist dann das ehemalige Logfile, in dem wir ans Dateiende gestossen sind.
suelzomat.log.0 suelzomat.log
So funktioniert's
suelzomat.log.0 suelzomat.log
Und jetzt durchsuchen wir alles, was seitdem an Meldungen entstanden ist.
suelzomat.log
Bis das es nichts mehr zu durchsuchen gibt.
Der Zeitpunkt der letzten Modifikation
und die Position innerhalb des Logfiles
werden wieder gespeichert.
suelzomat.log.0
Nagios Conference 2007 | Monitoring von Logfiles mit check_logfiles by Gerhard Laußer
08/15 Beispiel
$ check_logfiles -V
check_logfiles v2.3
$
$ check_logfiles --logfile=/var/log/messages 
--tag=0815 –-criticalpattern='.*0815.*'
OK - no errors or warnings |0815_lines=0 0815_warnings=0 0815_criticals=0
0815_unknowns=0
$
$ logger "test1 das ist doch 0815"
$ logger "das nicht, weil 0916"
$
$ check_logfiles --logfile=/var/log/messages 
--tag=0815 –-criticalpattern='.*0815.*'
CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-15-10-02) - Oct
10 15:09:56 localhost lausser: test1 das ist doch 0815 |0815_lines=2
0815_warnings=0 0815_criticals=1 0815_unknowns=0
$
$ echo $?
2
Mehr 08/15 Logging
$ logger "gelaber"
$ logger "test2 das ist auch 0815"
$ logger "gefasel"
$
$ check_logfiles --logfile=/var/log/messages 
--tag=0815 –-criticalpattern='.*0815.*'
CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-15-12-02) – Oct
10 15:11:51 localhost lausser: test2 das ist auch 0815 |0815_lines=3
0815_warnings=0 0815_criticals=1 0815_unknowns=0
$
$ echo $?
2
$
$ logger "geblubber"
$ check_logfiles --logfile=/var/log/messages 
--tag=0815 –-criticalpattern='.*0815.*'
OK - no errors or warnings |0815_lines=1 0815_warnings=0 0815_criticals=0
0815_unknowns=0
$ echo $?
0
Wie sieht die
Servicedefinition aus?
define service {
service_description check_0815msgs
host_name logserver
max_check_attempts 1
is_volatile 1
check_command check_logfiles!0815!/var/adm/messages!.*0815.*
}
define command {
command_name check_logfiles_critical
command_line $USER1$/check_logfiles --logfile=”$ARG2$ --criticalpattern="
$ARG3$" --tag=" $ARG1$"
}
max_check_attempts darf nur 1 sein, weil der gleiche Fehler bei einem erneuten
Check nicht wieder auftaucht.
Wie werden überhaupt
Rotationen erkannt?
$ cat /tmp/check_logfiles._tmp_suelzomat.log.suelz
$state = {
logoffset => 10,
logtime => 1182640189,
devino => '773:510722',
logfile => '/tmp/suelzomat.log',
};
1;
Wie weit haben wir das Logfile gelesen? (= wie groß war es?)
Wann wurde zuletzt was reingeschrieben?
Welche Inode-Nummer hatte es?
Dann schaut man sich das aktuelle Logfile an.
Wie groß ist es und welche Inode-Nr. hat es?
Damit lässt sich rausfinden, ob es eine Rotation gab und welche der
wegrotierten Dateien in die Suche einbezogen werden müssen.
Configfiles
Das war Kinderkram:
check_logfiles --wo? --was?
Configfiles bieten wesentlich mehr :
check_logfiles -f waskompliziertes.cfg
Voriges Beispiel mit
einem 08/15 Configfile
$ cat gesuelze.cfg
@searches = ({
tag => '0815',
logfiles => '/var/log/messages',
criticalpatterns => '.*0815.*',
rotation => 'debian',
options => 'noprotocol'
});
$
$ check_logfiles -f gesuelze.cfg
CRITICAL - (4 errors) – error: msg-0815 ... |0815_lines=39
0815_warnings=0 0815_criticals=4 0815_unknowns=0
was bedeutet dieses
noprotocol?
Die Treffer im Logfile werden normalerweise in
eine Protokolldatei geschrieben.
/tmp/check_logfiles.protocol.<datum-zeit>
$options => “noprotocol”
schaltet das ab.
Welche Parameter
gibt es noch?
$ cat gesuelze.cfg
@searches = ({
tag => '0815',
logfiles => '/var/log/messages',
criticalpatterns => '.*0815.*',
criticalexceptions => '.*0815 macht aber nix.*',
warningpatterns => ['.*failure.*', '!successful'],
warningthreshold => 10,
okpatterns => '.*cleared.*',
rotation => 'debian',
options => 'case,script'
script => 'restart_suelzomat'
});
$
Nochmal von
Anfang an
● Wir durchsuchen ein oder mehrere Logfiles
oder einfach irgendwelche Dateien
● Und zwar nach regular Expressions
● Manche sollen als CRITICAL und manche als
WARNING gewertet werden.
● Von jeder Kategorie können mehrere angeben
werden, auch solche die auftauchen müssen(!)
● Logfiles werden gelegentlich rotiert, aber auch
die wegrotierten (und evt. komprimierten)
Dateien werden durchsucht, so daß keine
Lücken in der Überwachung entstehen.
Globale Variablen
im Konfigfile
● $protocolsdir – wohin mit den Protokolldateien. (def. /tmp)
● $protocolretention – Maximales Alter von Protokolldateien
in Tagen. Nach Ablauf werden sie gelöscht.
● $seekfilesdir – wohin mit den seekfiles (def. /tmp. !!Solaris)
● @searches – Das Kernstück: wonach wird wo gesucht?
● $prescript – Ein Kommando, das ausgeführt wird, bevor
die Sucherei anfängt.
● $postscript – dto. Wird ausgeführt, nachdem alle Logfiles
durchsucht wurden. Kann Endergebnis bzw. Ausgabe
beeinflussen.
Globale Variablen
im Konfigfile II
● $MACROS – Vordefinierte Strings, die man nachher in
Dateinamen und Pattern wiederverwenden kann.
$MACROS = { KAPUTTEPLATTE => 'scsi01lun02' },
...
criticalpatterns => 'SCSI error: ',
criticalexceptions => '$KAPUTTEPLATTE$'
Es gibt eine Fülle von Macros, die intern definiert wurden.
(Uhrzeit, Hostname, Domain,...)
Wichtig ist:
Wo und was
@searches = (
{
tag => 'lamp-apache'
logfile => '/var/log/apache/error.log',
criticalpatterns => ['.*error.*, '.*fatal.'],
rotation => 'solaris'
},
{
tag => 'lamp-mysql',
logfile => '/var/log/mysql.log',
criticalpatterns => ['corruption', 'you hit a bug']
}
);
Und sowas kommt
raus
CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-16-21-09) –
InnoDB: Database page corruption on disk or a failed |lamp-mysql_lines=12
lamp-mysql_warnings=0 lamp-mysql_criticals=1 lamp-mysql_unknowns=0
Wieviele Criticals und Warnings
Wenn der Admin zu faul ist, das Logfile zu durchsuchen, dann gibt's ein
Protokollfile, wo die ganzen Fehlermeldungen drinstehen.
Die aktuellste Fehlermeldung steht im Plugin-Output.
Performancedaten
<tag>_lines die Anzahl der Zeilen, die durchsucht wurden
<tag>_warnings die Anzahl der gefundenen Warningpatterns
<tag>_criticals die Anzahl der gefundenen Criticalpatterns
<tag>_unknowns die Anzahl der gefundenen Unknownpatterns
z.b: lamp-mysql_lines=8 lamp-mysql_warnings=1 lamp-mysql_criticals=0 lamp-
mysql_unknowns=0 lamp-apache_lines=377 lamp-apache_warnings=0 lamp-
apache_criticals=0 lamp-apache_unknowns=0 lamp-php_lines=19 lamp-
php_warnings=3 lamp-php_criticals=0 lamp-php_unknowns=0
Rotation
Wenn die Durchsuchung von wegrotierten
Logfiles gewünscht ist, dann muss man dem
check_logfiles eine Hilfestellung geben, wie diese
heissen könnten. Dazu gibt es das Feld “rotation”
in einer search-definition.
Der Wert dieses Feldes ist entweder eine
vordefinierte Rotationsmethode oder ein regulärer
Ausdruck.
Beispiel
$ find /var/log/nagios
/var/log/nagios
/var/log/nagios/archives
/var/log/nagios/archives/nagios-10-04-2007-00.log
/var/log/nagios/archives/nagios-10-05-2007-00.log
/var/log/nagios/archives/nagios-10-06-2007-00.log
/var/log/nagios/nagios.log
@searches = {
tag => 'naglog',
logfile => '/var/log/nagios/nagios.log',
archivedir => '/var/log/nagios/archive',
rotation => 'nagios-dd-dd-dddd-dd.log',
....
}
Vordefinierte Rotationen
suse
debian
logrotate
solaris
hpux
mod_log_rotate
log
log.1log log.0
log.20071008.gz
log.20071009.gz
log log.0
log
log.1.gz
log.0.gz log.1.gz
OLDloglog
log.1191940029
log.1191948332
log.1191953149
Der Parameter type
● Was ist das überhaupt für eine Art von Logfile?
● Wenn rotation angegeben ist ,dann ist type implizit
“rotation”.
● Wenn nicht, dann ist type implizit “simple”. Das nimmt man
her, wenn Logfiles einfach gelöscht und neu angelegt
werden, oder wenn man in Kauf nimmt, daß die letzten
Zeilen in einer wegrotierten Logdatei nicht durchsucht
werden.
Krasse Typen
● type => 'virtual' für Linux-proc-file-device-status-oder-so-
Dateien. z.b. /proc/scsi/lun/id/bla/online, wo 0 oder 1
drinsteht. Oder /proc/fcal/host/status, wo “Link: Up”
drinsteht. Damit kann man schnell eine
Hardwareüberwachung bauen. Diese Logfiles werden
jedesmal ganz von Anfang an durchsucht.
● type => 'errpt' zum Durchsuchen des AIX Error Report.
Die Ausgabe des errpt-Kommandos wird nach Pattern
durchsucht, als wäre sie eine gewöhnliche Logdatei.
● type => 'psloglist' (experimental) zum Durchsuchen des
Windows EventLog.
Weitere Optionen
● noperfdata – Anzeige von Performancedaten wird
unterdrückt
● syslogserver – im Logfile stehen Messages, die von
allen möglichen Servern stammen. Mit dieser Option
werden nur Messages vom lokalen Host untersucht.
● syslogclient – dto., aber diesmal werden nur
Messages untersucht, die von einem bestimmten
Client stammen. ...,syslogclient=hostname,...
● nologfilenocry – Normalerweise ist es ein Grund für
ein UNKNOWN, wenn das Logfile nicht existiert. Mit
dieser Option ist es einfach egal.
Aktionen bei einem
Treffer ausführen
Mit der Option script kann man dafür sorgen, daß
Code ausgeführt wird, sobald ein Pattern im
Logfile gefunden wurde.
script => 'name_eines_programms'
oder seit neuestem
script => sub { perl }
Warum?
Restart von Applikationen
Versenden von SNMP-Traps
Versenden von NSCA-Messages
Dadurch kann check_logfiles auch als
Standalone-Script laufen.
Nochmal
@searches =(
{
tag => 'suelz',
logfile => '/var/log/suelzomat.log',
criticalpatterns => ['ERROR', 'crashed'],
script => 'restart_suelzomat',
scriptparams => '--suelzprefix=bla',
options => 'script'
});
Und wenn das Script
fehlschlägt?
Dann muss man das hinnehmen, weil es ein
dämliches Script ist.
In jedem Fall ist der Exitcode von check_logfiles
CRITICAL.
Auch wenn der Restart geklappt hat und
eigentlich wieder alles in Ordnung ist.
Nehmen wir also das
Script ernst
@searches =(
{
tag => 'suelz',
logfile => '/var/log/suelzomat.log',
criticalpatterns => ['ERROR', 'crashed'],
script => 'restart_suelzomat',
scriptparams => '--suelzprefix=bla',
options => 'smartscript'
});
Ein smartscript hat
einen Exitcode
Und zwar von 0..3 wie man das so kennt.
Ein Exitcode 2 von restart_suelzomat wird
behandelt, als ob ein criticalpattern im Logfile
gefunden worden wäre. Die entsprechende
Message ist die erste Zeile des Outputs von
restart_suelzomat.
Was bringt das?
Msg. Suelzomat abgeraucht -> Critical Nr.1
Restart-Script schlägt fehl -> Critical Nr.2
2 Criticals. Na ja, warum nicht?
Msg. Suelzomat abgeraucht -> Critical Nr.1
Restart erfolgreich -> OK
Bleibt immer noch 1 Critical. Suboptimal.
Siebengescheite Scripts
@searches =(
{
tag => 'suelz',
logfile => '/var/log/suelzomat.log',
criticalpatterns => ['ERROR', 'crashed'],
script => 'restart_suelzomat',
scriptparams => '--suelzprefix=bla',
options => 'supersmartscript'
});
Supersmart?
Supersmart Scripts ersetzen mit ihrem Exitcode
und Output den auslösenden Treffer im Logfile,
anstatt ihn zu ergänzen.
Msg. Suelzomat abgeraucht -> Critical Nr.1
Restart-Script schlägt fehl -> Critical Nr.1 neu
“CRITICAL – restart of suelzomat failed”
Msg. Suelzomat abgeraucht -> Critical Nr.1
Restart erfolgreich -> OK
“OK – restarted suelzmat”
Pre- und Postscripts
Supersmart Prescripts brechen den Lauf von
check_logfiles komplett ab, wenn der Exitcode > 0
ist.
Wenn z.b. Ein Prozess nicht läuft, wozu dann
noch im Logfile dieser Applikation nach Fehlern
suchen?
Pre- und Postscripts
Supersmart Postscripts tauschen das
Endergebnis von check_logfiles komplett aus,
egal wieviele Error Messages vorher gefunden
wurden.
Fehlermeldungen, die
einem an der Backe kleben
@searches = ({
tag => 'suelzfull',
logfile => '/var/log/suelzomat.log',
criticalpattern => 'oversuelzed',
okpattern => 'restarted',
options => 'sticky=36000'
});
Check_logfiles liefert so lange CRITICAL, bis die
Applikation neu gestartet wurde, bzw. behält den
kritischen Zustand 10 Stunden bei.
Sehr, sehr experimentell. Am besten Finger weg!!!!!!
FIN

Weitere ähnliche Inhalte

Was ist angesagt?

coshsh
coshshcoshsh
Der oracle dba_und_seine_passwoerter
Der oracle dba_und_seine_passwoerterDer oracle dba_und_seine_passwoerter
Der oracle dba_und_seine_passwoerter
Gunther Pippèrr
 
Open-Source-Monitoring von Netzwerkkomponenten mit check_nwc_health
Open-Source-Monitoring von Netzwerkkomponenten mit check_nwc_healthOpen-Source-Monitoring von Netzwerkkomponenten mit check_nwc_health
Open-Source-Monitoring von Netzwerkkomponenten mit check_nwc_health
Gerhard Lausser
 
FLOW3-Workshop F3X12
FLOW3-Workshop F3X12FLOW3-Workshop F3X12
FLOW3-Workshop F3X12
Karsten Dambekalns
 
Introduction into Oracle Data Pump 11g/12c - Export and Import Data
Introduction into Oracle Data Pump 11g/12c - Export and Import DataIntroduction into Oracle Data Pump 11g/12c - Export and Import Data
Introduction into Oracle Data Pump 11g/12c - Export and Import Data
Gunther Pippèrr
 
Perl 5 Quiz Chemnitz Edition
Perl 5 Quiz Chemnitz EditionPerl 5 Quiz Chemnitz Edition
Perl 5 Quiz Chemnitz Edition
lichtkind
 
IT-Tage 2021: Java to Go - Google Go für Java-Entwickler
IT-Tage 2021: Java to Go - Google Go für Java-Entwickler IT-Tage 2021: Java to Go - Google Go für Java-Entwickler
IT-Tage 2021: Java to Go - Google Go für Java-Entwickler
Jan Stamer
 
01 sqlplus
01 sqlplus01 sqlplus
01 sqlplus
Gunther Pippèrr
 
GNU Bourne Again SHell
GNU Bourne Again SHellGNU Bourne Again SHell
GNU Bourne Again SHell
Fabian Becker
 
Wundertüte Perl
Wundertüte PerlWundertüte Perl
Wundertüte Perl
lichtkind
 
OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer
OSMC 2010 | Monitoring mit Shinken by Gerhard LaußerOSMC 2010 | Monitoring mit Shinken by Gerhard Laußer
OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer
NETWAYS
 
Funktionale Reaktive Programmierung mit Sodium
Funktionale Reaktive Programmierung mit SodiumFunktionale Reaktive Programmierung mit Sodium
Funktionale Reaktive Programmierung mit Sodium
Torsten Fink
 
IPC2017SE - Zend\Expressive Workshop
IPC2017SE - Zend\Expressive WorkshopIPC2017SE - Zend\Expressive Workshop
IPC2017SE - Zend\Expressive Workshop
Ralf Eggert
 
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...
NETWAYS
 

Was ist angesagt? (15)

coshsh
coshshcoshsh
coshsh
 
Der oracle dba_und_seine_passwoerter
Der oracle dba_und_seine_passwoerterDer oracle dba_und_seine_passwoerter
Der oracle dba_und_seine_passwoerter
 
Open-Source-Monitoring von Netzwerkkomponenten mit check_nwc_health
Open-Source-Monitoring von Netzwerkkomponenten mit check_nwc_healthOpen-Source-Monitoring von Netzwerkkomponenten mit check_nwc_health
Open-Source-Monitoring von Netzwerkkomponenten mit check_nwc_health
 
FLOW3-Workshop F3X12
FLOW3-Workshop F3X12FLOW3-Workshop F3X12
FLOW3-Workshop F3X12
 
Introduction into Oracle Data Pump 11g/12c - Export and Import Data
Introduction into Oracle Data Pump 11g/12c - Export and Import DataIntroduction into Oracle Data Pump 11g/12c - Export and Import Data
Introduction into Oracle Data Pump 11g/12c - Export and Import Data
 
Perl 5 Quiz Chemnitz Edition
Perl 5 Quiz Chemnitz EditionPerl 5 Quiz Chemnitz Edition
Perl 5 Quiz Chemnitz Edition
 
IT-Tage 2021: Java to Go - Google Go für Java-Entwickler
IT-Tage 2021: Java to Go - Google Go für Java-Entwickler IT-Tage 2021: Java to Go - Google Go für Java-Entwickler
IT-Tage 2021: Java to Go - Google Go für Java-Entwickler
 
01 sqlplus
01 sqlplus01 sqlplus
01 sqlplus
 
GNU Bourne Again SHell
GNU Bourne Again SHellGNU Bourne Again SHell
GNU Bourne Again SHell
 
Wundertüte Perl
Wundertüte PerlWundertüte Perl
Wundertüte Perl
 
Web Entwicklung mit PHP - Teil 1
Web Entwicklung mit PHP - Teil 1Web Entwicklung mit PHP - Teil 1
Web Entwicklung mit PHP - Teil 1
 
OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer
OSMC 2010 | Monitoring mit Shinken by Gerhard LaußerOSMC 2010 | Monitoring mit Shinken by Gerhard Laußer
OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer
 
Funktionale Reaktive Programmierung mit Sodium
Funktionale Reaktive Programmierung mit SodiumFunktionale Reaktive Programmierung mit Sodium
Funktionale Reaktive Programmierung mit Sodium
 
IPC2017SE - Zend\Expressive Workshop
IPC2017SE - Zend\Expressive WorkshopIPC2017SE - Zend\Expressive Workshop
IPC2017SE - Zend\Expressive Workshop
 
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...
OSMC 2008 | Programmierung von Nagios-Plugins für NetApp Speichergeräte by In...
 

Ähnlich wie Nagios Conference 2007 | Monitoring von Logfiles mit check_logfiles by Gerhard Laußer

Logging mit log4net
Logging mit log4netLogging mit log4net
Logging mit log4net
Thomas Mentzel
 
TYPO3 CMS 7.3 - Die Neuerungen - pluswerk
TYPO3 CMS 7.3 - Die Neuerungen - pluswerkTYPO3 CMS 7.3 - Die Neuerungen - pluswerk
TYPO3 CMS 7.3 - Die Neuerungen - pluswerk
die.agilen GmbH
 
TYPO3 CMS 7.6 - Die Neuerungen - pluswerk
TYPO3 CMS 7.6 - Die Neuerungen - pluswerkTYPO3 CMS 7.6 - Die Neuerungen - pluswerk
TYPO3 CMS 7.6 - Die Neuerungen - pluswerk
die.agilen GmbH
 
JAX 2024: Go in der Praxis einsetzen
JAX 2024: Go in der Praxis einsetzenJAX 2024: Go in der Praxis einsetzen
JAX 2024: Go in der Praxis einsetzen
Jan Stamer
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
Josef Adersberger
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
QAware GmbH
 
TYPO3 CMS 8.1 - Die Neuerungen - pluswerk
TYPO3 CMS 8.1 - Die Neuerungen - pluswerkTYPO3 CMS 8.1 - Die Neuerungen - pluswerk
TYPO3 CMS 8.1 - Die Neuerungen - pluswerk
die.agilen GmbH
 
TYPO3 CMS 6.2 LTS - Die Neuerungen
TYPO3 CMS 6.2 LTS - Die NeuerungenTYPO3 CMS 6.2 LTS - Die Neuerungen
TYPO3 CMS 6.2 LTS - Die Neuerungen
die.agilen GmbH
 
X$Tabellen und SgaScanner, DOAG 2009
X$Tabellen und SgaScanner, DOAG 2009X$Tabellen und SgaScanner, DOAG 2009
X$Tabellen und SgaScanner, DOAG 2009
Frank
 
Ausgewählte PL/SQL Packages (2)
Ausgewählte PL/SQL Packages (2)Ausgewählte PL/SQL Packages (2)
Ausgewählte PL/SQL Packages (2)
Ulrike Schwinn
 
Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...
Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...
Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...
OPITZ CONSULTING Deutschland
 
Rsyslog deutsche Qualitätsarbeit für Linux Roman Gächter
Rsyslog deutsche Qualitätsarbeit für Linux Roman GächterRsyslog deutsche Qualitätsarbeit für Linux Roman Gächter
Rsyslog deutsche Qualitätsarbeit für Linux Roman Gächter
Désirée Pfister
 
Rsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für LinuxRsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für Linux
Trivadis
 
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG KonferenzDomino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
panagenda
 
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
Marc Müller
 
OSMC 2014: Plugin Entwicklung für Einsteiger | Alexander Wirt
OSMC 2014: Plugin Entwicklung für Einsteiger | Alexander WirtOSMC 2014: Plugin Entwicklung für Einsteiger | Alexander Wirt
OSMC 2014: Plugin Entwicklung für Einsteiger | Alexander Wirt
NETWAYS
 
TYPO3 CMS 7.4 - Die Neuerungen - pluswerk
TYPO3 CMS 7.4 - Die Neuerungen - pluswerkTYPO3 CMS 7.4 - Die Neuerungen - pluswerk
TYPO3 CMS 7.4 - Die Neuerungen - pluswerk
die.agilen GmbH
 
Mögen die Tests mit dir sein
Mögen die Tests mit dir seinMögen die Tests mit dir sein
Mögen die Tests mit dir sein
codepitbull
 
TYPO3 CMS 7.5 - Die Neuerungen - pluswerk
TYPO3 CMS 7.5 - Die Neuerungen - pluswerkTYPO3 CMS 7.5 - Die Neuerungen - pluswerk
TYPO3 CMS 7.5 - Die Neuerungen - pluswerk
die.agilen GmbH
 
Python builds mit ant
Python builds mit antPython builds mit ant
Python builds mit ant
roskakori
 

Ähnlich wie Nagios Conference 2007 | Monitoring von Logfiles mit check_logfiles by Gerhard Laußer (20)

Logging mit log4net
Logging mit log4netLogging mit log4net
Logging mit log4net
 
TYPO3 CMS 7.3 - Die Neuerungen - pluswerk
TYPO3 CMS 7.3 - Die Neuerungen - pluswerkTYPO3 CMS 7.3 - Die Neuerungen - pluswerk
TYPO3 CMS 7.3 - Die Neuerungen - pluswerk
 
TYPO3 CMS 7.6 - Die Neuerungen - pluswerk
TYPO3 CMS 7.6 - Die Neuerungen - pluswerkTYPO3 CMS 7.6 - Die Neuerungen - pluswerk
TYPO3 CMS 7.6 - Die Neuerungen - pluswerk
 
JAX 2024: Go in der Praxis einsetzen
JAX 2024: Go in der Praxis einsetzenJAX 2024: Go in der Praxis einsetzen
JAX 2024: Go in der Praxis einsetzen
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
 
TYPO3 CMS 8.1 - Die Neuerungen - pluswerk
TYPO3 CMS 8.1 - Die Neuerungen - pluswerkTYPO3 CMS 8.1 - Die Neuerungen - pluswerk
TYPO3 CMS 8.1 - Die Neuerungen - pluswerk
 
TYPO3 CMS 6.2 LTS - Die Neuerungen
TYPO3 CMS 6.2 LTS - Die NeuerungenTYPO3 CMS 6.2 LTS - Die Neuerungen
TYPO3 CMS 6.2 LTS - Die Neuerungen
 
X$Tabellen und SgaScanner, DOAG 2009
X$Tabellen und SgaScanner, DOAG 2009X$Tabellen und SgaScanner, DOAG 2009
X$Tabellen und SgaScanner, DOAG 2009
 
Ausgewählte PL/SQL Packages (2)
Ausgewählte PL/SQL Packages (2)Ausgewählte PL/SQL Packages (2)
Ausgewählte PL/SQL Packages (2)
 
Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...
Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...
Wiederherstellung von Daten im Rechenzentrum - OPITZ CONSULTING - Andreas Rei...
 
Rsyslog deutsche Qualitätsarbeit für Linux Roman Gächter
Rsyslog deutsche Qualitätsarbeit für Linux Roman GächterRsyslog deutsche Qualitätsarbeit für Linux Roman Gächter
Rsyslog deutsche Qualitätsarbeit für Linux Roman Gächter
 
Rsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für LinuxRsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für Linux
 
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG KonferenzDomino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
 
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
 
OSMC 2014: Plugin Entwicklung für Einsteiger | Alexander Wirt
OSMC 2014: Plugin Entwicklung für Einsteiger | Alexander WirtOSMC 2014: Plugin Entwicklung für Einsteiger | Alexander Wirt
OSMC 2014: Plugin Entwicklung für Einsteiger | Alexander Wirt
 
TYPO3 CMS 7.4 - Die Neuerungen - pluswerk
TYPO3 CMS 7.4 - Die Neuerungen - pluswerkTYPO3 CMS 7.4 - Die Neuerungen - pluswerk
TYPO3 CMS 7.4 - Die Neuerungen - pluswerk
 
Mögen die Tests mit dir sein
Mögen die Tests mit dir seinMögen die Tests mit dir sein
Mögen die Tests mit dir sein
 
TYPO3 CMS 7.5 - Die Neuerungen - pluswerk
TYPO3 CMS 7.5 - Die Neuerungen - pluswerkTYPO3 CMS 7.5 - Die Neuerungen - pluswerk
TYPO3 CMS 7.5 - Die Neuerungen - pluswerk
 
Python builds mit ant
Python builds mit antPython builds mit ant
Python builds mit ant
 

Nagios Conference 2007 | Monitoring von Logfiles mit check_logfiles by Gerhard Laußer

  • 1. Überwachung von Logfiles mit check_logfiles
  • 2. Wer bin ich? Gerhard Laußer aus München arbeite bei der Firma ConSol betreue Nagios bei ***
  • 3. Entstehungsgeschichte Tivoli musste abgelöst werden. Tivoli hat einen sog. Logfile-Adapter. Programme müssen z.T. in Pipes schreiben. Ein Leseprozess muss ständig laufen. Schon wieder etwas, das kaputt gehen kann. Vorhandene Plugins lassen Lücken zu. Erste Version von Anfang 2006 für den Eigenbedarf. Stetige Weiterentwicklung und Zufluss von Ideen. ●
  • 5. Auspacken und Zusammenbauen tar zxvf check_logfiles-2.3.tar.gz cd check_logfiles-2.3 ./configure –help ..... --libexecdir=DIR program executables [PREFIX/libexec] ...... --with-nagios-user=USER set user name to run nagios --with-nagios-group=GROUP set group name to run nagios --with-seekfiles-dir=PATH sets directory for the state files (default=/tmp) --with-protocols-dir=PATH sets directory for the protocol files (default=/tmp) --with-trusted-path=PATH sets trusted path for executables called by scripts (default=/bin:/sbin:/usr/bin:/usr/sbin) --with-perl=PATH sets path to perl executable --with-gzip=PATH sets path to gzip executable ......
  • 6. So funktioniert's $ check_logfiles --logfile=/var/log/suelzomat.log --tag=gesuelz --criticalpattern='.*suelz.*' --rotation=debian OK - no errors or warnings |gesuelz_lines=31 gesuelz_warnings=0 gesuelz_criticals=0 gesuelz_unknowns=0 $ suelzomat –log-msg=”so ein gesuelze” $ sleep 999999 $ check_logfiles --logfile=/var/log/suelzomat.log --tag=gesuelz --criticalpattern='.*suelz.*' --rotation=debian CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-14-59-05) - so ein gesuelze |gesuelz_lines=9371 gesuelz_warnings=0 gesuelz_criticals=1 gesuelz_unknowns=0 $ suelzomat.log suelzomat.log.0 suelzomat.log.1.gzsuelzomat.log.0suelzomat.log so ein gesuelze
  • 7. So funktioniert's suelzomat.log suelzomat.log.0 suelzomat.log.1.gzsuelzomat.log.0suelzomat.log Hier endet der erste Lauf. Merke: Offset im Logfile und Modification Time Einige Zeit vergeht......... Eine Fehlermeldung wird erzeugt Mehr Zeit vergeht........ suelzomat.0 wird zu suelzomat.1.gz suelzomat.log wird zu suelzomat.log.0 Ein neues suelzomat.log wird angelegt Es wurden insges. 9371 Meldungen vom Suelzomat erzeugt
  • 8. So funktioniert's suelzomat.log.1.gzsuelzomat.log.0suelzomat.log 2.Lauf: Wo waren wir stehengeblieben? Zeitstempel und Offset Such mir jetzt alle Logfilekandidaten, die sich seit Zeitstempel geändert haben. suelzomat.log suelzomat.log.0 Sortier sie so, daß die älteste an erster Stelle kommt. Das ist dann das ehemalige Logfile, in dem wir ans Dateiende gestossen sind. suelzomat.log.0 suelzomat.log
  • 9. So funktioniert's suelzomat.log.0 suelzomat.log Und jetzt durchsuchen wir alles, was seitdem an Meldungen entstanden ist. suelzomat.log Bis das es nichts mehr zu durchsuchen gibt. Der Zeitpunkt der letzten Modifikation und die Position innerhalb des Logfiles werden wieder gespeichert. suelzomat.log.0
  • 11. 08/15 Beispiel $ check_logfiles -V check_logfiles v2.3 $ $ check_logfiles --logfile=/var/log/messages --tag=0815 –-criticalpattern='.*0815.*' OK - no errors or warnings |0815_lines=0 0815_warnings=0 0815_criticals=0 0815_unknowns=0 $ $ logger "test1 das ist doch 0815" $ logger "das nicht, weil 0916" $ $ check_logfiles --logfile=/var/log/messages --tag=0815 –-criticalpattern='.*0815.*' CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-15-10-02) - Oct 10 15:09:56 localhost lausser: test1 das ist doch 0815 |0815_lines=2 0815_warnings=0 0815_criticals=1 0815_unknowns=0 $ $ echo $? 2
  • 12. Mehr 08/15 Logging $ logger "gelaber" $ logger "test2 das ist auch 0815" $ logger "gefasel" $ $ check_logfiles --logfile=/var/log/messages --tag=0815 –-criticalpattern='.*0815.*' CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-15-12-02) – Oct 10 15:11:51 localhost lausser: test2 das ist auch 0815 |0815_lines=3 0815_warnings=0 0815_criticals=1 0815_unknowns=0 $ $ echo $? 2 $ $ logger "geblubber" $ check_logfiles --logfile=/var/log/messages --tag=0815 –-criticalpattern='.*0815.*' OK - no errors or warnings |0815_lines=1 0815_warnings=0 0815_criticals=0 0815_unknowns=0 $ echo $? 0
  • 13. Wie sieht die Servicedefinition aus? define service { service_description check_0815msgs host_name logserver max_check_attempts 1 is_volatile 1 check_command check_logfiles!0815!/var/adm/messages!.*0815.* } define command { command_name check_logfiles_critical command_line $USER1$/check_logfiles --logfile=”$ARG2$ --criticalpattern=" $ARG3$" --tag=" $ARG1$" } max_check_attempts darf nur 1 sein, weil der gleiche Fehler bei einem erneuten Check nicht wieder auftaucht.
  • 14. Wie werden überhaupt Rotationen erkannt? $ cat /tmp/check_logfiles._tmp_suelzomat.log.suelz $state = { logoffset => 10, logtime => 1182640189, devino => '773:510722', logfile => '/tmp/suelzomat.log', }; 1; Wie weit haben wir das Logfile gelesen? (= wie groß war es?) Wann wurde zuletzt was reingeschrieben? Welche Inode-Nummer hatte es? Dann schaut man sich das aktuelle Logfile an. Wie groß ist es und welche Inode-Nr. hat es? Damit lässt sich rausfinden, ob es eine Rotation gab und welche der wegrotierten Dateien in die Suche einbezogen werden müssen.
  • 15. Configfiles Das war Kinderkram: check_logfiles --wo? --was? Configfiles bieten wesentlich mehr : check_logfiles -f waskompliziertes.cfg
  • 16. Voriges Beispiel mit einem 08/15 Configfile $ cat gesuelze.cfg @searches = ({ tag => '0815', logfiles => '/var/log/messages', criticalpatterns => '.*0815.*', rotation => 'debian', options => 'noprotocol' }); $ $ check_logfiles -f gesuelze.cfg CRITICAL - (4 errors) – error: msg-0815 ... |0815_lines=39 0815_warnings=0 0815_criticals=4 0815_unknowns=0
  • 17. was bedeutet dieses noprotocol? Die Treffer im Logfile werden normalerweise in eine Protokolldatei geschrieben. /tmp/check_logfiles.protocol.<datum-zeit> $options => “noprotocol” schaltet das ab.
  • 18. Welche Parameter gibt es noch? $ cat gesuelze.cfg @searches = ({ tag => '0815', logfiles => '/var/log/messages', criticalpatterns => '.*0815.*', criticalexceptions => '.*0815 macht aber nix.*', warningpatterns => ['.*failure.*', '!successful'], warningthreshold => 10, okpatterns => '.*cleared.*', rotation => 'debian', options => 'case,script' script => 'restart_suelzomat' }); $
  • 19. Nochmal von Anfang an ● Wir durchsuchen ein oder mehrere Logfiles oder einfach irgendwelche Dateien ● Und zwar nach regular Expressions ● Manche sollen als CRITICAL und manche als WARNING gewertet werden. ● Von jeder Kategorie können mehrere angeben werden, auch solche die auftauchen müssen(!) ● Logfiles werden gelegentlich rotiert, aber auch die wegrotierten (und evt. komprimierten) Dateien werden durchsucht, so daß keine Lücken in der Überwachung entstehen.
  • 20. Globale Variablen im Konfigfile ● $protocolsdir – wohin mit den Protokolldateien. (def. /tmp) ● $protocolretention – Maximales Alter von Protokolldateien in Tagen. Nach Ablauf werden sie gelöscht. ● $seekfilesdir – wohin mit den seekfiles (def. /tmp. !!Solaris) ● @searches – Das Kernstück: wonach wird wo gesucht? ● $prescript – Ein Kommando, das ausgeführt wird, bevor die Sucherei anfängt. ● $postscript – dto. Wird ausgeführt, nachdem alle Logfiles durchsucht wurden. Kann Endergebnis bzw. Ausgabe beeinflussen.
  • 21. Globale Variablen im Konfigfile II ● $MACROS – Vordefinierte Strings, die man nachher in Dateinamen und Pattern wiederverwenden kann. $MACROS = { KAPUTTEPLATTE => 'scsi01lun02' }, ... criticalpatterns => 'SCSI error: ', criticalexceptions => '$KAPUTTEPLATTE$' Es gibt eine Fülle von Macros, die intern definiert wurden. (Uhrzeit, Hostname, Domain,...)
  • 22. Wichtig ist: Wo und was @searches = ( { tag => 'lamp-apache' logfile => '/var/log/apache/error.log', criticalpatterns => ['.*error.*, '.*fatal.'], rotation => 'solaris' }, { tag => 'lamp-mysql', logfile => '/var/log/mysql.log', criticalpatterns => ['corruption', 'you hit a bug'] } );
  • 23. Und sowas kommt raus CRITICAL - (1 errors in check_logfiles.protocol-2007-10-10-16-21-09) – InnoDB: Database page corruption on disk or a failed |lamp-mysql_lines=12 lamp-mysql_warnings=0 lamp-mysql_criticals=1 lamp-mysql_unknowns=0 Wieviele Criticals und Warnings Wenn der Admin zu faul ist, das Logfile zu durchsuchen, dann gibt's ein Protokollfile, wo die ganzen Fehlermeldungen drinstehen. Die aktuellste Fehlermeldung steht im Plugin-Output.
  • 24. Performancedaten <tag>_lines die Anzahl der Zeilen, die durchsucht wurden <tag>_warnings die Anzahl der gefundenen Warningpatterns <tag>_criticals die Anzahl der gefundenen Criticalpatterns <tag>_unknowns die Anzahl der gefundenen Unknownpatterns z.b: lamp-mysql_lines=8 lamp-mysql_warnings=1 lamp-mysql_criticals=0 lamp- mysql_unknowns=0 lamp-apache_lines=377 lamp-apache_warnings=0 lamp- apache_criticals=0 lamp-apache_unknowns=0 lamp-php_lines=19 lamp- php_warnings=3 lamp-php_criticals=0 lamp-php_unknowns=0
  • 25. Rotation Wenn die Durchsuchung von wegrotierten Logfiles gewünscht ist, dann muss man dem check_logfiles eine Hilfestellung geben, wie diese heissen könnten. Dazu gibt es das Feld “rotation” in einer search-definition. Der Wert dieses Feldes ist entweder eine vordefinierte Rotationsmethode oder ein regulärer Ausdruck.
  • 27. Vordefinierte Rotationen suse debian logrotate solaris hpux mod_log_rotate log log.1log log.0 log.20071008.gz log.20071009.gz log log.0 log log.1.gz log.0.gz log.1.gz OLDloglog log.1191940029 log.1191948332 log.1191953149
  • 28. Der Parameter type ● Was ist das überhaupt für eine Art von Logfile? ● Wenn rotation angegeben ist ,dann ist type implizit “rotation”. ● Wenn nicht, dann ist type implizit “simple”. Das nimmt man her, wenn Logfiles einfach gelöscht und neu angelegt werden, oder wenn man in Kauf nimmt, daß die letzten Zeilen in einer wegrotierten Logdatei nicht durchsucht werden.
  • 29. Krasse Typen ● type => 'virtual' für Linux-proc-file-device-status-oder-so- Dateien. z.b. /proc/scsi/lun/id/bla/online, wo 0 oder 1 drinsteht. Oder /proc/fcal/host/status, wo “Link: Up” drinsteht. Damit kann man schnell eine Hardwareüberwachung bauen. Diese Logfiles werden jedesmal ganz von Anfang an durchsucht. ● type => 'errpt' zum Durchsuchen des AIX Error Report. Die Ausgabe des errpt-Kommandos wird nach Pattern durchsucht, als wäre sie eine gewöhnliche Logdatei. ● type => 'psloglist' (experimental) zum Durchsuchen des Windows EventLog.
  • 30. Weitere Optionen ● noperfdata – Anzeige von Performancedaten wird unterdrückt ● syslogserver – im Logfile stehen Messages, die von allen möglichen Servern stammen. Mit dieser Option werden nur Messages vom lokalen Host untersucht. ● syslogclient – dto., aber diesmal werden nur Messages untersucht, die von einem bestimmten Client stammen. ...,syslogclient=hostname,... ● nologfilenocry – Normalerweise ist es ein Grund für ein UNKNOWN, wenn das Logfile nicht existiert. Mit dieser Option ist es einfach egal.
  • 31. Aktionen bei einem Treffer ausführen Mit der Option script kann man dafür sorgen, daß Code ausgeführt wird, sobald ein Pattern im Logfile gefunden wurde. script => 'name_eines_programms' oder seit neuestem script => sub { perl }
  • 32. Warum? Restart von Applikationen Versenden von SNMP-Traps Versenden von NSCA-Messages Dadurch kann check_logfiles auch als Standalone-Script laufen.
  • 33. Nochmal @searches =( { tag => 'suelz', logfile => '/var/log/suelzomat.log', criticalpatterns => ['ERROR', 'crashed'], script => 'restart_suelzomat', scriptparams => '--suelzprefix=bla', options => 'script' });
  • 34. Und wenn das Script fehlschlägt? Dann muss man das hinnehmen, weil es ein dämliches Script ist. In jedem Fall ist der Exitcode von check_logfiles CRITICAL. Auch wenn der Restart geklappt hat und eigentlich wieder alles in Ordnung ist.
  • 35. Nehmen wir also das Script ernst @searches =( { tag => 'suelz', logfile => '/var/log/suelzomat.log', criticalpatterns => ['ERROR', 'crashed'], script => 'restart_suelzomat', scriptparams => '--suelzprefix=bla', options => 'smartscript' });
  • 36. Ein smartscript hat einen Exitcode Und zwar von 0..3 wie man das so kennt. Ein Exitcode 2 von restart_suelzomat wird behandelt, als ob ein criticalpattern im Logfile gefunden worden wäre. Die entsprechende Message ist die erste Zeile des Outputs von restart_suelzomat.
  • 37. Was bringt das? Msg. Suelzomat abgeraucht -> Critical Nr.1 Restart-Script schlägt fehl -> Critical Nr.2 2 Criticals. Na ja, warum nicht? Msg. Suelzomat abgeraucht -> Critical Nr.1 Restart erfolgreich -> OK Bleibt immer noch 1 Critical. Suboptimal.
  • 38. Siebengescheite Scripts @searches =( { tag => 'suelz', logfile => '/var/log/suelzomat.log', criticalpatterns => ['ERROR', 'crashed'], script => 'restart_suelzomat', scriptparams => '--suelzprefix=bla', options => 'supersmartscript' });
  • 39. Supersmart? Supersmart Scripts ersetzen mit ihrem Exitcode und Output den auslösenden Treffer im Logfile, anstatt ihn zu ergänzen. Msg. Suelzomat abgeraucht -> Critical Nr.1 Restart-Script schlägt fehl -> Critical Nr.1 neu “CRITICAL – restart of suelzomat failed” Msg. Suelzomat abgeraucht -> Critical Nr.1 Restart erfolgreich -> OK “OK – restarted suelzmat”
  • 40. Pre- und Postscripts Supersmart Prescripts brechen den Lauf von check_logfiles komplett ab, wenn der Exitcode > 0 ist. Wenn z.b. Ein Prozess nicht läuft, wozu dann noch im Logfile dieser Applikation nach Fehlern suchen?
  • 41. Pre- und Postscripts Supersmart Postscripts tauschen das Endergebnis von check_logfiles komplett aus, egal wieviele Error Messages vorher gefunden wurden.
  • 42. Fehlermeldungen, die einem an der Backe kleben @searches = ({ tag => 'suelzfull', logfile => '/var/log/suelzomat.log', criticalpattern => 'oversuelzed', okpattern => 'restarted', options => 'sticky=36000' }); Check_logfiles liefert so lange CRITICAL, bis die Applikation neu gestartet wurde, bzw. behält den kritischen Zustand 10 Stunden bei. Sehr, sehr experimentell. Am besten Finger weg!!!!!!
  • 43. FIN