Dienstag, 25. August 2009

Verteiltes Server-Monitoring: neighborhoodwat.ch

Erst vor wenigen Stunden im Netz aufgetaucht ist neighborhoodwat.ch (NHW). Einige Düsseldorfer haben die Idee eines verteilten Monitoring-Netzwerkes umgesetzt und bieten diesen interessanten Service an. Jeder, der einen Server überwachen lassen möchte, installiert auf einem seiner Server einen Agenten, der vom zentralen Server eine Liste mit URLs bekommt, die er fortan prüft. Aktuell bietet das System noch nicht viele Features. Es gibt z.B keine Historie. Aber mit einem derart verteilten Netz könnte man natürlich künftig interessante Aussagen über Performance und Verfügbarkeit aller Netze ermitteln, über die die Agenten verstreut sind.

Zur Prüfung meines Blogs, wollte ich den Service direkt mal ausprobieren. Zur Anmeldung kann man eine OpenID verwenden, die über viele Anbieter zur Verfügung steht. Da mein Blog über Google und Blogger läuft, lagen diese als IDs am nächsten. Aber leider bekam ich immer nur eine Fehlermeldung: Not found. Über den Twitter-Account der Betreiber (@thehoodwatch, @mutle) erfuhr ich dann, dass es noch Probleme gäbe und nur myOpenID aktuell sicher funktionieren würde.

Mit der OpenID von myOpenID funktionierte die Anmeldung dann ohne Probleme. Nach der Anmeldung landet man auf einer Übersichtsseite, die die überwachte Site und deren Staus anzeigt. Ohne Agenten tut sich hier aber noch nicht viel.

Für die Installation sind laut "Installationsbeschreibung" nur Ruby, Ruby Gems, Cron und natürlich ein NEIGHBORHOODWAT.CH-Account erforderlich. Darüberhinaus müssen noch gcc und g++ installiert sein, wenn Ihr wie ich Ruby selbst bauen wollt. Da auf dem Server noch kein Ruby installiert war, habe ich die Installation von Ruby (basierend auf Kates Gasis Anleitung) aber auf OpenSuSE 11 folgendermaßen durchgeführt:

wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p368.tar.gz
tar -xzf ruby-1.8.6-p368.tar.gz
cd ruby-1.8.6-p368/
./configure --prefix=/usr/local --enable-pthread \
--with-zlib-dir=/usr/local \
--with-readline-dir=/usr/local
make
sudo make install


Anschliessend musste noch Rubygems installiert werden. Es wird keine Version vorgegeben, also die aktuelle Version 1.3.5 verwenden:

wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz
tar -xzf rubygems-1.3.5.tgz
cd rubygems-1.3.5/
sudo ruby setup.rb


Jetzt sollte die Installation des Agenten folgen. Der liess sich leider auf der referenzierten Github-Seite (Liste der Gems) nicht direkt finden. Wie ich aus den Tweets von @mutle erfuhr, fehlte noch die Freigabe bei Github. Einige Stunden später lag der Agent in Version 0.0.7 via GitHub vor. Die Installation war noch ein wenig zickig, da die eventmachine in einer falschen Version gezogen wird, wenn man direkt den Agenten holen will. Deshalb zunächst die Gems eventmachine und json installieren:


sudo gem install eventmachine
sudo gem install json
sudo gem install mutle-neighborhoodwatch-agent \
--source=http://gems.github.com/


Über die WebSite von NHW musste nun noch der neuen Agent angelegt und über "Instructions" die ID des Agenten abgeholt werden. Nachdem die Gems installiert waren, konnte nun der Agent aufgerufen und die ID übergeben werden. Das funktionierte auf Anhieb. VORSICHT: Nach dem ersten erfolgreichen Aufruf kann man die ID nicht mehr über die WebSite von Neighborhoodwat.ch abrufen.

neighborhoodwatch-agent <agent id>

Nun noch der Eintrag in die crontab:

*/5 * * * * neighborhoodwatch-agent <agent id>

Der Prozess muss nicht mit Root-Rechten gestartet werden, so dass die ganze Installation mit einem unpreviligierten User möglich ist.

Bislang funktioniert die Benachrichtigung über Störungen nur per eMail. Ich hoffe, das die Ergänzung um Twitter als Meldekanal in Kürze nachgereicht wird.

Freitag, 14. August 2009

XP auf neuer Hardware installieren

Hätte nicht gedacht, dass ich über eine Windows-XP-Installation noch einen Blogeintrag schreiben würde. Leider hat mein alter APC seinen Geist aufgegeben. Ob nun eines der vielen Gewitter der letzten Wochen Schuld war, oder der lange Stromausfall mit vorhergehenden Netzstörungen, oder einfach nur die Hitze? Jedenfalls hatte ich den PC einige Wochen nicht genutzt. Und nun stand ein Spieleabend an, und da musste ein neues Gerät her. Zum Zocken habe ich mir also mit der Hilfe der PC Games Hardware-Zeitschrift einen neuen PC ohne Betriebssystem bei Alternate geordert. Schon 2 Tage später wurde das gute Stück geliefert. Vielleicht etwas naiv habe ich meine Windows XP Professional-CD eingeschoben und den Rechner eingeschaltet. Damit begann dann das Windows Abenteuer:

Schon während des Durchforstens der Treiber bei der Installationsvorbereitung verabschiedete sich diese mit einem BlueScreen und dem Hinweis, das der pci.sys-Treiber fehlerhaft sei:

Es wurde ein Problem festgestellt. Windows wurde heruntergefahren, damit der Computer nicht beschädigt wird.

[bla bla ...]

Technische Information:

*** STOP: 0x0000007E (...)

*** pci.sys - Address F748... base at F748..., DateStamp 3b...


Wahrscheinlich ein Treiberproblem. Also per Google nach der Fehlernummer gesucht und schnell fündig geworden. Es sollen also Chipsatzprobleme sein, die mit dem SP2 behoben sind. Gut das ich noch eine andere Installations-CD hatte, die schon SP2 beinhaltete. Also nochmal von vorne mit dieser CD. Damit ging es zwar etwas weiter, aber auch hier kam ein BlueScreen mit einer ähnlich kryptischen Fehlermeldung:

Es wurde ein Problem festgestellt. Windows wurde heruntergefahren, damit der Computer nicht beschädigt wird.

[bla bla ...]

Technische Information:

*** STOP: 0x0000007B (...)


Diese bedeutet, das XP das Boot-Device nicht finden kann. Also habe ich mein altes DVD-Laufwerk eingebaut. Damit kam ich dann endlich bis zum Willkommensbildschirm der Installation, um erneut zu scheitern, weil keine Festplatte gefunden wird.

Das Problem hier war dann die BIOS-Einstellung SATA-Laufwerke via AHCI anzusteuern, womit XP nicht von Haus aus umgehen kann. Man kann AHCI aber im BIOS abschalten. Daraufhin habe ich es wieder mit dem neuen DVD-Laufwerk probiert, und siehe da, das Problem löste sich damit ebenfalls und die Installation lief endlich durch.

Erst jetzt kam ich auf die Idee, das mit dem neuen PC ja auch eine Treiber-CD geliefert worden sein müsste. Dummerweise unterstützt die Installation von XP nur Treiber von Diskette. Und eine Floppy hat der neue Rechner natürlich nicht mehr.

Also alle Treiber unter XP von der CD installiert, insb. natürlich die Chipsatztreiber. Dann das System ausgeschaltet, eingeschaltet und im BIOS wieder umgestellt auf AHCI ... Klappte nicht! Der BlueScreen war so schnell wieder weg das ich nichts erkennen konnte. Also das automatische Neustarten nach einem BlueScreen abschalten und es erneut versuchen ... Die erwartete Fehlermeldung: XP kann das Boot-Device nicht finden. Schade. Also werde ich wohl erstmal AHCI abgeschaltet lassen, bis ich wieder Zeit habe das genauer zu untersuchen.

Über 60 Patches hat Microsoft auf Lager, die natürlich nur kleckerweise dargeboten werden und dann einen Neustart erfordern. Alles in allem werde ich beim nächsten mal die paar Euro für ein neues Betriebssystem nicht sparen.