jensschanz.de

Seit heute haben wir das check_hpasm Plugin bei uns inder Firma im Einsatz. Da die HP-Agents immer mal wieder die Lust verlieren und dann keine SNMP-Traps mehr rausschicken, habe ich die Hardwareüberwachung jetzt in Nagios integriert. Das ganze Thema hat auch nahezu auf Anhieb funktioniert, wäre da die Idee im Raum gestanden, die gesammlten Werte (Temperatur, Lüfter, etc.) per NagiosGrapher aufzubereiten.

Im Prinzip ist das Plugin schreiben für den NagiosGrapher kein großes Hexenwerk. Am Anfang sollte man sich überlegen, was man wie graphen möchte um dann die passenden Werte per Regular-Expression zu ermitteln damit man diese dem RRD-Tool per Skript zu schmeißen kann. Alles schon 100x erledigt.

Aber es wäre ja zu einfach, wenn es genau in diesem Fall auf Anhieb funktioniert hätte.
Das Problem ist eigentlich ganz einfach – Nicht jeder Server hat die identische Anzahl Lüfter oder Prozessoren. Manche haben 2 Lüfter (z.B. DL-360), manche auch 8 (z.B. DL-380). Manche sind redundant, andere nicht.  Um das ganze z vereinfachen hat sich HP auch etwas überlegt und bei jedem Modell, unter andere sogar bei gleichen Model (G4 und G4p) , die Temperaturfühler anderst belegt und sortiert. Ist im G4 die I/O-Zone der Fühler 1 ist im G4p der Fühler 3 dafür zuständig.

Um das ganze möglichst mit einem Skript zu erschlagen, stand der Gedanke im Raum einfach alle Parameter, egal ob vorhanden oder nicht, auszuwerten.

Tja … und damit begannen die Probleme.
Warum sich der NagiosGrapher bei einer nicht matchenden Regex für diesen Graph gleich beendet und kein RRD erstellt, war ziemlich einfach zu finden – OpenSource sei Dank. Der Nachteil von OpenSource ist unter anderem der, dass man davo auch ganz leicht Kopfschmerzen bekommen kann.

Wer GOTO in Perl verwendet, frisst auch kleine Kinder.

# Taking PerfData
if ( $perfdata =~ m/$_->{graph_perf_regex}/i ) {
    my $value = $1;
    $value =~ s/,/\./;
    $values{ $_->{graph_value} } = $value;
    $check = "TRUE";
    $ng->print_log("REGEX: ". 'match='. $value)
        if ($opt_verbose &    $LOG_DEBUG_REGEX);
} else {
    $ng->print_log("REGEX: NO MATCH.")
        if ($opt_verbose & $LOG_DEBUG_REGEX);
    $ng->print_log ("VALUES: ".$log_header."No matching perfdata values  found...")
        if ($opt_verbose & $LOG_VALUES_NOK);
    goto OUT;
}

Nachdem ich das

 goto OUT

auf die Schnelle mal rausgeschmissen hab, wurde zumindest das RRD angelegt und der Graph dazu erstellt. Unschönerweise werden natürlich jetzt auch für alle anderen ungefähr matchenden Regular-Expressions Graphen angelegt. check_hpasm_system und check_hpasm_iml sind nur ungefähr das gleiche. Naja … Das werden wir morgen fixen.

Wer Interesse am kompletten “Bugfix” hat, kann sich gerne melden.

Diese Woche haben wir bei einer Überprüfung unserer AIX- und Linux-LPARs festgestellt, dass die Pfade zu einem VIO-Server weggebrochen sind. Nicht wirklich schlimm, da der zweite wie erwartet übernommen hat, trotzdem aber ärgerlich weil

a) keiner was mitbekommen hat
b) die Redundanz dadurch unnötig gefährdet war

Damit das in Zukunft nicht wieder vorkommen kann, habe ich gleich ein Plugin in unsere Nagios Infrastruktur eingebaut. Ab sofort werden defekte Multipath-Pfade gemeldet.

Linux:
multipath -l | grep -i failed | awk ‘{ printf “\”" $2 ” ” $3 “(” $5 “)”"\”" }’

AIX:
lspath | egrep -i “failed|missing|disabled|detected|defined” | awk ‘{ printf “\”" $3 ” ” $2 “(“$1″)”  “\” ” }’

Download: check_multipath

Bisher habe ich beim Monitoring mit Nagios ausschließlich aktive Checks verwendet. Passive Checks werfen meiner Meinung nach immer wieder Probleme auf.

Da wir letztens über die Implementierung von Java-Prozessen in Nagios gesprochen haben und es wohl schon eine verwertbare API für NSCA gibt, habe ich das Thema passive Checks am Nagios-Server testweise aktiviert.

Ob und wie es funktioniert wird sich zeigen. Der Ansatz den ich gefunden habe, halte ich aber für gangbar.

Damit die passiven Checks auch mit Sicherheit funktionieren sind ein paar Nacharbeiten notwendig. Da Nagios nicht wie bei einem aktiven Check selbst über den Zustand des Dienstes wacht (Polling-Betrieb), sondern der Dienst mehr oder weniger über sich selbst (Push-Betrieb), sind ein paar Sicherheitsvorkehrungen notwendig, damit ein Ausfall auch rechtzeitig bemerkt wird.
Die kann mit den Optionen des Freshness-Checkings erreicht werden. Dabei werden dem Dienst selber in der Konfiguration folgende Parameter mit gegeben:

check_service_freshness = 1
service_freshness_check_interval=120

Mit der Option check_service_freshness überwacht nun Nagios den Status des Prozesses und zwar im Sekunden-Intervall des bei service_freshness_check_interval angegebenen Wertes. Steht dor 0, rechnet Nagios den Intervall selbst aus. Diese Lösung bevorzuge ich, da man dadurch ein Stück unabhängig wird vom Meldungs-Intervall des Dienstes.

Damit das nun auch reibungslos funktioniert, legt man ein einfaches Shell-Skript an

/usr/local/nagios/libexec/check_passive

#!/bin/sh
/bin/echo "CRITICAL: Service results are stale!"
exit 2

und macht das anschließend in der Object-Konfiguration (commands.cfg) von Nagios bekannt

define command{
        command_name check_passive
        command_line $USER1$/check_passive
}

Dieses Check-Command wird anschließend noch als check_command des passien Checks eingetragen.
Damit hat man nun eine ziemlich einfache und simple Überwachung, ob der passive Check noch aktuelle Daten hat.

Nachdem die mitgelieferten Init-Skripte für den Nagios/Netways-Grapher bei uns nie wirklich zufriedenstellend funktioniert haben, habe ich einfach kurz ein eigenes geschrieben. Das Skript ist unter OpenSuSE und SLES vollständig getestet und funktioniert. Unter Redhat sollte es aber ebenfalls tun. Verbesserungen für Debian und/oder Ubuntu nehme ich gerne an.

Download