3. Livestatus livestatus

Transkript

1 Firma MK dozent_kettner & Nagios-Experte Linux Diplom Informatiker früher Entwickler bei SuSE Autor von,,fehlerdiagnose und Problembehebung unter Linux seit 2000 selbständig als Dozent und Consultant firma_kettner MK Schulung, Consulting, Support Schwerpunktthema: Linux im Rechenzentrum, Nagios Sitz in München, Haidhausen Kontakt: Preysingstraße München WWW: mathias-kettner.de 3. Livestatus livestatus Welche Wege gibt es zum Zugriff auf die Statusinformationen und historischen Ereignisse von Nagios? von Nagios? status.dat (und nagios.log) klassischer Weg (Nagios CGIs) Jede Anfrage erfordert komplettes Parsen Größe bei Services über 30 MB! Daten sind i.a Sekunden veraltet teilweise fehlen Informationen (z.b. Timeperiods) keine Unterstützung für verteiltes Monitoren SQL-Datenbanken NDO/Merlin Daten werden aktiv in Datenbank transportiert Zugriff über SQL teils recht komplexe Joins notwendig vor allem: Aktuellhalten ist extrem CPU/IO-hungrig! große Probleme mit Housekeeping, etc. zusätzlicher Aufwand durch Datenbank-Administration verteiltes Monitoring kaum unterstützt Check_MK s Livestatus Modul Idee: Nagios hat alle Daten im Hauptspeicher diese sind untereinander optimal verknüpft Warum nicht diese direkt anzapfen......und an einem Socket zur Verfügung stellen? Genau das macht Livestatus! erste stabile Version: 27. November 2009 Addons, die Livestatus unterstützen NagVis von Lars Michelsen: ab Version Thruk von Sven Nierlein: Nagios-CGI-Nachbau in Perl Nagios Business Process AddOns: ab Version und: Check_MK Multisite: komplett neue GUI Derzeit in Arbeit ist: Icinga Weboberfläche Architektur livestatus.o wird als NEB-Modul geladen dieses öffnet ein UNIX-Socket und wartet auf Anfragen Anfragen werden direkt aus Nagios-Daten beantwortet Eigene Anfragesprache erlaubt effizientes Filtern sehr schnelle Antworten und topaktuelle Daten überhaupt kein Disk-I/O minimaler CPU-Verbrauch, und das nur bei Abfragen Nagios-Knowhow (.z.b in_notification_period Verteiltes Monitoren mit Livestatus Livestatus horcht auf TCP Socket (per inetd) GUI fragt mehrere Sockets parallel ab......und baut daraus eine Gesamtsicht Das kann z. B. NagVis, Multisite und Thruk 4. Installation livestatus_installieren Zwei Methoden, um Livestatus aufzusetzen: ➊ Check_MK installieren und bei Livestatus,,yes sagen ➋ Livestatus ohne Check_MK von Hand kompilieren

2 2 Kompilieren von Hand Quellcodes von : Download tar xzf mk-livestatus tar.gz cd mk-livestatus /configure --prefix=/usr make -j 10 make install Ergebnis: /usr/lib/mk-livestatus/livestatus.o Livestatusmodul /usr/bin/unixcat Hilfsprogramm Modul in Nagios integrieren: /etc/nagios/nagios.cfg broker_module=/usr/lib/mk-livestatus/livestatu s.o /var/lib/nagios/rw/live event_broker_options=-1 /var/lib/nagios/rw/live ist das UNIX-Socket. Soll im gleichen Verzeichnis liegen, wie Pipe Hinten kann man Optionen anhängen, z. B.: debug...debuglevel (0, 1 oder 2) num_client_threads... Anzahl Threads Beispiel: Debugmodus einschalten: broker_module=/usr/lib/mk-livestatus/livestatu s.o /var/lib/nagios/rw/live debug=1 Dokumentation: s.html Danach Nagios neustarten. In nagios.log: nagios.log [ ] livestatus: successfully finished initialization Testabfrage echo -e 'GET status' /var/lib/nagios/rw/live unixcat accept_passive_host_checks;accept_passive_ service_checks;cached_log_messages;check_e xternal_commands;check_host_freshness;chec 1;1;0;1;0;1;8; ;1;0;1;1;1;0;0;6 0; ;0;1.1.6;18233;2; ;0;0;1; ;3.2.1;7; ;3;0 5. Livestatus LQL Die Livestatus Query Language Grundsätzlicher Aufbau: Text, Zeile für Zeile, Trenner ist Linefeed zuerst GET und den Namen einer Tabelle dann beliebig viele Header dann Verbindung schließen oder Leerzeile ähnlich, aber nicht gleich HTTP Beispiel GET hosts Columns: name alias Filter: state!= 0 livestatus_lql Tabellen (Version 1.1.3) Statusobjekte: hosts...alle Hosts services... alle Services hostgroups... alle Hostgruppen servicegroups...alle Servicegruppen comments... Host-/Servicekommentare downtimes...scheduled Downtimes Joins mit Gruppen: servicesbygroup...servicegruppen mit Services hostsbygroup...hostgruppen mit Hosts servicesbyhostgroup Hostgruppen mit Services Zweck: alle Elemente aller Gruppen in einer Anfrage Hosts/Services können mehrfach oder garnicht auftauchen Konfigurationsdaten: commands...kommandos contacts...kontakte contactgroups...kontaktgruppen timeperiods...zeitperioden (nur Name und Alias Sonstiges: log... Die Nagios Logdateien! status...programmstatus, Performance columns...alle Spalten aller Tabellen Header: Columns wählt benötigte Spalten aus Tabelle aus wenn vorhanden Header werden unterdrückt wenn fehlt alle Spalten Achtung: teils sehr viele Spalten (z. B. 190 bei log) nicht gewählte Spalten kosten keine Performance! Header: Filter wählt bestimmte Zeilen aus Tabelle aus definiert Bedingung auf einer Spalte Mögliche Operatoren: =...Gleichkeit!=...Ungleichkeit >...größer >=...größer oder gleich <...kleiner <=...kleiner oder gleich ~...passt auf regulären Ausdruck (Teilstring)

3 3 =~...gleich bis auf groß/klein ~~...regulärer ausdruck groß/klein Beispiele Alle Hosts, die nicht OK sind: GET hosts Filter: state!= 0 Services, deren Check länger als 3 sec. gedauert hat: GET services Filter: execution_time > 3 6. Livestatus per TCP Idee Livestatussocket per TCP erreichbar machen von anderem Nagioshost aus abrufen livestatus_tcp komplett neuer Ansatz des verteilten Monitorens! Vorgehen Wir nutzen unixcat und xinetd! UNIX-Socket an Port 6557 binden: /etc/xinetd.d/livestatus service livestatus { type = UNLISTED port = 6557 socket_type = stream protocol = tcp wait = no cps = flags = NODELAY user = nagios server = /usr/bin/unixcat server_args = /var/lib/nagios/rw/live only_from = / disable = no Hinweise: cps setzt Connections pro Sekunde rauf NODELAY verbessert TCP Antwortzeiten only_from immer verwenden! Test von anderem Rechner aus Querydatei anlegen (Leerzeile am Ende wichtig): query1 GET status Columns: program_version Query per netcat absenden: netcat nagioshost 6557 < query1 > Auch bei Abfragen mit echo Leerzeile > echo -e "GET hosts n" netcat klon Multisite Multisite - eine neue Nagios-GUI Alleinstellungsmerkmale: ➊ schnell ➋ flexibel ➌ ermöglicht verteiltes Monitoren multisite Multisite löst außerdem Multiadmin ab und übernimmt dessen Möglichkeiten der Massenadministration. ➊ Schnell Multisite baut direkt auf Livestatus auf sehr schnelle Antwortzeiten, auch bei sehr großen Installationen mit vielen zigtausend Checks ➋ Flexibel Erweiterbar in alle Richtungen via Plugins Dynamische Sidebar, pro User konfigurierbar am wichtigsten: frei definierbare Views ➌ Verteiltes Monitoren mit Check_MK Multisite direkter Zugriff auf mehrere Nagios-Instanzen Standortübergreifende Darstellung Darstellung als ein großes Monitoringsystem Einzelne Standorte bleiben aber erkennbar skaliert sehr gut, da kein zentraler Datenspeicher Standorte können flexibel zu- und weggeschaltet werden leicht auf bestehndes Nagios aufschaltbar 8. Multisite aufsetzen multisite_aufsetzen Multisite wird mit Check_MK automatisch mitinstalliert Eventell fehlt noch: Python-Unterstützung für Apache installieren: aptitude install libapache2-mod-python Dann Apache neu starten: /etc/init.d/apache2 restart Und jetzt: Konfiguration Größtenteils per Web konfigurierbar, außer: Benutzerrollen zuordnen Standorte (Sites) = Nagiosinstanzen definieren

4 4 Konfiuration geschieht in /etc/check_mk/multisite.mk Sites Eine Site ist eine Nagios-Installation. Default: nur lokales Nagios per UNIX-Socket Konfiguration von lokalem und entferntem Site: /etc/check_mk/multisite.mk sites = { "muc" : { "alias" : "Muenchen", "ham" : { "alias" : "Hamburg", "socket" : "tcp: :6557", Benutzerverwaltung Anmeldung per HTTP genau wie bei Nagios kein HTTP user bekannt kein Zugang Setup verwendet gleiche Userdatenbank Rollenzuordnung in multisite.mk Rollen Defaultrechte der Rollen: admin... Darf alles guest... Darf alles sehen aber nix machen user...darf seine Objekte sehen und steuern Zuordnung zu Rollen Admins in Variable admin_users listen: /etc/check_mk/multisite.mk admin_users = [ "nagiosadmin", "hh" ] Gäste in guest_users listen: guest_users = [ "welcome", "guest" ] Alle andere mit HTTP login sind user. Nur bestimmte Benutzer überhaupt reinlassen: users = [ "meier", "mueller" ] Jetzt darf kein Unbekannter mehr rein. 9. Views multisite_views View: Ansicht auf einen Teil der Statusdaten Merkmale einer View ➊ Datenquelle: Hosts, Services, etc. ➋ Layout: Tabelle, Blöcke,... ➌ Filter: Welche Datensätze werden gezeigt? ➍ Sortierung: In welcher Reihenfolge? ➎ Gruppierung: Nach was wird gruppiert? ➏ Spalte: Welche Datenfelder werden gezeigt......und wie werden sie verlinkt? Alldieskannfreieditiertwerden Views und Benutzer Jeder kann eigene Views erstellen er kann sie für andere freigeben Der Admin kann Systemviews abändern Sichtbarkeit von Views View hat einen Namen, z. B. allhosts. Jeder Benutzer kann View dieses Namens definieren. Es gilt folgende Reihenfolge: ➊ eigene Views ➋ öffentliche Views von Administratoren ➌ eingebaute Views ➍ öffentliche Views anderer Benutzer nur Admins können eingebaute Views überschreiben Filter Filter wählt bestimmte Datensätze aus, z. B.: nur Hosts mit Problemen Services mit einem Text im Namen Services die nicht in einer Downtime sind Vier Arten wie eine View einen Filter einsetzen kann: ➊ fest verdrahtet in View ➋ für Benutzer auswählbar ➌ über HTML-Variaben in URL setzbar (Verlinken) ➍ deaktiviert Beispiel für ➌ View host hat Filter für Hostname zum Verlinken. Aufruf dieser View für einen bestimmten Host: /check_mk/view.py?view_name=host&host=nagios Link-Filter dienen auch zum Verlinken von Views untereinander. 10. Vielen Dank extro_mk_kompakt Bis zum nächsten Kurs alles Gute und viel Spaß beim Erproben des Stoffs in der Praxis! Copyright 2010