ich habe auf meinem Router (ipfire) einige Checks mittels NRPE zur Prüfung. Jetzt wollte ich einen Speedtest meiner Internetleitung implementieren und stehe vor einem Problem an dem ich nicht weiterkomme.
Führe ich das Skript auf dem Router direkt aus erhalte ich nach ca. 30sec eine Ausgabe.
[root@router ~]# /usr/lib/nagios/plugins/check_speedtest.sh
P WAN ping=34.835;100;500|upload=7.49;3:999;2:999|download=59.30;25:999;10:999 WAN ping/upload/download: 34.835/7.49/59.30
#!/bin/bash
#
# Track WAN connections in Check_MK
#
# (c) 2016 Stefan Heitmüller
# stefan.heitmueller@gmx.com
# This is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation in version 2. This file is distributed
# in the hope that it will be useful, but WITHOUT ANY WARRANTY; with-
# out even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE. See the GNU General Public License for more de-
# ails. You should have received a copy of the GNU General Public
# License along with GNU Make; see the file COPYING. If not, write
# to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
# Boston, MA 02110-1301 USA.
# Requirements:
# - https://github.com/sivel/speedtest-cli inside $PATH
# - bc (to calculate MB/s)
#
# Installation:
# Put script inside Check_MK local plugins directory and make it executable.
# Best practice is to use the "Cached local checks" function: https://mathias-kettner.de/checkmk_localchecks.html#Cached%20local%20checks%20(new%20in%20%3Cb%20class=new%3E1.2.3i1%3C/b%3E%20in%20the%20Linux%20agent)
# e.g. inside /usr/lib/check_mk_agent/local/1800/
# Warning/Critical Ranges:
PING_WARN=100 # if more than, in ms
PING_CRIT=500 # if more than, in ms
DOWNLOAD_WARN=25 # if less than, in MB/s
DOWNLOAD_CRIT=10 # if less than, in MB/s
UPLOAD_WARN=3 # if less than, in MB/s
UPLOAD_CRIT=2 # if less than, in MB/s
# Check Output:
# P WAN-PING ping=29.163;100;500 Ping time 29.163ms
# P WAN-UPLOAD upload=7.79;4:999;2:999 Upload speed 7.79Mb/s
# P WAN-DOWNLOAD download=34.73;25:999;10:999 Download speed 34.73Mb/s
if type speedtest-cli > /dev/null 2>&1 ; then
LOGFILE="$(mktemp "/tmp/speedtest.XXXXXXXX")"
speedtest-cli --csv > "$LOGFILE"
CSV=$(cat "$LOGFILE")
rm -f "$LOGFILE"
IFS=, VALUES=($CSV)
PING=${VALUES[5]}
DOWNLOAD=$( bc -l <<< 'scale=2; '${VALUES[6]}'/1024/1024' )
UPLOAD=$( bc -l <<< 'scale=2; '${VALUES[7]}'/1024/1024' )
# Uncomment these 3 lines to get single services (unique perfdata per service), !COMMENT! the single service below
#echo "P WAN-PING ping=${PING};${PING_WARN};${PING_CRIT} Ping time ${PING}ms"
#echo "P WAN-UPLOAD upload=${UPLOAD};${UPLOAD_WARN}:999;${UPLOAD_CRIT}:999 Upload speed ${UPLOAD}Mb/s"
#echo "P WAN-DOWNLOAD download=${DOWNLOAD};${DOWNLOAD_WARN}:999;${DOWNLOAD_CRIT}:999 Download speed ${DOWNLOAD}Mb/s"
# One service including all perfdata
echo "P WAN ping=${PING};${PING_WARN};${PING_CRIT}|upload=${UPLOAD};${UPLOAD_WARN}:999;${UPLOAD_CRIT}:999|download=${DOWNLOAD};${DOWNLOAD_WARN}:999;${DOWNLOAD_CRIT}:999 WAN ping/upload/download: ${PING}/${UPLOAD}/${DOWNLOAD}"
fi
ich kann auf meinem Router nur Pakete aus deren Repo installieren und das sind nrpe und die nagios-plugins. Der chek_mk Agent ist komplett rausgeflogen und somit bin ich auf nrpe umgestiegen. Falls ich das mit dem MRPE falsch verstehe und es doch ohne Agent auf dem Zielclient (Host - router) funktioniert dann teile mir das bitte mit. Danke.
Der Check_MK Agent ist nur ein Bash-Script und bedarf somit keinerlei “Installation” im klassischen Sinne. Wenn du eine Datei namens /etc/mrpe.cfg mit dem richtigen Inhalt (siehe Link oben) anlegst, dann wird das Skript(der Agent) den Inhalt auslesen und die Nagios-Checks (in deinem Fall den Speedtest) ausführen, die Ausgabe wird daraufhin um eine Sektion <<<mrpe>>> ergänzt und über den Discovery Mechanismus auf dem Server erkannt.
Das Checkscript ist weder ein klassisches Nagios Plugin noch ein CheckMK Plugin.
Dies ist ein CheckMK Local Check und kann damit auch nur richtig ausgewertet werden wenn er vom CheckMK Agent selbst ausgeführt wird.
Du kannst auf der ipfire jedes beliebige Shell Script ausführen und der Agent ist ja nix anderes.
Wie in dem anderen Thread schon geschrieben bitte die Anleitung für die Abfrage per SSH anschauen.
ich kann es leider nicht nachvollziehen das das von mir benannte Plugin sowie folgendes Plugin nicht funktionieren sollte.
https://github.com/jonwitts/nagios-speedtest/
./check_speedtest-cli.sh -w 10 -c 7 $ -W 15 -C 10 -l e -s 30907 -V
OK - Ping = 40.331 ms Download = 180.39 Mbit/s Upload = 8.73 Mbit/s
Leider habe ich die Alternative zum check_mk Agent noch nicht so ganz verstanden. Ich kann auf dem Router nicht einfach den Agent installieren da dieser aus dem Repo der Distro entfernt wurde. Ich kann zwar Skripte anlegen und Ordner aber ob diese dann nach einen Coreupdate noch da sind, weiß ich nicht. Wenn Du mir vielleicht eine ausführliche Anleitung zur Alternative geben könntest wäre ich sehr dankbar.
Das ist aber ein anderes Script wie oben im ersten Post
Erster Post war ein Check_MK Local Check, jetzt das Script sieht mehr nach einem klassischen Nagios Check aus.
Dieses Script welches du hier ausführst stammt doch auch aus keinem Repo und ist nur auf die ipfire kopiert. Genau so kannst auch den Check_MK Agent benutzen, der ist “nur” ein Shellscript.
In der hier beschriebenen Weise kann jedes beliebige Shellscript/Programm auf einem Host als Check_MK Agent benutzt werden.
Dieser Weg ist genau der Weg den du benutzen solltest.
Also hier jetzt auch nochmal mein letzter Tipp, andreas hat aber eigentlich schon alles Relevante verlinkt
ssh schlüsselpärchen auswürfeln als omd benutzer auf deiner site
per ssh-copy-id auf deine ipfire box
passwortlosen zugang testen und auf die ipfire box ssh’en
per wget den linux agent von deiner site auf die ipfire box laden oder per scp/sftp von deiner site auf die box kopieren und ausführbar machen
auf der ipfire box in der datei ~/.ssh/authorized key folgendes vor den key packen: command=/path/to/cmk_agent
zurück auf der site den aufruf testen, es sollte direkt der output vom agent kommen
regel anlegen unter Datasource Programs -> Individual program call instead of agent access die den ssh client mit deinem neu ausgewürfelten key als identity nimmt und als host $HOSTNAME$
Hallo Simon,
ich komme beim SSH nicht weiter. Innerhalb von ipfire gibt es unter “/etc/ssh” schon SSH Schlüssel die auch auf der Webseite angezeigt werden.
Ich habe aber trotzdem mich an die Anleitung gehalten und auf dem check_mk Server ein neues Schlüsselpaar generiert und dies auf den ipfire übertragen.
Wenn ich nun das root Kennwort eingebe funktioniert es aber das ist ja nicht der Sinn der Sache.
Habe ich etwas übersehen?
Kann ich die SSH-Keys vom ipfire nehmen und wenn ja welchen?
Ist der angepasste SSH Port 222 (statt 22) später ein Problem beim Check_mk?
Ist der Command Pfad command="/etc/check_mk" richtig bzw. passend/günstig?
Mit welchem User soll letztendlich die SSH Verbindung aufgebaut werden? Ich kann nur einen Benutzer dort anlegen.
Vielen Dank für die Mühe/Unterstützung
MfG Paul
Ps.: Vom check_mk Server habe ich die folgende Datei “/opt/omd/versions/1.5.0p24.cre/share/check_mk/agents/check_mk_agent.linux” nach “etc/check_mk” auf dem ipfire kopiert.
Hi Pablo,
du hast das Skript wirklich hier hingelegt? Ein besserer Ort wäre /usr/local/bin/check_mk_agent oder eben /usr/bin/check_mk_agent. In etc kommen eigentlich nur Konfigurationsdateien hin.
Diese Fehlermeldung deutet auf ein Problem mit dem öffentlichen Schlüssel hin. Möglicherweise muss er im RFC4716er Format vorliegen. Das Thema hatte ich zb. auch schon bei der Hetzner StorageBox. Den Befehl zum Umwandeln weiß ich gerade nicht auswendig, aber sollte sich über Tante Google leicht finden lassen.
PS: Das mit dem command= kannst du auch erstmal weglassen bis dein passwortloses Springen einwandfrei klappt. Das ist die Grundvoraussetzung für das regelmäßige Abfragen des Agenten.
Das ist was anderes - nämlich sind das die Host-Keys, mit denen sich die ipfire als ssh-Server dem anfragenden ssh-Client gegenüber identifiziert, damit der Client sicher sein kann, mit dem richtigen Server zu sprechen (und nicht mit einem man-in-the-middle).
Die müssen also bleiben, haben aber nichts damit zu tun, ob der Server die Verbindungsanfrage des Clients ankzeptiert.
der SSH-Zugriff klappt soweit ohne Abfrage vom Kennwort.
Muss ich auf Grund der angegebenen Pfade noch was machen, da diese ja nicht existent sind bei mir?
Mein Skript ist nun hier: /usr/local/bin/check_mk_agent
Ich bin nun hier in diesem Bereich “Edit rule: Individual program call instead of agent access” aber meine Versuche eine Regel zu bauen scheinen keine Auswirkungen zu haben.
Wie müsste ich da die Eintragungen vornehmen, gerade auch weil ich über den Port 222 SSH aufrufe und den Client über die IP-Adresse ansprechen muss und nicht den Namen.
Entschuldigt meine Anfängerfragen und ich dokumentiere mir dies aber auch, damit das beim nächsten Client ohne Rückfragen klappt
Sieht doch gut aus
In der Regel dann jetzt: ssh -i pfad/zu/deinem/private.key -l root -p222 <IP>
oder ssh -i pfad/zu/deinem/private.key -l root -p222 $HOSTNAME$ sollte auch gehen. Und dann halt in den conditions auf deine ipfire box beschränken oder eben auch nicht falls du mehrere hast.
Als Ergänzung zu @simon-mueller
Falls dein SSH Keypair nicht mit sonderbarem Namen erzeugt wurde auf dem Monitoring Host so brauchst du im ssh Aufruf auch keinen Key angeben.
SSH guckt einfach was da ist und probiert
entschuldige die verspätete Rückmeldung. Ich mache noch irgendein Fehler denn auch wenn die SSH Abfrage per ssh klappt so wird aber kein Check angelegt.
Der Host selbst muss auch auf Agent als Abfrage stehen.
Da bei deinem System kein “Check_MK” Service existiert steht der Host auf “No Agent” und “No SNMP”.
Heute wollte ich die Einstellungen auf meinen richtigen (Hardware) Router übertragen (vorher war es nur eine Test VM). Es kommt zum Host der Check “Check_MK Discovery” dazu und ist Rot mit dem Staus detail.
CRIT - no unmonitored services found, no vanished services found, [agent] Agent exited with code 255: Pseudo-terminal will not be allocated because stdin is not a terminal.
Ich habe auf dem Check_MK Server auch keine Probleme per SSH mich auf den Router zu verbinden und diesen auch als bekannten SSH Host hinzugefügt.
