check_by_ssh booster

Nachdem ich mir das Connection Sharing von SSH von SSH notiert hatte habe ich mich gefragt, warum ich das nicht gleich für Nagios check_by_ssh Plugin benutze.

Also habe ich das heute morgen mal versucht. Das ganze ist noch nicht ausgereift und fast noch nicht getestet, sollte dennoch aber ein wenig was bringen. Was habe ich also getan bzw. was ist notwendig.

ssh konfigurieren
Dazu müssen folgende Einträge in /etc/ssh/ssh_config rein.
```
Host *
    ControlPath ~/.ssh/sock/%r@%h:%p
    ControlMaster auto
```
Danach das Verzeichnis für den Nagios User anlegen
```
mkdir ~nagios/.ssh/sock
```
check_by_ssh commands anpassen
Alle commands die check_by_ssh verwenden um folgendes ergänzen (Achtung Pfad anpassen).
```
 -o 'ControlPath=/home/nagios/.ssh/s ock/%r@%h:%p' -o'ControlMaster=auto' 
```

Persistente Connections starten
Nachdem Nagios immer nur kurz einen Check ausführt und anschließend wieder die Connection tötet muss natürlich daher unabhängig von Nagios eine entsprechende dauerhafte aufgebaut werden. Ich habe mir dazu erstmal das Skript gebastelt:

#!/bin/sh

# simple script to start ssh backgrounds control masters for every 
# host configured inside nagios config

SSH="/usr/bin/ssh"
SORT="/bin/sort"
UNIQ="/usr/bin/uniq"
AWK="/bin/awk"
GREP="/bin/grep"
OBJECTS_CACHE="/usr/local/nagios/var/objects.cache"

SKIPLIST="127.0.0.1\|10.10.10.10"

HOSTS=$($AWK '/address/ {print $2}' $OBJECTS_CACHE | $GREP -v $SKIPLIST | $SORT 
| $UNIQ)

for host in $HOSTS
do
  echo $host
  $SSH -q -O check $host 2>/dev/null || $SSH -MNf $host
done

exit 0

[note]Achtung: Das Skript muss logischerweise als Nagios User laufen.[/note]

reload nagios
Fertig …

Nachdem ich nicht wirklich viele Server per SSH teste würde mich die Erfahrung meiner Leser interessieren. Daher hier die Umfrage:
[poll id=“2″]

Falls es Freiwillige mit ein paar Host per check_by_ssh gibt würde ich mich über Erfahrungen, Kommentare, Auszüge von Nagiostats (vorher und danach),… freuen.

7 Gedanken zu „check_by_ssh booster“

Gerd Beitragsautor30. Dezember 2008

bei mir läuft es seit heute morgen entsprechend. Hier die Zahlen von nagiostats nach ca. 12h

vorher: Active Service Execution Time: 0.007 / 7.820 / 1.049 sec
nachher: Active Service Execution Time: 0.007 / 4.047 / 0.411 sec

Mal weiter beobachten…

Antworten ↓

Matthias Flacke 31. Dezember 2008

Ich hab die SSH-Tunnels mit 630 Hosts getestet – und gleich mal vorweg: die Performance pro check_by_ssh-Aufruf steigt um den Faktor 3 – 10.
Wo ich zuerst fuer 10 Aufrufe ‚check_by_ssh -H -C uptime‘ 30 Sekunden gebraucht habe, dauerts mit schon vorhandenem Tunnel nur noch 3 Sekunden. Das bei einer recht lahmen WAN-Kiste, im LAN und bei schnelleren Hosts ist die Ersparnis nicht ganz so hoch.

Ich habe aber auch ein paar Probleme festgestellt, die eine Implementierung in check_by_ssh beruecksichtigen sollte:

* Speziell wenn mehrere Aufrufe gleichzeitig ablaufen, kommt es oefter zu Fehlermeldungen a la

Remote command execution failed: ControlSocket /var/user/nagios/.ssh/sock/nagios@:22 already exists

* check_by_ssh muss sich auch um den Socket kuemmern: wenn die ssh stirbt, wird das Socket-File nicht aufgeraeumt und dann geht der naechste Tunnel schief.

Ansonsten ist der Speicherverbrauch der Tunnels recht moderat (~1.1 MB resident pro Tunnel bei meiner OpenSSH_4.3p2 / RHEL5).

@Gerd: wenn du einen Tester fuer die check_by_ssh-Patches brauchst, ich bin dabei 😉

Antworten ↓

Gerd Beitragsautor31. Dezember 2008

danke fürs Feedback.

Matthias Flacke :
* Speziell wenn mehrere Aufrufe gleichzeitig ablaufen, kommt es oefter zu Fehlermeldungen a la

Remote command execution failed: ControlSocket /var/user/nagios/.ssh/sock/nagios@:22 already exists

Strange, das sollte doch durch den „auto“ Mode unterstützt werden. Ich lese da mal nach. Bei mir klappen 30 ssh Checks an einen Host gleichzeitig ohne Probleme

Bei mir ist jetzt „nur“ insgesamt doppelt so schnell geblieben.

Guten Rutsch

Gerd

Antworten ↓

Sascha Klauder 12. Januar 2009

Ich habs jetzt seit einer Woche laufen, funktioniert prinzipiell sehr gut, danke! Bisher erst einen Fehlalarm wg. Plugin-Fehler (SSH-Verbindung war verstorben, aber der Control-Socket noch da).

Die ssh-Optionen aus Schritt 1 habe ich in ~nagios/.ssh/config gepackt, damit die System-Konfig sauber bleibt. Schritt 2 ist zumindest bei mir nicht nötig gewesen.

Da ich nicht auf allen Hosts im Nagios check_by_ssh-Checks fahre, nehme ich ausserdem die Adressen für das Skript nicht aus dem objects.cache-File, sondern aus ~nagios/.ssh/known_hosts.

Antworten ↓

Gerd Beitragsautor12. Januar 2009

Hi Sascha,

danke fürs Feedback. Beide Anmerkungen sind absolut berechtigt. Danke für den Tipp.

D.h. doch eigentlich wir müssten den Hostcheck nur noch um den Test für eine Stale Verbindung ergänzen oder einen eigenen Service dafür bauen: Wenn das Socket noch existiert aber kein entsprechender Prozess, dann muss der Tunnel neu gebaut werden. Oder übersehe ich da was?

Gruß Gerd

Antworten ↓

Gerd Beitragsautor12. Januar 2009

Hat eigentlich schon jemand einen Graphen, wie sich das bzgl. der Load auswirkt?

Antworten ↓

Sascha Klauder 12. Januar 2009

Gerd :
D.h. doch eigentlich wir müssten den Hostcheck nur noch um den Test für eine Stale Verbindung ergänzen oder einen eigenen Service dafür bauen: Wenn das Socket noch existiert aber kein entsprechender Prozess, dann muss der Tunnel neu gebaut werden. Oder übersehe ich da was?

Das wollte ich als nächstes schreiben 🙂 Ich hatte den Fall, dass die Verbindung weg, der Socket aber noch da war, wie gesagt erst einmal; keine Ahnung, was da passiert ist. Die Überwachung der bestehenden Verbindungen und Sockets wird sicherlich komplizierter als alles andere, wäre aber für den Dauereinsatz sicher unbedingt nötig — soll ja schonmal vorkommen, dass man was rebooten muss.

Antworten ↓

7 Gedanken zu „check_by_ssh booster“

Schreibe einen Kommentar Antworten abbrechen