PRTG und SSH

Auf den SSH-Sensor von PRTG bin ich über einen Kollegen aufmerksam geworden, der die Temperatur seiner selbst gebauten PFSense-Firewall messen wollte. Bei seinem Selbstbau-PC mit AMD-CPU konnte der Wert nicht per SNMP abgerufen werden. Aber auf dem BSD-Unix kann man mit SYSCTL die Daten ermitteln.

Auslöser

Die Aufgabenstellung ergab sich daraus, dass er eine lüfterlose PC-Plattform auf Basis eines APU2C4 Boards mit 3x Gigabit als PFSense-Firewall auf gebaut an, die aber nicht die erwartete Stabilität geliefert hat. Ursächlich dürfte dabei die CPU-Temperatur gewesen sein, die PFSense auch angezeigt hat:

Technisch wurde das Problem dann so gelöst, dass mein Kollege ein Loch in das Gehäuse gemacht hat um auf die CPU, die auf der Unterseite der Platine sitzt, einen Lüfter zu setzen.

Die Firewall muss nun natürlich "kopfüber" montiert werden, damit der Lüfter oben ist und sollte mechanisch auch geschützt sein. Auch wenn es nur für den Heimgebrauch ist, soll die CPU dauerhaft mit PRTG überwacht werden. Aber dennoch ist für den Dauerbetrieb eine Überwachung gewünscht.

Temperatur ermitteln

Natürlich ist SNMP das erste mittel der Wahl, zumal viele Dienste hierüber ihre Daten bereit stellen. Das ist auch bei BSD der Fall. Eine SNMP-Abfrage per SNMPWalk liefert sogar die ObjectID.

1.3.6.1.2.1.25.3.2.1.3.69 = "amdtemp0: AMD CPU On-Die Thermal Sensors" [ASN_OCTET_STR]

Aber leider ist das Ergebnis "leer". Irgendwo ist hier der Wurm drin, das die Daten nicht per SNMP abrufbar sind. Ich habe den Weg SNMP hier nicht weiter verfolgt.

Sie sind aber mit SYSCTL problemlos zuerhalten.

sysctl -a | grep dev.amdtemp.0.core0.sensor0
dev.amdtemp.0.core0.sensor0: 56.5C

Wenn ich SYSCTL mit dem Parameter "-n" aufrufe, kann ich mir das nachfolgende GREP auch noch sparen und bekomme einfach nur den Wert.

sysctl -n dev.amdtemp.0.core0.sensor0
56.3C

Allerdings ist hier die Einheit "Grad Celsius" noch angehängt.

Ausgabe für PRTG vorbereiten

Ehe darauf aber nun ein PRTG-Sensor werden kann, muss der Wert noch um das "C" erleichtert werden und ein Statuscode und eine Bemerkung addiert werden. Damit wird es dann ganz schnell zu einem Shell-Script.

#!/bin/sh

echo 0:`sysctl -n dev.amdtemp.0.core0.sensor0 |tr -d C `:Grad

Bei der Konfiguration als "Float" muss das Trennzeichen der Einer zu den Zehntel ein "Punkt" statt eines Komma sein. IT-Technisch ist der englische/amerikanische Sprachraum maßgeblich. Ich habe mich hier auf die erste CPU beschränkt

Einbinden in PRTG

Die SSH-Unterstützung von PRTG ist sehr pfiffig gelöst. Natürlich müssen Sie entsprechende Anmeldedaten hinterlegen, um auf das Zielsystem zugreifen zu können aber dann holt sich der Installationsassistent alleine alle Skripte, die auf dem Zielsystem vorliegen. Diese müssen Sie daher vorher schon auf dem Zielsystem an /var/prtg/scripts ablegen und "Executable" setzen. Dann können Sie in PRTG einfach das Skript auswählen und ggfls. noch ein paar Parameter einstellen.

Suchen Sie sich dazu einfach in PRTG das Device, welches Sie überwachen wollen. Ehe Sie aber einen SSH-Sensor addieren können, müssen Sie auf dem Device oder auf einem darüber liegenden Knoten die SSH-Zugangsdaten hinterlegen. Ansonsten sind die SSH-Sensoren "grau".

Dann können Sie auf dem Device einen SSH-Sensor anlegen. Es ist dabei nicht relevant, dass die Probe den eigentlichen SSH Aufruf ausführt. Die Definition erfolgt am Device:

In meinem Fall ist es einfach ein SSH Script, welches aber in PRTG als "sehr hoher Ressourcenbedarf" klassifiziert ist. Sofort nach der Auswahl versucht der PRTG-Assistent sich per SSH mit der Gegenstelle zu verbinden und das Verzeichnis "/var/prtg/scripts" nach Skripten zu durchsuchen. Wenn das nicht möglich ist, bekommen Sie schon hier folgende Fehlermeldung:

Die Verzeichnisstruktur können Sie am besten über SSH anlegen. PUTTY ist ein gutes auch auf Windows verfügbares Werkzeug, mit dem Sie auch gleich den SSH-Zugang testen. Sie kommen hier dann auf eine Shell, um die Verzeichnisse anzulegen und die Datei zu erstellen. Meine Schritte waren dabei

Befehl

Bedeutung

Putty.exe starten und verbinden

Putty starten und mit dem System auf Port 22 mit den gewünschten Anmeldedaten verbinden.

Sollte da schon nicht gehen, sind Firewalls zu prüfen und vielleicht ist der SSHD auf dem Zielsystem gar nicht aktiv.

mkdir /var/prtg
mkdir /var/prtg/scripts

Verzeichnisse anlegen. Das Basisverzeichnis "/var" gibt es in der Regel schon. Das Verzeichnis "/var/prtg" mit dem Unterverzeichnis "Scripts" aber nicht.

vi /var/prtg/scripts/cputemp
i
#!/bin/sh

echo 0:`sysctl -n dev.amdtemp.0.core0.sensor0 |tr -d C `:Grad
<esc>:wq

Mit den Befehlen starte ich den UNIX-Editor VI
mit dem "i" wechsele ich vom Command-Mode in den "Einfüge"-Mode.
und dann gebe ich den Code ein

Mit der "ESC-Taste" kommt man zurück zum Command-Mode. Das ist aber nicht sichtbar. Daher einfach dann ein ":wq" eingeben für Datei schreiben und beenden.

chmod 755 /var/prtg/scripts/cputemp

Nun muss das Skript noch ausführbar" gesetzt werden. 755 erlaubt mir als Besitzer die Ausführung und der Gruppe und der Welt nur Lesen und schreiben. Ich gehe davon aus, dass der Account zum Erstellen des Skripts auch in PRTG genutzt wird.

./cputemp

Ich rufe das Skript einfach mal so auf um zu sehen, dass es funktioniert. Nichts anderes macht PRTG später auch.

Wenn die Verbindung zum SSH-Server dann doch funktioniert und dass Skript schon im richtigen Verzeichnis liegt, dann können Sie dieses im Sensor einfach in PRTG auswählen.

Denken Sie daran den "Value Type" auf Float umzustellen, da die Temperatur vom Sensor mit zehntel Grad gemeldet wird.

Wer natürlich mehr Daten zurückgeben will, kann das über SSH Advanced Sensor mache, der dann eine XML-Struktur akzeptiert.

Mittlerweile wurde die Erfassung der CPU-Temperator von SSH auf HTTP-Push umgestellt. Siehe auch HTTPPush-Sensoren. Damit erspare ich mit den SSH Aufruf, der jedes mal ca. 500ms dauert. Das Skript wird nun durch einen CRON-Job gestartet und meldet aktiv an PRGT.

SSH für mehr ?

Die Umsetzung per SSH ist für PRTG weniger aufwändig als lokale Skripte, da das Zielsystem den Befehl ausführt. Es könnte in einigen Umgebungen sogar sicherer sein, da SSH gut bekannt und per Kennwort aber auch Zertifikaten zu sichern ist, während die Abfrage aus der Ferne je nach Produkt weitere Schnittstelle zumindest zur PRTG-Probe geöffnet werden müssen. Dennoch warnt PRTG vor zu vielen SSH-Sensoren.

This sensor type can have a high impact on the performance of your monitoring system. Please use it with care! We recommend that you use not more than 50 sensors of this sensor type on each probe.
Quelle: https://www.paessler.com/manuals/prtg/ssh_script_sensor

Die Windows Administratoren kennen da eher WinRM und Remote PowerShell oder Remote-CMD, um eine Dos-Box "remote" zu nutzen. Sie können aber natürlich auch auf einem Windows Server einen SSH-Service installieren. Allerdings sehe ich da keinen großen Vorteil und eher eine Einschränkung. Dann würde ich eher einen PRTG:HTTPPush-Sensoren entwickeln, der auf dem Windows Server per Taskplaner gestartet wird und die Ergebnisse an PRTG meldet. Für UNIX-Systeme kann der SSH-Sensor aber sehr nützlich sein. Wobei auch hier eine Umsetzung als HTTP-Push-Sensor durchaus zu überlegen ist. Das könnte dann als Skript wie folgt aussehen:

Beachten Sie, dass ein "?" ein Platzhalter ist und ein & als Verkettung von Befehlen gilt. Sie müssen diese Zeichen in der URL entsprechend ein "\" voranstellen. Der unter Windows liebgewonnene Backslash "\" muss aber zu einem "/" werden.

#!/bin/sh
 
wert=$(sysctl -n dev.amdtemp.0.core0.sensor0``| tr -d C)
.\curl http://prtg.example.com:5050/temp-pfsense\?value=$wert\&text=OK

Für ihre Umgebung muss natürlich sowohl der Server Hostname und Port (prtg.examplecom:500) als auch das Token (12345678) durch die eigenen Werte ersetzt werden. Dann können Sie das Skript per CRON-Job einfach regelmäßig starten lassen.

Denn besser das eine Monitoring-System "erreichbar" halten als viele UNIX-Systeme per SSH auf Port 22 ansprechbar zu machen.

Weitere Links