iRrdcached spart Zeit und Last

Die Monitoring-Software Munin [1] leistet mir seit Jahren treue Dienste. Die Werte, die Munin sammelt, landen auf einem zentralen Server in Round-Robin-Datenbanken (RRDs), wo sie in festgelegten Intervallen zu Graphen verarbeitet werden. Munin überwacht pro Maschine oft mehrere Dutzend Werte und in großen Setups nicht selten eine drei- oder vierstellige Anzahl von Servern.

Beim Aktualisieren Tausender RRDs steigt die I/O-Last auf dem Munin-Server problematisch an. Weil die Platten permanent ihre Schreib-Lese-Köpfe neu positionieren, um einige Bytes der RRD zu aktualisieren, dauert das Ganze lange und geht je nach Update-Intervall dann wieder von vorne los.

Beim anschließenden Neuzeichnen der Graphen spare ich etwas Zeit, indem ich dem Graph-Kommando den Parameter »"- - lazy"« übergebe. Unveränderte Graphen werden so nicht neu geschrieben.

Optimierter Zyklus

Auch für die zyklischen Aktualisierungen der RRDs gibt es Hilfe. Dafür muss RRD Tool ab Version 1.4 installiert sein sowie Rrdcached [2]. Die gängigen Linuxe haben Letzteres in der Regel als eigenständiges, von RRD Tool getrenntes Paket an Bord (Abbildung 2).

© © nito500, 123RFAbbildung 2: Die Last der Platten verringert Rrdcached.

Wird das Kommando zum Aktualisieren einer RRD ausgeführt (»rrdtool update ...« ), fängt Rrdcached diesen Aufruf ab und speichert die Daten in seinem RAM-Cache, der je nach Anzahl der RRDs entsprechend üppig sein sollte. Im Hintergrund läuft ein großzügig bemessener Timeout, um vor Ablauf jede RRD mehrmals zu aktualisieren. Rrdcached konsolidiert diese Aktualisierungen in seinem Cache und schreibt sie nach Ablauf des Timeouts gebündelt in die RRDs auf der Festplatte.

Wichtige Daten über längere Zeit nur im RAM zu speichern ist gefährlich. Rrdcached löst dieses Problem, indem es die Cachedaten regelmäßig in ein Journal auf der Platte schreibt. Die dabei entstehende Festplattenlast ist vernachlässigbar. Gesteuert wird Rrdcached über Kommandozeilenoptionen. Listing 1 zeigt einen typischen Aufruf.

01 rrdcached -s rrdtool -m 0660  -l unix:/var/run/rrdtool/cache.sock -P FLUSH,PENDING,STATS -l 192.168.10.10 -j /var/lib/rrcached/journal/ -F -b /var/lib/rrcached/db/ -B -w 1800 -z 1800

Mit dem Parameter »-s« lege ich die Gruppenberechtigung für den Unix-Domain-Socket fest, den Rrdcached benutzen soll, und verwende dafür die Gruppe »rrdtool« , die auf dem RRD-Tool-Server ohnehin existiert. Es lässt sich auch eine neue Gruppe, etwa mit dem Namen »rrdcached« anlegen, um Verwirrung zu vermeiden. Die Filesystem-Berechtigungen für den Socket legt der Parameter »-m« fest, bevor »-l« definiert, um welchen Socket es sich handelt.

Im Beispiel ist es ein Unix Domain Socket, dessen Pfad und Name »unix:/var/run/rrdtool/cache.sock« lautet. Entfällt die Angabe, würde Rrdcached den Unix Domain Socket »unix:/tmp/rrdcached.sock« benutzen. Das funktioniert, aber das »/tmp« -Verzeichnis ist zu sehr Spielwiese, um dort einen wichtigen Socket zu platzieren.

Neben dem Unix-Socket lässt sich zusätzlich ein Netzwerk-Socket etablieren, wie im Beispiel mit »-l 192.168.10.10« geschehen. Als Port dient standardmäßig UDP 42217. Auf ihn schicke ich verschiedene Kommandos, die das Verhalten von Rrdcached zur Laufzeit steuern. Die Manpage enthält eine Liste der Kommandos. »HELP« und »QUIT« sind selbsterklärend und werden immer akzeptiert.

Ansonsten sind weitere Befehle hinter dem Parameter »-P« explizit aufzulisten. Die Kommandos aus dem Beispiel: »FLUSH Dateiname« verschiebt die Updates für »Dateiname« an die erste Stelle der Update-Warteschlange. »PENDING Dateiname« gibt eine Übersicht über alle Updates für »Dateiname« aus, die in der Warteschlange noch ihrer Erledigung harren. »STATS« präsentiert eine Reihe statistischer Daten über die Arbeit von Rrdcached, darunter die aktuelle Länge der Warteschlange, die Anzahl erhaltener Updates, bereits erledigter Updates und die Größe des Journals. Hinter »-j« definiere ich den Pfad zum Journal.