Reimplementierung und Redesign von Nagios in Python Gerhard Laußer 07.10.2010
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 07.10.2010 2 www.consol.de
Entstehung Autor Ziele Überblick Installation Konfiguration Überblick Komponenten Arbiter Scheduler Poller Reaktionner Broker / Module Ausblick Palaver 07.10.2010 3 www.consol.de
Situation 2009 07.10.2010 4 www.consol.de
Situation 2011 07.10.2010 5 www.consol.de
Autor: Jean Gabès 07.10.2010 6 www.consol.de
Performance 100K checks in 5min, Merlin interface : (in fact after code tuning I raised 150k). In a Xeon 4cores@3Ghz 07.10.2010 7 www.consol.de
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 07.10.2010 8 www.consol.de
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. 07.10.2010 9 www.consol.de
Komponenten eines Shinken-Systems nagios.cfg arbiter scheduler shinken-specific.cfg ping checkresults checks eventhandler notifications events poller reactionner broker 07.10.2010 10 www.consol.de
Komponenten eines Shinken-Systems - Arbiter nagios.cfg arbiter 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 07.10.2010 11 www.consol.de
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. 07.10.2010 12 www.consol.de
Komponenten eines Shinken-Systems - 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 poller Verteilt die Arbeitspakete auf seine Worker (processes_by_worker) Ein Worker forked Prozesse, in denen die Plugins ausgeführt werden worker worker worker Ein Worker prüft periodisch, ob Prozese schon fertig sind und liefert deren Ergebnis durch eine Queue zum Poller plugin plugin plugin 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 07.10.2010 13 www.consol.de
Komponenten eines Shinken-Systems - 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) reactionner worker notification eventhandler 07.10.2010 14 www.consol.de
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 broker module module module 07.10.2010 15 www.consol.de
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. 07.10.2010 16 www.consol.de
Scheduler poller checkresult reactionner check-action eventhandler-action notification-action broker log-brok statusupdate-brok 07.10.2010 17 www.consol.de
Komponenten eines Shinken-Systems Broker und Außendarstellung broker status_dat livestatus merlin 07.10.2010 18 www.consol.de
Was unterscheidet Shinken von Nagios? Simple Redundanz ping define scheduler{ scheduler_name scheduler-default default address node1 port 7774 spare 0 realm All weight 2 define scheduler{ scheduler_name scheduler-spare spare address node2 port 7774 spare 1 realm All weight 2 arbiter scheduler default scheduler spare ping 07.10.2010 19 www.consol.de
Rekonfiguration bei Ausfall einer Komponente ping failed arbiter scheduler default poller scheduler-spare, fang an zu arbeiten! scheduler spare ping Poller, du hast jetzt einen neuen scheduler (host:port) 07.10.2010 20 www.consol.de
Redundanz auf allen Ebenen Der Arbiter pingt die aktiven Knoten an und schickt bei Ausfällen Startkommandos mit neuer Konfiguration (host:port) arbiter arbiter scheduler scheduler poller poller reactionner reactionner broker broker 07.10.2010 21 www.consol.de
Redundanz und Loadbalancing auf allen Ebenen Da jeder Prozess auf einem beliebigen Server laufen kann, könnte man so eine Konfiguration im Extremfall auf 14 und mehr Server verteilen arbiter arbiter scheduler scheduler scheduler poller poller poller reactionner reactionner reactionner broker broker broker 07.10.2010 22 www.consol.de
Was kann Shinken, was Nagios nicht kann? Mehrere Konfigdateien einlesen Realms Poller_tag Maintenance_period Notificationway Hostgroup-Logik 07.10.2010 23 www.consol.de
Was kann Shinken, was Nagios nicht kann? 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) 07.10.2010 24 www.consol.de
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 define host { host_name srv_a realm de define host { host_name srv_b realm us # shinken-specific.cfg specific.cfg define realm{ realm_name de default 1 define realm{ realm_name us define scheduler{ scheduler_name scheduler-de de node shinkensrv1.example.de realm de define scheduler { scheduler_name scheduler-us us node shinkensrv2.example.com realm us 07.10.2010 25 www.consol.de
Verteilte Konfigurationen - Realms arbiter de de scheduler-de poller-de us us srv_de scheduler-us poller-us srv_us 07.10.2010 26 www.consol.de
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 07.10.2010 27 www.consol.de
Was kann Shinken, was Nagios nicht kann? 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 07.10.2010 28 www.consol.de
Was kann Shinken, was Nagios nicht kann? 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 07.10.2010 29 www.consol.de
Was kann Shinken, was Nagios nicht kann? 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 07.10.2010 30 www.consol.de
Was kann Shinken, was Nagios nicht kann? 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 07.10.2010 31 www.consol.de
Was kann Shinken, was Nagios nicht kann? 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 07.10.2010 32 www.consol.de
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 07.10.2010 33 www.consol.de