Wissen, was gut ist. Studieren in Chemnitz.

Überwachung der Dienste und Rechnersysteme mit "XYMON"

System- und Netzwerkmonitoring ist eine wichtige Voraussetzung für die Realisierung zuverlässiger serverbasierter Dienste, die frühzeitige Erkennung von (zukünftigen) HW- und SW-Problemen sowie die Verfügbarkeit der eingesetzten Ressourcen.

BigBrother im URZ

ToSCA (Toolbox for System Configuration and Administration) ist ein System von
  • Datenstrukturen
  • Methoden und
  • Verfahren
zur effektiven und skalierbarbaren Systemadministration von Rechnersystemen unterschiedlicher Betriebssystemfamilien.

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

Probleme

Unter den gegebenen Randbedingungen sind o.g. Anforderungen nur durch den Einsatz von XYMON realisierbar.

Einführung in XYMON

Architektur

XYMON-Server

XYMON-Klienten

Status-Anzeigen und Farb-Codes

Colorkürzlich geändertLetzte Änderung > 24 Stunden
Green: Alles OK Green - recently changedGreen
Yellow: Achtung, Grenzwert überschritten, evtl. Gefahr im VerzugYellow - recently changedYellow
Red: echtes Problem, Aktion notwendigRed - recently changedRed
Clear: keine Daten verfügbar, Test abgeschaltetClear - recently changedClear
Purple: keine Statusmeldungen (seit mind. 30 Minuten) reportPurple - recently changedPurple
Blue: Anzeige abgeschaltet (disabled) z.B: wegen WartungsmaßnahmenBlue - recently changedBlue
Red ACK bzw. Purple ACK: Problem bestätigt und in Bearbeitung Red - acknowledged bzw. Purple - acknowledged -

Status-Anzeigen

XYMON-Demo

Views

Reports (Auswahl)

Administration (Auswahl)

Info-Anzeige

Trends-Anzeige

Host-Informationen- und Aktionen (Hostname-URL)

Konfiguration der Status-Anzeigen

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

conn

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)

cpu 

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

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

disk 

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


   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

procs 

   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

svcs 

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

msgs 

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

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. 

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:

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

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)

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

#!/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 

     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.
Bitte beachten: Ursprungsbenachrichtigung muss innerhalb 24 Stunden bestätigt werden

Zeitweises Abschalten kritischer Anzeigen (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


bb_disable "hermes*" 1d Reparatur Mainboard

Wieder-Einschalten (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>


bb_enable "hermes*"

Überlegungen zu Zugangsbeschränkungen zu den XYMON-Infos 

  das hat zur Folge, dass der Zugang zum Monitoring-Server voraussetzt, dass der Dienst Shibboleth
  funktioniert, deshalb ist das noch nicht entgültig entschieden.

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

Projekt BigBrother New Generation (BBNG)

Literatur

-- MatthiasClauss - 08 Feb 2012