omnomnom - Schwer Verdauliches (Teil 2/3)

Wie im letzten Teil angekündigt, hier die Auflösung, was das mit dem ntpd-Skript auf sich hat:

OMD: a new challenger appears

Irgendwann 2012 habe ich mich in einem (seltenen und komischen) Anfall von „keine Lust“ davor gedrückt, ein neues RRD-Skript zur Überwachung meines NTP-Dämons zu schreiben. Kurz darauf stand ein „schau Dir mal OMD an, das kann das“ im Raum. OMD ist eine Monitoring-Distribution, die sich aus diversen Einzelkomponenten wie Nagios, Icinga und check_mk zusammensetzt, einen eigenen Webserver, Alerting und einiges mehr mitbringt. Das ganze ist definitiv „datacenter grade“, natürlich mit eigener Benutzerverwaltung, man kann auch Schichtpläne für „wer wird wann benachrichtigt“ und geplante Ausfallzeiten („Server X kriegt heute Nacht mehr Speicher, bitte nicht den Notdienst rauspiepen, wenn der offline geht“) hinterlegen.

Kurz: Der totale Overkill für meine paar Rechner! Aber klicki, bunti und was zum Basteln – nicht zum Programmieren, aber zum Konfigurieren.

Ich bin mit OMD nie ganz warm geworden, da es viel zu mächtig und kompliziert war, trotzdem hat es sich rückblickend erschreckend lange gehalten (ganze fünf Jahre). Die ganze Zeit über habe ich meine RRD-Skripte weiter gepflegt und genutzt und vermutlich auch viel öfter angeguckt als die OMD-Statistiken. Das folgende Zitat stammt von ganz oben auf der OMD-Seite in meinem internen Notizen-Wiki (der OMD-Artikel ist mit 35% Vorsprung der längste Artikel im ganzen Wiki …):

Warum zum Henker habe ich mir das eigentlich alles ans Bein gebunden? Ich wollte mir die vermutlich 3 Stunden Programmieraufwand sparen, für meine NTP-Genauigkeit (Parsen von ntpq -p) ein neues RRD-Skript zu bauen. Stattdessen habe ich jetzt 30 Stunden in OMD investiert und verbrenne obendrauf Tonnen an Energie mit unnützer Netz- und CPU-Last.
~~mitch

gefühlte Komplexität

OMD (und z.B. auch der TeamSpeak-Server) hinterlassen bei mir irgendwie das Gefühl absichtlicher Komplexität: „Seht her, hier ist unser tolles Projekt, das ist natürlich OpenSource und hier ist Doku, das kann jeder nutzen – aber wir wissen genau, dass die Doku nicht reicht. Aber keine Angst, wir bieten auch Beratung auf Stundenbasis an. Haben wir schon erwähnt, dass ihr das Full-Service provisioniert und betreut bei uns hosten lassen könnt? Und ein Buch haben wir auch geschrieben…“

Das ist jetzt überspitzt dargestellt und auch nur persönliches Empfinden. Beide Produkte sind zugegeben sehr komplex. Aber komplex ist z.B. Exim auch (und ich habe hier eine viel zu komplexe Konfiguration für nur zwei popelige User laufen) – aber da habe ich dieses komische Gefühl der „absichtlichen Komplexität“ gerade nicht. Vielleicht ist einfach die Doku besser oder es gibt mehr Tutorials im Internet. Gleiches gilt für R: Ich habe in meinem Leben bisher ein einziges, nicht ganz kleines R-Skript mit tatkräftiger Unterstützung von Google und Stackoverflow zusammengebastelt. Ich bin nicht in der Lage, auf mich alleine gestellt irgendwas sinnvolles zu tun. Aber ich habe das Gefühl, dass das Internet voll von guten Tutorials und Uni-Kursmitschriften ist, die ich nur lesen müsste, wenn ich wollte. Falls es sowas für OMD auch gibt, habe ich es nie gefunden.

(Ich will das Geschäftsmodell von OMD und TeamSpeak nicht schlechtreden^[1], das sollen die mal ruhig so machen und wenn sie das für den „kleinen User“ frei verfügbar machen, ist das toll – aber das spricht mich halt irgendwie nicht an. Ist einfach eine Nummer zu groß für mich.)

der Anfang vom Ende

Das Fass zum Überlaufen gebracht haben letztendlich zwei Dinge:

1. Beim Debian-Update auf Stretch gab es extreme Probleme, weil man dafür die OMD-Version erneuern musste, die neue Version aber für 32bit gar nicht mehr vorhanden war. OMD ist immer etwas zickig beim Update (Dritthersteller-Repository), aber das war echt übel diesmal. Letztendlich musste ich das dpkg-prerm-Skript patchen, um das OMD-Paket deinstallieren zu können und irgendwie mit dem Systemupdate durchzukommen.
2. Danach habe ich mein System endlich mal auf 64bit umgestellt (ich war seit Jahren mit 64bit-Kernel und 32bit-Userland „weil ich nicht neu installieren wollte“ unterwegs – das heutige System hat früher mal auf einer 32bit-CPU gewohnt). Das war zwar auch abenteuerlich, die Umstellung lief aber letztendlich recht reibungslos (für einen Blogartikel dazu war leider keine Zeit, googelt nach Debian Crossgrade). Danach habe ich das 64bit-OMD in neuer Version installiert und es lief auch. Aber dann waren natürlich alle RRD-Datenbanken kaputt, weil die architekturspezifisch gespeichert werden. Anders als bei meinen eigenen RRD-Skripten reicht es auch nicht aus, die .rrd-Dateien einfach zu löschen, damit sie unter Verlust der alten Daten automatisch leer neu angelegt werden: OMD hat nach der Löschung der RRDs einfach nur andere Fehler als vorher geworfen. Auf die Schnelle nichts dazu gefunden, also stand ich mal wieder im Regen.

Jahrelang genug geärgert, guter Punkt für einen Schlussstrich: Dann habe ich OMD endgültig deinstalliert. Von dem anderen Server auch. Netter Nebeneffekt: Die Systemlast auf allen beteiligten Systemen ist deutlich runtergegangen. Außer sich selbst zu monitoren haben die nicht viel gemacht.

Und was dann passierte, erzähle ich euch beim nächsten Mal.