openitcockpit Manual NSTA 2010 NSTA Manual Nagios-Satellite-Transfer-Agent it-novum GmbH 2010 Version 1.1

Transkript

1 NSTA Manual Nagios-Satellite-Transfer-Agent it-novum GmbH 2010 Version 1.1

2 Inhalt 1. Was ist der NSTA? Systemvoraussetzungen Installation Vorbereitung für Systeme, auf denen openitcockpit nicht installiert ist SSH-Keys Arbeiten an den Satelliten-Systemen NSTA.PL NSTA.INIT Konfiguration SQL-Konfiguration ohne bestehende openitcockpit Installation NSTA.PL Funktionsweise Bekannte Probleme NSTA allgemein Änderung bei PNP it-novum GmbH Version 1.1

3 1. Was ist der NSTA? Mit dem NSTA (NagiosSatelliteTransferAgent) ist es möglich, Daten von verschiedenen Nagios Satelliten-Systemen abzuholen und an eine zentrale Nagios-Instanz weiterzureichen (Distributed Monitoring). Die Daten werden mit Timestamps versehen und im Falle von System- oder Leitungsausfällen an verschiedene Stellen zwischengespeichert. Später können sie dann dem Nagioskern zugeführt werden (näheres siehe unter Funktionsweise). Die Verbindung, um Daten von den entfernten Systemen abzuholen, wird ausschließlich vom zentralen Mastersystem aus initiiert und verschlüsselt ausgeführt. Dadurch kann auch auf Daten zugegriffen werden, wenn der Master Server durch eine Firewall geschützt wird, weil die Verbindung grundsätzlich von innen aufgebaut wird. it-novum GmbH Version 1.1

4 2. Systemvoraussetzungen Systempakete: MySQL Nagios Gmp-devel Aus dem CPAN Archiv: Net::SSH::Perl (SSH2, einfach den Standards folgen. Achtung: Hier werden sehr viele CPAN-Pakete durch Abhängigkeiten installiert und der Crypt::DH Teil kann SEHR lange dauern!) Math::Pari Math::BigInt::GMP it-novum GmbH Version 1.1

5 3. Installation 3.1. Vorbereitung für Systeme, auf denen openitcockpit nicht installiert ist Falls NSTA auf einen System ohne eine openitcockpit Installation mit einer Nagios-Oberfläche laufen soll, muss als erstes die SQL-Datei in die MySQL Datenbank importiert werden, die den Satteliten-System-Teil der ITCOCKPIT- Datenbank installiert. mysql -uroot -p$passwort$ < nsta.sql Zum Verwalten bzw. zum Auslesen der Satellitensystemdaten benötigt NSTA einen MySQL-Benutzer mit passenden Rechten. Sollte ein solcher noch nicht existieren, muss er angelegt werden. Standards: Benutzername = nagios Passwort = open2itc mysql -uroot -p$passwort$ -e "create user 'nagios'@localhost identified by 'open2itc';grant USAGE ON *.* TO 'nagios'@'localhost' IDENTIFIED BY 'open2itc' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;GRANT ALL PRIVILEGES ON itcockpit.* TO 'nagios'@'localhost' WITH GRANT OPTION;" 3.2. SSH-Keys Für die Datenabholung über SSH benötig NSTA ein SSH-Key-Pair. Das Key-Pair kann wie folgt generiert werden: ssh-keygen -t rsa Der Schlüssel kann unter jedem Benutzer erstellt werden, solange aus der id_rsa.pub die User- und Hostbeschränkung entfernt wird. mit Beschränkung: *dksjfjwodfhng7/kdfj+sdfj== root@servername it-novum GmbH Version 1.1

6 ohne Beschränkung: *dksjfjwodfhng7/kdfj+sdfj== Der Inhalt des öffentlichen Teils "id_rsa.pub" muss auf die Satelliten-Systeme in den Homeordner des Nagiosuser "/home/nagios/" und dort in die Datei ".ssh/authorized_keys" eingefügt werden. Der private Teil "id_rsa" muss in den Ordner ".ssh" des Homeordner des Users kopiert werden, unter dem der NSTA laufen soll (Nagios Standard: nagios; openitcockpit Standard: wwwrun). 3.3 Arbeiten an den Satelliten-Systemen Um die Satelliten-Systeme zu veranlassen, ihre gemessenen Daten in das nsta.que (NSTA-Satelliten-Spool-File) abzulegen, müssen folgende Dinge im Nagios konfiguriert werden. In der Nagios Konfigurationsdatei nagios.cfg: ocsp_timeout=10 obsess_over_services=1 ocsp_command=submit_check_result obsess_over_hosts=1 ochp_command=submit_host_check_result Zusätzlich bindet man entweder die beiliegende sat.cfg ein: cfg_dir=/opt/openitc/s_nagios/etc/sat oder direkt die in ihr liegenden Kommandos: define command{ command_name submit_check_result command_line /usr/bin/printf "%b" "SERVICE^$TIMET$^$HOSTNAME$^$SERVICEDESC$^$SERVICESTATEID$^ $SERVICEOUTPUT$ $SERVICEPERFDATA$\n" >> /opt/openitc/s_nagios/var/sat/nsta.que } define command{ command_name submit_host_check_result it-novum GmbH Version 1.1

7 command_line /usr/bin/printf "%b" "HOST^$TIMET$^$HOSTNAME$^$HOSTSTATEID$^$HOSTOUTPUT$\n" >> /opt/openitc/s_nagios/var/sat/nsta.que } Damit Nagios die Datei nsta.que anlegen kann, muss noch der passende Ordner angelegt werden, falls dieser nicht schon angelegt ist. mkdir -p /opt/openitc/s_nagios/var/sat/ Neben der Nagios Konfiguration muss das Satellitenabholskript 'nsta.sh' auf das Satelliten-System kopiert werden und Ausführrechte für den Nagios User bekommen. Der Standardpfad ist "/opt/openitc/s_nagios/bin/nsta.sh". 3.4 NSTA.PL 1. Der Ordner für die Log-Datei mkdir -p /var/log/nsta Achtung! Die Berechtigungen müssen so angepasst werden, dass der User, unter dem NSTA laufen soll, einen Schreibzugriff auf den Ordner erhält. 2. Der Spoolordner am MasterSystem für den Fall, dass die "nagios.cmd" nicht verfügbar ist. mkdir -p /opt/openitc/nagios/var/spool/nsta/ Nachdem man auch noch die nsta.pl nach /opt/openitc/nagios/bin gelegt hat, kann man den Daemon per Hand starten. sudo -u wwwrun /opt/openitc/nagios/bin/nsta.pl -d Die Option -d steht für den Befehl, auch Debug Informationen in das LogFile /var/log/nsta/nsta.log zu schreiben. it-novum GmbH Version 1.1

8 3.5 NSTA.INIT Das Init-Skript "NSTA.init" muss nach /etc/init.d kopiert und in die passenden Runlevel eingetragen werden. insserv /etc/init.d/nsta.init 4. Konfiguration 4.1 SQL-Konfiguration ohne bestehende openitcockpit Installation Achtung: Die nachfolgenden Befehle sind ausschließlich für Nagios-Systeme ohne openitcockpit! Die Pflege der Satelliten-Systeme sollte nur über openitcockpit erfolgen. Anlegen von Sat.-Systemen (bitte tauschen Sie die $VARIABLEN$ aus, z.b. $IP$ durch ): mysql -unagios -popen2itc -Ditcockpit -e "INSERT INTO nag_satellites (name, ip, master, intern, id_tenant, id_location) VALUES ('$SAT_SYSTEM_NAME$', '$IP$', 0, 0, 0, 0);" Löschen von Satelliten-Systemen: mysql -unagios -popen2itc -Ditcockpit -e "DELETE FROM nag_satellites WHERE name = '$SAT_SYSTEM_NAME$' LIMIT 1;" Tipp: Einfacher geht es über Tools wie phpmyadmin! it-novum GmbH Version 1.1

9 4.2 NSTA.PL Der NSTA lässt sich mit vielen optionalen Parametern aufrufen, die die Standardwerte überschreiben. Eine detaillierte Übersicht über die möglichen Optionen bekommt man durch den Aufruf `./nsta.pl --help'. 5. Optionale Überwachung des NSTA Für die Überwachung der Funktion des NSTA gibt es ein rudimentäres Plugin, das auf die vom NSTA hinterlegten Statusdaten zurückgreift und einige wichtige Werte mit Performancedaten anzeigt. define command{ command_name command_line $ARG3$ $ARG4$ $ARG5$ } check_nsta $USER1$/check_nsta.sh $ARG1$ $ARG2$ Bei diesem Kommando gibt es folgende Optionen: ARG1 => der Sat.-Systemname => "Satsystem1" ARG2 => Warning Events min:max => "0:9999" ARG3 => Citical Events min:max => "0:9999" ARG4 => Warning SSH Transmissiontime => "2" ARG5 => Critical SSH Transmissiontime => "5" Beispielservice: define service { use failover-service host_name srvitc01 service_description NSTA-Beispiel-Satellit process_perf_data 1 check_period 24x7 max_check_attempts 10 it-novum GmbH Version 1.1

10 normal_check_interval 1 retry_check_interval 1 notification_interval 120 notification_period 24x7 notification_options c,r check_command check_nsta!beispiel- Satellit!0:9999!0:9999!2!5 active_checks_enabled 1 is_volatile 0 check_freshness 0 flap_detection_enabled 1 flap_detection_options o,w,u,c } 6. Funktionsweise NSTA wird als Dämon unter dem User "nagios" (Standard Nagios Installation) oder "wwwrun" (openitcockpit Installation) vom Initskript auf dem Master gestartet. Der Dämon holt sich aus der Datenbank bei jedem Durchlauf die aktuellen Satelliten-Systemdaten und kontaktiert jedes Satellitensystem, um dort über SSH die Satelliten-Spooldatei abzuholen und nach erfolgter Übertragung zu leeren. Falls die Abholung zu diesem Zeitpunkt nicht möglich ist, verbleiben die bereits von Satelliten-System gesammelten Daten in der Spooldatei und werden beim nächsten Aufruf abgeholt. Nachdem alle Daten von den Satelliten-Systemen eingesammelt wurden, werden sie aufbereitet und an die FIFO (FirstInFirstOut) "nagios.cmd" übergeben. Ist die "nagios.cmd" nicht verfügbar, werden die Daten des Durchlaufs in eine Spooldatei in den NSTA-Spoolordner des Mastersystems geschrieben. Bei jedem Durchlauf wird dann überprüft, ob die "nagios.cmd" wieder vorhanden ist. Ist das der Fall, werden alle bisher aufgelaufenen Spooldateien in ihrer chronologischen Reihenfolge an die "nagios.cmd" übergeben. Nachdem alle Spooldateien verarbeitet wurden, werden auch die Daten des aktuellen Durchlaufs an die "nagios.cmd" übergeben. it-novum GmbH Version 1.1

11 Damit die Funktionen des NSTA leicht zu überwachen sind, erzeugt NSTA bei jedem Durchlauf eine Statusdatei, in der die wichtigsten Werte wie "Anzahl der abgeholten Elemente eines Satelliten-Systems" oder "Die Übertragungsdauer pro Satelliten-System" hinterlegt sind. Da der NSTA als Dämon angelegt ist, kann auf seine Funktion nur über sein Kommandofile Einfluss genommen werden (/opt/openitc/nagios/ var/rw/nsta.cmd). Momentan gibt es für den NSTA allerdings nur ein Kommando "stop". Dieser Befehl bewirkt, dass der Dämon sofort alle Satelliten- Systeme abfragt und sich danach beendet. 7. Test der Funktionsweise Um zu testen, ob und wie die Nachverarbeitung der Prüfdaten funktioniert, liegt dem NSTA-Paket noch ein rudimentäres Plugin für die Satelliten-Systeme bei, das lediglich bei jedem Durchlauf um eins höher zählt und bei 50 wieder auf null zurückspringt. Durch die ständige und zeitlich festgelegte Änderung des Wertes lässt sich über die Grafendaten die Funktion des NSTA kontrollieren. Dazu einfach das Plugin in ein Satelliten-System einbinden und die Verbindung für ein paar Minuten unterbrechen. Nachdem die Verbindung wiederhergestellt ist, befüllen sich die Grafen nach kurzer Zeit nach und nach von selber. define command{ command_name command_line } check_nsta-test $USER1$/check_nsta-test.sh $ARG1$ it-novum GmbH Version 1.1

12 8. Bekannte Probleme 8.1 NSTA allgemein Beim Betrieb von NSTA kommt es manchmal zu einem Zombieprozess (immer wechselnde PID). Der Prozess ist nicht weiter problematisch, da sich der Parentprozess nach dem eingestellten Intervall wieder um sein Child kümmert und sein Ende bestätigt. Aus Sicherheitsgründen und um Probleme mit dem Abbau der SSH-Verbindung zu vermeiden, sollte NSTA nicht unter root betrieben werden. 8.2 Änderung bei PNP Damit die Nachverarbeitung auch bei PNP funktioniert, muss am Mastersystem folgende Option angepasst werde: service_perfdata_file_template=datatype::servic EPERFDATA\tTIMET::$LASTSERVICECHECK$\tHOSTNAME::$HOST NAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$ SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKC OMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOST STATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTAT ETYPE::$SERVICESTATETYPE$ ($TIMET$ wurde durch $LASTSERVICECHECK$ ersetzt) it-novum GmbH Version 1.1