© Markus Feilner

Noch so ein Underdog: Collectd 4.3 ist ein umfangreiches Monitoring-Werkzeug, das mit einer ausbaubaren Plugin-Architektur aufwartet. Wie mit Legosteinen steckt sich der Admin das Monitoring zusammen.

Von Collectd gehört haben die meisten Admins bereits, aber wirklich beschäftigt haben sich deutlicher weniger mit ihm, obwohl seine Anfänge bis ins Jahr 2005 reichen. Florian Forster veröffentlichte damals die ersten Versionen von Collectd [1], die eine begeisterte OSS-Community fortführte und bis heute ausbaut.

Konsequent modular

In den Augen vieler Fans ist das wirklich bestechende Feature von Collectd sein Design mit einer alles durchdringenden Modularität. Manch ein Colledct-Anwender meint, der eigentliche Kern von Collectd sei fast primitiv, weil er gar keine Monitoring-Features bereitstellt. Was an Monitoring-Funktionalität vorhanden ist, kommt ausschließlich von Plugins, die der Collectd-Kern nur mehr lädt.

Collectd ist in C geschrieben und enthält praktisch keinen Code, der spezifisch für ein Betriebssystem wäre. Collectd lässt sich somit auf nahezu jedem unixoiden System betreiben. Und es ist überaus genügsam: Weil das Tool kaum Ressourcen benötigt, läuft es auch auf Minimal-Hardware wie dem guten alten Linksys WRT54G oder einem Raspberry Pi.

Die Installation

Aber im Alltag wird der Admin, der beim Monitoring auf Collectd setzt, wohl eher auf klassische Serverhardware mit Linux setzen. Eine handelsübliche Pizza-Box ist völlig ausreichend, und ganz gleich, welche Linux-Distribution läuft: Collectd ist in kürzester Zeit bereit für den Einsatz. Debian-basierten Distributionen liegt Collectd als Paket bei; auch wer auf Centos- oder RHEL-basierten Systemen unterwegs ist, findet im Web fertig kompilierte Pakete der aktuellen Collectd-Version.

Collectd lässt sich sehr leicht installieren (Abbildung 1), was für Admins von großer Bedeutung ist. Es funktioniert nach einem simplen Client-Server-Prinzip: Auf einem zentralen Server läuft der wichtigste »collectd« , aber auch auf jedem zu überwachenden Host startet der Admin eine Instanz des Dienstes.

Abbildung 1: Ohne seine vielen Plugins wäre Collectd nahezu nutzlos. Doch allzu leicht verirren sich Admins in den langen Listen mit verfügbaren Erweiterungen, die es im Web für fast jeden Zweck gibt.

Anhand des erwähnten Framework und der zugehörenden Plugins findet ein Datenaustausch zwischen den vielen Collectd-Instanzen und dem Masterserver statt: Read-Plugins sammeln auf den überwachten Systemen die Monitoring-Daten; ein Write-Plugin verschicken sie anschließend über ein eigenes Protokoll an die Collectd-Masterinstanz. Diese wertet die empfangenen Daten aus, bereitet sie auf und stellt sie über ein Webinterface dar. Wer sich dabei nun einen Nagios- oder Icinga-Nachbau vorstellt, greift allerdings daneben – das Web-GUI zeigt maßgeblich RRD-Graphen an, aus denen sich ablesen lässt, wie der Zustand eines Dienstes über einen Zeitraum ausgesehen hat (Abbildung 2).

Abbildung 2: RRD-Graphen waren das eigentliche Steckenpferd von Collectd, die Sache mit Notifications und Monitoring kam erst wesentlich später hinzu.

Das hat vorrangig historische Gründe: Collectd war ursprünglich nicht fürs Monitoring gedacht, sondern als Hilfsmittel für Admins, die den nötigen Grad an Skalierung ausfindig machen wollten. Collectd sollte Aufzeichnungen darüber führen, welche Last welchen Systemen in welchem Zeitraum zu schaffen machte, damit der verantwortliche Admin rechtzeitig reagieren und mehr Blech für sein Setup einsetzen konnte.

Die Monitoring-Funktion hielt als Notification-Feature erst in Collectd 4.3 Einzug in das Programm, und sie ist – natürlich – über Plugins realisiert. Zusammen mit der Notification-Funktion fanden in 4.3 übrigens auch Thresholds ihren Weg in Collectd; Anwender halten diese Version für die erste vollständige Monitoring-Lösung auf Collectd-Grundlage.

Einfache und doch vielschichtige Konfiguration

Collectd kommt mit einer einzigen Konfigurationsdatei daher. Das ist auf der einen Seite gut, weil so kein Dateien-Chaos entsteht, wie Admins es von Nagios und Konsorten kennen. Andererseits führt das Prinzip dazu, dass die »collectd.conf« in relativ kurzer Zeit ein ziemlich langer Schlauch wird, den irgendwann nur mehr ihr Autor versteht.

Kommentare sind erlaubt und empfohlen. In »collectd.conf« stehen zunächst allgemeine Einstellungen, die Collectd auf dem Host betreffen. Für jedes zu nutzende Plugin findet sich hier eine »LoadPlugin« -Zeile, geladene Module lassen sich in der Datei weiter unten per »Plugin« -Direktive konfigurieren – die Syntax erinnert teilweise an die Konfigurationssyntax von Apache. Damit steht fest: Jeder Host erhält seine eigene Version von »collectd.conf« , die festlegt, für welche Dienste Events des Typs »Notification« auszuführen sind.

Was im Falle von Notification-Events passiert, obliegt weitestgehend dem Gutdünken des zuständigen Admin: Das »Network« -Plugin, das für die Client-Server-Kommunikation verantwortlich ist, kann Notification-Events beispielsweise an den Masterserver weiterleiten, der dann anhand eines definierbaren Ablaufs eine Alarm-E-Mail versendet. Diese Methode ermöglicht es, aus dem Tool für Performance-Messung ein echtes Werkzeug für Monitoring zu machen.

Plugins, Plugins, Plugins

Das Testszenario wickelt Collectd im Wesentlichen souverän ab. Natürlich stehen Plugins zum Auslesen zentraler Systemwerte zur Verfügung: Das CPU-Plugin überprüft die CPU-Last eines Systems, mittels Memory-Plugin lässt sich ein Host im Hinblick auf den verfügbaren Arbeitsspeicher testen, und das Df-Plugin kümmert sich darum, dass die Platten nicht volllaufen. Auch ein Smart-Plugin kursiert im Netz, mit dem sich der Gesundheitszustand der Platte prüfen lässt.

Für praktisch alle gängigen Dienste, die den Alltag eines IT-Admin bestimmen, finden sich Prüf-Plugins, sei es nun Bind, MySQL oder Apache. Wer auf einem Host virtualisiert und dazu die Libvirt nutzt, kann mit Hilfe des zugehörigen Plugins detailliert herausfinden, wie es einer VM gerade geht. Ein ähnliches Plugin für Xen gibt es ebenfalls. Und das obligatorische Ping-Plugin darf natürlich ebenso nicht fehlen.

Fluch oder Segen? Individuelle Parameter pro Plugin

Doch die schiere Menge verfügbarer Plugins ist für Collectd letztlich Fluch und Segen zugleich. Denn während sie auf der einen Seite eine massive Flexibilität ermöglicht, wirkt sie schnell auch verwirrend. Für jedes Plugin aus unserem Beispiel muss der Admin beispielsweise nachschauen, welches die jeweiligen Konfigurationsparameter sind, die er in »collectd.conf« nutzen darf oder muss.

Plugins sind de facto eigene Skripte, meist handelt es sich sogar um Shellskripte. Die Parameter unterscheiden sich von Plugin zu Plugin, und ein paar der vorgestellten Plugins gehören gar nicht zum offiziellen Umfang von Collectd, sondern wollen separat hinzuinstalliert sein.

Das alles sorgt für ein verhältnismäßig hohes Maß an Komplexität. Ein Admin wird mit Collectd zwar in der Lage sein, ein umfängliches und voll funktionstüchtiges Monitoring für sein Setup mit vielen überwachten Servern aufzubauen, doch wird das wegen der eher komplizierten Konfigurationsarbeit beim ersten Mal einige Zeit in Anspruch nehmen.

Grafische Werkzeuge, die anhand festgelegter Parameter eine fertige Konfiguration für die direkte Benutzung produzieren, existieren derzeit nicht. Um das Editieren von »collectd.conf« mit allen Begleiterscheinungen kommen Admins leider nicht herum.

Fazit: Vollständig, aber auch komplex

Collectd ist ein komplexes Werkzeug, das neben vollständigem Monitoring für die aufgezeichneten Testwerte gleich auch fertige RRD-Graphen produziert und insgesamt das Leben des Admin erleichtert. Jedenfalls dann, wenn er es bis zu dem Punkt schafft, an dem das Erleichtern losgeht. Denn während sich die Installation von Collectd als sehr leicht erweist, dürfte es einige Zeit in Anspruch nehmen, eine vollständige »collectd.conf« für jeden einzelnen Host im eigenen Netzwerk zu bauen. Das trifft besonders dann zu, wenn sich die Rechner beispielsweise im Hinblick auf benutzte Hardware deutlich oder auch nur graduell voneinander unterscheiden.

In Sachen Komplexität steht Collectd einer Nagios- oder Icinga-Installation kaum nach. Wer Collectd einsetzt, erhält somit ein qualitativ hochwertiges Monitoring, das aber eine komplexe Installation als Pferdefuß mitbringt.