Ein machtvolles Feature ist eval. Mit dieser Kommandodatei-Option kann man beliebige Perl-Ausdruecke bewerten und die Resultate fuer spaetere Checks benutzen oder in der Schlussbewertung der Stati verwenden.

Es gibt zwei Versionen von eval:

• eval - stille Evaluierung
• eeval - echo eval - zeigt die Ausgabe des Ausdrucks im Extended Plugin Output

eval [ TAG ] = <Ausdruck>

eeval [ TAG ] = <Ausdruck>

Fortsetzungszeilen werden unterstuetzt mit einem abschliessenden '\' am Ende der Zeile, (vgl. das Beispiel hier). Damit koennen auch menschliche Wesen Kommandodateien lesen und verstehen

Die Kommandodatei bestimmt dynamisch, welches das Default Interface ist (also das Interface, auf dem die Default Route liegt). Dann werden die einzelnen Einstellungen fuer dieses Interface ermittelt. In der abschliessenden Bewertung wird eine Warnung ausgegeben, wenn die Interface-Geschwindigkeit nicht mindestens 100 MBit oder die Duplex-Einstellung nicht 'full' ist.
Zusaetzliches Feature: alle Netzwerk-Parameter, der Interface-Name und die Einstellungen werden im Extended Plugin Output angezeigt.

# determine def_gw interface from /proc/net/route
command [ def_gw  ] = awk '$2 == "00000000" {print $1}' /proc/net/route

# get ethtool output and store it in temporary file
command [ ethtool ] = sudo /usr/sbin/ethtool $def_gw$ > /tmp/if_$def_gw$.txt \
                      && echo OK

# get interface settings using ethtool
command [ link    ] = awk '/Link detected:/    {print $3}' /tmp/if_$def_gw$.txt 
command [ speed   ] = awk '/Speed:/            {print $2}' /tmp/if_$def_gw$.txt 
command [ duplex  ] = awk '/Duplex:/           {print $2}' /tmp/if_$def_gw$.txt 
command [ autoneg ] = awk '/Auto-negotiation:/ {print $2}' /tmp/if_$def_gw$.txt 

# evaluate results
state   [ UNKNOWN ] =  "$def_gw$"  eq "" || ethtool != OK
state   [ WARNING ] = ("$speed$"   && "$speed$"  !~ /100/) || \
                      ("$duplex$"  && "$duplex$" !~ /FULL/i)
state   [ CRITICAL] =  "$link"     && "$link"    eq "no"

SUNs Hardware-Check-Program prtdiag haengt stark von der jeweils verwendeten Hardware ab. Das macht es schwierig, alle verschiedenen HW-Versionen in einem einzigen Check abzufragen.
Die check_multi-Status-Bewertung bietet einen eleganten Weg, dieses Problem zu loesen.

Netter Seiteneffekt: die Ausgabe von prtdiag ist im Extended Plugin Output verfuegbar.

# prtdiag.cmd
# Teste prtdiag Ausgabe auf Fehlermeldungen
eval [ hw_platform ] = `uname -i`
eeval [ prtdiag ] = `/usr/platform/$hw_platform$/sbin/prtdiag`
state [ CRITICAL ] = '$prtdiag$' =~/detected failure|fault: .* detected|Failed Field Replaceable Units|Detected System Faults|ERROR|FAILED|faulty|failed/

(Dank an Gerhard Lausser fuer dieses Beispiel!)

Fuer die Replikation von SAN Daten in metropolitan clusters bietet HP eine Daemon-Loesung. Das Problem beim Monitoring dieser Daemons besteht darin, dass sie mit unterschiedlichen Namen daherkommen. Es haengt also jeweils von der lokalen Installation ab, welche Daemons ueberwacht werden muessen.
Netterweise koennen die Namen der horcmd-Daemons aber aus den Namen der Konfigurations-Dateien abgeleitet werden, die unter /etc liegen:

$ ls /etc/hor*
/etc/horcm.conf   /etc/horcm0.conf  /etc/horcm1.conf

Aufgrund der u.g. zwei Konfigurationsdateien sollten zwei Daemons laufen:

$ ps -ef|grep horcmd
    root 401440      1   0   Jan 08      -  0:12 horcmd_01 
    root 467158      1   0   Jan 08      -  0:20 horcmd_00

Bestimmung der Prozess-Namen fuer die check_multi-Konfiguration:

$ /usr/bin/ps -eo 'stat uid pid ppid vsz pcpu comm args'|grep horcmd
A      0 401440      1   800   0.0 horcmgr  horcmd_01 
A      0 467158      1   804   0.0 horcmgr  horcmd_00

Das Programm selber heisst also horcmgr, und Parameter ist der Name des einzelnen Daemon.

Die Parent-Konfiguration verfolgt zwei Ziele:

1. Generierung der Child-Konfiguration in /tmp/horcmd_child.cmd
2. Aufruf-Anweisung fuer den Child-Check

eval [ find_horcmd ] =                         \
open HORCMD, ">/tmp/horcmd_child.cmd";               \
foreach (glob "/etc/horcm*.conf") {                  \
  /horcm(\d+)\.conf/ &&                              \
  printf HORCMD "command [ horcmd%02d ] = check_procs -C horcmgr -a horcmd_%02d\n", $1, $1; \
}                                                    \ 
close HORCMD; 
command [ horcmd ] = check_multi -f /tmp/horcmd_child.cmd

Die Child-Konfiguration, wie sie dynamisch vom Parent generiert wurde:

$ cat /tmp/horcmd_child.cmd
command [ horcmd00 ] = check_procs -C horcmgr -a horcmd_00
command [ horcmd01 ] = check_procs -C horcmgr -a horcmd_01

Die Ausgabe des Plugins auf der Kommandozeile:

$ check_multi -f horcm_top.cmd
OK - 2 plugins checked, 2 ok
[ 1] find_horcmd 1
[ 2] horcmd OK - 2 plugins checked, 2 ok
[ 1] horcmd00 PROCS OK: 1 process with command name 'horcmgr', args 'horcmd_00'
[ 2] horcmd01 PROCS OK: 1 process with command name 'horcmgr', args 'horcmd_01'
|check_multi::check_multi::plugins=2 time=0.23 horcmd::check_multi::plugins=2 time=0.11