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.

  1. ssh konfigurieren
    Dazu müssen folgende Einträge in /etc/ssh/ssh_config rein.

    1
    2
    3
    
    Host *
        ControlPath ~/.ssh/sock/%r@%h:%p
        ControlMaster auto

    Danach das Verzeichnis für den Nagios User anlegen

    mkdir ~nagios/.ssh/sock
  2. 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'
  3. 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:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    
    #!/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]

  4. reload nagios
    Fertig …
    • Falls sich das Vorgehen bewährt will ich vielleicht nach Rücksprache mit Ton Voon einen entsprechenden Patch für check_by_ssh liefern. Vielleicht aber schreibe ich erst mal einen Wrapper dafür.

      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.

      VN:F [1.9.22_1171]
      Rating: 0.0/10 (0 votes cast)
      VN:F [1.9.22_1171]
      Rating: 0 (from 0 votes)

8 Antworten auf „check_by_ssh booster“

  1. 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…

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. 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 😉

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. 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

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. 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.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  5. 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

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  6. Hat eigentlich schon jemand einen Graphen, wie sich das bzgl. der Load auswirkt?

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  7. 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.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.