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.

 

Ich beziehe mich in den folgenden Beispielen auf Icinga und Linux Systeme welche überwacht werden sollen. Als Monitoring-Software darf aber alles laufen was Nagios kompatible Checks verwenden kann. Also egal ob Nagios, Shinken, check_mk und wie Sie alle heißen mögen.

Icinga Agent

Wer ohnehin Icinga2 nutzt kann auch gleich den Icinga2 Agent nutzen. Der ist klein, schlank und sicher. Dazu ist er sauber in Icinga integriert. Klar, ist ja schließlich Icinga selbst. Hauptnachteil für mich: Der bläht die Zonenconfig immer so ungemein auf. Für einzelne Rechner wo man überwachen will gleich den großen Aufwand mit Zonen- und Endpoint-Config wagen? Kann man machen. Für alle ohne Icinga: ganz klar, hier muss was anderes her. Oder wechselt zu Icinga. Kann ich wärmstens empfehlen 😉

NRPE

Lange Zeit erstes Mittel der Wahl: NRPE, der Nagios Remote Plugin Executor (https://github.com/NagiosEnterprises/nrpe). Seit 2017 keine Änderung mehr. Wozu auch? Solange es funktioniert ist ja alles gut. Ja, NRPE ist simpel und einfach. Und da liegt vermutlich das Problem. Verschlüsselung gibt es, jedoch keine Authentifizierung. Lediglich das frei schalten von IP-Adressen welche Anfragen stellen dürfen. Dazu noch die tolle Problematik rund um dont_blame_nrpe. Jeder der das Konstrukt kennt weiß was ich meine. Ansonsten einfach mal nach dem Schalter in der Dokumentation suchen. Viel Spaß beim lesen 😉

Zusammengefasst: Kann man machen. Im abgeschlossenen Netzwerk hinter einer Firewall sollte Verschlüsselung und IP Filter reichen. Das Ding ist klein und schlank, die Problematik rund um dont_blame_nrpe haben genau genommen alle Remote Agent Lösungen. Dumm nur, dass bei aktuellen Distributionen wie z.B. SLES 15.1 der Trend dazu geht NRPE nicht mehr mit auszuliefern. Zu lange keine Änderungen an den Paketen heißt es in der Begründung. Dem Trend werden vermutlich weitere Distributionen folgen bzw. sind schon gefolgt. Als NRPE Nutzer sollte man wohl zumindest offen für anderes sein – jenachdem was die Zukunft einem zu bieten hat.

 

 

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!

Und Windows?

Hier gibt es ebenfalls SNMP. Was der so alles kann und ob bzw. wie man den erweitert weiß ich nicht wirklich. Gerne Kommentare dazu her!

Ich selbst nutze dafür bisher eigentlich immer diesen Weg: https://icinga.com/docs/icinga2/latest/doc/07-agent-based-monitoring/#nsclient-on-windows. Dank Icinga Agent ist die Übertragung gesichert und man kann über nscp ohne großen Aufwand alles mögliche Rund um Windows abfragen.

Testen

Ich nehme inzwischen ganz gerne um so etwas zu testen einen Docker Container. Hat den Vorteil, dass ich den Dienst in einem Container starten und falls ich den nicht mehr brauche einfach löschen kann. Ebenso unkompliziert ist es kurzerhand einen zweiten Dienst mit anderer Konifg parallel zu starten falls man was probieren möchte. Geht aber auch ohne Docker. Für alle mit Docker bzw. Docker interessierten füge ich hier mal meine docker-compose und dockerbuild Datei an:

Ginge auch ohne compose – zumal ich mit nur einem Container ausgekommen bin 😉

#
# Gehirn-Mag.Net snmpd
#

version: '3'

services:

   snmpd:
      build:
         context: .
         dockerfile: snmpd.Dockerfile
      ports:
         - "127.0.0.1:161:161/udp"
      volumes:
         - ./volumes/etc_snmp/:/etc/snmp/

 

Mein Docker-Container basiert auf Ubuntu 18.04. Sollte ein Proxy notwendig sein um das Internet zu erreichen einfach die beiden Proxy-Zeilen entsprechend anpassen.

FROM ubuntu:18.04

# Notwendige Software installieren
#ENV http_proxy=http://xxxx:xxxx@10.1.1.1:3128/
#ENV https_proxy=http://xxxx:xxxx@10.1.1.1:3128/
RUN apt-get update && apt-get install -y snmpd snmp-mibs-downloader snmp openssl monitoring-plugins git wget
RUN git clone https://github.com/dnsmichi/manubulon-snmp.git /usr/lib/nagios/plugins/manubulon
RUN wget "https://exchange.nagios.org/components/com_mtree/attachment.php?link_id=3121&cf_id=29" -O /usr/lib/nagios/plugins/check_by_snmp && chmod -v 0755 /usr/lib/nagios/plugins/check_by_snmp
RUN ln -sv /usr/lib/nagios/plugins/manubulon/plugins/*.pl /usr/local/bin
RUN ln -sv /usr/lib/nagios/plugins/check_snmp /usr/local/bin
RUN ln -sv /usr/lib/nagios/plugins/check_by_snmp /usr/local/bin

# snmpd vorbereiten und starten
ENV MIBSDIR=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
RUN /bin/mkdir -pv /var/run/agentx
CMD /usr/sbin/snmpd -Lo -u Debian-snmp -g Debian-snmp \\
    -I -smux,mteTrigger,mteTriggerConf -f

Im Container selbst sind dann die Manubulon Checks sowie check_snmp und check_by_snmp nach /usr/local/bin verlinkt. Zum testen also einfach direkt die Checks aufrufen.

Meine Beispiels snmpd.conf. Mit v2 Community „icinga“ sowie einem v3 Benutzer „icinga“ und Passwort „abcde%12345“.

#
# Gehirn-Mag.Net Beispiel snmpd.conf fürs Monitoring
#

#######################################
#
# Allgemeine Einstellungen
#


# Auf *:161 lauschen
agentAddress udp:161

#######################################
#
# Auth: 1x SNMPv3, 2x community
#


# system, interfaces, host, ucdavis, nsExtendObjects
view icinga included .1.3.6.1.2.1.1
view icinga included .1.3.6.1.2.1.2
view icinga included .1.3.6.1.2.1.25
view icinga included .1.3.6.1.4.1.2021
view icinga included .1.3.6.1.4.1.8072.1.3.2


# Die folgende Zeile "createuser..." sollte besser in /var/lib/snmp/snmpd.conf stehen
# Und das Passwort sollte sinnigerweise angepasst werden ;-)
createUser icinga SHA "abcde%12345" AES
rouser icinga default -V icinga
rocommunity icinga default -V icinga


# public darf nur die sysDescr sehen ;-)
view public included .1.3.6.1.2.1.1.1.0
rocommunity public default -V public


#######################################
#
# Build in - ein paar Beispiele
#


# System Informationen
sysLocation GMN-RZ/WDD
sysContact Mein.Gehirn-Mag.Net <mein@gehirn-mag.net>
sysServices 72


# Process Monitoring
proc snmpd


# Disk Monitoring
disk / 20%
includeAllDisks 10%


# System Load
load 12 10 5

#######################################
#
# Erweiterungen
#


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:

 

In der dritten Registerkarte direkt über diesem Abschnitt findet sich die von mir verwendete snmpd.conf. Diese kann auch ohne Docker als Ausgangsbasis für eigene Tests verwendet werden.

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.