check_xencpu

Das Script steuert mittels SNMP ein weiteres Script auf einer XEN dom0 an, welches die CPU Statistik liefert, Es dient nicht zum ermitteln harter Stati (OK/CRITICAL) sondern zum sammeln von Langzeitdaten mittels PNP.

Das Script Es wird ein Script „xenupdate.py“ erstellt, zum Beispiel unter /root/script:

#!/usr/bin/python
import sys
import os
import re
import time
 
now=str(int(time.time()))
 
data=os.popen2("/usr/sbin/xm list")[1].read()
domains=data.split("\n")[1:-1]
for domain in domains:
    name,id,mem,cpu,state,cputime=re.split("[\t ]+",domain)
    cputime=int(float(cputime)*1000)
    print name + "=" + str(cputime)+"c",

Das Script erfordert natürlich Python und den Befehl „xm“ unter /usr/sbin.

Einbinden in SNMP

snmpd.conf

exec check_xencpu /root/script/xenupdate.py

Script unter nagios/libexec/ Wir legen eine Datei mit dem Namen check_xencpu an:

#!/bin/bash
/opt/nagios/libexec/check_snmp -H $1 -P 1 -C public -o .1.3.6.1.4.1.2021.8.1.101.7 | awk -F\" '{print $2 " | " $2}'

Wie hier zu sehen ist natürlich das check_snmp Script notwendig, unter Umständen muss der Pfad angepasst werden. Die OID (angegeben mit -o) kann von System zu System unterschiedlich sein, je nachdem an welcher Stelle das Script in der snmpd.conf eingetragen wurde. Im Beispiel sind vorher noch 6 andere Scripte eingetragen, darum auch die 7.

Einbinden in commands.cfg

define command {
	command_name	check_xencpu
	command_line	$USER1$/check_xencpu $HOSTADDRESS$
	}

Einbinden als Service

define service{
	use				minute-service
	host_name			mein_server.de
	service_description		XEN CPU
	check_command			check_xencpu
	}

Damit das ganze auch nach etwas ausschaut, sollte natürlich ein angepasstes PNP Template nicht fehlen. Also erstellen wir ein angepasstes Template mit dem Namen check_xencpu.php im templates Ordner dder PNP Installation.

<?php
$opt[1] = "--vertical-label CPU% -l0  --title \"$hostname / $servicedesc\" ";
 
$color = array("000000", "FF0000", "00FF00", "0000FF", "DEDE00", "00FFFF", "FF90FF", "FF8040", "C040A0", "A0A0A0", "40A0A0", "40A0FF", "FFA040");
 
$def[1] = "";
foreach ($DS as $i)
{
	$def[1] .=  "DEF:$NAME[$i]raw=$rrdfile:$DS[$i]:AVERAGE " ; 
	$def[1] .= "CDEF:$NAME[$i]percent=$NAME[$i]raw,10,/ ";
	$def[1] .= "CDEF:$NAME[$i]zero=$NAME[$i]percent,DUP,UN,EXC,0,EXC,IF ";
	$def[1] .= "CDEF:$NAME[$i]neu=$NAME[$i]zero,0,400,LIMIT ";
	$def[1] .= "CDEF:$NAME[$i]neup=$NAME[$i]percent,0,400,LIMIT ";
}
 
foreach ($DS as $i)
{
	if($i == 1) { $string = "AREA"; }
	else { $string = "STACK"; }
	$def[1] .= "$string:$NAME[$i]neu#$color[$i]:$NAME[$i] ";
	$def[1] .= "GPRINT:$NAME[$i]neup:AVERAGE:\"Average CPU usage\: %02.0lf%%\j\" ";
}
 
?>

Das Template ist für ein QuadCore System enstanden, das somit max. 400% CPU Auslastung haben kann, damit keinen unschönen Spitzen beim Neustart einer domU entstehen werden im Template nur Werte bis max. 400 zugelassen, dies lässt sich aber jeder Zeit ändern.

Wenn wir alles richtig gemacht haben, schaut das ganze am Ende etwa so aus:

Das ganze ist natürlich noch lange nicht der Weisheit letzter Schluss, sondern eher eine Machbarkeitsstudie, die aber sicher den Einen oder Anderen auf gute Ideen bringt. Diese momentane Methode hat allerdings zwei große Probleme:

• Ändern der Datensätze (eine domU kommt hinzu/weg) schon muss die RRD gelöscht werden
• Max. Stringlänge für PNP, zuviele domUs sind nicht möglich, es kann auch passieren das nach und nach welche Verschwinden je weiter der Counter mit den CPU Daten hoch zählt

Für beides ist vermutlich check_multi die ideale Lösung und wird nach erfolgreicher Nagios 3 Migration auch sicherlich so umgesetzt.