Monitoring mit Xymon

1. Service Monitoring
   1. Status-Anzeigen und Farb-Codes
   2. Konfiguration der Monitoring-Direktiven
      1. Direktive conn
      2. Direktive cpu
      3. Direktive disk
      4. Direktive procs
      5. Direktive svcs
      6. Direktive msgs
      7. Direktive used
   3. Integration eigener Service Tests (externe XYMON-Scripte)
      1. Bereitstellung des Scripts durch Funktionsverantwortliche
      2. Hinweise
   4. Automatische Benachrichtigung der Funktionsadmins
      1. Reaktionsmöglichkeiten der Funktionsadmins
         1. Bestätigung (Acknowledge)
         2. Zeitweises Abschalten kritischer Anzeigen (Disable)
         3. Wieder-Einschalten (Enable)
   5. Zugangsbeschränkungen zu den XYMON-Infos
   6. Literatur

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 Monitoring-System bb angezeigt, und eine Störungsmeldung wird 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.

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

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 ()

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 Skriptname 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 erfolgen, 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-Skripte funktionieren auch in der XYMON-Umgebung

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

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

Das Skript sollte in einem geeigneten ToSCA-Root-Repository

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, FU_..._DEVICE)
• keine Benachrichtigung:
  • sog. Entwicklungs- oder Testsystemen (FU_..._DEVEL_MISC)
  • Arbeitsplatzsystemen (FU_..._WS)
  • Poolrechnern (FU_..._POOL_..._WS)
  • 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
   "<hostname|fqdn>.<event>"|"<hostname|fqdn>.*"  --> 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 ToSCA-AFS-Gruppe to:user sind, z. B. Funktionsadmins
• nicht erlaubt für Nutzer 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|fqdn>.<event>"|"<hostname|fqdn>.*"  --> enable <event> for <hostname> OR all events for <hostname>

• Anzeigen bleiben so lange , bis zum nächste Zyklus des XYMON-Klienten

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-Skripte (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

Links/Literatur

• https://bb.hrz.tu-chemnitz.de/xymon.html
• https://bb1.hrz.tu-chemnitz.de/xymon.html
• https://bb2.hrz.tu-chemnitz.de/xymon.html
• https://xymon.hrz.tu-chemnitz.de/xymon.html
• SourceForge - https://sourceforge.net/projects/xymon/
• BBWin-Klient - http://bbwin.sourceforge.net/