Monitoring nach Remote

Monitoring kann spannende Dinge überwachen. Funktioniert richtig toll solange das Ziel direkt via Netzwerk vom Monitorring aus erreichbar ist. Ein SMTP Server lauscht üblicherweise auf Port 25 und dort geht – oh Wunder – doch tatsächlich ein SMTP-Server ran. Lässt sich super mit einem Check prüfen welcher SMTP spricht. Nur was ist wenn es keinen Netzwerkdienst zu der überwachenden Komponente gibt? Solche Dinge wie der Füllstand der Festplatte, die Auslastung der CPU? Ein Agent muss auf das Zielsystem. Bleibt die Frage nach dem welchem. Ein kurzer Überblick der Möglichkeiten.

check_by_ssh

Oder nur by_ssh wie es innerhalb von Icinga heißt. Jemand schon mal bei NRPE das Problem gehabt, dass der Ausgabe Text gekürzt wurde? Weil die maximale Größe für die Ausgaben seitens Quellcode auf 1024 Zeichen beschränkt wurde? Und wie gelöst? By_ssh? Willkommen im Verein 😉

Oder auch anders ausgedrückt: Welches Linux-System hat keinen ssh Server am laufen? Wenn es im Netz steht und man Monitoring darauf ansetzt dürfte es das so gut wie nie geben. Die Problematik der NRPE Installation ist weg, die Sicherheit ist hoch: Verschlüsselung und Authentifizierung ist bei ssh einfach super gelöst. Die dont_blame-Problematik ist hier sinngemäß die Gleiche: Wenn man erlaubt Argumente zu übergeben könnte jemand Blödsinn machen. Könnte. Heißt ja nicht gleich „muss“. Oder einfach keine Argumente zu lassen. Problem der Eventualität gelöst. Wo nichts ist kann auch niemand. Klingt super, oder? Naja, ein Problem fällt mir spontan dazu schon ein. Spaßverderber, ich weiß: Ich brauche einen Benutzer der sich via ssh anmelden kann.

Ok, das ist ja jetzt nicht so das Thema. Das Thema ist eher: Checks sind meistens irgendwelche Skripte, der Benutzer fürs Monitoring braucht somit eine Login-Shell. Der Benutzer kann sich also am System anmelden und Dinge tun die er aus Sicht des Monitoring gar nicht braucht. Wenn jetzt irgendjemand das Monitroing-System knackt und dort die Zugangsdaten fürs ssh ausliest oder den hinterlegten key entsprechend weiter verwendet… Ihr seht schon auf was ich raus will. Der Benutzer braucht also so irgendwas wie chroot mit nur den Checks und Bibliotheken drin die er braucht. Und vermutlich noch das proc-System weil da heraus solche Dinge wie Festplattenbelegung usw. heraus gelesen werden. Und was sonst noch alles so fehlt. Puh, ganz schön aufwendig.

Geht auch etwas anders: Für jeden Check einen eigenen Benutzer anlegen und dem via sshd-Config als auszuführendes Programm den entsprechenden Check hinterlegen. Oder die Login-Shell bei dem Benutzer auf den Check ändern. Irgendwas, was keine Anmeldung mehr in Richtung Shell mit der Möglichkeit der eigenen Befehlseingabe erlaubt.

Machbar also. Mit Aufwand. Ein Hoch auf Orchestrierungstools wie ansible, puppet, chef oder wie die alle auch heißen mögen.

SNMP

Ganz anderer Ansatz: SNMP kennt man. Drucker, Netzwerkkomponenten, diverse Appliances. Die alle haben SNMP drauf und das funktioniert doch super. Ok, in Version 2 mit Community-String ist die Sicherheit so naja. Aber spätestens mit v3 wo Authentifizierung und Verschlüsselung gefordert werden kann ist doch alles wunderbar. Und wenn dann der Monitoringbenutzer im SNMP-Baum unter seiner Kennung nur das findet was er fürs Monitoring braucht ist doch alles perfekt. Bleibt die Frage was mit den eigentlichen Checks fürs Monitoring ist.

Also der Reihe mal nach durchgehen: SNMP ist unter Linux rasch installiert. Von Haus aus gibt es bei Icinga bereits die Checks welche via SNMP CPU, RAM, Prozesse, Plattenplatz usw. auswerten können. Grobe Sicht auf das was die Hardware betrifft: Läuft. Und die speziellen Checks welche man ggf. sogar noch selbst programmiert hat? Ja, die laufen auch. Einfach in die Config mit aufnehmen, im Internet nach check_by_snmp suchen und wie analog zu NRPE oder by_ssh verwenden. Läuft ebenfalls (Links finden sich weiter unten).

Ok, braucht man einen snmpd-Dienst. Einen extra Dienst brauchst bei NRPE aber ebenfalls. Die Checks muss man in der Config definieren. Musst bei NRPE ebenfalls und wenn by_ssh „richtig“ machen willst ja auch. Von daher tut das eigentlich nicht weh. Ein weiterer Vorteil gefällig? Systeminventarisierung welche via SNMP Systeme ermittelt? Klar, das kannst jetzt ebenfalls machen. Ein spezielles Überwachungstool welches zusätzlich zum Monitoring läuft und ebenfalls SNMP kann? Na logisch doch, kein Problem. Und ich kenn sogar noch eine GroupWare Lösung welche via Webfrontend überwacht werden kann. Oder via AgentX Schnittstelle den lokal installierten SNMP erweitert. Somit ohne speziellen Checks am Monitoring dran. Das macht Laune, weil das funktioniert mit jeglichem Monitoring welches SNMP kann.

Fazit

SNMP ist viel spannender als man zunächst ggf. vermutet hätte. Jeder der das bisher noch nicht nutzt sollte es zumindest mal anschauen. Es lohnt sich!

Zum testen ist noch ein v2 Zugang mit icinga als Community String enthalten, ebenso steht der v3 Zugang direkt in dieser Konfigdatei. Diese sollte aber, wie im Kommentar erwähnt entsprechend in die zweite snmpd Konfig verschoben werden. Die vollständige Doku zur Konfig gibt es hier: http://www.net-snmp.org/docs/man/snmpd.conf.html

„Allgemeine“ Checks

Für Checks wie CPU, Plattenplatz usw. verwende ich gerne die SNMP-Checks von Manubulon. Diese sind z.B. in Icinga2 bereits enthalten. Ansonsten finden diese sich hier: http://nagios.manubulon.com/. Leider sind diese nicht mehr aktuell gepflegt, deswegen greife ich gerne auf diesen Fork von einem der Icigna Entwickler zurück: https://github.com/dnsmichi/manubulon-snmp. Diese sind ebenfalls im Container installiert und wären nach /usr/local/bin verlinkt.

Ein paar Beispiele dazu:

root@0b99c3febe7b:/# check_snmp_load.pl -H localhost -2c -C icinga -Tnetsl -w 1,1,1 -c 2,2,1.5
Load (CPUs: 4) : 0.56 1.00 1.34 : OK
root@0b99c3febe7b:/# check_snmp_mem.pl -H localhost -2c -C icinga -w 20,20 -c 30,30
Ram : 87%, Swap : 26% : > 30, 30 ; CRITICAL

Das funktioniert schon mal wunderbar 🙂

check_by_snmp

Um nun „eigene“ Nagios-Checks einzufügen muss man lediglich in der Config einen Eintrag der Form „extend <check_name> <check_command mit args>“ aufnehmen. In dem Beispiel von mir finden sich folgende zwei Zeilen:

extend   check_disk     /usr/lib/nagios/plugins/check_disk -w 20% -c 10%
extend   check_critical /usr/lib/nagios/plugins/check_procs -C gibtesnicht -c 1:

Vom Grundsatz her sieht das zu NRPE ja sehr ähnlich aus. Fehlt noch das passende Gegenstück zu check_nrpe bzw. check_by_ssh. Das gibt es hier: https://exchange.nagios.org/directory/Plugins/%2A-Remote-Check-Tunneling/check_by_snmp–2F-check_snmp_extend–2F-check_snmp_exec/details. In dem Beispiel-Container ist das, wie bereits erwähnt, ebenfalls nach /usr/local/bin verlinkt. Also einfach aufrufen. Und so sehen die beiden Beispiele aufgerufen aus:

root@0b99c3febe7b:/# check_by_snmp -H localhost -2 -C icinga -E check_disk
DISK WARNING - free space: / 30394 MB (20% inode=93%);| /=120929MB;127595;143544;0;159494
root@0b99c3febe7b:/# check_by_snmp -H localhost -2 -C icinga -E check_critical
PROCS CRITICAL: 0 processes with command name 'gibtesnicht' | procs=0;;1:;0;

Auch das funktioniert super! Mehrzeilige Ausgaben, der richtige Exit-Code: Kommt alles sauber mit rüber.

Sonstiges

Das war ja schon mal einiges was man damit tun kann. Es geht aber noch etwas mehr. Ich habe bei den Beispielen mit extend immer einen vollwertigen Nagios-Check aufgerufen. Das darf aber natürlich auch ein ein Skript sein welches zum Beispiel nur einen Integer Wert zurück liefert. Dieser kann dann mit check_snmp abgerufen und entsprechend weiter aufbereitet werden. Die Doku dazu gibt es hier: https://www.monitoring-plugins.org/doc/man/check_snmp.html. Der ist bei vielen Monitoringlösungen bereits mit dabei und ihr ahnt es ja bereits: Innerhalb von Icinga hießt der nur snmp.

Finale

Neben der Zugriffskontrolle die man wie so oft natürlich entsprechend umfangreich aufblähen kann ist der Rest der snmpd.conf jedoch eher kurz und übersichtlich gehalten. Also innerhalb kürzester Zeit machbar. Meiner Meinung nach lohnt es sich also SNMP als Alternative zu NRPE und check_by_ssh auf dem Schirm zu haben.