Netz - Rettung - Recht (Artikel mit Tag munin)

Munin auf einen anderen Host umziehen

nospam@example.com (Thomas Hochstein) — Sat, 15 Jan 2011 22:40:00 +0000

Munin-Laufzeiten - vorher und nachher.

Über die Einrichtung des Monitoring-Tools Munin habe ich bereits vor 2 Jahren geschrieben. Mittlerweile habe ich meine Installation aus den Debian-Backports auf die Version 1.4.5 geupdatet, die deutlich ressourcenhungriger zu sein scheint; überdies sind mittlerweile auch mehr Hosts durch Munin zu überwachen. Beides führte zu einer spürbaren Grundlast auf dem (älteren) System, das bislang den Munin-Server darstellte; daher habe ich Munin nunmehr auf eine andere Maschine umgezogen, was deutlich sichtbare Performance-Verbesserungen gebracht hat, die sich schon in einer Laufzeitverkürzung darstellen.

Bei dem Umzug sollten aber auf jeden Fall die bereits erstellten Statistiken aus den letzten beiden Jahren erhalten bleiben, um nicht komplett von vorne beginnen zu müssen. Eigentlich sollte ja nichts leichter als das sein: Munin auf dem neuen Rechner installieren, die Konfiguration des alten Systems übernehmen, das neue System auf allen Nodes für den Abruf freischalten, testen, dann die gesammelten Daten auf dem alten Rechner packen, auf den neuen transferieren und dort wieder auspacken, Munin auf dem alten Rechner anhalten, fertig. Ungefähr so geht das auch tatsächlich - wenn denn diebeiden Systeme dieselbe Architektur haben. Wenn aber der alte Rechner ein 32bit-System ist und der neue ein 64bit-System, dann sind die erzeugten RRD-Dateien nicht kompatibel. Autsch. Aber auch dafür gibt es glücklicherweise eine Lösung, die ich einem alten Eintrag aus dem Cacti-Forum abgeschaut habe.

Insgesamt sieht der Ablauf dementsprechend tatsächlich so aus:

Munin auf dem neuen Rechner installieren
Konfiguration des alten Rechners übernehmen
Achtung! Falls auf dem alten Rechner "127.0.0.1" in einer Host-Definition stand, muß das auf dem neuen Rechner angepaßt werden, sonst werden die Graphen für die alte Maschine mit den Daten der neuen Maschine fortgeführt!
auf allen Nodes den Zugriff von der neuen Maschine aus freischalten
Munin auf der neuen Maschine testen
auf der alten Maschine die RRD-Dateien dumpen (ggf. kann man das auch rekursiv machen, wenn erforderlich):

cd /var/lib/munin/my.host.group
for i in *.rrd; do rrdtool dump $i > $i.xml; done
cd ..
tar -czf munin-data.tgz my.host.group/*.xml
# transfer munin-data.tgz to the new host
rm -f my.host.group/*.xml

auf der neuen Maschine die RRD-Dateien neu erzeugen:

cd /var/lib/munin
# copy munin-data-tgz here
tar -xzf munin-data.tgz
cd my.host.group
for i in *.xml; do A=`echo $i|sed ‘s/.xml//’`; rrdtool restore -f $i $A; done
rm *.xml
cd ..
rm munin-data.tgz

Munin auf der neuen Maschine erneut testen
Munin auf dem alten Rechner deaktivieren (Cronjob entfernen)

Fertig.

Update vom 20.01.2011: Die Performance-Verbesserung ist verblüffend.

CPU-Last auf der alten Maschine

CPU-Last auf der neuen Maschine

Load auf der alten Maschine

Load auf der neuen Maschine

Munin: Limits und Notifications

nospam@example.com (Thomas Hochstein) — Thu, 21 Jan 2010 20:56:00 +0000

Eines muß ich von den Basteleien aus der letzten Woche bzw. vom Sonntag noch nachtragen: ich habe bei meinem vor ungefähr einem Jahr installierten Munin die Mailbenachrichtigungen aktiviert und die Limits für "warning" und "critical" entsprechend angepasst, soweit das erforderlich war. Jetzt werde ich über Probleme ggf. alle 5 Minuten - nach jedem Munin-Poll - per E-Mail informiert.

Die Konfiguration ist hinreichend einfach. Zunächst sind die Benachrichtigungen auf dem zentralen Munin-Host im globalen Bereich der /etc/munin/munin.conf zu konfigurieren, für Benachrichtigungen per E-Mail bspw. so:

contact.thomas.command mail -s "Munin notification ${var:host}" thomas@provider.example
contact.thomas.always_send warning critical

Es können verschiedene Benachrichtigungsziele (Kontakte) definiert werden, wenn bspw. je nach Host unterschiedliche Ansprechpartner zu benachrichtigen sind; hier habe ich das Ziel "thomas" konfiguriert durch Angabe eines Betreffs und einer Zieladresse und der Zustände, bei denen Benachrichtigungen versandt werden sollen.

Danach können pro Host(gruppe) die zu verständigenden Kontakte definiert werden:

[host.domain.example]
contacts <em>thomas</em>

Zu verwenden ist natürlich einer der zuvor definierten Kontakte, hier eben "thomas". An diesen Kontakt werden dann die entsprechenden Benachrichtigungen versandt.

Sinnvollerweise sollten - ebenfalls pro Host - die nicht passend gesetzten oder gar aufgrund von Konfigurationsproblemen völlig unsinnig gesetzten Limits korrigiert werden durch Einfügen von Zeilen wie

sensors_temp.temp2.warning 55
sensors_temp.temp2.critical 65

oder ähnlich. Wo Handlungsbedarf besteht, erkennt man ganz einfach am Mailbombardement nach der Aktivierung der Benachrichtigungen.

Natürlich können Benachrichtigungen nicht nur per E-Mail versandt werden. Für die Einzelheiten verweise ich auf die Munin-Dokumentation.

Munin-Plugin und BIND 9.5.1 revisited

nospam@example.com (Thomas Hochstein) — Mon, 18 May 2009 05:40:00 +0000

Ich hatte bereits geschildert, daß das Munin-Plugin für BIND nicht mit dem Format der Statistikdatei von BIND 9.5.x umgehen kann, und auch eine Lösung vorgeschlagen, die bei mir dafür gesorgt hatte, daß die Lücke in den Munin-Daten für BIND sehr schmal blieb. Leider mußte ich jetzt - nachdem ich, bedingt durch Zeitmangel, erst nach längerer Zeit wieder einmal einen Blick auf diese spezielle Grafik werfen konnte - feststellen, daß sich ein neues, bald zwei Wochen messendes Loch aufgetan hat.

Der Grund ist einfach: BIND 9.5.1 schreibt die Statistikdatei nicht immer wieder neu, sondern hängt die neuen Informationen am Ende an. So wird die Datei immer länger; hier waren es jetzt > 33 MB. Und da das Munin-Plugin die Datei schlicht zeilenweise liest und dabei auf das (letzte) Auftreten bestimmter Schlüsselbegriffe achtet, um die entsprechende Zeile dann auszuwerten, dauert das ab einer gewissen Dateigröße einfach so lange, daß dabei ein Timeout des entsprechenden Plugins entsteht.

Weiß jemand zufällig, ob man BIND 9.5.1 beibringen kann, die Statistiken wie früher immer neu zu dumpen, statt sie an die alte Datei anzuhängen? Sonst wird sich wohl ein Cronjob der Sache annehmen müssen, der die Datei rotiert - oder regelmäßig löscht.

Debian Lenny und Munin

nospam@example.com (Thomas Hochstein) — Thu, 16 Apr 2009 18:33:00 +0000

Beim Upgrade eines Systems, auf dem ein Munin-Client läuft, von Debian Etch auf Debian Lenny sind ggf. einige Handgriffe nötig, damit Munin weiterhin ordnungsgemäß funktioniert.

Zum einen muß ggf. für die Apache-Statistiken der Konfigurationseintrag für mod\_status (wieder) ergänzt werden, weil er von der apache2.conf in die Modulkonfiguration in mods-available/status.conf umgezogen ist. "Allow from localhost 127.0.0.1" sollte sich dort finden, und ggf. "ExtendedStatus On".

Problematischer ist das Update von BIND auf Version 9.5.1; im Debian-Paket gibt es zwar ohnehin kein Plugin für den Nameserver, aber wer bisher das bind\_-Plugin von MuninExchange verwendet hat, stößt auf das Problem, das dieses nicht mit BIND 9.5.x kompatibel ist. Der Grund dafür liegt in dem unterschiedlichen Format der von BIND erzeugten Statistikdatei. Die neue Version ist da viel ausführlicher, hat aber eben auch ein ganz anderes Format.

Daher habe ich das Plugin quick’n’dirty auf das neue Format umgeschrieben. Ob es überhaupt noch möglich ist, die Statistiken nur für bestimmte Domains zu sammeln, wie es das bind\_-Plugin anbietet, weiß ich nicht; dieses Feature habe ich nicht benutzt. Jedenfalls kann man mit dem "neuen" Plugin nahtlos an die alten Munin-Graphiken anschließen; daher sammelt es auch nur (genau) die Daten, die auch das alte Plugin angeboten hat, auch wenn das neue Statistik-Format ggf. weitergehende Informationen bereit hält (mit einer Ausnahme: die Referrals scheinen nicht mehr geloggt zu werden). Meine Lösung ist nicht von der Perfektion weit entfernt, schon deshalb, weil sie teilweise Werte etwas willkürlich auf die alten Kategorien mappt (bspw. bei "failures"), aber es tut, und wie meine Graphen zeigen, sind die Werte von der Größenordnung her vergleichbar mit den früher erfassten. Dass BIND 9.5.x die Statistikdatei im übrigen nicht - wie offensichtlich früher der Fall - überschreibt, sondern die neuen Werte jeweils anhängt, stört gleichfalls nicht, weil das Plugin immer nur den letzten Match auswertet.

Wenn jemand Interesse daran hat - oder sich um eine Verbesserung kümmern möchte, für die mir momentan die Zeit fehlt, kann er sich das Plugin bind95 gerne herunterladen; Kommentare sind willkommen.

Wer seine bisherigen Munin-Graphen nahtlos weiterführen will, muß dafür sorgen, daß der symbolische Link - oder die Datei - in /etc/munin/plugins/ denselben Namen ("bind\_") wie bisher trägt, oder die Datensammlungen in /var/lib/munin/$DOMAIN/ entsprechend umbennen, d.h. von /var/lib/munin/$DOMAIN/$HOST-bind\_-\*.rrd nach /var/lib/munin/$DOMAIN/$HOST-bind95-\*.rrd. Und, wie immer: ein Backup schadet nicht …

Servermonitoring mit Munin

nospam@example.com (Thomas Hochstein) — Sat, 21 Feb 2009 21:19:00 +0000

Jetzt hat es dieses Wochenende doch geklappt, wenigstens eine der mittlerweile gesammelten neuen Ideen einmal umzusetzen und sowohl auf meiner heimischen Allroundkiste als auch auf den von mir betreuten Servern das Monitoring-Tool Munin, benannt nach einem der Raben des Göttervaters Odin, zu installieren, das mit Hilfe von Plugins aus verschiedenen Quellen Daten sammelt und diese dann in täglichen, wöchentlichen, monatlichen und jährlichen Graphen aufbereitet. Zwar ist das eine oder andere sicherlich noch zu tun, die Darstellung zu optimieren, vielleicht die Menge der Datenquellen nach dem ersten Enthusiasmus etwas zu begrenzen und fortgeschrittene Aufgaben wie das Erstellen von Summenübersichten einmal auszuprobieren, aber bisher gefällt mir das schon sehr, sehr gut - und erfüllt zudem einen lange gehegten Wunsch. Schon seit Jahren hätte ich auch gerne so hübsche Bilder und Statistiken - ganz zu schweigen von der Nutzbarkeit dieser Darstellungen einerseits für einen generellen Überblick über die Be- und Auslastung der Maschinen und andererseits zur Aufklärung sonst ungeklärter Abstürze, Fehler und Probleme:Wie oft läßt sich aus Logfiles nicht wirklich klar erkennen, warum eine Maschine sich weggehäng hat? Wenn das letzte, was man von ihr sieht, bspw. eine steil steigende Kurve bei Load, Speicherauslastung, Temperatur oder sonstwas ist, weiß man zumindest schon einmal, in welche Richtung man suchen kann.

Möglicherweise ergibt sich auf diese Weise auch schon ein Anhaltspunkt für die neuerdings regelmäßig (?) nach dem Ausfall der heimischen Außenanbindung auftretenden Netzwerkturbulenzen, die ich schon geschildert habe:

Wackelnetz?

Ein störungsfreies Netz ist jedenfalls sicher etwas anderes …

[Aktualisiert.]