© dolgachov, 123RF

Spätestens dann, wenn eine Monitoring-Software auf den Ausfall eines Dienstes oder Servers hinweist, sind Systemverwalter gefragt. Im Gegensatz zu diesem reaktiven Ansatz ermöglicht es proaktives Monitoring, Probleme im Vorfeld zu erkennen.

Viele Monitoring-Lösungenreagieren auf ein Problem, sobald ein vom Admin festgelegter Schwellenwert erreicht ist. Diese Werte beruhen meist auf Erfahrung, führen aber regelmäßig zu Verstimmungen beim Bereitschaftsdienst, wenn beispielsweise Festplatten-Auslastungen während eines Backups über einen Grenzwert steigen und mitten in der Nacht einen Alarm auslösen.

Anstelle dieses reaktiven Monitorings propagieren der Entwickler Kyle Kingsbury und sein Team das so genannte proaktive Monitoring mit Riemann Listing 2 zeigt bereits, wie das Benachrichtigen per E-Mail aussehen kann. Aufgrund der Clojure-Konfiguration stehen weitere von der Sprache unterstützte Wege offen, etwa SMS, IRC oder die Kooperation mit externen Diensten wie Hipchat, Pagerduty, Blueflood oder Campfire. Eine Übersicht der verfügbaren Schnittstellen liefert Listing 2 zeigt, wie Admins den Graphite-Dienst anbinden und alle Riemann-Events dorthin weiterleiten. Wer etwas selektiver sein möchte, konfiguriert einen entsprechenden Stream in der Riemann-Konfigurationsdatei; das folgende Beispiel versendet nur Ereignisse vom PostgreSQL-Dienst:

(streams
  (where (service "postgres")
    graph))

Graphite selbst benötigt keine besonderen Einstellungen, um Ereignisse vom Riemann-Server anzunehmen. Ein Artikel aus dem Jahr 2014 beschreibt die Installation und Einrichtung [16]. Die Webkonsole erreichen Anwender über »http://localhost:8080« . Auf der linken Seite sind in einer Baumansicht die Clients aufgelistet. Anwender klicken einen Eintrag an, um ihn in dem Graphite Composer auf der rechten Seite darzustellen (Abbildung 4). Dort ist es nicht nur möglich, bestimmte Zeitspannen festzulegen, sondern auch den Graphen zu gestalten.

Abbildung 4: Graphite stellt Riemann-Metriken über einen längeren Zeitraum hinweg dar.

Knapp kalkuliert

Riemann verfolgt einen interessanten Ansatz, hat aber durchaus seine Schwächen. Die Clojure-Syntax der Konfiguration dürfte die größte Hürde darstellen – wer nicht damit vertraut ist, sollte eine längere Einarbeitungszeit einplanen. Dank der Dokumentation auf der Projektseite mit ihren Beispielen ist diese Aufgabe aber gut zu meistern.

Ein anderes Problem ist sicherlich das Design der Clients – ein Prozess pro Metrik hat einen faden Beigeschmack und verfälscht je nach Umfang des Setups möglicherweise die erhobenen Werte. Daher bietet sich eine Zusammenarbeit mit einem Statistik-Daemon wie Collectd [17] an, der die Metriken einsammelt und dann an Riemann schickt.

Ein Konzept für Hochverfügbarkeit, zum Beispiel eine Synchronisation zwischen mehreren Nodes, eine Ausfallsicherung oder Lastverteilung, gibt es ebenfalls nicht. Wer nicht das Beispiel der Testumgebung mit mehreren Servern, die an eine zentrale Instanz berichten, nachbauen möchte, kann der Empfehlung der Entwickler folgen. Sie schlagen im Howto vor, zwei Server mit einer Floating-IP einzusetzen. Die Auswertung geschieht basierend auf Events, die dann je nach Floating-IP-Status zu dem einen oder zu dem anderen Server gehen.

Ein echter Pluspunkt ist, dass Riemann das Handling der Schwellenwerte auf die Clients auslagert, was nicht nur in größeren Organisationen das Deployment von neuen Systemen vereinfachen kann. Für das eingangs erwähnte Alarmierungsproblem während eines nächtlichen Backupvorgangs könnte die Sicherungssoftware über ihre internen Metriken Bericht an Riemann erstatten und die Schwellenwerte temporär an die veränderte Situation anpassen.