3. Nagios am Limit check_mk_motivation

Transkript

1 1 1. dozent_kettner ² Æ Ó ¹ ÜÔ ÖØ Ä ÒÙÜ Diplom Informatiker früher Entwickler bei SuSE Autor von,,fehlerdiagnose und Problembehebung unter Linux seit 2000 selbständig als Dozent und Consultant 3. Nagios am Limit check_mk_motivation Nagios stößt bei sehr umfangreichen Installation an technische und menschliche Grenzen. Schwierigkeiten bei komplexen Installationen Konfigurationsaufwand Ausbringung und Pflege der Agenten evtl. viele unterschiedliche Zielplattformen Performance von Nagios! Übersicht in der Darstellung Verwaltungsaufwand beim Operating Ñ neues umfassendes Addon für Nagios ersetzt NRPE, NSClient++, check_snmp eigene Agenten für Linux, Unix, Windows und VMS vereinfacht Erstellen und Pflege der Konfiguration verbessert Gesamtperformance mehr Checks pro Zeit Lizenz: GNU GPL Version 2 Home: Ablauf mit NRPE, Beispiel: Dateisystem Grafische Oberfläche für die Konfiguration? hübsch, aber Firma MK firma_kettner ändert nicht was konfiguriert werden muss, sondern wie ersetzt nicht den Aufwand bei den Agenten hilft nicht beim Operating verbessert nicht die Performance gibt außerdem die Vorteile von Textdateien auf ➊ Nagios ruft check_nrpe als aktiven Check auf ➋ check_nrpe sendet Kommando an NRPE ➌ NRPE ruft check_disk als lokales Plugin auf ➍ Das Resultat geht zurück an check_nrpe ➎ Über Exitcode und stdout geht s weiter an Nagios Neuer Denkansatz notwendig! Ablauf mit Ñ : Ganzer Host auf einmal MK Schulung, Consulting, Support Schwerpunktthema: Linux im Rechenzentrum, Nagios Sitz in München, Haidhausen 4. check_mk check_mk Kontakt: Preysingstraße München WWW: mathias-kettner.de mk@mathias-kettner.de ➊ Nagios führt pro Host 1 pro Zyklus check_mk aus. ➋ check_mk kontaktiert den Agenten per TCP ➌ Der Agent ermittelt alle verfügbaren Daten auf einmal ➍ check_mk extrahiert relevante Daten gemäß Konfig. ➎ und sendet Ergebnisse als passive Checks zu Nagios. Beispielausgabe des Agenten:

2 2 <<<check_mk>>> Version: <<<df>>> /dev/mapper/system-root ext % / /dev/md1 ext % /boot /dev/mapper/system-home ext % /home /dev/mapper/system-svn ext % /svn /dev/mapper/system-local ext % /usr/local /dev/mapper/system-cd ext % /cdarchiv <<<ps>>> init [2] udevd --daemon /sbin/portmap /sbin/rpc.statd /usr/sbin/rpc.idmapd...usw... Umsetzung der Agenten: Windows Standalone check_mk_agent.exe als Dienst keine Konfiguration notwendig keine DLLs, keine Laufzeitumgebung nötig verwendet nur WIN32 API portabel aktuell nur über C/C++ erweiterbar Umsetzung der Agenten: Linux/UNIX einfaches Shellskript Einbindung per inetd, SSH oder stunnel optimal portabel, da nicht binär benötigt keine Nagios-Plugins! sehr einfach erweiterbar 5. Inventur check_mk_inventur Idee Agent sendet alle denkbaren Daten über Host z. B.: alle plattengebundenen Dateisysteme daraus automatisch Services ermitteln Dies geht auch in vielen anderen Fällen, z. B. Netzwerkkarten RAID-Arrays und -platten Multipathgeräte Hardwaresensoren Windows-Dienste Inventur in der Praxis ➊ Aufruf von check_mk -I alltcp ➋ neue Services werden gefunden ➌ Aufruf von check_mk -R ➍ Konfiguration für Nagios wird automatisch erzeugt! ➎... und Nagios durchgestartet Inventur arbeitet inkrementell und kann jederzeit wiederholt werden. 6. Demonstration und nun: kurze Demonstration in der Praxis! check_mk_demo 7. check_mk und SNMP check_mk_snmp Netzwerkgeräte, FC-Switche, Appliances, uvm. können nur per SNMP überwacht werden. oftmals: tabellarische Daten: Switchports, Sensoren... Prinzip von check_mk auch hier anwendbar In der Praxis: check_mk unterstützt viele Geräte out-of-the-box Beispiel: Cisco-Switches, Brocade FC-Switche, Bladecenter, FSC Server View, uvm. Beispiel: Ablauf Switchports ➊ SNMP auf Switch freigeben für Nagios ➋ Switch in all_hosts aufnehmen ➌ Inventur auslösen mit check_mk -I ifoperstatus ➍ check_mk -R erzeugt Konfig, startet Nagios durch check_mk überwacht automatisch alle belegten Ports 8. Inventurchecks check_mk_inventurchecks Idee warnen, wenn auf Host ungecheckte Items auftauchen Umsetzung check_mk --check-inventory $HOSTADDRESS$ läuft als normaler aktiver Nagios-Check pro Host is OK, wenn Inventur nichts neues finden würde Zyklus z.b. alle zwei Stunden Konfiguration Einfach in main.mk: main.mk inventory_check_interval = 120 Checks werden automatisch in Nagios integriert 9. Monitoring von Clustern check_mk_cluster Problemstellung Manche HA-Cluster habe keine Service-IP

3 3 Wie monitore ich einen Dienst wenn ich nicht weiß, wo er läuft? Lösung mit Ñ ➊: Definition meiner Cluster in main.mk: main.mk clusters = { "cluster1" : [ "node1", "node2" ], "cluster2" : [ "node3", "node4", "node5" ] } ➋: Festlegung, welche Dienste geclustert sind: clustered_services = [ ( ["knot11", "knot12"], [ "fs_/cdarchiv" ] ), ( ALL_HOSTS, [ "fs_/exchange" ] ) ] ➌: Inventur auslösen Rest geht automatisch 10. Weitere Funktionen check_mk_weiteres Logfilemonitoring Aggregation von Services Übersicht Multiadmin: Viele Services auf einmal steuern Kontakte, Hostgruppen, Servicegruppen zuordnen 11. check_mk aufsetzen check_mk_aufsetzen ➊: Ñ holen und installieren Software von holen und unter /root ablegen. Dann:»ÖÓÓØ Ø Ö ÜÞ Ñ ¹½º¼º ºØ Öº Þ Ñ ¹½º¼º Jetzt wichtig: Apache + Nagios muss laufen! Dann: º» ØÙÔº Defaults sind in der Regel richtig. Testen: Ñ ¹Î This is check_mk version Copyright (C) 2009 ➋: Installation des Agenten ÐÓ Ð Ó Ø auf Zunächst brauchen wir xinetd: ÔØ ØÙ Ò Ø ÐÐ Ü Ò Ø Jetzt den Agenten selbst installieren: Ô ¹»ÖÓÓØ» ¹Ñ ¹ ÒØ ½º¼º ¹¾ ÐÐº Test: Abruf der Daten von TCP Port 6556: Ò Ø Ø ÐÓ Ð Ó Ø <<<check_mk>>> Version: <<<df>>> /dev/hda1 ext <<<ps>>> init [2] udevd --daemon /usr/sbin/rsyslogd -c3 ➌: ÐÓ Ð Ó Ø in Monitoring aufnehmen Als ersten Host localhost aufnehmen: /etc/check_mk/main.mk all_hosts = [ localhost ] Inventurlauf: neue Checks finden: Ñ ¹Á ÐÐØÔ oracle_asm_dg cpu.loads lsi.disk vms_md statgrab_net.params multipath cpu.threads diskstat Ò Û ½ ½ Ò Û ¾ Ò Û Test: Check von localhost manuell durchführen: Ñ ¹ÒÚ ÐÓ Ð Ó Ø Getting info cpu from host localhost ( ) CPU load OK Number of threads OK - 69 threads fs_/ OK - 35% used Disk IO read OK - 0.0MB/s (in last secs) Disk IO write OK - 0.0MB/s (in last secs) CPU utilization OK - user: 0%, system: 1%, wait: 1% Memory used OK % of RAM (52 MB) used by processes NIC eth0 counters OK - Receive: 0.00 MB/sec - Send: 0.00 MB/sec OK - Agent Version , Successfully processed 8 host infos ➍: Durchstarten Jetzt fehlt noch: Konfiguration für Nagios generieren Hostchecks vorkompilieren Nagios neu starten das alles macht ein Befehl: Ñ ¹Ê Generating Nagios configuration for hosts...ok Generating Nagios configuration for services...ok Validating Nagios configuration...ok Precompiling host checks...ok Restarting Nagios...OK Host localhost und Services erscheinen in Nagios ➎: Ñ Weboberfläche check_mk bringt Webseite in Python mit: Einzige Funktion aktuell: ÅÙÐØ Ñ Ò Suchfunktion über Services Steuerbefehle auf Suchergebnis anwenden Dazu braucht Apache braucht mod_python

4 4 Python-Unterstützung für Apache installieren: ÔØ ØÙ Ò Ø ÐÐ Ð Ô ¾¹ÑÓ ¹ÔÝØ ÓÒ Dann Apache neu starten:» Ø» Ò Øº» Ô ¾ Ö Ø ÖØ Und jetzt: Am besten als Link in die Sidebar einbauen /usr/local/nagios/share/side.php <li><a href="/check_mk/filter.py" target=main >Check_MK Multiadmin</a></li> 12. Livestatus check_mk_livestatus Welche Wege gibt es zum Zugriff auf die aktuellen Statusinformationen von Nagios? status.dat klassischer Weg Jede Anfrage erfordert komplettes Parsen Daten sind i.a Sekunden veraltet Teilweise fehlen Informationen (z.b. Timeperiods) NDO / SQL-Datenbanken Daten werden aktiv in Datenbank transportiert Zugriff über SQL teils recht komplexe Joins notwendig Und: Aktuellhalten ist extrem CPU-hungrig! Große Probleme mit Housekeeping, etc. zusätzlicher Aufwand durch Datenbank-Administration Ñ s Livestatus Modul Idee: Nagios hat alle Daten im Hauptspeicher diese sind untereinander optimal verknüpft Warum nicht diese direkt anzapfen? Genau das macht Livestatus! 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 kein Overhead für Daten-Kopieren Nagios-Knowhow (.z.b in_notification_period) Beispiel: Verwendung von der Shell Komplette Information über alle Hosts: Ó ³ Ì Ó Ø ³ ÙÒ Ü Ø»» Ó Ø sh> Beispiele für Anfragen Alle Hosts holen, aber nur bestimmte Spalten: Columns: name alias address state Das gleiche, aber nur hosts, die nicht UP sind: Columns: name alias address state Filter: state!= 0 Tabellen sind verbunden, z.b. service host: Columns: description state Ó Ø Ø Ø Nagios-spezifische Logik Hosts, die gerade in ihrer notification_period sind: Filter: in_notification_period = 1 Alle nicht-ok services, für die harri ein Kontakt ist (auch indirekt über Host): Filter: contacts >= harri Zählen statt ausgeben Beispiel: wieviele Services sind OK/WARN/CRITICAL Stats: state = 0 Stats: state = 1 Stats: state = 2 Ausgabe sieht so aus: 834;12;2 Das gleiche, aber nur für einen bestimmten Host: Stats: state = 0 Stats: state = 1 Stats: state = 2 Filter: host_name = xyz Vielen Dank extro_mk_kompakt Bis zum nächsten Kurs alles Gute und viel Spaß beim Erproben des Stoffs in der Praxis!