Munin hat speziell mich die letzten zwei Wochen auf Trab gehalten, seitdem unsere Testserver für die neuen Softwarekomponenten auf Fedora 21 umgestellt wurden. Jeden Tag haben wir hunderte Emails von Munin bekommen, daß alles auf dem Server ok wäre. Eine Konsultation mit den Entwicklern von Munin brachte nur ein „Kann ich nicht reproduzieren“ hervor, ja.. also.. kann passieren 😉
Da mir das nun langsam auf die Nerven gegangen ist, habe ich mich dann selbst an Munin versucht.
Das Problem
Das DiskFree Modul und die DiskFree-Inodes Modul von Munin ( kurz df und df_inode) gehen die Liste von Filesystemen eines Servers durch und prüfen, ob diese voll oder fast voll sind. Dabei wird scheinbar alles geprüft, was irgendwie ein Filesystem ist, selbst romfs, ramfs und debugfs, die ja nun keine echten Filesysteme mit möglichen Belegungsproblemen sind. Komischerweise schickte uns Munin immer nur OK Meldungen, aber keine Warnmeldungen zu df und df_inode zu. Die Filesysteme auf den Servern hatten zudem auch gar keine Belegungsprobleme, trotzdem haben wir alle 15 bis 30 Minuten so eine Email bekommen.
testdomain.de :: testdomain.de :: Inode usage in percent OKs: /run/user/0 is 0.00, /sys/fs/cgroup is 0.01, /opt/root/dev/shm is 0.00, /run is 0.88, / is 3.78, /run/user/496 is 0.00, /dev/shm is 0.00, /dev is 0.24.
Die Analyse
Munin bietet zwar von Haus aus Debugfunktionen an, aber keine führte zum Ziel. Damit man Munin debuggen kann, muß man zunächst zum Munin User werden, der „normalerweise“ keine Shell hat, damit man sich nicht einloggen kann:
# su munin -s /bin/bash
Dann gibt mal als erstes mal munin-limits ein, um sich einen Überblick zuverschaffen.
# /usr/share/munin/munin-limits --debug
pre>2014/12/22 15:41:19 [DEBUG] processing critical: _dev_xvda1 -> : 98
2014/12/22 15:41:19 [DEBUG] processing warning: _dev_xvda1 -> : 92
2014/12/22 15:41:19 [DEBUG] processing unknown_limit: _dev_xvda1 -> 3
2014/12/22 15:41:19 [DEBUG] processing field: localhost::localhost::df::_dev_xvda1
2014/12/22 15:41:19 [DEBUG] field: $VAR1 = {
‚#%#name‘ => ‚_dev_xvda1‘,
‚critical‘ => ’98‘,
‚graph_data_size‘ => ’normal‘,
‚label‘ => ‚/‘,
‚update_rate‘ => ‚300‘,
‚warning‘ => ’92‘
};
2014/12/22 15:41:19 [DEBUG] value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
2014/12/22 15:41:19 [DEBUG] generating service message: localhost::localhost::df
2014/12/22 15:41:19 [DEBUG] Contact list for localhost::localhost::df:
2014/12/22 15:41:19 [DEBUG] processing service: fw_conntrack
2014/12/22 15:41:19 [DEBUG] state_file: /var/lib/munin/state-localhost-localhost.storable
Das obige Beispiel ist natürlich nur ein Ausschnitt, im Normalfall kommen dort Dutzende verschiedene Werte zur Ausgabe. Interessant ist diese Zeile:
value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
Der Wert des Feldes „df“ war 22.62 % für /dev/xvda1 ( unsere Rootpartition ). Eine Warnung gibt es bei 92 % Belegung und einen Critical ab 98%. In diesem Beispielfall kommt also keine Email zustande, weil alles im Toleranzbereich ist.
Munin schickt laut Sourcecode nur dann noch Emails, wenn sich der Zustand geändert hat, also z.b. vorher Critical war und dann bei nächsten Check wieder OK ist. Genauso in die andere Richtung ( ok -> fail ).
d.h., wenn Munin keinen anderen tieferen Bug hat, muß es so einen Wechsel festgestellt haben und da die Platte als Quelle ausschied, weil dich dort nicht geändert hat, mußte die Warnung für ein anderes Filesystem gekommen sein, auch wenn man das nicht gesehen hat. Allzuviele kommen da nicht in Frage:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/xvda1 78G 17G 58G 23% /
devtmpfs 490M 0 490M 0% /dev
tmpfs 500M 0 500M 0% /dev/shm
tmpfs 500M 3,1M 497M 1% /run
tmpfs 500M 0 500M 0% /sys/fs/cgroup
tmpfs 500M 4,0K 500M 1% /opt/root/dev/shm
tmpfs 100M 0 100M 0% /run/user/0
Scheinbar hatten sich die Ausgaben für tempfs und devtempfs von Fedora 20 zu Fedora 21 verändert,
was Munin verwirrt hat.
Die Lösung
Nach einigen Tests gelang es mir dann, Munin zur Aufgabe zu bewegen.
Dazu muß man in der plugin-conf für df das devtempfs und das tempfs excluden. Es macht sowieso kaum Sinn ein Ramlaufwerk zu checken, da Ramlaufwerke i.d.R. immer zu 100% voll sind, außer man hat ein fixed Ram-Drive gewählt.
# cat /etc/munin/plugin-conf.d/df
[df*]
env.exclude none unknown iso9660 squashfs udf romfs ramfs debugfs binfmt_misc rpc_pipefs fuse.gvfs-fuse-daemon tmpfs devtmpfs
Das alleine half aber nur bei dem Wert für df, df_inode sendete fleißig weiter OK Meldungen. Wie sich dann herausstellte, kann man auch für das df_inode eine eigene Configdatei ablegen. Dazu braucht man nur die df Datei zu kopieren „cp df df_inode“ und dann das System neustarten : systemctl restart munin-node . Den letzten Schritt sollte man nicht vergessen, denn auch wenn Munin alle 5 Minuten vom Cron gestartet wird, heißt das nicht, daß die Limits dann eingelesen werden, da die Node als eigener Prozess läuft.