Gerade eben bin ich über ein Problem gestopert, welches mir etwas Kopfzerbrechen bereitet hat.
Für eine NagVis-Grafik habe ich in der Icinga-Konfiguration kurz eine neue Servicegruppe angelegt. Obwohl ein kurzer Check mit
/usr/local/icinga/bin/icinga -v /usr/local/icinga/etc/icinga.cfg |
keine Probleme angezeigt hat, ist Icinga nicht mehr gestartet.
Nach
[1314104494] livestatus: Hint: please try out OMD - the Open Monitoring Distribution
[1314104494] livestatus: Please visit OMD at http://omdistro.org
[1314104494] Event broker module '/usr/local/lib/mk-livestatus/livestatus.o' initialized successfully.
[1314104494] idomod: IDOMOD 1.4.1 (05-11-2011) Copyright (c) 2005-2008 Ethan Galstad (nagios@nagios.org), Copyright (c) 2009-2011 Icinga Development Team (http://www.icinga.org))
[1314104494] idomod: Successfully connected to data sink. 0 queued items to flush.
[1314104494] Event broker module '/usr/local/icinga/bin/idomod.o' initialized successfully.
[1314104508] SERVICE FLAPPING ALERT: server.localhost;check_load;STARTED; Service appears to have started flapping (20.9% change >= 20.0% threshold)
[1314104511] TIMEPERIOD TRANSITION: 24x7;-1;1
[1314104511] TIMEPERIOD TRANSITION: shortWorkhours;-1;1
[1314104511] TIMEPERIOD TRANSITION: workhours;-1;1
[1314104570] livestatus: Couldn't write 16 bytes to client socket: Broken pipe |
war irgendwie Schluß und der Icinga-Prozess hat sich wieder verabschiedet.
Da die letze Meldung irgendwas mit mk-livestatus zu tun hat, hab ich an der Stelle angesetzt. Das Unix-Socket kann folgendermaßen geprüft werden:
echo 'GET hosts' | unixcat /usr/local/icinga/var/rw/live |
Da aber hier, trotz vorhandenem File, auch eine Fehlermeldung kam, hab ich mal ein bisschen in die Doku geschaut. Zuerst wollte ich mal schauen, was mk-livestatus überhaupt tut. Dies kann man erzwingen, wenn man dem Modul den Parameter debug=1 mit gibt.
define module{
module_name mk-livestatus
module_type neb
path /usr/local/lib/mk-livestatus/livestatus.o
args /usr/local/icinga/var/rw/live debug=1
} |
Leider hat dies auch nicht mehr Informationen zu Tage gebracht, da wohl das Problem gleich beim starten des mk-livestatus passiert. Die letzte Ausgabe war folgende
[1314104384] TIMEPERIOD TRANSITION: shortWorkhours;-1;1
[1314104384] TIMEPERIOD TRANSITION: workhours;-1;1
[1314104449] livestatus: Starting 10 client threads
[1314104449] livestatus: Query: GET services
[1314104449] livestatus: Query: GET services |
Beim durchlesen der möglichen Optionen bin ich dann auf die Option thread_stack_size gestoßen.
Folgendes gibt die Doku dazu her
This parameter sets the size of the stack of each client thread. In versions before 1.1.4, the stack size was set to 8 MB (pthread default). The new default value is 64 KB. A small stack reduces virtual memory usage and also save CPU ressources. A too small value will probably crash your Nagios process, though. You have been warned…
In der Tat war das der richtige Ansatz. Die Stack-Size des Prozesse erhöht sich mit Anzahl der zu checkenden Hosts und Services. Die aktuelle Stack-Size kann im proc-Filesystem ausgelesen werden. Dazu die PID des Icinga-Prozesses suchen und ein
cat /proc/<pid>/smaps
</pid> |
durchführen und den Block suchen, der mit [stack] beginnt:
...
7fff03bb4000-7fff03be6000 rw-p 00000000 00:00 0 [stack]
Size: 204 kB
Rss: 68 kB
Pss: 16 kB
Shared_Clean: 0 kB
Shared_Dirty: 56 kB
Private_Clean: 0 kB
Private_Dirty: 12 kB
Referenced: 68 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
... |
Die Zeile mit Rss zeigt dann den aktuell verwendeten Speicher an. In diesem Fall sind es mittlerweile 68kB.
Die Default Option liegt bei 64kB, so dass diese 4kB wohl zum unweigerlichen Absturz des Icinga-Prozesses führen.
Um das ganze wieder zum laufen zu bringen, muss das Borker-Modul mit einem angepassten thread_stack_size gestartet werden.
define module{
module_name mk-livestatus
module_type neb
path /usr/local/lib/mk-livestatus/livestatus.o
args /usr/local/icinga/var/rw/live thread_stack_size=131072
} |
Knapp 128kB (131072 byte) sollten eigentlich für die nächsten Checks ausreichen.
Aktuell sind es 302 Hosts und 3937 Services. Ziel nach der Migration von Nagios auf Icinga sind 1563 Hosts und 8887 Services … Mal sehen, was noch so alles auftaucht 
