Viele Auseinandersetzungen und sogar Entscheidungen im Bereich IT-Performance basieren nicht auf gemessenen und nachvollziehbaren Daten, sondern auf aktuellen Erlebnissen und subjektiven Eindrücken der Beteiligten. Ob beispielsweise ein Netzwerk mit 1000 angeschlossenen Geräten an seine Kapazitätsgrenze stösst oder nicht, kann man nicht entscheiden, indem beispielsweise der Firmenchef eine Powerpoint-Präsentation auf seinem Laptop öffnet und einem dann von seinem Performance-Eindruck berichtet. Um die Ursache für Performance-Probleme zu finden, müssen Leistungsdaten von den am Vorgang beteiligten Systemen verfügbar sein. Die Analyse dieser Daten erlaubt es dann festzustellen, wo welcher Anteil der Zeit verbraucht wird. Im Idealfall lässt sich eine Komponente identifizieren, die durch Umkonfiguration, Erweiterung oder Ersatz für das ganze System eine signifikante Leistungssteigerung bringt. Es wird sich auch zeigen, welche Komponenten am Problem nicht beteiligt sind. Diese Daten zu bekommen, verlangt jedoch einiges an Aufwand.
Die meisten Hard- und Softwarekomponenten, die heute eingesetzt werden, bieten die Möglichkeit, Performance- und Statusdaten abzufragen. Dabei kommt eine breite Palette von Schnittstellen zum Einsatz. Im Netwerkbereich ist SNMP populär. Dazu kommen weitere Standardschnittstellen wie WMI, aber auch einfache Log-Dateien oder applikationsspezifische Lösungen mit speziellen Performance-Abfrageagenten. Das Gemeinsame dabei ist, dass all diese Datenquellen regelmässig Informationen liefern: alle 5 Minuten die Anzahl Bytes, die durch ein Netzwerk-Interface gesendet wurden, alle 10 Sekunden die Prozessorauslastung oder alle 10 Minuten die Temperatur im Serverraum. Je kompletter das Bild werden soll, umso mehr Daten werden anfallen. Dabei sind nicht nur die aktuellen Daten relevant, sondern auch die jeweilige Daten-Geschichte. So kann es beispielsweise sein, dass heute morgen die CPU-Auslastung des Servers hoch ist, jedoch die Auswertung der Daten der letzten drei Monate zeigt, dass dieser Zustand erst dreimal für jeweils 2 Stunden vorgekommen ist und sich auch kein Trend erkennen lässt.
Im Bereich Performance-Monitoring existieren unzählige Lösungen. Teilweise wird hier sehr viel Geld verdient mit Systemen, die hübsch aussehen, jedoch im konkreten Fall nur wenig über die lokalen Gegebenheiten aussagen können, weil die Anbindung an die unternehmensspezifischen Systeme nicht möglich ist oder aus Kostengründen zurückgestellt wurde. In diesem Umfeld hat sich in den letzten Jahren eine grosse Zahl von Open-Source-Lösungen etabliert. Die meisten dieser Lösungen verwenden für die Speicherung und Darstellung von Daten die Software RRDtool (RRD steht für Round Robin Database).
RRDtool ist eine freie Software. Sie übernimmt die Aufgaben, die besonders aufwendig sind beim Schreiben von Monitoring-Software: einerseits die langfristige Speicherung der Daten und andererseits deren graphische Darstellung. Mit RRDtool ist es möglich, einen einfachen Netzwerkmonitor für ein Linux-System in 10 Zeilen Code zu schreiben. Abbildung 1 zeigt die Netzwerklast auf dem Webserver, der die Website von RRDtool hostet, erstellt von einem ebensolchen zehnzeiligen Skript.
Viele Systeme stellen heute Messdaten bereit. Oft gibt es dazu sogar eine kleine Graphik. Der Task-Manager auf Windows ist ein Beispiel dafür. Sollen die Daten jedoch über einen längeren Zeitraum erhoben werden, reicht dies nicht aus.
RRDtool ist spezialisiert auf die Speicherung und graphische Darstellung von Zeitreihen, im speziellen von Daten, die in mehr oder weniger regelmässigen Abständen anfallen. Also zum Beispiel alle 5 Minuten die verfügbare Netzwerkbandbreite. Die Speicherung von Zeitserien erzeugt oft grosse Datenmengen. Das macht deren Verwaltung aufwendig, insbesondere dann, wenn der zur Verfügung stehende Speicherplatz und die zur Auswertung benötigte Rechenleistung endlich sind.
Das Design von RRDtool geht davon aus, dass die Daten, je älter sie werden, immer weniger interessant sind. Konkret heisst das zum Beispiel, dass für heute und für die letzte Woche Werte mit einer Auflösung von 5 Minuten benötigt werden. Wenn jedoch Daten von vor drei Monaten analysiert werden, ein Wert pro Stunde ausreicht, um langfristige Trends zu erkennen.
Bei der Konfiguration einer RRD-Datenbank kann der Benutzer festlegen, wieviele Daten wie lange und in welcher Auflösung von RRDtool gespeichert werden sollen. Also zum Beispiel: 5-Minuten-Werte für einen Tag, den 30-Minuten-Durchschnitt für eine Woche, 2 Stunden für einen Monat und Tageswerte für drei Jahre.
Die internen Datenstrukturen von RRDtool sind so gebaut, dass der benötigte Speicherplatz für die Ablage der Daten gleich zu Anfang reserviert wird. Das heisst, eine RRD-Datenbank belegt immer gleich viel Speicherplatz. Da die Daten intern in zirkuläre Buffer gespeichert werden, bleibt zudem der Aufwand zum Eintragen neuer Werte konstant, unabhängig von der Grösse der Datenbank. Alte Werte werden zum konfigurierten Zeitpunkt automatisch mit neuen überschrieben (Round-Robin-Prinzip).
Sobald die Datenbank erstellt ist, können Daten darin gespeichert werden. Da die Regeln für die Speicherung und Konsolidierung der Daten beim Erstellen der Datenbank festgelegt wurden, ist das Speichern von Daten sehr einfach. Es müssen lediglich die Daten sowie der Zeitpunkt, zu dem sie erfasst wurden, an RRDtool übergeben werden. Der Rest läuft automatisch.
Nachdem das System mit Daten gefüllt ist, können mit der Graphikkomponente von RRDtool graphische Auswertungen erzeugt werden. Auch hier wurde darauf geachtet, dass der Prozess möglichst einfach vonstatten geht und der Benutzer nur da Hand anlegen muss, wo er mit den Standardeinstellungen nicht glücklich ist.
Was nötig ist, um den Netzwerkverkehr eines Linux-Rechners «von Hand» mit RRDtool zu überwachen, zeigt ein kleines Beispiel. Das Programm besteht aus drei Teilen. Der wichtigste Teil ist die Datenbank (siehe Kasten 1).
Diese heisst «net.rrd» und erwartet alle 60 Sekunden neue Messwerte. Die Daten kommen von zwei Datenquellen (DS, steht für Data Source) mit den Namen «in» und «out». Die Datenquellen sind zwei Netzwerkverkehrzähler. Um die genutzte Bandbreite zu erhalten, muss man RRDtool anweisen, die Ableitung der Zählerwerte (sprich deren Veränderung pro Zeiteinheit) zu speichern. Zusätzlich wird definiert, dass mindestens alle 70 Sekunden neue Werte in die Datenbank geschrieben werden sollen und dass gültige Messwerte der Bandbreite zwischen 0 und 100 Megabyte pro Sekunde liegen. Die «RRA»-Zeilen definieren, wie die Daten in der Datenbank aufbewahrt werden sollen. Die Zeilen lesen sich am besten von hinten: Es sollen 1500 Werte gespeichert werden. Jedes Mal, wenn ein 60-Sekunden-Wert ankommt, soll ein Wert gespeichert werden. Damit ein gültiger Wert gespeichert wird, muss mindestens die Hälfte der zugrundeliegenden Werte gültig sein. Die weiteren Zeilen sind nach demselben Schema aufgebaut, mit dem Unterschied, dass erst nach mehreren 60-Sekunden-Intervallen ein Wert geschrieben wird. Das Wort AVERAGE/MIN/MAX gibt die Funktion an, die angewendet werden soll, um aus mehreren ankommenden Werten den Wert zu berechnen, der in der Datenbank gespeichert wird.
Die RRD-Datenbank ist nun bereit, um Daten entgegenzunehmen. In unserem Beispiel verwenden wir Informationen aus dem Proc-Filesystem von Linux, die dynamisch und daher immer aktuell sind:
rrdtool update net.rrd N:`grep eth0: /proc/net/dev| sed ‚s/.*://‘| awk ‚{print $1“:“$9}‘`
Dieser etwas verschachtelte Einzeiler liest aus der Datei /proc/net/dev die relevanten Informationen über den Netzwerkverkehr der Linux-Maschine und formatiert sie passend für RRDtool.
Er verfüttert an die Datenbank net.rdd die aktuellen Werte der Netzwerk-Byte-Zähler. Der Buchstabe N steht für die aktuelle Zeit. An seiner Stelle ist es auch möglich, explizit die Zeit anzugeben zu der die jeweiligen Daten erfasst wurden. Die Update-Routine muss nun regelmässig alle 60 Sekunden aufgerufen werden, zum Beispiel mit einem entsprechenden Eintrag in die crontab. Kasten 2 zeigt, wie aus einer Datenbank eine Grafik erstellt werden kann. In der ersten Zeile wird der Name der Grafikdatei festgelegt (graphik.png). Die DEF-Zeilen definieren, welche Daten dargestellt werden sollen. Die LINE-Zeilen legen fest, dass die Daten als Linien gezeichnet werden sollen. Die Ausdrücke «#f00» und «#0f0» bestimmen die Farben der Linien. Das Resultat ist in Abbildung 1 zu sehen. Mit wenig mehr Aufwand lässt sich aus denselben Daten auch die Graphik in Abbildung 2 erzeugen. Sie enthält einen Titel, das aktuelle Datum und eine andere Darstellung der genutzten Bandbreite.
Weitere Beispiele sowie ein Verzeichnis von Software, die auf RRDtool basiert, hält die Projekt-Webseite oss.oetiker.ch/rrdtool/ bereit.
Tobias Oetiker (tobi.oetiker.ch) ist Autor von RRDtool und hat für seine Arbeit an MRTG und RRDtool den Sage Outstanding Achivement Award erhalten.
