[SAGE-MUC] Erfahrungsaustausch Monitoring unter UNIX/Linux

[Sascha Haupt]

> Hallo zusammen,
>
> ich antworte hier einmal stellvertretend. Die Frage wozu das Monitoring
> gebraucht wird, war nicht ganz unpassend. Deshalb hier etwas genaueres:
>
> Unser Monitoring ist fuer ca. 150 Linux/Solaris-Server und Linux
> Workstations der Pharma Forschung. Wir haben eine ziemlich breite
> Palette. Beowulf Cluster, Chemische Analyse Workstations, Oracle
> Cluster, OCFS und Redhat Cluster Filesystem... um ein paar zu nennen.
> Wir haben kaum wirklich hohe Verfuegbarkeit. Es ist eher die
> Komplexizitaet, um alle wissenschaftlichen Applikation miteinander
> laufen zu lassen. Performance ist ein wichtiger Faktor. Ausserdem werden
> die Applikation von allen Niederlassungen rund um die Welt genutzt. Hier
> noch einige Details, was wir wofuer einsetzen:
>
> Spong:
> - Ist im Einsatz fuer Ueberwachung und Alarming. z.B. es schickt einen
> zeitversetzen Alarm per SMS. Nach 20 min Verzoegerung, hat sich in der
> Regel alles wieder ergeben, was durch kurzfristige Netzprobleme oder
> kurzfristig hohen load verursacht wurde. Testet server und clientseitig.
> - Die Syslog Analyse funktioniert mit perl regexp.
> - Die Darstellung ist sehr kompakt und meiner Meinung nach
> uebersichtlich. Ich mach mal 'nen screenshot.
> - Mit selbstgeschriebenen perl modulen ueberwachen wir auch die
> Verfuegbarkeit von wissenschaftlichen Applikationen und lassen damit die
> Application Manager alarmieren.
>
> Ganglia:
> - Graphische Darstellung von Performance und Verfuegbarkeit:
> Funktioniert bestens mit allen Arten von Clustern (wir haben beowulf und
> high availability cluster) . Nutzt MRTG (RRD database)
> - Die Grafische Darstellung unterstuetzt auch bei der root cause
> analysys. Wir haben immer wieder crashes, da ein grosser Teil der
> Software von den Forschen selbstentwickelt ist und Linux nicht ganz so
> stabil ist, wie Solaris oder IRIX.
>
> SAR:
> kennt Ihr wirklich sar nicht? Dann gebt bitte mal sar auf eurem
> UNIX/Linux ein. Wir verwenden es fuer hartnaeckige Probleme ueber lange
> Zeitraeume um den jeweiligen Zustand der  Systemumgebung zu untersuchen.
>
> Alles sind ziemlich einfache tools. (Was mir persoenlich auch
> sympathisch ist.)
>
> Gruss, Hermann


Ich denke Zabbix könnte in diesem Fall eine gute Wahl für euch sein.

Es kann vom Monitoring-Server aus Remote-Tests durchführen oder man kann
einen Agent auf dem "Device Under Test" (DUT) installieren und damit
System interne Tests durchführen.

Das Management vieler Systeme geht sehr elegant über Templates. Man
definiert z.B. ein Template für eine Hostgruppe (z.B. Cluster-Nodes) und
kann darin Einstellungen für alle gleichartigen Systeme machen.

Es gibt viele eingebaute Standard-Tests (z.B. Load) und man spart sich
damit das Skript schreiben. Es ist aber dennoch möglich auch eigene
Skripte zu verwenden. Bei der Verwendung eigener Skripte hatte ich bereits
das Problem, dass man manche Daten nur als Root auslesen durfte. Da hilft
dann aber sudo.

Mit sogenannten Triggern kann man Schwellwerte für Alarmierungen etc.
vorgeben. Dabei kann man dann auch E-Mail Versand oder ähnliches anstoßen.

Es gibt auch eingebaute RRD Grafiken für Load, etc.

Sehr schön ist, dass man viele Einstellungen vom Management-Server aus
machen kann (z.B. Einstellung von Abfrage-Intervallen). Auf den DUT muss
man eigentlich nur dann etwas konfigurieren, wenn man lokale
Selbstbau-Testskripte verwendet.

Logfile-Analyse mit Zabbix könnte man vielleicht mit Selbstbau-Skripten
machen. Ich weis aber nicht, ob das wirklich Sinnvoll ist und ob man das
gut realisieren kann. Da hilft nur anschauen und ausprobieren.
Wahrscheinlich ist es aber sinnvoller für die Logfile-Analyse eine von
Zabbix unabhängige Lösung zu finden.

Auch hatte ich von Zabbix den Eindruck, dass es noch recht junge Software
ist und sich zwischen den Releases noch sehr viel tut. Öftere Upgrades
sind zumindest auf Serverseite daher sicherlich nicht falsch. Aber man
kann es bereits produktiv einsetzen.

Wie es mit der Performance in einer größeren Umgebung ausschaut müsste man
ebenfalls austesten. Man kann afaik Zabbix-Server, Datenbank und
Webinterface auch auf unterschiedlichen Maschinen laufen lassen. Auch
Distributed Umgebungen sind möglich.

So, jetzt habe ich wahrscheinlich schon den halben Zabbix-Vortrag von
Michael Schwartzkopff obsolet gemacht :-)

Ich fände es interessant wenn Du uns nach der Implementierung vielleicht
mit einem Bericht/Vortrag über die Umsetzung (egal mit welcher Technik)
beglücken könntest. Ist ein interessantes Thema.

Gruß
Sascha