Es heißt ja immer mit Icinga ließe sich alles überwachen. Prinzipiell ist das auch richtig, aber manchmal gibt es einfach noch nicht das passende Plug-In. Da es aber schon Tausende Plug-Ins auf exchange.icinga.org gibt, kann es ja nicht so schwer sein ein eigenes Plug-In zu schreiben.

Was macht das Stück Code zum Plug-In?

Kürzeste Antwort: Der Exit Code. Jedes Nagios/Icinga/Shinken/Naemon Plug-In hat 4 Exit Codes. Diese Rückgabewerte lassen sich mit “echo $?”, nach dem Ausführen, überprüfen. Sie haben folgende Bedeutung: 0=OK, 1=Warning, 2=Critical, 3=Unknown

schulung_icinga2Was gibt es noch zu beachten?

Plug-Ins können in jeder auf dem jeweiligen System zur Verfügung stehenden Sprache geschrieben werden. Für einfache Fälle und schnelle Hilfe bietet sich Shell-Skripte an. Schöner sind oft aber perl oder python.
Ich möchte heute einmal ein schönes Shell Plugin schreiben. Um das umzusetzen lohnt sich als erstes ein Blick in die Monitoring Plugins Development Guidelines. Dort kann man unter anderem folgende Voraussetzungen für ein Plugin nachlesen.

Params

  • Es muss bei -h oder –help eine Hilfe bereitstellen
  • Es muss bei -v oder –verbose mehr Output liefern
  • Schwellwerte können als range definiert werden.
    “-c 5:  ” bedeutet z.B. alles kritisch, was unter 5 ist. Praktischerweise übernimmt die Interpretation der Ranges eine Funktion aus der utils.sh. Sie ist Bestandteil des Monitoring Plug-In Pakets

Perfdata

Plugins können Performancedaten ausgeben. Mit Hilfe dessen ist es tools wie pnp4nagios, ingraph oder graphite möglich Kurven über die ermittelten Werte zu zeichnen. Performancedaten müssen in folgendem Format vorliegen:
| ‘label’=value[UOM];[warn];[crit];[min];[max]
Also z.B. ‘Drive C’ = 15GB;5;3;0;20 bedeutet folgendes: Drive C hat noch 15GB frei. Bei 3 bzw. 5 GB wird’s kritisch bzw. gewarnt.
Obacht: Es gibt nur bestimmte Maßeinheiten, die hier nachgelesen werden können. Diese sind s(Sekunden), %(Prozent), B (Bytes, auch MB KB usw) und c (counter)

Los geht’s

Nicht lang schnacken sondern losgelegt. Wir schreiben ein Plugin, dass die Files in /tmp zählt. Auf die gleiche Weise lassen sich auch alle anderen Plugins schreiben die auf zählbaren Werten basieren. Zunächst müssen wir das Plugin initialisieren und utils.sh einbinden (soll im gleichen Verzeichnis wie das plugin liegen).

#!/bin/bash
VERSION=1.0
VERBOSE=0
PROGNAME=`/usr/bin/basename $0`
PROGPATH=`echo $0 | /bin/sed -e 's,[\\/][^\\/][^\\/]*$,,'`
. $PROGPATH/utils.sh

Dann brauchen wir eine Funktion, die Hilfe und Version ausgibt.

function printHelp() {
echo
echo "Usage: $PROGNAME [-v] [-V] [-h] [-L]"
echo
echo " -v verbose output"
echo " -V Version"
echo " -h this help"
echo " -L License"
echo " -w warning"
echo " -c critical"
echo
echo " This plugin checks the number of files in /tmp"
echo
}
function printVersion() {
    echo
    echo "$PROGNAME Version $VERSION"
    echo
}

Des weiteren möchten wir gerne Parameter einlesen. $STATE_UNKNOWN kommt übrigens auch aus utils.sh

function checkOptions() {
    while getopts "hvVc:w:" OPTIONS $@; do
            case $OPTIONS in
                c) CRITICAL=$OPTARG
                   ;;
                w) WARNING=$OPTARG
                   ;;
                h) printHelp
                   exit $STATE_UNKNOWN
                   ;;
                v) VERBOSE=1
                   ;;
                V) printVersion
                   exit $STATE_UNKNOWN
                   ;;
                ?) printHelp
                   exit $STATE_UNKNOWN
                   ;;
            esac
    done
}
checkOptions $@

Jetzt werden die Dateien in /tmp gezählt und mit den Schwellwerten verglichen.

FILECOUNT=`ls /tmp|wc -l`
if check_range $FILECOUNT $CRITICAL; then echo -n "CRITICAL - "; exitCode=2
else
  if check_range $FILECOUNT $WARNING; then
    echo -n "WARNING - "
    exitCode=1
  else
    echo -n "OK"
    exitCode=0
  fi
fi

Am Ende noch ein wenig Text und die Performancedaten, sowie der Exitcode und schon läuft die Sache.

echo -n "/tmp has $FILECOUNT files "
echo "| tmp_files=${FILECOUNT}c;$WARNING;$CRITICAL;0;$FILECOUNT"
exit $exitCode
Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.