OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer

07.10.2010
Reimplementierung und Redesign
von Nagios in Python
Gerhard Laußer

07.10.2010 2 www.consol.de
Wer bin ich
• Monitoring Consultant @ ConSol
• 200 Mitarbeiter
• Business Unit Services
• OP5 Professional Partner
• Nagios-Projekte und Drumrum seit 2005
• Für Kunden, deren IT wir betreiben
• Für Kunden, die Nagios einführen oder nicht selbst betreiben wollen
• Plugin-Autor
• check_logfiles
• check_hpasm
• check_oracle/mysql/mssql/db2_health
• Co-Autor von Shinken

• Entstehung
• Autor
• Ziele
• Überblick
• Installation
• Konfiguration
• Überblick Komponenten
• Arbiter
• Scheduler
• Poller
• Reaktionner
• Broker / Module
• Ausblick
• Palaver

Situation 2009

Situation 2011

Autor: Jean Gabès

Performance
100K checks in 5min, Merlin interface :
(in fact after code tuning I raised 150k).
In a Xeon 4cores@3Ghz

Download und Installation
Vorraussetzung:
• Python-Interpreter 2.6.x oder 2.7.x (nicht 3.x!)
• Pyro-Modul
• Python ist entweder bereits vorhanden oder man installiert das Source-Paket
(./configure mit Defaulteinstellungen)
• Von http://pypi.python.org holt man sich das Paket setuptools
(Auspacken und „python setup.py“)
• easy_install pyro

Download und Installation
Shinken-Software
• git clone git://shinken.git.sourceforge.net/gitroot/shinken/shinken
• cd shinken
• (vi etc/shinken-specific.cfg)
• bin/launch_all.sh
• Am unkompliziertesten:
Virtuelle Maschine von http://www.shinken-monitoring.org/download/
• Die neue Version 0.3 gibt es als Virtualbox Image, Vmware kommt noch diese Woche.

ping
events
notificationseventhandlercheckresults
checks
Komponenten eines Shinken-Systems
arbiter
broker
scheduler
reactionnerpoller
nagios.cfg
shinken-specific.cfg

Komponenten eines Shinken-Systems - Arbiter
arbiter
nagios.cfg
shinken-specific.cfg
• Liest die Nagios-Konfigdateien und überprüft sie syntaktisch
• Liest die shinken-specific.cfg und kennt danach alle konfigurierten Komponenten im Netz
• Zerlegt die Konfiguration in mehrere Portionen, falls es mehrere Scheduler gibt (Nach
Gewichtung und evt. Realm-Zugehörigkeit)
• Erzeugt Python-Objekte aus host/service/etc-Definitionen und schickt sie dem Scheduler
• Überwacht kontinuierlich alle Prozesse
• Gibt Spare-Prozessen das Startsignal bei einem Ausfall (auch Arbiter-Spare ist möglich)
• Liest die Command-Pipe und schickt das Kommando an den/die zustandigen Scheduler

Komponenten eines Shinken-Systems - Scheduler
scheduler
• Erhält Hosts, Services, Commands, usw. in Form von Python-Objekten vom Arbiter
• Entscheidet, wann ein Host/Service gecheckt werden muss und hinterlegt einen
entsprechenden Arbeitsauftrag für den/die Poller
• Veranlasst die Ausführung von Dependency-Checks
• Analysiert die Checkergebnisse, die der/die Poller abgeliefert haben.
• Entscheidet anhand des SOFT/HARD/attempt -Algorithmus, ob Eventhandler oder
Notifications ausgeführt werden. Wenn ja, Arbeitsauftrag für den/die Reactionner
• Überwacht Freshness
• Erzeugt Broks (Log, Statusupdate) und legt die für den/die Broker zur Abholung
bereit.

Komponenten eines Shinken-Systems - Poller
poller
• Startet Workerprozesse (min_workers max_workers)
• Erhält Arbeitspakete vom Scheduler (Python-Objekte
vom Typ Check). Im Grunde sind das aufgelöste
check_commands plus eine Referenz auf den
Host/Service
• Verteilt die Arbeitspakete auf seine Worker
(processes_by_worker)
• Ein Worker forked Prozesse, in denen die Plugins
ausgeführt werden
• Ein Worker prüft periodisch, ob Prozese schon fertig
sind und liefert deren Ergebnis durch eine Queue zum
Poller
• Solange noch Slots frei sind und neue Checks
gefordert werden, können ständig weitere Plugin-
Prozesse geforkt werden.
• Legt dem Scheduler die Checkergebnisse (status,
exec_time, ) ins Postfach
• Kann zig-fach vorhanden sein
workerworker worker
plugin
plugin
plugin

Komponenten eines Shinken-Systems - Reactionner
reactionner
• Startet Workerprozesse
(auch min_workers max_workers, aber
normalerweise sollte default:1 reichen)
• Erhält Arbeitspakete vom Scheduler (Python-Objekte
vom Typ Notification oder Eventhandler).
• Verteilt die Arbeitspakete auf seine(n) Worker
(processes_by_worker)
• So gut wie identisch zum Poller
(viel gemeinsamer Code)
eventhandler
notification
worker

Komponenten eines Shinken-Systems - Broker
• Holt sich Broks vom Scheduler (Python-Objekte vom
Typ Brok, bestehend aus „type“ und „data“). Beispiele
sind: log, initial_service_status,
update_service_status, service_check_result,
service_next_check_schedule
• Startet für jedes konfigurierte Modul einen Prozess
und verbindet sich mit diesem durch eine FIFO
• Schiebt die Broks durch die Pipes zu den Modul-
Prozessen
• Modul-Prozesse entscheiden selbst, ob sie Broks mit
bestimmten „type“ verarbeiten.
(def manage_[brok-type]_brok)
• Es gibt Module für Logging in Datei, status.dat,
Livestatus, NDO (MySQL und Oracle), Merlin (MySQL
und SQLite), CouchDB, npcdmod
• Ein Modul zu schreiben ist nicht besonders schwer, da
kommen sicher noch viele gute Ideen
module module module
broker

Komponenten eines Shinken-Systems – Warum mehrere Prozesse?
• Das Kernstück, der Scheduler, wird entlastet. Er delegiert Jobs und kümmert sich ums
Scheduling und Bewerten von Checkergebnissen
• Alle diese Komponenten können auf ihrem eigenen Server laufen. Beispielsweise kann man
(in etwa wie bei nod_gearman oder DNX) mehrere Poller-Knoten hinstellen, die nur Plugins
ausführen.
• Alle diese Komponenten können auch als Standby-Prozesse laufen. Sie werden vom Arbiter
aufgefordert, tätig zu werden, wenn ein aktiver Prozess ausfällt (oder der Server, auf dem
dieser läuft)
• Die Kommunikation findet im Netzwerk und Hauptspeicher statt.
Keine Dateien mit Checkergebnissen, kein I/O, kein Parsen
Keine Fork-Orgien mit nsca
• Hängenbleiben einer Datenbank, z.B. NDO, führt nicht dazu, daß der Scheduler blockiert und
keine Checks mehr ausführt. Ist zwar schade, aber Checks/Notifications laufen weiter.
• 100% Python, daher lauffähig auf Unix, Windows, MacOS bzw. überall, wo ein Python 2.6 zur
Verfügung steht. Eine frühere Version lief auch auf Android.

Scheduler
broker
reactionner
poller
statusupdate-brok
log-brok
notification-action
eventhandler-action
check-action
checkresult

Komponenten eines Shinken-Systems – Broker und Außendarstellung
livestatus merlinstatus_dat
broker

Was unterscheidet Shinken von Nagios? Simple Redundanz
define scheduler{define scheduler{define scheduler{define scheduler{
scheduler_name schedulerscheduler_name schedulerscheduler_name schedulerscheduler_name scheduler----defaultdefaultdefaultdefault
address node1address node1address node1address node1
port 7774port 7774port 7774port 7774
spare 0spare 0spare 0spare 0
realm Allrealm Allrealm Allrealm All
weight 2weight 2weight 2weight 2
}}}}
scheduler_name schedulerscheduler_name schedulerscheduler_name schedulerscheduler_name scheduler----sparesparesparespare
address node2address node2address node2address node2
port 7774port 7774port 7774port 7774
spare 1spare 1spare 1spare 1
realm Allrealm Allrealm Allrealm All
weight 2weight 2weight 2weight 2
}}}}
arbiter
scheduler
default
scheduler
spare
ping
ping

Rekonfiguration bei Ausfall einer Komponente
arbiter
scheduler
default
scheduler
spare
ping
ping
failed
poller
scheduler-spare,
fang‘ an zu
arbeiten!
Poller, du hast
jetzt einen neuen
scheduler
(host:port)

Redundanz auf allen Ebenen
scheduler
scheduler
brokerreactionnerpoller
arbiter
arbiter
Der Arbiter pingt die
aktiven Knoten an
und schickt bei
Ausfällen
Startkommandos mit
neuer Konfiguration
(host:port)

Redundanz und Loadbalancing auf allen Ebenen
scheduler
arbiter
arbiter
scheduler
scheduler
poller
poller
reactionner
reactionner
broker
broker
Da jeder Prozess auf
einem beliebigen
Server laufen kann,
könnte man so eine
Konfiguration im
Extremfall auf 14 und
mehr Server verteilen

Was kann Shinken, was Nagios nicht kann?
• Mehrere Konfigdateien einlesen
• Realms
• Poller_tag
• Maintenance_period
• Notificationway
• Hostgroup-Logik

• Mehrere Konfigurationsdateien einlesen.
shinken-arbiter –c etc/nagios.cfg
–c etc/shinken-specific.cfg
–c etc/testconfig.cfg
• Kein „Killerfeature“, aber praktisch, um eine vorhandene Konfig mit Shinken zu testen
• Kann benutzt werden, um auf die Schnelle ein temporäres Verzeichnis mit Objektdefinitionen
ins Monitoring einzubinden, ohne die eigentliche Konfiguration anfassen zu müssen
(cfg_dir in testconfig.cfg)

Verteilte Konfigurationen - Realms
• Shinken kennt das Attribut „realm“ für hosts und
hostgroups
• Auch scheduler, poller, reactionner und broker können
mit „realm“ gekennzeichnet werden
• Der Arbiter zerteilt die Nagios-Konfiguration dann in
Teilkonfigurationen
• Jede Teilkonfiguration enthält nur die Hosts eines
bestimmten Realms
• Sämtliche Aktivitäten (checks, eventhandler,
notifications) bzgl. Hosts eines Realms werden dann
ausschliesslich in Prozessen durchgeführt, die zum
gleichen Realm gehören
# hosts.cfg# hosts.cfg# hosts.cfg# hosts.cfg
define host {define host {define host {define host {
host_name srv_ahost_name srv_ahost_name srv_ahost_name srv_a
realm derealm derealm derealm de
…………
define host {define host {define host {define host {
host_name srv_bhost_name srv_bhost_name srv_bhost_name srv_b
realm usrealm usrealm usrealm us
…………
# shinken# shinken# shinken# shinken----specific.cfgspecific.cfgspecific.cfgspecific.cfg
define realm{define realm{define realm{define realm{
realm_name derealm_name derealm_name derealm_name de
default 1default 1default 1default 1
}}}}
define realm{define realm{define realm{define realm{
realm_name usrealm_name usrealm_name usrealm_name us
}}}}
scheduler_name schedulerscheduler_name schedulerscheduler_name schedulerscheduler_name scheduler----dededede
node shinkensrv1.example.denode shinkensrv1.example.denode shinkensrv1.example.denode shinkensrv1.example.de
realm derealm derealm derealm de
…………
}}}}
define scheduler {define scheduler {define scheduler {define scheduler {
scheduler_name schedulerscheduler_name schedulerscheduler_name schedulerscheduler_name scheduler----usususus
node shinkensrv2.example.comnode shinkensrv2.example.comnode shinkensrv2.example.comnode shinkensrv2.example.com
realm usrealm usrealm usrealm us
…………
}}}}
…………

Verteilte Konfigurationen - Realms
scheduler-us
scheduler-de
poller-us
poller-dearbiter dede
usus
srv_de
srv_us

Poller für Spezialaufgaben – poller_tag
• Shinken kennt für Commands, Hosts und Services
sowie Poller das Attribut „poller_tag“
• „This variable is used to define the poller_tag of the
host. All checks of this hosts will only taken by pollers
that have this value in their poller_tags parameter.“
• Damit ist es z.B. möglich einen Unix- und einen
Windows-Poller aufzusetzen.
Die Kennzeichnung „poller_tag windows“ sorgt dann
automatisch dafür, daß Host- bzw. Servicechecks auf
dem Windows-System ausgeführt werden.
• Nicht mit Realms verwechseln. Beides kann zugleich
verwendet werden, z.B.
host_win_ny ist in Realm „us“ und besitzt das Poller-
Tag „win“
define command {
command_name check_command_test
command_line $USER1$/check_firewall
--hostname $ARG1$
poller_tag : DMZ
}
define poller {
poller_tag DMZ
…
}
define poller {
poller_tag WINDOWS
…
}

• Notificationways
Dient der Reduktion von Contacts.
Je nach Timeperiod ändern sich
notification_command und -options
define contact{
contact_name test_contact
alias test_contact_alias
email nobody@localhost
can_submit_commands 1
notificationways email_in_day,sms_the_night
}
#Email the whole 24x7 is ok
define notificationway{
notificationway_name email_in_day
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r,f
host_notification_options d,u,r,f,s
service_notification_commands notify-service
host_notification_commands notify-host
}
#But SMS only the night
define notificationway{
notificationway_name sms_the_night
service_notification_period night
host_notification_period night
service_notification_options c
host_notification_options d
service_notification_commands notify-service-sms
host_notification_commands notify-host-sms
}

• Result_modulations
Wird verwendet, damit Testserver
keine CRITICALs erzeugen, die
schwerwiegend aussehen, tatsächlich
aber niemanden so richtig interessieren
define resultmodulation{
resultmodulation_name critical_is_warning
# optional: welche exitcodes sollen modifiziert werden?
exit_codes_match 2
# was soll nachher rauskommen?
exit_code_modulation 1
# wann soll modifiziert werden?
modulation_period night
}
define service/host {
name ichwillschlafen
register 0
resultmodulations critical_is_warning
}
define service {
service_description check_cpu
host_name test_spielzeug_srv1
use ichwillschlafen
…

• Flexible Zuordnung zu Hostgroups
• & : UND-Verknüpfung von Hostgroups
• | : ODER-Verknüpfung
• ! : NICHT in einer Gruppe oder Verknüpfung
• , : alternative ODER-Verknüpfung
• ( und ) : Verschachtelung
define service {
hostgroup_name
fileserver & hw_qlogic & !test
...
Check_command check_fcal
}

• enable_problem_impacts_states_change=1
• Wenn ein Router (oder allgem. Ein Host) down ist, dann
bekommt alles, was dahinterhängt, den Status
UNREACHABLE bzw. UNKNOWN.
• Ist auch per Livestatus abfragbar.
• GUIs sollen künftig Ursache und Auswirkung eines Problems
anzeigen können
Bsp. gw-asia DOWN
=> _alle_ Services in Asien werden UNKNOWN
Wenn man künftig bei einem Service von srv-asia3 auf
„Problem“ klickt, sieht man gw-asia
Klickt man bei gw-asia auf „Impact“, sieht man die davon
betroffenen Hosts und Services
Integration in Thruk ist in Arbeit

• maintenance_period
• Versetzt Hosts/Services automatisch in
downtime, z.B. wenn es wiederkehrende
Wartungsfenster gibt.
• Man muss keine Cronjobs pflegen, die so
etwas auch könnten.
• Jetzt auch in OP5 Monitor/Ninja
So ein Feature scheint also wichtig.
define host {
host_name termsrv1
maintenance_period not_sat_morning
…
}
define service {
service_description check_citrix
host_name termsrv1
…
}

Wo gibt‘s Informationen?
• Offizielle Webseite: http://www.shinken-monitoring.org
• Mailingliste: shinken-devel@lists.sourceforge.net
• Wunschzettel: http://shinken.ideascale.com (wird tatsächlich gelesen!)
• Blog von Jean Gabès: http://gabes.fr

OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (13)

Ähnlich wie OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer

Ähnlich wie OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

OSMC 2010 | Monitoring mit Shinken by Gerhard Laußer