Ich habe vor einiger Zeit mal über die Konfiguration und Anwendung von Nagios geschrieben. Hier will ich mich nun mit einem anderen, leichter einzurichtenden Programm zuwenden.
Nur leichter einzurichten bedeutet alles andere als schlechter! Wenn ich mich Entscheiden müsste zwischen Xymon (ehemals Hobbit) und Nagios, so würde ich für mich persönlich Xymon nehmen, da mich Nagios mit seinen zahlreichen Funktionen direkt überfordert.
Xymon ist mit den Funktionen nicht ganz so umfänglich, deckt aber die wichtigsten ab. So lassen sich mit Xymon Serverkomponenten wie Harddisks, CPU, Memory, Prozesse, aber auch Dienste wie FTP, SSH, SMTP, POP und vieles mehr überwachen.
Doch wenn man so tief ins System eines Servers eingreifen will, dann braucht man meistens auch einen Agent, welcher die ganzen Daten ausliest.
Dieser Agent ist für Debian-basierte Systeme in den Paketquellen verfügbar und kann wie folgt installiert werden:
1
| sudo apt-get install xymon |
Während der Installation wird man nach der IP des Datacollectors gefragt, welcher das Webfrontend und damit die ganzen Daten verwaltet.
Nun muss man zusätzlich auch noch Apache installieren, da, aus welchen Gründen auch immer, dieses Paket nicht als Abhängigkeit eingerichtet wurde:
2
| sudo apt-get install apache2 |
Jetzt gilt es noch die Daten aus /etc/hobbit/web über den Browser verfügbar zu machen. Dazu kann man einen Softlink von /var/www zum Ordner mit den Xymon-Webfrontend-Daten:
3
| sudo ln -s /etc/hobbit/web /var/www/hobbit |
Wenn man nun die IP des Datacollectors im Browser aufruft, so wird dieser bereits automatisch überwacht. Es müssen nun also noch weitere Server zugefügt werden.
Dazu editiert man die Datei /etc/hobbit/bb-host:
4
| sudo vim /etc/hobbit/bb-host |
Bei mir sieht die Datei so aus:
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| # Master configuration file for Hobbit
#
# This file defines several things:
#
# 1) By adding hosts to this file, you define hosts that are monitored by Hobbit
# 2) By adding "page", "subpage", "group" definitions, you define the layout
# of the Hobbit webpages, and how hosts are divided among the various webpages
# that Hobbit generates.
# 3) Several other definitions can be done for each host, see the bb-hosts(5)
# man-page.
#
# You need to define at least the Hobbit server itself here.
#0.0.0.0 .default. # NOPROPRED:+apt,+libs
#group Servers
127.0.0.1 unix
192.168.1.1 router
192.168.1.4 iLO
192.168.1.5 VMware Server
192.168.1.6 Webserver
192.168.1.7 SVN Server
192.168.1.8 Monitoring Server
192.168.1.9 Reverse Proxy
192.168.1.10 DNS Server
192.168.1.11 LTSP Server
#group Dialup
#0.0.0.0 notebook.bla.net # noconn dialup |
Hier definiert man unter #group Servers zuerst die IP, dann den Namen für die Beschreibung.
In der Datei /etc/hobbit/bb-services kann man Services definieren wie SSH, FTP, SMTP und vieles mehr. Die da angegebenen Standards sind für mich total ausreichend. Besonders interessant für mich, ist die Möglichkeit den ClamAV Daemon zu überwachen.
Wie sich aber die Services auch im Webfrontend anzeigen lassen, habe ich bis jetzt noch nicht herausgefunden.
Weiter gibt es noch die Möglichkeit, bei Fehlern Benachrichtigungen per Mail oder SMS zu versenden. Dazu kann man für jeden Service in der Datei /etc/hobbit/hobbit-alerts.cfg einen eigenen Verantwortlichen, die Alarmierungszeit, Mailadressen und vieles mehr definieren.
Danach zeigt einem das Webfrontend auf einen Blick für jeden Server genau an, welche Server, wo Probleme hat. Unterschieden wird dabei mit den Farben Rot, Violett, Gelb, Grün und Weiss den Zustand des Servers und diverse Symbole, welche angeben, ob ein Server erst seid kurzem oder schon länger Probleme hat.
Dazu werden automatisch Graphen mit Trends und anderen Informationen generiert. Und zu guter Letzt kann man auch noch Reports von Services und Funktionen über bestimmte Zeiträume erstellen.
Nun gilt es noch herauszufinden, wie sich Services überwachen lassen. Wer mir dazu also weiterhelfen kann, vielen Dank 
Vom 27.12. bis zum 30.12.2009 findet in Berlin der 26. Chaos Communication Congress statt. Der C3 ist ein jährlicher Kongress der jedes Jahr zwischen Weihnachten und Silvester im Berliner Congress Centrum (bcc) stattfindet und vom CCC veranstaltet wird. Auf diesem fehlen wir natürlich auch nicht, und so sind Fabian und Matthias dieses Jahr zum ersten Mal dabei. Heute am 26.12 reisen wir mit der Bahn an und sind ab dann in Berlin anzutreffen. Wer uns sucht, wir haben meist die roten Disfunctions.de Pullis an! Natürlich bloggen und twittern wir auch von dort und so haben wir extra verschiedene Sachen gebastelt um mit euch in Kontakt zu bleiben. Bloggen werden wir ganz normal im Blog, aber alles unter der Kategorie 26c3. Alle Artikel zum 26C3 werden auch noch auf der neuen Seite “26C3” gesammelt, damit alle die Übersicht behalten. Twittern werden wir wie gewohnt unter @DisfunctionsDE. Bei einem solchen Ereigniss dürfen natürlich auch Bilder nicht fehlen, die werfen wir alle samt auf Picasa. Ich hoffe das war jetzt alles und wir werden in den nächsten Tagen gute Inhalte liefern und ihr kommentiert viel. 
Den Sommer habe ich sehr genossen, da ich einfach Zeit hatte für Dinge, die ich schon immer mal machen wollte. Dazu zählten u.a. ein Camping-Urlaub mit meiner Frau und das Erlernen von Python. Aus letzterem ist dann ein kleines Projekt namens 
Das folgende Beispiel wurde unter Ubuntu Karmic Koala 9.10 und einer Entwicklungsumgebung für Android durchgeführt. Die Einrichtung einer Entwicklungsumgebung für Android unter Linux ist im Artikel 
Wird das Device nicht erkannt hilft ein Neustart der Android Debug Bridge. ($ <sdk>/adb kill-server)
