© ratselmeister, 123RF

Wer die Performance eines Rechnerclusters oder einer Applikation untersuchen soll, der muss Daten sammeln und sie nach Möglichkeit auch grafisch aufbereiten, um schnell und sicher Zusammenhänge zu erkennen. Ein Tool für diesen Zweck hebt sich aus der Masse ab: Graphite.

Chris Daviz hat Graphite [1] im Jahre 2006 als ein Nebenprojekt bei der Firma Orbitz entwickelt. Zwei Jahre später gab er das Toolset dann unter der Apache-2.0-Lizenz frei. Graphite eignet sich insbesondere für Zeitreihendaten. Das können Performancedaten verschiedener Server sein, es lassen sich aber auch Messwerte aus eigenen Applikationen auf einfache Weise verarbeiten.

Für ein paar wenige Metriken lohnt sich der Aufwand womöglich nicht. Spätestens aber, wenn Hunderte unterschiedlicher Datenquellen zu bearbeiten sind, zeigt Graphite seine wahre Stärke. Das Zusammenspiel der verschiedenen Komponenten ergibt eine gut skalierbare Architektur, die auch mal den Ausfall eines Servers verkraftet und dennoch eine große Anzahl Messwerte speichern, verdichten und visualisieren kann.

Hingegen ist Graphite nicht dafür geschaffen, die Daten selbst zu erfassen. Zum Glück gibt es aber schon eine ganze Reihe anderer Tools, die das zuverlässig erledigen und sich mit Graphite integrieren lassen. Mit wenig Aufwand kann Graphite nahezu beliebige Zeitreihendaten entgegennehmen.

Strukturiert

Graphite besteht aus mehreren Komponenten (Abbildung 1), die jeweils eigene Aufgaben erfüllen. Das Gesamtbild mit seinen vielen Teilen mag zu Beginn etwas komplex erscheinen, es werden aber nicht von Anfang an alle Bestandteile zwingend benötigt. Die Vorteile der Aufteilung zeigen sich spätestens dann, wenn man seine Systeme im Hinblick auf Ausfallsicherheit und Lastverteilung erweitern möchte. Die einzelnen Komponenten sind:

Abbildung 1: In einem Graphite-System teilen sich mehrere Komponenten in die Aufgabe, beliebige Zeitreihendaten zu speichern und zu visualisieren.

• Carbon oder auch Carbon Cache genannt bildet in Standardinstallationen die erste Anlaufstelle. Sie empfängt die Daten, die andere Programme gesendet haben. Der Daemon lauscht auf einem festgelegten Port und lässt sich entweder via UDP oder TCP ansprechen. Die Daten kommen entweder als Plaintext oder im so genannten Pickle-Format herein. Letzteres wird von Programmen genutzt, um mehrere Datensätze gleichzeitig zu senden. Eine weitere Möglichkeit stellt die Kommunikation mittels AMQP dar, das sich im Prinzip genauso wie das Plaintext-Protokoll verhält.
• Whisper ist die Storage-Engine, in die Carbon die empfangenen Daten speichert. Whisper verhält sich sehr ähnlich wie das allseits bekannte RRD. Warum verwendet man dann nicht gleich RRD? Weil ihm die Fähigkeit abgeht, Daten mit Zeitstempeln aus der Vergangenheit einzufügen. Mit dem in Python geschriebenen Nachbau Whisper wird das Problem zwar umgangen, doch leidet die Performance etwas darunter.
• Graphite Web ist für die Visualisierung der Daten zuständig, eine Webapplikation, die auf Django und Ext JS basiert. Graphite Web ordnet die Daten in Verzeichnisstrukturen. Mit Wildcards kann man verschiedene Graphen gleichzeitig anzeigen, die Vielfalt der integrierten Funktionen erlaubt es, die Darstellung sehr spezifisch anzupassen. Eigene Dashboards und Templates lassen sich erstellen und dauerhaft speichern.
• Carbon Relay fungiert als Vermittlungsstelle und kann anstelle von Carbon Cache die Daten entgegennehmen. Im Anschluss schickt die Komponente sie dann an einen oder mehrere Server weiter, an denen wiederum ein Carbon Cache lauscht. Um das endgültige Ziel für bestimmte Daten festzulegen, konfiguriert der Admin Regeln, die bestimmen, wohin die Daten weitergereicht werden. Alternativ kann man auch eine Liste von Hosts hinterlegen, unter denen Carbon Relay die Daten dann selbst verteilt. Diese Methode hilft etwa beim Aufbau einer ausfallsicheren oder lastverteilenden Architektur.
• Carbon Aggregator kann als eigener Listener neben Carbon Cache agieren oder diesen auch komplett ersetzen. Je nach Regelsatz aggregiert er mehrere Datenpunkte bereits vor dem Speichern. Beispielsweise kann er die Anzahl von Requests verschiedener Webserver als Summe abspeichern. Solche Regeln verbessern nicht nur die Performance beim Schreiben der Daten, sondern auch beim späteren Visualisieren mit Graphite Web.

In der Standardinstallation werden die drei Komponenten Carbon Cache, Python Whisper und Graphite Web eingerichtet. Für eine mittelgroße Umgebung würde das sogar für den Produktivbetrieb ausreichen.

Klein beginnen

Leider bieten selbst viele große Distributionen nicht für alles fertige Pakete an, daher installieren viele Admins Graphite mit Hilfe der Source-Tarballs. Für diese Art der Installation spricht außerdem ihre Simplizität. Dank der mitgelieferten Setup-Skripte in den einzelnen Python-Projekten reicht für jede Komponente schon ein einzelner Befehl aus, um sie zu installieren.

Doch leidet bei diesem Verfahren die Wartbarkeit. Daher kommt im Folgenden die Installation unter der aktuellen Ubuntu-Version 14.04 LTS zum Zuge. Alle Pakete, die eine Grundinstallation benötigt, stehen in deren Repositories zur Verfügung.

Der erste Schritt sorgt dafür, dass Graphite Daten entgegennimmt und speichern kann. Diese zwei Aufgaben erledigen der Carbon Cache und die Storage-Engine Whisper im Zusammenspiel. Die Installation erfolgt in drei Schritten: Zunächst installiert der Admin die Software, danach muss er Carbon noch aktivieren und starten. Zum Speichern der Daten in Whisper ist keine manuelle Konfiguration notwendig, die Standardkonfiguration bringt bereits alles Notwendige mit:

apt-get install graphite-carbon python-whisper
vim /etc/default/graphite-carbon
# CARBON_CACHE_ENABLED=true
service carbon-cache start

Der Daemon lauscht anschließend auf den beiden Ports 2003 und 2004. Der erste hört auf das Plaintext-, der zweite auf das Pickle-Protokoll.

Graphite Web präsentiert ein paar mehr Abhängigkeiten. Die mit Hilfe des Django-Framework programmierte Weboberfläche benötigt neben einem Apache2-Webserver auch das zugehörige WSGI-Modul. Nach der Installation – samt Abhängigkeiten – muss der Admin die Webserver-Konfiguration manuell kopieren und aktivieren. Damit die Standardseite von Apache2 ihm nicht in die Quere kommt, schaltet er sie im Voraus ab (Listing 1).

01 apt-get install graphite-web apache2-mpm-prefork libapache2-mod-wsgi python-sqlite python-yaml
02 cp /usr/share/graphite-web/apache2-graphite.conf  /etc/apache2/sites-available/graphite.conf
03 a2dissite 000-default
04 a2ensite graphite
05 a2enmod wsgi

Das Webinterface benötigt für die Benutzer-Authentifizierung eine Datenbank. Sie speichert neben den Benutzern auch Dashboards und konfigurierte Graphen. In einer verteilten Umgebung empfiehlt sich eine MySQL- oder PostgreSQL-Datenbank, damit alle beteiligten Server auf die Daten zugreifen können. Für eine einfache Umgebung reicht aber auch eine SQlite aus.

Die Datenbank muss der Admin vor dem Start der Applikation noch initialisieren. Bei der Initialisierung wird auch ein Standarduser angelegt. Wie dieser heißen soll und welches Passwort er bekommt, lässt sich interaktiv festlegen:

python /usr/lib/python2.7/dist-packages/django/bin/django-admin.py syncdb --settings=graphite.settings
service apache2 restart

Im Anschluss lässt sich Graphite Web im Browser öffnen. Ganz ohne Daten sieht es noch sehr leer aus, ein paar wenige Statistiken schreibt Carbon Cache allerdings schon selbstständig. Unter dem Punkt »Graphite | carbon | agents« finden sich bereits ein paar Graphen, die zum Beispiel aussagen, wie viele Updates Carbon ausführt oder wie viel Speicher es benutzt. Diese Statistiken können im laufenden Betrieb sehr wertvoll sein, wenn es um Skalierung geht.

Mit Daten füttern

Mit dieser Installation steht alles bereit und wartet nur auf Daten. Um zu verstehen, wie Carbon die Daten speichert und sie später darstellt, hier ein kleines Beispiel mit dem Plaintext-Protokoll:

echo "localhost.tmp.files `ls /tmp | wc -l`   `date +%s`" | nc localhost 2003

Der vorangestellte String beschreibt einen eindeutigen Pfad, unter dem die Metrik in Graphite wiederzufinden ist. Punkte trennen die einzelnen Elemente. Der »wc« -Befehl gibt die Anzahl der Dateien aus, die sich im Verzeichnis »/tmp« befinden, und der Timestamp markiert den Zeitpunkt, zu dem Graphite das protokolliert. Das letzte Element des Metrik-Pfades »files« ist der Name der Datei, in die gespeichert wird, die vorangestellten Pfad-Komponenten entsprechen einer Verzeichnishierarchie, die auch das Webinterface so darstellt.

Das Beispiel zeigt vereinfacht, wie sich Datenpunkte an Carbon übermitteln lassen. Nach diesem Vorbild könnte ein User sich seine Skripte und Daemons selbst schreiben. Will er aber Standardwerte aufzeichnen, ist das noch nicht einmal nötig, für diesen Zweck gibt es fertige Software.

Eines dieser kleinen Programme heißt Collectd. Der in C geschriebene Daemon sammelt in einem festgelegten Intervall Performancedaten wie CPU-Load, Speicherverbrauch oder Festplattenbelegung. Mit über 90 fertigen Plugins lässt sich Collectd zudem auch gut erweitern. Das macht es beispielsweise sehr einfach, Performancedaten von MySQL oder Apache zu erfassen – man braucht nur das zugehörige Plugin in der Konfiguration zu aktivieren.

Unter den Erweiterungen gibt es auch ein paar so genannte Write-Plugins. Sie können alle gesammelten Werte an eine zentrale Stelle übermitteln. Zu den Write-Plugins zählt auch eines, das mit Carbon kommuniziert. Collectd lässt sich so direkt als Client für Carbon benutzen.

Neben Collectd gibt es noch weitere Tools, etwa Collectctl, Diamond oder auch Hoardd. Sie haben eine ähnliche Arbeitsweise, unterscheiden sich aber in Programmiersprache, Erweiterbarkeit und Konfiguration. Selbst Windows-Betriebssysteme bleiben nicht außen vor: Mit dem Programm SSC Serv kann der Admin auch sie monitoren und die Werte an Carbon weiterleiten.

Die bisher betrachteten Tools sammelten Systemstatistiken, es gibt aber auch solche, die wie Host Sflow das gesamte Netzwerk bis hin zu virtuellen Switchen überwachen.

Justieren

Das Sammeln von Daten ist also recht einfach. Umso mehr Aufmerksamkeit sollte der Admin allerdings der Konfiguration der zentralen Stelle, Carbon, schenken. Konfiguriert wird dabei prinzipiell im Verzeichnis »/etc/carbon« , wo sich zu Beginn zwei Dateien befinden. In »carbon.conf« liegen die Einstellungen bezüglich des ausführenden Benutzers, des Logging und Caching und der diversen Limits und Intervalle.

In der Datei »storage-schemas.conf« wird dagegen definiert, welche Daten, in welcher Frequenz, wie lange gespeichert werden. Kommt also ein neuer Datenpunkt bei Carbon an, muss dieser mindestens mit einem konfigurierten Pattern zusammenpassen.

Eine entsprechende Regel legt dann fest, in welchem Intervall diese Daten erwartet werden und wie viele dieser Datenpunkte zu speichern sind. Mit Eintreffen des ersten Datenpunkts, legt der Daemon das zugehörige Whisper-File an. Es beinhaltet die entsprechende Struktur und bleibt – wie beim Vorbild RRD – für seinen gesamten Lebenszyklus statisch:

[collectd_clients]
pattern = ^collectd\..*
retentions = 10s:7d,1m:30d,30m:2y

Dieses Beispiel legt eine Regel für Collectd-Hosts fest. Das Pattern passt auf alle Metriken, die mit »collectd« beginnen. Die dritte Zeile definiert, wie lange die Daten aufgehoben werden. Datenpunkte werden im 10-Sekunden-Intervall erwartet und in dieser Frequenz für sieben Tage aufgehoben. Whisper berechnet automatisch für minütliche und 30-minütliche Intervalle Durchschnittswerte. Diese werden für 30 Tage beziehungsweise zwei Jahre gespeichert.

Diese Art der Aggregation spart Platz auf der Festplatte und vermeidet I/O-Last. Stellt man nämlich etwa alle Werte eines Monats dar, benutzt das System die 30-Minuten- statt der 10-Sekunden-Werte. Erreicht die Aufzeichnung das Ende des programmierten Intervalls, beginnt Whisper wieder von vorne und die ältesten Werte werden überschrieben.

Das starre Regime der Whisper-Dateien bringt es mit sich, dass sie sich nur schwer im Nachhinein manipulieren lassen. Obwohl einige Tools existieren, die Dumps generieren, Dateien zusammenführen oder die Größe verändern, zeigt sich in der Realität, dass es bei Fehlkonfigurationen doch am besten ist, die Dateien einfach komplett neu anlegen zu lassen.

Wer in dieser Absicht die Konfigurationsdatei »storage-schemas.conf« verändert, lädt sie nach spätestens 60 Sekunden automatisch neu. Ein Neustart oder Reload des Daemon ist also nicht notwendig. Auf bereits bestehende Whisper-Files hat die geänderte Konfiguration jedoch keinen Einfluss mehr.

Darstellen

Die einzelnen Regeln arbeitet Graphite von oben nach unten ab. Das erste Pattern, das zutrifft, wird benutzt. Trifft keine der Regeln zu, gehen die Daten verloren. Es ist also ratsam, am Ende der Konfiguration eine Standardregel festzulegen, die immer zutrifft.

Graphite Web kümmert sich um die Darstellung der Datenpunkte in Graphen. In der Standardansicht, genannt Composer (Abbildung 2), lassen sich neben der einfachen Visualisierung auch Funktionen auf die Daten anwenden, um die Graphen zu transformieren oder Berechnungen anhand der Datenpunkte auszuführen. Beispielsweise lassen sich Graphen von mehreren Hosts summieren. Die Funktionen reichen von einfachen Summen bis hin zu komplexen mathematischen Berechnungen wie dem Holt-Winters-Forecast. Einmal konfigurierte Graphen kann der Anwender auch dauerhaft für den schnellen Aufruf speichern.

Abbildung 2: Die Standardansicht der Graphen im so genannten Composer.

Für die Anmeldung wird der während der Initialisierung der SQlite-Datenbank erstellte User benutzt. Über Funktionen des Dashboard lassen sich unterschiedliche Graphen gruppieren, zusammenführen und in einer Ansicht speichern. Graphite Web stellt auch ein funktionsreiches API zur Verfügung. Es lässt sich mittels HTTP direkt über den Browser ansprechen und bietet fast alle Funktionen des Composers. Die Datenpunkte stellt Graphite Web wahlweise als Bild im PNG-Format oder auch in anderen Formaten wie Json oder CSV dar:

http://ubuntu/render?target=collectd.ubuntu.load.load.shortterm&height=400&width=800

Der Aufruf zeigt die Statistiken der Shortterm Load vom Collectd-Host »ubuntu« . Der einzige zwingend erforderliche Parameter ist das Target, alle weiteren wie Höhe und Breite sind optional:

http://ubuntu/render?target=collectd.ubuntu.df-root.df_complex-*&height=400&width=800&title=Disk Usage in %&graphType=pie

Der nächste Aufruf zeigt die Auslastung der Festplatte an. Dabei soll ein Tortendiagramm (Abbildung 3) die Werte darstellen. Dafür wird im Target nicht nur eine einzelne Metrik angegeben, sondern eine Wildcard benutzt. In diesem Beispiel ist es eine einfache Wildcard, bei Bedarf lässt sich hier aber auch ein komplexer regulärer Ausdruck einsetzen. Graphite Web sucht sich automatisch alle auf den angegebenen Metrikpfad passenden Daten zusammen und stellt sie dar. Das vereinfacht den Vergleich von unterschiedlichen Daten.

Abbildung 3: Ein Tortendiagramm zeigt die Auslastung der Festplatte.

Angaben über Farben, Schriftarten oder Titel sind frei wählbar. Zudem lassen sich alle mathematischen Funktionen einsetzen, die auch der Composer kennt.

Andere Interfaces

Obwohl Graphite Web sehr viele Varianten anbietet, um Graphen zu visualisieren, ist für den einen oder anderen die Arbeit im Alltag damit doch etwas mühsam. Deshalb entstanden alternative Webinterfaces. Jedes verfolgt eigene Ideen, wie ein alternatives Graphite Web auszusehen hat. Als Backend benutzen sie aber alle Graphite.

Das Webinterface Grafana [2] kennt Query-basierte Dashboards. Das Aussehen und der Name orientieren sich an Kibana, das oft in Verbindung mit Logstash und Elasticsearch benutzt wird. Mit einfachen Mausbewegugnen lässt sich in Graphen hinein- und herauszoomen. Als Backend für die Dashboards können wahlweise Dateien oder Elasticsearch verwendet werden.

Das Webinterface namens Graphsky [3] verfolgt eher das Ziel größtmöglicher Einfachheit als eine funktionsreiche Visualisierung. Die Dashboards erstellt es anhand der bestehenden Metrikpfade. Mit den von Collectd gesammelten Daten kommt es daher sehr gut zurecht, da sie immer gleich strukturiert sind. Wer will, kann noch feiner abgestuft gruppieren, indem er Pfadkomponenten für das Rechenzentrum oder etwa das Rack hinzufügt.

Das auf der Videoplattform Vimeo entwickelte Tool Graph Explorer [4] verfolgt den Ansatz, Daten aus verschiedenen Stellen schnell gruppieren zu können. Es fügt den bestehenden Daten Tags hinzu und speichert sie in einer eigenen Datenbank. So lassen sie sich mit einer eigenen Querysprache durchsuchen. Zusätzlich beherrscht es die Funktion, via E-Mail zu alarmieren, wenn definierte Schwellenwerte überschritten werden.

Alles in allem stellen die genannten drei Interfaces gute Lösungen für Dashboards bereit, es gibt allerdings noch viele mehr. Durch die vielfältigen Fähigkeiten des API lassen sich Graphen aber auch manuell relativ schnell in eigene Applikationen oder Webseiten einbetten.

Ausblick

Von systemrelevanten Statistiken, über die Laufzeit der eigenen Applikation, bis hin zu Messwerten angeschlossener Sensoren: Die simple Kommunikation mit Graphite macht es möglich, alle diese Daten dauerhaft und gut strukturiert zu speichern. Alles, was für die Visualisierung benötigt wird, bringt Graphite mit. Neben den vielen mathematischen Funktionen besitzt es viele Schalter und Hebel, um die Darstellung anzupassen und die erstellten Graphen in eigene Webseiten einzubauen.

Graphite wird mit all seinen Komponenten stetig weiterentwickelt. So kommen mit den neuen Versionen nicht nur Bugfixes, sondern auch neue Funktionen hinzu.

Für die Storage-Engine Whisper beispielsweise ist ein Ersatz namens Ceres geplant. Im Gegensatz zu Whisper sollen die Datenbanken damit leichter veränderbar statt statisch sein. Die Verteilung von Daten auf verschiedene Speichermedien auf unterschiedlichen Servern oder Mountpoints soll ebenfalls verbessert werden. Das Aggregieren und Überschreiben alter Daten soll in Zukunft nicht mehr die Storage-Engine übernehmen, sondern die Komponente Carbon selbst. Diese Änderungen sind sehr vielversprechend und lassen auf eine noch bessere Skalierbarkeit hoffen, als sie ohnehin schon gegeben ist.