Service Monitoring

Der Betrieb von realen Systemen und Virtual Private Server (VPS) wird durch Monitoring-Software überwacht, u.a. hinsichtlich folgender Monitoring-Direktiven:

Netzkonnektivität (Monitoring-Direktive conn)
CPU-Last (cpu)
Füllstand der lokalen Filesysteme (disk)
RAM-Nutzung: (memory)
kritische Systemnachrichten (msgs)
definierte Systemprozesse (procs), falls vom Funktionsadmin angegeben
definierte Services (svcs), falls vom Funktionsadmin angegeben
Funktionstest (func), falls vom Funktionsadmin realisiert
Verfügbarkeitstests von Netzdiensten, falls vom Funktionsadmin angefordert, z.B.
- http[s]
- imap
- pop3
- smtp
graphische Trendanzeigen (trends)
Infos über Konfiguration (info)

Entsprechende Anzeigen sind per Web verfügbar. Im folgenden wird für reale Systeme und VPS der Begriff Host verwendet.

Erbringt der Host kritische Dienste (Produktionsserver), so werden durch die Monitoring-Software festgestellte Probleme im http://bb.hrz.tu-chemnitz.de/bb.html angezeigt und eine Störungsmeldung per E-Mail an die Diensteverantwortlichen (Funktionsadmins) gesendet.

Erbringt der Host keine kritischen Dienste (z.B. Arbeitsplatz-, Pool- oder Entwicklungsrechner), so werden durch die Monitoring-Software festgestellte Probleme abhängig vom Eigentümer des Hosts angezeigt. In solchen Fällen erfolgt keine Störungsmeldung per E-Mail.

Name	Einsatz	URL des Monitoring-Servers
bb	alle Produktionsserver	http://bb.hrz.tu-chemnitz.de/bb.html
bb1	Arbeitsplatz- und Entwicklungsrechner alle Einrichtungen (außer URZ,UB)	http://bb1.hrz.tu-chemnitz.de/bb.html
bb2	Arbeitsplatz-, Pool-, Entwicklungsrechner UB und URZ	http://bb2.hrz.tu-chemnitz.de/bb.html

Status-Anzeigen und Farb-Codes

Beginn der Monitoring-Main-Page (Beispiel):

Umschaltung auf die Zusammenfassung (Pfeil) aller Hosts mit "non-green"-Anzeigen:

Status-Anzeigen und Farb-Codes

Color	kürzlich geändert	Letzte Änderung > 24 Stunden
Green: Alles OK
Yellow: Achtung, Grenzwert überschritten, evtl. Gefahr im Verzug
Red: echtes Problem, Aktion notwendig
Clear: keine Daten verfügbar, Test abgeschaltet
Purple: keine Statusmeldungen (seit mind. 30 Minuten) report
Blue: Anzeige abgeschaltet (disabled) z.B: wegen Wartungsmaßnahmen
Red ACK bzw. Purple ACK: Problem bestätigt und in Bearbeitung	bzw.	-

Konfiguration der Monitoring-Direktiven

Man unterscheidet verschiedene Monitoring-Direktiven, z.B. Konnektivitätstest (Direktive conn ), Filesystem-Füllstand (Direktive disk ) usw.

Konfigurationsregeln für die Auswertung der Monitoring-Direktiven werden auf den XYMON-Servern zentral gehalten.

Konfigurations-Anforderung durch Funktionsadmin: per OTRS-Ticket: mailto:support@hrz.tu-chemnitz.de?subject=XYMON: ...

Konfigurations-Prinzip	Bedeutung
ZE	Monitoring-Direktive wird zentral für alle Hosts mit dem betreffenden BS einheitlich konfiguriert
ZI	Monitoring-Direktive wird zentral für jeden einzelnen Host individuell konfiguriert
GI	Monitoring-Direktive wird generisch für jeden Host individuell erzeugt
DI	Monitoring-Direktive wird dezentral , d.h. durch den Funktionsadmin für jeden einzelnen Host individuell konfiguriert

Direktive conn

Konfigurations-Prinzip Windows: ZI
Konfigurations-Prinzip Linux: ZI

Für Produktionsserver ist der Konnektivitätstest zwingend und nicht abschaltbar. Für Entwicklungs- bzw. Testsysteme kann der Funktionsadmin anfordern, dass kein Test erfolgt ( Clear - recently changed

)

Direktive cpu

Konfigurations-Prinzip Windows: ZE

<cpu>
        <setting name="alwaysgreen" value="false" />
        <setting name="default" warnlevel="80%" paniclevel="95%" />
        <setting name="uptime" value="1h" />
</cpu>

Konfigurations-Prinzip Linux: ZI

- Konfigurationswerte basieren auf den

5-Minuten-Last-Durchschnittswerten (load average) des =uptime=-Kommandos (2. Spalte). Die Spezifikation erfolgt im File analysis.cfg nach folgendem Muster

HOST=<hostname>.<domaene>.tu-chemnitz.de
   LOAD <warnlevel> <paniclevel>

z.B.

HOST=aelius.hrz.tu-chemnitz.de
   LOAD 3.5 7.0

Direktive disk

Konfigurations-Prinzip Windows: ZE

<disk>
        <setting name="alwaysgreen" value="false" />
        <setting name="default" warnlevel="90%" paniclevel="95%" />
        <setting name="remote" value="false" />
        <setting name="cdrom" value="false" />
</disk>

Konfigurations-Prinzip Linux: GI (abhängig von der tatsächlichen FS-Kapazität)

   DISK <filesystem> <warnlevel> <paniclevel>
   DISK <filesystem> IGNORE
z.B.:

HOST=beo.hrz.tu-chemnitz.de
   DISK / 85 88
   DISK /www 92 93
   DISK /var 84 87
   DISK /.afscache 100 101
   DISK /tmp 83 86
   DISK %^/mnt IGNORE
   DISK %^/media IGNORE

Direktive procs

Windows: nicht verfügbar
Konfigurations-Prinzip Linux: ZI

   PROC <processname> <minimumcount> <maximumcount color> ...
z.B.

HOST=*
   PROC  crond yellow
   PROC  ntpd  1  1  yellow
   PROC  "%xinetd -stayalive -pidfile /var/run/xinetd.pid" 1  1
   PROC  "%/bin/xymonlaunch --config=./etc/clientlaunch.cfg" 1 1

...

HOST=xyz.hrz.tu-chemnitz.de
   PROC vmtoolsd yellow
   PROC %ora_...._vcdb 19
   PROC bbd 1 2

Direktive svcs

Konfigurations-Prinzip Windows: ZE

<svcs>
        <setting name="alwaysgreen" value="false" />
        <setting name="alarmcolor" value="yellow" />
        <setting name="autoreset" value="false" />
        <setting name="OpenAFS Client" value="started" autoreset="false" alarmcolor="red" />
        <setting name="cfengine" value="started" autoreset="false" alarmcolor="red" />
        <setting name="Big Brother Hobbit Client" value="started" autoreset="false" alarmcolor="red" />
</svcs>

Linux: nicht verfügbar

Direktive msgs

Konfigurations-Prinzip Windows: ZE
Konfigurations-Prinzip Linux: ZE

HOST=*
   LOG /var/log/messages %(I/O|read).error COLOR=yellow
   LOG /var/log/messages %kernel:.Call.Trace: COLOR=yellow
   LOG /var/log/messages %Offline.uncorrectable.sectors COLOR=yellow
   LOG /var/log/messages %Currently.unreadable COLOR=yellow
   LOG /var/log/messages %:.segfault.at.COLOR=yellow
   LOG /var/log/messages %invoked.oom-killer: COLOR=red
   LOG /usr/local/xymon/client/logs/xymonclient.log %Whoops.!.Failed.to.send.message COLOR=yellow
   LOG /usr/local/xymon/client/logs/xymonclient.log %Could.not.connect.to.Xymon.daemon COLOR=yellow

Direktive used

Die used -Anzeige wird nur für die zentralen Pool-Rechner angezeigt. Sie zeigt an, ob ein Nutzer an der Konsole angemeldet ist sowie dessen Nutzerkennzeichen.

Integration eigener Service Tests (externe XYMON-Scripte)

Die Bereitstellung eigener Service- oder Funktionstests und die Integration in das Monitoring-Konzept ist relativ einfach möglich und wird allen Funktionsadmins von Hosts, die kritische Dienste erbringen, dringend empfohlen.

allgemeingültiger Mechanismus für func -Anzeige
Basis: Wrapper-Scripts

Definition der externen Variablen $GREEN, $YELLOW, $RED in
/afs/tu-chemnitz.de/ToSCA/ROOTS/LINUX/ROOT4ANY/usr/local/xymon/client/ext/xymon-func.sh 
/afs/tu-chemnitz.de/ToSCA/ROOTS/LINUX/ROOT4ANY/usr/local/xymon/client/ext/xymon-sudo.sh

Bereitstellung des Scripts durch Funktionsverantwortliche

Das Shell -Script muss in einem festgelegten Verzeichnis stehen:

Linux: /usr/local/xymon/ext/func.d/

Der Name des Scripts kann frei gewählt werden unter Beachtung folgender Regeln:

Scriptname muss auf .sh enden

Im Linux wird der sudo -Mechanismus benutzt, um gezielt root -Rechte zu ermöglichen. Deshalb muss der Scriptname mit su - beginnen, falls die Ausführung root -Rechte erfordert. Zusätzlich muss durch den Auftraggeber (Funktionsadmin) der entsprechende sudo -Eintrag angefordert werden.

Das Ergebnis des Service-Tests wird über die o.g. externe Variablen bereitgestellt (exit -Status)

Test OK: exit $GREEN
Test ergibt unkritische Fehler: exit $YELLOW
Test ergibt kritische Fehler: exit $RED

Zusätzliche Informationen zu den Testergebnissen können über stdout bzw. stderr bereitgestellt und im Monitoring angezeigt werden.

Beispiel für Script:

#!/bin/sh
# nkz, 11.06.2008: Funktionstest Mount

STATUS=$GREEN

SOLLMOUNT=$(awk ' /^[^#].*\/vicep/ { print $2 }' /etc/fstab| sort)
ISTMOUNT=$( mount| awk ' $3 ~ /\/vicep/ {print $3}'| sort)

echo "Sind alle Vice-Partitions montiert?"
echo
echo -n "SOLL: "; echo $SOLLMOUNT
echo -n "IST : "; echo $ISTMOUNT
if [ "$ISTMOUNT"  != "$SOLLMOUNT" ]; then
    STATUS=$RED
fi
exit $STATUS

Hinweise

Status-Anzeige $RED sollte nur dann passieren, wenn ein Dienstausfall festgestellt wurde, der sofortige Problembehebung erforderlich macht.

Andernfalls ist z.B. eine Mail an die Funktionsadmins ausreichend.

Für BigBrother bereitgestellte func -Scripte funktionieren auch in der XYMON-Umgebung

Es wird empfohlen, die Funktionstest atomar zu gestalten, d.h. pro Funktionstest ein separates Script bereitstellen.

Im Fehlerfall ist es sinnvoll, wenn ein Link auf die Dokumentation zur Analyse und Behebung des Fehlers angezeigt wird.

Das Script sollte in einem geeigneten ToSCA-Root-Repository bereitgestellt werden.

z.B. in
/afs/tu-chemnitz.de/ToSCA/ROOTS/LINUX/FU_xxx_SERVER/usr/local/xymon/client/ext/func.d/

Automatische Benachrichtigung der Funktionsadmins

nur bei Systemen, die kritische Dienste erbringen (sog. Produktionsserver - FU_..._SERVER)
keine Benachrichtigung:
- sog. Entwicklungs- oder Testsystemen (FU_..._DEVEL_MISC)
- Arbeitsplatzsystemen (FU_..._WS)
- Poolrechnern (FU_..._POOL_...)
- SH Level 1
Benachrichtigungsregeln (z.Z.)
- kritische Anzeigen:
- Benachrichtigung erfolgt mit 5 Minuten Verzögerung an ALLE Funktionsadmins des betreffenden Servers
- Wiederholung nach jeweils 4 Stunden (sofern Anzeige nicht OK)
- Benachrichtigung erfolgt auch dann, wenn wieder OK
Benachrichtigung: Mail mit Subject

     Xymon [520115] xyz.hrz.tu-chemnitz.de:memory CRITICAL (RED)
     
     --> 520115: Acknowledgment Code

Reaktionsmöglichkeiten der Funktionsadmins

Bestätigung (Acknowledge)

Funktionsadmin sollte bestätigen, dass er sich um die Lösung des Problems kümmert. Damit zeigt er die Problembearbeitung an und es wird vermieden, dass sich weitere Personen parallel mit dem Problem auseinandersetzen.

über Administration --> Acknowledge Alert
- Zeitbedarf, bis Problem (vermutlich) gelöst ist
- Erklärung, Ursache für Problem
- Acknowledgement Code

Bitte beachten: Ursprungsbenachrichtigung muss innerhalb 24 Stunden bestätigt werden

kurze Zeit später: "Häkchen"-Anzeige bzw.

Zeitweises Abschalten kritischer Anzeigen (Disable)

V1: Linux-Kommando bb_disable

   $ /usr/local/bin/bb_disable

   usage: /usr/local/bin/bb_disable
    [-h]                     --> this help message
    [-n]                     --> no mail to function admins
    [-x]                     --> only disable for xymon
   "<hostname>.<event>"|"<hostname>.*"  --> disable <event> for <hostname> OR all events for <hostname>
    <duration>               --> how long should be disabled, e.g. 300s or 2h or 1d (Standard: m)
    [reason]                 --> short text string

nur Nutzern erlaubt, die Mitglieder der AFS-Gruppe to:user sind, aber nicht root
Beispiel: für einen Tag keine Monitoring-Anzeigen für Host "hermes" wegen Mainboard Reparatur:
Anzeigen werden

bb_disable "hermes*" 1d Reparatur Mainboard

V2: über Info-Anzeige
V3: über Administration --> Enable/Disable

Wieder-Einschalten (Enable)

V1: festgelegte Zeitspanne ist abgelaufen
V2: Linux-Kommando bb_enable

   $ /usr/local/bin/bb_enable 
   usage: /usr/local/bin/bb_enable
      [-h]                    --> this help message 
      "<hostname>.<event>"|"<hostname>.*"  --> enable <event> for <hostname> OR all events for <hostname>

Anzeigen bleiben so lange bis zum nächste Zyklus des XYMON-Klient

bb_enable "hermes*"

V3: über Info-Anzeige
V4: über Administration --> Enable/Disable

Zugangsbeschränkungen zu den XYMON-Infos

generell Zugang nur per Shibboleth (auch auf die Hauptseite)
der Zugang zu den (statischen) Übersichts-Views ist für all jene möglich, die einen URZ-Nutzerkennzeichen haben
der Zugang zu Web-Seiten mit Detailinformationen ist für all jene möglich, die in diesem Bereich administrative Verantwortung besitzen, z.B.:
- alle Funktionsadmins und die benannten Ansprechpartner (Kontaktpersonen) der dort gelisteten Server
- URZ-Admins
- URZ-Dispatcher
- UB-Service-Mitarbeiter
die entscheidenden cgi-Scripts (z.B. svcstatus.cgi ) für einen Host können ebenfalls nur Personen mit administrativer Verantwortung ausführen:

wer	welche Hosts
Funktionsadmins	betreffender Host
Selfadmins	betreffender Host
Kontaktpersonen	betreffender Host
Admins des URZ	alle Hosts
Dispatcher des URZ	URZ-Hosts
UB-Service-Mitarbeiter	UB-Hosts