Reimplementierung und Redesign von Nagios in Python

Transkript

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

2 Was hat ConSol mit Shinken zu tun? = =

3 Entstehung Autor Ziele Überblick Installation Konfiguration Überblick Komponenten Arbiter Scheduler Poller Reaktionner Broker / Module Start des Systems Ausblick Palaver

4 Situation

5 Situation

6 Autor: Jean Gabès

7 Performance VMware 4 GHz, 4 GB Services mit sleep(5..25) Hosts mit sleep(2..7)

8 Download und Installation Vorraussetzung ist ein Python-Interpreter 2.6.x (nicht 3.x!) und das Pyro-Modul Python 2.6 ist entweder bereits vorhanden oder man installiert das Source-Paket (./configure mit Defaulteinstellungen) Von holt man sich das Paket setuptools (Auspacken und python setup.py ) easy_install pyro git clone git://shinken.git.sourceforge.net/gitroot/shinken/shinken cd shinken/src vi etc/shinken-specific.cfg etc/*d.cfg Oder Monitoring::Generator::TestConfig mit layout=>shinken Am unkompliziertesten: Virtuelle Maschine von

9 Komponenten eines Shinken-Systems nagios.cfg arbiter scheduler shinken-specific.cfg ping checkresults checks eventhandler notifications events poller reactionner broker

10 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 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) Zerlegt die Konfiguration in mehrere Portionen, falls es mehrere Scheduler gibt (Nach Gewichtung und evt. Realm-Zugehörigkeit) Liest die Command-Pipe und schickt das Kommando an den/die zustandigen Scheduler

11 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

12 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 Verteilt die Arbeitspakete auf seine Worker (processes_by_worker) Ein Worker forked Prozesse, in denen die Plugins ausgeführt werden (ohne wait() ) 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 poller worker worker worker worker plugin plugin plugin

13 Komponenten eines Shinken-Systems - Reactionner Startet Workerprozesse (auch min_workers max_workers, aber default:1 reicht) Erhält Arbeitspakete vom Scheduler (Python-Objekte vom Typ Notification oder Eventhandler). Im Grunde sind das aufgelöste check_commands plus eine Referenz auf den Host/Service Verteilt die Arbeitspakete auf seine(n) Worker (processes_by_worker) So gut wie identisch zum Poller (viel gemeinsamer Code) reactionner

14 Komponenten eines Shinken-Systems - Broker Startet für jedes konfigurierte Modul einen Prozess und verbindet sich mit diesem durch eine FIFO 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 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 Ein Modul zu schreiben ist nicht besonders schwer, da kommen sicher noch viele gute Ideen broker module module module

15 Komponenten eines Shinken-Systems 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 einem eigenen Server laufen. Beispielsweise kann man (in etwa wie bei 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 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. 100% Python, daher lauffähig auf Unix, Windows, MacOS bzw. überall, wo ein Python 2.6 zur Verfügung steht

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

17 Komponenten eines Shinken-Systems Broker und Außendarstellung broker status_dat livestatus merlin

18 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

19 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)

20 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

21 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 Server verteilen arbiter arbiter scheduler scheduler scheduler poller poller poller reactionner reactionner reactionner broker broker broker

22 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 # shinken-specific.cfg specific.cfg define host { host_name srv_a realm de define host { host_name srv_b realm us define realm{ realm_name de default 1 } define realm{ realm_name us } define scheduler{ scheduler_name scheduler-de de node shinkensrv1.example.de } define scheduler { scheduler_name scheduler-us us node shinkensrv1.example.com }

23 Verteilte Konfigurationen - Realms arbiter de de scheduler-de poller-de us us srv_a scheduler-us poller-us srv_b

24 Poller für Spezialaufgaben poller_tag Shinken kennt für 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 take 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

25 Wo gibt s Informationen? Offizielle Webseite: Blog von Jean Gabès: Mailingliste: shinken-devel@lists.sourceforge.net Was zum Rumspielen: Login: shinken/shinken./launch_all Ninja: (monitor/monitor) Thruk: