===== Expression evaluation =====
A powerful feature is //eval//. With this command file option you can evaluate arbitrary perl expressions and store the results either to reuse them lateron or to use the results in the final state evaluation.

There are two versions of eval:
  * eval - silent evaluation
  * eeval - //echo eval// - shows evaluation tag in extended plugin output

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

Continuation lines are supported with a trailing '\' at the end of the line ([[projects:check_multi:eval#example_3san_data_replication_monitoring_horcm|Example here]]). This allows human beings to read and understand command files :-D
\\ 
\\ 





===== Example 1: Linux network interface settings =====
The cmd file dynamically checks which is the default interface (i.e. the interface where the default route lies on). Then the settings (speed, duplex and auto negotiation) for this interface are collected. 
In the last step a warning is returned if the interface speed is not at least 100 MBit or if the duplex setting is not 'full'. 
Additional feature: all network parameters, the interface name and its settings are displayed in the extended plugin output.   
<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>\\ 
\\ 


{{tag>configuration state}}



===== Example 2: SUN prtdiag =====
SUNs hardware check program prtdiag is highly dependent on the particular kind of hardware it is running on. That makes it difficult to cover all different versions of HW in one check.
//check_multi// state evaluation provides an elegant way to cover different HW versions.

 Nice side effect: the output of prtdiag is available in the extended plugin output. 
<code># prtdiag.cmd
# evaluates prtdiag output against error strings
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>\\ 
\\ 


{{tag>eval eeval}}







===== Example 3: SAN data replication monitoring (HORCM) =====
(Thanks to [[gerhard.lausser@consol.de|Gerhard Lausser]] for this example!)

==== Environment ====
For the replication of SAN data in metropolitan clusters [[http://www.docs.hp.com/en/B7660-90014/ch05s04.html|HP provides a daemon solution]]. The problem in monitoring these daemons are their changing names - it depends on the local installation which daemons have to be checked.

Fortunately the names of the horcmd daemons can be determined from the names of the daemon config files which are located under /etc: 
<code>$ ls /etc/hor*
/etc/horcm.conf   /etc/horcm0.conf  /etc/horcm1.conf
</code>
==== Daemons ====
Following the config files two daemons should run:
<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>

Determination of the name of the calling process for the //check_multi// configuration:
<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>
The program itself is called ''horcmgr'' and its called with the parameter of the particular daemon.

==== check_multi parent configuration ====
Parent configuration, with two aims:
  - create child configuration in /tmp/horcmd_child.cmd
  - add monitoring command statement
<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 configuration ====
The child configuration, dynamically created by the parent:
<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>

==== Command line test ====
The plugin output on the command line:
<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>