Kommandos

Das check_multi Plugin wird konfiguriert durch eine einfache an NRPE angelehnte ASCII-Datei.

Format

<Schluesselwort> [ <Bezeichner> ] = <content>

Elemente

• Moegliche Schluesselworte:
  1. command
  2. state
  3. eval
  4. eeval
  5. statusdat
• '#' leitet eine Kommentarzeile ein. Achtung: '#' duerfen nur am Zeilenanfang stehen, auch nicht in Fortzetzungszeilen!
• Leerzeilen sind erlaubt.
• Blanks, Tabs etc. zwischen den Elementen sorgen fuer bessere Lesbarkeit.

Mit dem attribute-Kommando koennen globale Variable sowie spezifische Child-Check-Einstellungen gesetzt werden.

Format

attribute [ <Globale Variable> ] = <Wert der globalen Variablen>

attribute [ <Tag>::<Variable> ] = <Child Check-Wert>

Elemente

• Tag: <tag> ist der Name eines Child-Checks, siehe auch command or eval.
• Global Variable: Jede -s-Variable, die per '-s <Variable>=<Wert>' gesetzt wird, vergleiche auch 'check_multi -hhh'
• Child-Check / Tag Variable: Child-Check-Attribute, die per check_multi XML export angezeigt werden (-r 256).

Beispiele

• /tmp-Zugriffsrechte testen. /tmp sollte fuer everybody schreibbar sein, aber nur mit Sticky-Bit:

command   [ tmp_dir_permissions           ] = ls -ld /tmp
attribute [ tmp_dir_permissions::critical ] = "$tmp_dir_permissions$" !~ /^drwxrwxrwt/

• Die globale Variable extinfo_in_status setzen. Hier wird das Newline durch das HTML '<br />' ersetzt, um sowohl plugin_output als auch long_plugin_output in der Status-View anzuzeigen:

attribute [ extinfo_in_status ] = 1

Die Kommando-Definitionen erzeugen die Liste der Child-Plugin-Aufrufe, die von check_multi als Parent-Check ausgefuehrt werden sollen.

Format

command [ <Bezeichner> ] = <Plugin Kommandozeile>

Elemente

• Bezeichner: der <Bezeichner> ist frei waehlbar. Man kann sich diesen Ausdruck als eine Art Primaerschluessel zur Identifikation des Plugin-Aufrufes vorstellen. Speziell in grossen Installationen ist es wichtig, sich ueber eine Namenskonvention Gedanken zu machen. Erlaubte Zeichen: A–Za-z0–9_:
• Plugin Kommandozeile: Dies ist eine normale Plugin Kommandozeile mit allen Parametern.
  Das Directory oder der volle Path des Plugins muss hier nicht angegeben werden. Es gilt entweder der Default /usr/local/nagios/libexec oder ein Pfad kann spezifiziert werden durch die Option –libexec <pfad>, vgl. hier.
  
  Neu: der Standard-PATH wird fuer die Ausfuehrung von Programmen verwendet. Daher ist die Reihenfolge der Pfadermittlung wie folgt:
  1. libexec-Directory (Voreinstellung oder ueber die –libexec-Option angegeben)
  2. PATH des Nagios-Users
  3. absolute Pfadangaben sind natuerlich auch moeglich

• Nagios-Makros sind erlaubt. So kann z.B. $HOSTNAME$ den aktuellen Namen des Servers beinhalten. Damit koennen sehr flexible Konfigurationsdateien geschrieben werden.
• Uebrigens: die Liste der Eintraege wird in der Reihenfolge der Konfigurationsdatei ausgefuehrt.
• PNP: Wenn ein bestimmtes Plugin fuer Performance-Daten angegeben werden soll, bitte das abgewandelte Label-Format command [ tag::plugin ] verwenden.

Eval ist ein maechtiges Mittel, um Informationen aus allen moeglichen Quellen zu sammeln und flexible Plugin-Konfigurationen zu erstellen.

• eval wertet den angegebenen Ausdruck aus und speichert das Resultat in $<tag>$. Es gibt keine Ausgabe.
• eeval (sprich: e(cho)eval) tut das Gleiche wie eval, diesmal aber mit einer Ausgabe.

Format

eval [ <tag> ] = <perl expression>

eeval [ <tag> ] = <perl expression>

Elemente

• tag: wie bei den commands ist <tag> ein frei waehlbarer Namen und dient quasi als Primaerschluessel fuer den Check.
• perl expression: dies kann ein beliebiger Perl-Ausdruck sein .

Return code
Ein eeval-Statement ist selber ein kleines Perl-Script, und der Return Code (RC) kann wie in anderen Scripten ueber die $?-Variable gesetzt werden.
Nichtsdestotrotz ist es ein wenig verwirrend, denn der RC muss zuerst gesetzt werden, und dann im letzten Statement wird der eigentliche Output des eval-Statements mit dem return-Befehl bestimmt.
Im folgenden Beispiel wird das vielleicht besser verstaendlich:[code perl]eeval [ RC_CRITICAL_output_xyz ] =

 # the RC has to be shifted to the high byte of $?     
 $? = $CRITICAL << 8;
 # the output itself is the return value (well, that's not quite intuitive ;))
 return "xyz";[/code]

Examples Beispiele fuer die Verwendung von eval gibt es hier.

Format

livestatus [ <tag> ] = <host>:<service>

livestatus [ <tag> ] = <host>

Elemente

• tag : wie in der command-Anweisung ist <tag> ein frei waehlbarer Ausdruck und dient als Primaerschluessel fuer den Check.
• host : Host, auf dem der Service laeuft.
• service: Service-Description des gewuenschten Service.

Anmerkung: Normalerweise wird der livestatus-Socket unter <nagiosdir>/var/live gesucht. Wenn Sie einen anderen Pfad benoetigen, koennen Sie das wie folgt angeben:

check_multi -s livestatus=</path/to/livestatus-socket>

Mehrere Hosts / Services
Sie koennen Wildcards und Regular Expressions (Perl) verwenden, wobei die Regular Expressions in '/' eingeschlossen werden. Beispiele:

livestatus [ web ] = srv*:/web/

livestatus [ web ] = srv*:http

Nehmen wir mal an, dass Sie drei Webserver namens h1, h2 und h3 haben und auf jedem ein Service httpd laeuft.
check_multi expandiert nun den Child-Check web zuerst zu drei Webservices wie folgt:

livestatus [ web_h1_httpd ] = h1:httpd
livestatus [ web_h2_httpd ] = h2:httpd
livestatus [ web_h3_httpd ] = h3:httpd

Die neuen Tags werden dabei wie folgt gebildet:<TAG>_<host>_<service>
Diese livestatus-Services werden dann zur Laufzeit durch die Ergebnisse der 'normalen' Services ersetzt.

Auch Services koennen mit Wildcards sowie mit Regular Expressions gebildet werden.

Preisfrage zum Schluss: was wird wohl passieren, wenn Sie das folgende Statement angeben?

livestatus [ all ] = *:*

Richtig: alle Services aus ihrer Installation werden in einem check_multi-Call vereint…
Dies wird wahrscheinlich Ihre Nagios Puffer-Groessen sprengen und es ist auch nicht wirklich sinnvoll . Aber es zeigt, wie die Expandierung wirken kann.

Zuerst einmal: fuer die normale Funktion von check_multi ist das Status-Definitions-Feature nicht noetig, weil dort die Standard-Bewertung greift . Die Status-Definition legt fest, wie die Ergebnisse der Child-Plugins bewertet werden. In der eingebauten Standard-Bewertung wird geprueft, ob Stati ungleich OK vorliegen und dann gewinnt der mit der hoechsten Wertigkeit.
Die Bewertungsreihenfolge dabei ist zuerst OK, dann UNKNOWN, schliesslich WARNING und zuletzt CRITICAL.

Format

state [ <Status> ] = <Ausdruck>

Elemente

• Status: kann einer der Standard-Nagios-Stati OK, UNKNOWN, WARNING oder CRITICAL sein.
• Ausdruck: ein logischer Ausdruck im Perl-Stil bestimmt, ob der genannte Status wahr oder falsch wird.
  Beispiel: (disk_root == CRITICAL || disk_opt == CRITICAL).
• Perl Operatoren sind hier erlaubt. Weil die Vorrangregeln bei Perl manchmal etwas kompliziert sind, empfiehlt es sich, im Zweifelsfalle zu klammern. Dies kommt auch der besseren Lesbarkeit zugute .
• Check-Bezeichner werden durch ihre jeweiligen Return codes ersetzt, z.B. disk_root → 2 (CRITICAL).
• COUNT(<Status>) wird durch die Anzahl der Child-Returncodes fuer den jeweiligen Status ersetzt.
  Beispiel: COUNT(WARNING) → 2
• COUNT(ALL) wird ersetzt durch die Anzahl der Checks, z.B. fuer Regeln wie diese:
  state [ CRITICAL ] = COUNT(CRITICAL) == COUNT(ALL)
• Hinweis: alle Spezial-Ausdruecke (COUNT, OK, UNKNOWN, WARNING, CRITICAL) sind *nicht* case-sensitiv, man kann also ohne Problem folgendes formulieren: count(warning).

Beispiele

• Builtin Standard Stati (Hinweis: sie werden in dieser Reihenfolge bewertet:
  

  state [ OK       ] = 1
  state [ UNKNOWN  ] = COUNT(UNKNOWN)  > 0
  state [ WARNING  ] = COUNT(WARNING)  > 0
  state [ CRITICAL ] = COUNT(CRITICAL) > 0

• WARNING and UNKNOWN ignorieren und nur CRITICAL Stati zaehlen:
  

  state [ UNKNOWN  ] = (1==0)
  state [ WARNING  ] = (1==0)
  state [ CRITICAL ] = COUNT(CRITICAL) > 0

• Clustering: Es gilt nur dann CRITICAL, wenn mehr als ein CRITICAL Status auftritt, ansonsten WARNING:
  

  state [ WARNING  ] = COUNT(WARNING) > 0 || COUNT(CRITICAL) > 0
  state [ CRITICAL ] = COUNT(CRITICAL) > 1

Config-Datei ↔ Kommandozeile Alle Stati koennen auch auf der Kommandozeile angegeben werden mit den Optionen -o|-u|-w|-c <Ausdruck>. Die Reihenfolge in der Auswertung ist dabei

1. Eingebaute Regeln
2. Config-Datei
3. Kommandozeile

Format

statusdat [ <tag> ] = <host>:<service>

(und seit 2010/06/04)

statusdat [ <tag> ] = <host>

Elemente

• tag : wie in der command-Anweisung ist <tag> ein frei waehlbarer Ausdruck und dient als Primaerschluessel fuer den Check.
• host : Host, auf dem der Service laeuft.
• service: Service-Description des gewuenschten Service.

Anmerkung: Normalerweise wird die status.dat unter <nagiosdir>/var/status.dat gesucht. Wenn Sie einen anderen Pfad benoetigen, koennen Sie das wie folgt angeben:

check_multi -s status_dat=</path/to/status.dat>

Erweiterung seit 0.20: Sie koennen nun auch Wildcards verwenden, z.B.

statusdat [ web ] = srv*:http

Nehmen wir mal an, dass Sie drei Webserver namens h1, h2 und h3 haben und auf jedem ein Service httpd laeuft.
check_multi expandiert nun den Child-Check web zu drei Webservices wie folgt:

statusdat [ web_h1_httpd ] = h1:httpd
statusdat [ web_h2_httpd ] = h2:httpd
statusdat [ web_h3_httpd ] = h3:httpd

Die neuen Tags werden dabei wie folgt gebildet:<TAG>_<host>_<service>
Services koennen auch mit Wildcards gebildet werden.

Preisfrage zum Schluss: was wird wohl passieren, wenn Sie das folgende Statement angeben?

statusdat [ all ] = *:*

Richtig: alle Services in Ihrer status.dat werden in einem check_multi-Call vereint…
Dies wird wahrscheinlich Ihre Nagios Puffer-Groessen sprengen und es ist auch nicht wirklich sinnvoll . Aber es zeigt, wie die Expandierung wirken kann.