check_mk auf Synology mit DSM 6 und höher

Die Idee

Ursprünglich hat mich dieser Blog-Artikel auf die Idee gebracht, auf meinem Synology NAS den check_mk agent zu installieren, da das von Synology „mitgelieferte“ SNMP-Monitoring zwar sehr performant ist, aber leider nur sehr rudimentäre Informationen zum Zustand des NAS liefert.

Da ich mich am Ende dann doch nur sehr grob an dem o.g. Artikel orientiert habe, habe ich beschlossen, selbst einen Artikel zum Thema zu schreiben, statt einen Kommentar im Blog zu hinterlassen.

Die Basis – ssh-Abfrage oder bootstrap mit xinetd?

Für ältere DSM-Versionen (4.x und 5.x) kommt man im Grunde nicht an einem bootstrap der Synology vorbei, da für eine sinnvolle Nutzung des check_mk agents noch einige zusätzliche Tools und Pakete benötigt werden, die bei älteren DSM-Versionen nicht mitgeliefert werden.

Ab DSM 6 läuft der check_mk linux agent aber auch ohne zusätzliche Software einwandfrei, da diese DSM-Version alle Voraussetzungen bereits mitbringt.

Wer sein NAS mit DSM 6 oder höher nicht ausschließlich dafür bootstrappen will, um anschließend den check_mk agent darauf laufen zu lassen, dem würde ich eher empfehlen, den Agent per ssh-Abfrage zu nutzen.

Die bootstrap-Variante ist für alle Nutzer interessant, die sowieso schon eine Paketverwaltung auf ihrem NAS installiert haben oder die nach einem guten Grund suchen, sich mit dem Thema auch für andere Anwendungsmöglichkeiten zu befassen.

Installation der Paketverwaltung (bootstrap)

In vielen bootstrap-Artikeln für Synology-Geräte wird die Installation von ipkg beschrieben. Da ipkg jedoch seit Jahren nicht mehr gepflegt wird und inzwischen (hoffnungslos) veraltet ist, würde ich immer eine der verfügbaren Paketverwaltung auf Basis von opkg vorziehen, sofern diese für für die Prozessor-Architektur des eigenen NAS verfügbar ist.

Vor allem die Besitzer von Synologys mit PowerPC-Prozessoren bleiben bei opkg jedoch leider außen vor. Zumindest ist mir bei mehreren Recherchen in den letzten Jahren keine opkg-Distribution für die PPC-Linie von Synology untergekommen.

Für ARM- und Intel-Architekturen kann ich die entware-ng Distribution empfehlen. Und um hier nicht alles doppelt zu schreiben, verweise ich für die eigentliche Installation auf den sehr guten Artikel dazu auf der entware-ng Seite:

Install on Synology NAS

Installation und Konfiguration des xinetd

Nach dem bootstrap wird mit dem Befehl

opkg install xinetd

der xinetd daemon installiert.

Anschließend wird /opt/etc/xinetd.conf editiert und am Ende der Datei die Konfiguration für den check_mk Service ergänzt:

service check_mk
{
 type = UNLISTED
 port = 6556
 socket_type = stream
 protocol = tcp
 wait = no
 user = root
 server = /opt/bin/check_mk_agent
 log_on_success =
 disable = no
}
Weiterhin muss die Datei /opt/etc/xinetd.d/check_mk mit folgendem Inhalt angelegt werden:
user=root
server=/opt/bin/check_mk_agent

Installation des Check_MK Agents

Nun wird der eigentliche Check_MK Agent auf das NAS kopiert. Das geht am einfachsten per scp vom NAS aus. Benutzer und Host für das scp-Kommando (root@nagios) müssen entsprechend angepasst werden:
scp root@nagios:/opt/omd/versions/default/share/check_mk/agents/check_mk_agent.linux /opt/bin/check_mk_agent
Nun kann xinetd mit dem Befehl
/opt/etc/init.d/S10xinetd start
gestartet werden.
Das ist im Grunde auch schon alles, das Synology NAS sollte sich nun über die Inventarisierung per Check_MK zum Monitoring hinzufügen lassen.

Bonus: Nutzung lokaler Plugins und Konfigurationsdateien

Auf einem Synology NAS ist es bei der Nutzung eigener Software ratsam, um Systemverzeichnisse, wie /usr/ oder /etc/, einen Bogen zu machen, da bei DSM-Updates das, wenn auch kleine, Risiko besteht, dass selbst vorgenommene Änderungen in diesen Verzeichnissen überschrieben oder gelöscht werden und damit verloren gehen.
Im Linux check_mk_agent stehen diese Pfade leider ausschließlich „hard-coded“ im Agent-Skript selbst. Das Agent-Skript direkt zu ändern, ist nicht optimal, aber es ist die einfachste und verlässlichste Methode, diese Anpassung auf die Synology-Umgebung vorzunehmen.
Im Agent-Skript /opt/bin/check_mk_agent muss dazu den Pfaden in den folgenden Konfigvariablen ziemlich am Anfang des Skripts ein ‚/opt‘ vorangestellt werden:
[...]
export MK_LIBDIR="/opt/usr/lib/check_mk_agent"
export MK_CONFDIR="/opt/etc/check_mk"
export MK_VARDIR="/opt/var/lib/check_mk_agent"
[...]
Hinweis: Diese Anpassung muss bei jedem Update des Agenten wiederholt werden.

Tipp: Falls eins oder mehrere der oben konfigurierten Verzeichnisse noch nicht existieren, können diese mit dem folgenden Befehl angelegt werden:

mkdir -p /opt/usr/lib/check_mk_agent /opt/etc/check_mk /opt/var/lib/check_mk_agent
Nun können lokale Plugins im Verzeichnis
/opt/usr/lib/check_mk_agent/plugins/
abgelegt werden. Diese werden vom check_mk Agent nun ebenfalls ausgeführt und in der Agent-Ausgabe ergänzt.
Konfig-Dateien für den Check_MK Agent können entsprechend im Verzeichnis
/opt/etc/check_mk/
gespeichert werden.

Troubleshooting

Der check_mk agent kann zunächst auf dem NAS selbst gestartet werden, um zu prüfen, ob das Skript überhaupt läuft:
/opt/bin/check_mk_agent
Sofern das funktioniert, wird geprüft, ob der xinetd läuft und einen Service auf Port 6556 anbietet:
netstat -tulpen | grep 6556
Es sollte eine Ausgabe der Art
tcp 0 0 0.0.0.0:6556 0.0.0.0:* LISTEN 0 29375177 25063/xinetd
erscheinen. Wenn nicht, wurde der xinetd nicht korrekt konfiguriert oder nicht gestartet.
Passt das auch, wird als nächstes versucht, den Agent lokal per netcat oder telnet anzusprechen. Auf der Synology ist OOTB allerdings weder netcat, noch telnet verfügbar. Über opkg kann jedoch zumindest das Paket ’netcat‘ installiert werden:
opkg install netcat
Nun kann mit dem Befehl
netcat localhost 6556
geprüft werden, ob der Check_MK Agent seine Ausgabe liefert.
Funktioniert das ebenfalls, sollte das gleiche vom Monitoring-Server aus probiert werden.
Mit dem folgenden Befehl kann die Rohausgabe des Linux Agenten auf dem Monitoring-Server per Check_MK angezeigt werden. Der Hostname ’synology‘ muss angepasst werden:
cmk -d synology
Statt des Hostnamens kann auch eine IP angegeben werden, um Probleme bei der Inventarisierung (innerhalb check_mk) oder mit der Namensauflösung auf dem Monitoring-Server auszuschließen.