===== Eval - Bewertung von Ausdruecken =====
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

=== Syntax ===
<code>eval [ TAG ] = <Ausdruck></code>
<code>eeval [ TAG ] = <Ausdruck></code>

Fortsetzungszeilen werden unterstuetzt mit einem abschliessenden '\' am Ende der Zeile, 
([[de:projects:check_multi:eval#beispiel_3san_data_replication_monitoring_horcm|vgl. das Beispiel hier]]). Damit koennen auch menschliche Wesen Kommandodateien lesen und verstehen :-D
\\ 
\\ 


===== Beispiel 1: Linux Netzwerk-Interface Einstellungen =====
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.   

<code># 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"
</code>\\ 
\\ 

===== Beispiel 2: SUN prtdiag =====
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.
<code># 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/

</code>\\ 
\\ 


===== Beispiel 3: SAN data replication monitoring (HORCM) =====
(Dank an [[gerhard.lausser@consol.de|Gerhard Lausser]] fuer dieses Beispiel!)

==== Problemstellung ====
Fuer die Replikation von SAN Daten in metropolitan clusters [[http://www.docs.hp.com/en/B7660-90014/ch05s04.html|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:
<code>$ ls /etc/hor*
/etc/horcm.conf   /etc/horcm0.conf  /etc/horcm1.conf
</code>
==== Daemons ====
Aufgrund der u.g. zwei Konfigurationsdateien sollten zwei Daemons laufen:
<code>$ ps -ef|grep horcmd
    root 401440      1   0   Jan 08      -  0:12 horcmd_01 
    root 467158      1   0   Jan 08      -  0:20 horcmd_00</code>

Bestimmung der Prozess-Namen fuer die //check_multi//-Konfiguration:
<code>
$ /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</code>
Das Programm selber heisst also ''horcmgr'', und Parameter ist der Name des einzelnen Daemon.

==== check_multi Parent-Konfiguration ====
Die Parent-Konfiguration verfolgt zwei Ziele:
  - Generierung der Child-Konfiguration in /tmp/horcmd_child.cmd
  - Aufruf-Anweisung fuer den Child-Check
<code>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</code>

==== check_multi Child-Konfiguration ====
Die Child-Konfiguration, wie sie dynamisch vom Parent generiert wurde:
<code>$ cat /tmp/horcmd_child.cmd
command [ horcmd00 ] = check_procs -C horcmgr -a horcmd_00
command [ horcmd01 ] = check_procs -C horcmgr -a horcmd_01</code>

==== Test auf der Kommandozeile ====
Die Ausgabe des Plugins auf der Kommandozeile:
<code>$ 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</code>