Feinarbeit

Nachdem Cfgmaker die erste Version der Konfigurationsdatei »mrtg2.cfg« angelegt hat, müssen Sie sie noch von Hand editieren, um die Ressourcenstatistiken für CPU, Festplatte und Speicher zu konfigurieren. Das folgende Beispiel zeigt ein einfaches Template zur Erhebung der CPU-Statistik.

Die UCD-SNMP-MIB enthält eine ganze Reihe von leistungsbezogenen Variablen, die sich mit MRTG überwachen lassen. Werfen Sie doch mal einen Blick in die MIB-Definition [3], um zu sehen, was es alles gibt. Um einen Parameter wie die CPU-Auslastung der MRTG-Konfiguration hinzuzufügen, legen Sie dafür zuerst die beiden folgenden Verzeichnisse an:

mkdir /etc/mrtg
mkdir /etc/cron.mrtg

Dann erzeugen Sie eine Konfigurationsdatei namens »cpu.cfg« mit dem Inhalt aus Listing 1. Die Datei »/etc/cron.mrtg/cpu« ist ein Shellskript mit den folgenden Zeilen:

#!/bin/sh
/usr/local/mrtg/bin/mrtg /etc/mrtg/cpu.cfg

Nachdem Sie die Datei mit »chmod +x /etc/cron.mrtg/cpu« ausführbar gemacht haben, testen Sie sie mit »sh /etc/cron.mrtg/cpu« . Auftretende Warnungen können Sie getrost ignorieren, wenn das Skript ansonsten durchläuft. Schließlich können Sie aus den gesammelten Daten eine erste Indexdatei generieren:

indexmaker --output=/usr/local/apache2/↩
htdocs/mrtg/cpu_index.html --title="CPU Usage"↩
 --sort=name --enumerate /etc/mrtg/cpu.cfg

Konfigurieren Sie noch den Cron-Daemon so, dass er das eben geschriebene Shellskript regelmäßig ausführt, zum Beispiel als Administrator mit »crontab -e« :

*/5 * * * * /bin/run-parts /etc/cron.mrtg↩
 1 > /dev/null

Um das Polling-Intervall zwischen zwei Zeitpunkten der Datenerhebung festzulegen, tragen Sie die entsprechenden Aufrufzeiten in der systemweiten Crontab ein:

0,5,10,15,20,25,30,35,40,45,50,55 * * * *↩
 env LANG=C /usr/local/mrtg/bin/mrtg /usr/↩
 local/mrtg/cfg/mrtg2.cfg

Dieser Eintrag legt ein Fünf-Minuten-Intervall fest. Ohne einen solchen Cronjob zum Daten sammeln erhält MRTG keine Daten, mit denen es seine Graphen zeichnen kann. Sie können das Polling-Intervall nach Belieben anpassen, aber denken Sie daran: Je seltener MRTG die Daten sammelt, umso ungenauer wird der resultierende Graph.

Je nach Webserver-Setup müssen Sie beim Abruf der generierten Statistiken eventuell den ganzen Namen der von MRTG erzeugten Datei angeben. Im Beispiel wurden die Dateien alle im Verzeichnis abgelegt, das Sie mit der Option »Workdir« spezifiziert haben. Das Indexmaker-Tool hat eine Index-Datei »/usr/local/apache2/htdocs/mrtg/cpu_index.html« angelegt. Unter der URL »http:///mrtg/cpu_index.html« finden Sie dann den CPU-Graphen.

Interpretation

Den besten Gebrauch machen Sie von MRTG, wenn Sie regelmäßig die Graphen anschauen und im Lauf der Zeit ein Gefühl dafür entwickeln, wie sie im Normalzustand aussehen. Es ist auch eine gute Idee, eine Art Baseline-Graph zu erzeugen, der im Problemfall als Referenz dienen kann. Zum Beispiel zeigt Abbildung 1 eine Reihe von Servern unter normaler Belastung. Mehrere Server in einem Diagramm zusammenzufassen, ist ein Feature von RRDTool, dem Round Robin Database Tool, das ein nützliches Add-On zu MRTG darstellt.

Abbildung 1: Das CPU-Diagramm einer Gruppe von Servern bei normaler Belastung.

Gibt es einen systematischen Ausschlag, wie in Abbildung 2, liegt die Vermutung nahe, dass es sich zum Beispiel um ein Backup handelt, das um Mitternacht beginnt. Eine alternative Theorie wäre ein Angriff auf die Serverfarm. Um zwischen diesen beiden Szenarien zu entscheiden, vergleicht man den CPU-Graphen mit der Darstellung des Netzwerk-Traffic (Abbildung 3).

Abbildung 2: Ein erheblicher Ausschlag der CPU-Load gegen Mitternacht. Was ist passiert?

Abbildung 3: In der Netzwerkstatistik kommt es zu diesem Zeitpunkt zu keiner Abweichung von der Norm.

Der Netzwerk-Graph zeigt zu diesem Zeitpunkt keinen Ausschlag, sodass die Schlussfolgerung nahe liegt, dass es sich nicht um einen Angriff von außen handelt. Als nächster praktischer Schritt stünde die Untersuchung der Logdateien an, um festzustellen, ob zu diesem Zeitpunkt ein Batch-Job ablief.