Das permanente Überwachen der IT gehört zur Routine jedes Admins. Doch abhängig von Umfang und Komplexität der Umgebung sind oft mehrere Werkzeuge notwendig. Bloonix will als modular aufgebautes Monitoringtool zahlreiche Dienste unter einer Oberfläche zusammenfassen. Wir zeigen die Inbe- triebnahme und das Monitoring mit der freien Software.
Die benutzerfreundliche Umgebung für Monitoringaufgaben namens Bloonix [1] kann alle IT-Assets überwachen, die über eine Netzwerkverbindung ansprechbar sind. Lediglich für das Abfragen bestimmter Netzwerkkomponenten sind spezielle Plug-ins einzuspielen – dazu später mehr. Doch die webbasierte, modular aufgebaute Umgebung stellt für alle gängigen Hard- und Softwarekomponenten entsprechende Module zur Verfügung. Grundsätzlich stützt sich Bloonix auf SNMP, kann aber auch andere Protokolle für das Monitoring verwenden.
Die ersten Codezeilen von Bloonix des gleichnamigen Unternehmens aus dem Rhein-Sieg-Kreis gehen auf das Jahr 2006 zurück. Seit März diesen Jahres unterliegt das Projekt der Server Side Public License v1 (SSPL). Dabei handelt es sich um eine Copyleft-Source-Available-Lizenz, also im engeren Sinne nicht um eine freie Software. Doch das dürfte die wenigsten Anwender ernsthaft stören, denn im Kern geht es um Zuverlässigkeit und solides Monitoring. Laut Angaben der Entwickler ist die Serversoftware von Bloonix hochverfügbar sowie hochskalierbar und kann zur Lastverteilung auf mehreren Servern betrieben werden. Beim Monitoring setzt das Tool primär auf Agenten, die für gängige Betriebssysteme verfügbar sind. Für Desktopsysteme existieren keine Pakete – auch nicht für macOS. Bloonix ist als Managed Server und als selbst gehostete Umgebung verfügbar [2]. Interessierte können sich in der Onlinedemo [3] einen ersten Eindruck von der Umgebung verschaffen. Freie Unterstützung leistet die Community [4] – wenn auch in überschaubarem Umfang.
Die Bloonix-Architektur
Um die komplexen Herausforderungen beim Monitoring von heterogenen Umgebungen zu bewältigen, bedient sich Bloonix einer modularen Architektur, die fünf Komponenten umfasst. Das Herzstück ist der Bloonix-Server, in dem die Fäden der verschiedenen Module zusammenlaufen. Fährt dieser Server hoch, startet er verschiedene Prozesspools wie beispielsweise Listener, DB-Manager, Keepalived und verschiedene Checker- und Scheduler-Module. Der Bloonix-Server schreibt seine Daten in der Regel in PostgreSQL- und Redis-Datenbanken.
Die benutzerfreundliche Umgebung für Monitoringaufgaben namens Bloonix [1] kann alle IT-Assets überwachen, die über eine Netzwerkverbindung ansprechbar sind. Lediglich für das Abfragen bestimmter Netzwerkkomponenten sind spezielle Plug-ins einzuspielen – dazu später mehr. Doch die webbasierte, modular aufgebaute Umgebung stellt für alle gängigen Hard- und Softwarekomponenten entsprechende Module zur Verfügung. Grundsätzlich stützt sich Bloonix auf SNMP, kann aber auch andere Protokolle für das Monitoring verwenden.
Die ersten Codezeilen von Bloonix des gleichnamigen Unternehmens aus dem Rhein-Sieg-Kreis gehen auf das Jahr 2006 zurück. Seit März diesen Jahres unterliegt das Projekt der Server Side Public License v1 (SSPL). Dabei handelt es sich um eine Copyleft-Source-Available-Lizenz, also im engeren Sinne nicht um eine freie Software. Doch das dürfte die wenigsten Anwender ernsthaft stören, denn im Kern geht es um Zuverlässigkeit und solides Monitoring. Laut Angaben der Entwickler ist die Serversoftware von Bloonix hochverfügbar sowie hochskalierbar und kann zur Lastverteilung auf mehreren Servern betrieben werden. Beim Monitoring setzt das Tool primär auf Agenten, die für gängige Betriebssysteme verfügbar sind. Für Desktopsysteme existieren keine Pakete – auch nicht für macOS. Bloonix ist als Managed Server und als selbst gehostete Umgebung verfügbar [2]. Interessierte können sich in der Onlinedemo [3] einen ersten Eindruck von der Umgebung verschaffen. Freie Unterstützung leistet die Community [4] – wenn auch in überschaubarem Umfang.
Die Bloonix-Architektur
Um die komplexen Herausforderungen beim Monitoring von heterogenen Umgebungen zu bewältigen, bedient sich Bloonix einer modularen Architektur, die fünf Komponenten umfasst. Das Herzstück ist der Bloonix-Server, in dem die Fäden der verschiedenen Module zusammenlaufen. Fährt dieser Server hoch, startet er verschiedene Prozesspools wie beispielsweise Listener, DB-Manager, Keepalived und verschiedene Checker- und Scheduler-Module. Der Bloonix-Server schreibt seine Daten in der Regel in PostgreSQL- und Redis-Datenbanken.
Zur Erfassung relevanter Systemmetriken auf den Zielhosts, insbesondere CPU-Auslastung, Speicherbelegung und Datenbankservices, setzt die Monitoringumgebung primär auf Agenten. Grundsätzlich lässt sich ein solcher Agent auch auf Servern ausführen, die Bloonix selbst nicht direkt abfragen kann. Von einem solchen Punkt aus ist dann die Überwachung von Routern, Switches und anderen relevanten Netzwerkdiensten möglich. Für Unternehmen mit verteilten Standorten bietet "Bloonix-Satellite" die Möglichkeit, global verteilte Webdienste zu überwachen.
Die Steuerung erfolgt über das Web-GUI mitsamt der Verwaltung von Hosts, Gruppen, Clients und sonstigen Services. Außerdem verfügt die Bloonix-Umgebung über einen Plug-in-Mechanismus. Bei den Plug-ins handelt es sich um mehr oder minder einfache Skripte, die den Status von einem oder mehreren Diensten abfragen. Die Erweiterungen werden üblicherweise mit den Agenten, dem Server beziehungsweise den Satelliten installiert. Unter Linux sind die Plug-ins standardmäßig im Verzeichnis "/usr/lib/bloonix/ plugins" zu finden.
Die Listener-Komponenten nehmen die Statusinformationen und die Metriken der Agenten entgegen, validieren diese und legen sie in der Datenbank ab. Obendrein prüft der Server, ob eine Benachrichtigung an den Administrator auszulösen ist. Für alle datenbankspezifischen Aufgaben ist das Modul "DB Manager" zuständig. Es schreibt die Metriken in die PostgreSQL-Datenbank. Die Daten werden über einen Nginx-Webserver für das Webinterface aufbereitet. Der Bloonix-Server ist zudem für die Prüfungen von registrierten Routern, Switches und Services zuständig. Er fragt auch die Satellitenkonfiguration ab.
Kommerzielle Services
Bloonix steht kommerziell als Managed Server oder als Self-Hosted-Umgebung zur Verfügung. Bei der Managed-Server-Variante wird Kunden eine eigene VM zugewiesen. Außerdem sind tägliche Backups sowie Gateways für SMS verfügbar. Die Preise beginnen bei etwa 60 Euro pro Monat, abhängig von der VCPU-Zahl sowie der RAM- und Festplattengröße. Unternehmen, die Bloonix selbst hosten, aber nicht auf Support verzichten möchten, können zwischen verschiedenen Supportvarianten wählen. Diese beginnen bei 600 Euro pro Jahr.
Das Monitoring in Betrieb nehmen
Beim Monitoring unterscheidet Bloonix zwischen der Überwachung von Hosts und Services. Grundsätzlich präferiert die Umgebung beim Monitoring das Zusammenspiel mit Linux-Servern. Um die Konfiguration zu vereinfachen, sollte auf dem überwachten System bereits ein Agent installiert sein. In einem solchen Szenario kann die Hostkonfiguration von dessen Seite aus erfolgen.
Um einen ersten Host in die Überwachung einzubeziehen, öffnen Sie das "Host"-Menü, klicken rechts oben auf das Pluszeichen und spezifizieren in dem zugehörigen Dialog die typischen Serverdaten. Sie können den Hostnamen über die Systemeinstellungen mit "Bloonix Server Hostnames" anpassen. Zur Agentenkonfiguration stehen Ihnen zwei Wege offen: manuell oder mithilfe des Skripts "bloonix-init-host". Bei der manuellen Konfiguration müssen Sie die Dateien "/etc/bloonix/agent/ main.conf" und "/etc/bloonix/agent/conf.d/ host.conf" bearbeiten. Außerdem tragen Sie die Adresse des Bloonix-Servers in die Datei "/etc/bloonix/agent/main.conf" ein. Die zugehörigen Anpassungen nehmen Sie im Abschnitt "server" und dem zugehörigen Parameter "host" vor:
server {
host 127.0.0.1
host bloonix.server.de
Dann speichern Sie Host-ID und Passwort in "/etc/bloonix/agent/conf.d/host.conf":
host {
host_id 01
password <Streng_geheim>
}
Anschließend müssen Sie den Bloonix-Agenten neu starten, damit die Änderungen wirksam werden.
Um die Agentenkonfiguration zu automatisieren greifen Sie zum erwähnten Skript "bloonix-init-host". Die Voraussetzung dafür ist allerdings, dass sich die Konfigurationsdatei der Agenten im Originalzustand befindet. Sie dürfen mithin noch keine Änderungen vorgenommen haben. Alternativ genügt es, dass Sie zumindest die Zeile "host 127.0.0.1" im Abschnitt "server" eintragen. Ein Beispiel:
bloonix-init-host \
--host-id 33 \
--password <Streng_geheim>
--server bloonix.server.der
Nach dem Anlegen eines ersten Hosts können Sie mit der Konfiguration der zu überwachenden Services beginnen. Das Prozedere gleicht dem Hinzufügen von Hosts: Im "Services"-Menü klicken Sie auf das Pluszeichen und spezifizieren die Eigenschaften. Dazu gehört auch die Auswahl der Plug-ins, also der Skripte, die für das eigentliche Monitoring zuständig sind. Die Erweiterungen werden vom Server, dem Agenten und der Satellite-Komponente ausgeführt.
Bild 1: Nach der Inbetriebnahme informiert Bloonix über sein webbasiertes Dashboard.
Die Plug-in-Welt nutzen
Bloonix verfügt über Plug-ins für externe Tests sowie für Linux-, SNMP-, Webserver-, Caching- und datenbankspezifische Prüfungen. Laut der Dokumentation können Sie sich aus über 40 Plug-ins bedienen. Um beispielsweise die CPU-Last eines Linux-Servers zu überwachen, wählen Sie "check-linux-cpu". Weitere relevante SNMP-Prüfungen untersuchen die Speicher- und Festplattenauslastung sowie die Anzahl der Services und Prozesse. Die beiden wichtigsten externen Checks dienen der Überwachung von TCP/IP oder UDP/IP. Beim Monitoring von Datenbanken sind Sie jedoch auf PostgreSQL und MySQL beschränkt.
In diesem Kontext ist es interessant, wie der Server und die Agenten interagieren. Nach dem Einrichten eines Diensts besitzt dieser zunächst den "INFO"-Status, da noch kein Monitoring erfolgt. Die Service-Übersicht zeigt die Statusinformationen in der gleichnamigen Spalte an. Mit dem Initiieren des Monitorings stellt der Agent eine Verbindung zum Server her, authentifiziert sich und übermittelt fortwährend die Plug-in-spezifischen Daten. Aus der blau hinterlegten "INFO"-Meldung wird im Idealfall ein grünes "OK". Bloonix kennt sieben verschiedene Statusinformationen: "OK", "INFO", "NOTICE", "WARNING", "ALERT", "CRITICAL" sowie "UNKNOWN". Die farbige Hinterlegung im Web-GUI vereinfacht beim Überfliegen der Meldungen deren Einordnung. In der "Services"-Übersicht können Sie zudem mit einem Klick auf die Kopfzeile die Sortierung ändern; das vereinfacht die Analyse der Ausgaben.
Beim Prüfen von Diensten sind Sie nicht zwingend auf Agenten angewiesen, sondern können dies auch von einem Bloonix-Server oder von den Bloonix-Satelliten erledigen lassen. Das ist bei all jenen Prüfungen vorgesehen, die durch das Setzen der Option "Remote check" auf "No" lokal ausführbar sind. Gleichwohl haben die Remotechecks Vorteile, zum Beispiel, dass Sie die Qualität eines Diensts beim Internetzugang beurteilen können – und zwar aus der Perspektive unterschiedlicher Standorte. Davon profitieren Sie vornehmlich beim Monitoring von HTTP, IMAP, POP3 und SMTP. Wenn Sie eine Satellite-Konfiguration implementieren, steht über das Web-GUI ein spezielles Dashboard zur Verfügung, das das Filtern der Antwortzeiten nach unterschiedlichen Standorten erlaubt.
Detailkonfiguration und Administration
Über das Web-GUI legen Sie nicht nur Hosts und Services an, sondern verwalten auch Hostgruppen, Benutzer und Satelliten. Zur Benutzeradministration bedient sich Bloonix der Rollen "admin", "operator" und "user" – samt zugehörigen Berechtigungen. Wenn Sie tiefer in die Spezifika einsteigen wollen, lohnt sich ein Blick in die Konfiguration der verschiedenen Komponenten. Die Konfiguration des Bloonix-Servers erfolgt mithilfe der Datei "/etc/ bloonix/server/main.conf". Mit dem Parameter "webgui_domain" bestimmen Sie die Domain des Webinterfaces. Die Plug-ins verwaltet die Umgebung üblicherweise in "/usr/lib/ bloonix/plugins". Dort legen Sie auch Ihre Eigenentwicklungen ab. Die verwendete Datenbank und den Storage richten Sie über die beiden Konfigurationsdateien "/etc/bloonix/ database/ main.conf" und "/etc/bloonix/ datastore/ main.conf" ein.
Die Web-GUI-Konfiguration schreibt Bloonix in die Datei "/etc/bloonix/webgui/main.conf", die der Bloonix-Agenten befindet sich in "/etc/bloonix/agent/ main.conf". Anpassungen an beiden sind nur unter besonderen Umständen ratsam. Schließlich können Sie die Satellitenkonfiguration über "/etc/bloonix/satellite/ main.conf" bearbeiten.
Bild 2: Die vom Monitoring ermittelte Service-Übersicht präsentiert eine Vielzahl nützlicher Details.
Benachrichtigungen einrichten
Doch es nützt wenig, wenn Bloonix die IT-Infrastruktur im Blick hat, Sie aber im Falle von kritischen Ereignissen davon keine Kenntnis erhalten. Damit das nicht passieren kann, verfügt die Software über eine Benachrichtigungsfunktion, die auf drei Wegen kommunizieren kann: Sendmail, HTTP und die skriptbasierte Hinweisausgabe. Für Sendmail benötigen Sie einen MTA wie Postfix oder Exim. Wichtig ist dabei, dass Sie einen gültigen Absender spezifizieren. Mithilfe des MTA steuern Sie, ob die E-Mail-Benachrichtigungen über einen Relay-Server oder per SMTP auf den Weg gebracht werden. Beim HTTP-basierten Versand können Sie URL-codierte oder JSON-basierte Daten über ein entsprechendes HTTP-Interface weiterreichen.
Sollten die HTTP- und Sendmail-Varianten Ihren Anforderungen nicht genügen, greifen Sie zur Skript-basierten Benachrichtigung, die sich in das Web-GUI integriert. Ein einfaches Beispiels soll das Prozedere verdeutlichen: Das Skript müssen dem Verzeichnis speichern, das mit der Option "message_service_script_path" in der Bloonix-Serverkonfiguration hinterlegt ist. Exemplarisch verwenden wir "test.py" und speichern es unter "/usr/local/lib/bloonix/message-service". Das Skript sehen Sie im Listing.
Als Nächstes legen Sie über das Web-GUI einen neuen Nachrichtendienst vom Typ "Script" an und weisen "Message" den Wert "%message%" zu. Bei "send_to" hinterlegen Sie "%send_to%" und bei "foo" schließlich "bar".
Löst Bloonix einen Alarm aus, werden die im Web-GUI definierten Parameter über STDIN im JSON-Format an das Skript übergeben. Der Exit-Code teilt dem Bloonix-Server mit, ob das Senden der Nachricht erfolgreich war. Dabei steht 0 für einen erfolgreichen und 1 für einen nicht erfolgreichen Versand. In der Protokolldatei "/tmp/test.log" finden Sie anschließend den entsprechenden Eintrag.
Die Ziele der Benachrichtigungen nennen sich Kontakt beziehungsweise Kontaktgruppen. Sie können einem Kontakt unterschiedlich viele Nachrichtendienste zuordnen. Außerdem sind Sie in der Lage, die Benachrichtigungszeiträume festzulegen, sofern deren Inhalt nicht kritisch ist. Das Konzept der Kontaktgruppen erlaubt es Ihnen, Kontakte mit Host und Diensten zu verknüpfen. Sie steuern so exakt, welche Kontakte vom Ausfall spezifischer Hosts beziehungsweise Services erfahren. In der Praxis erweist es sich als nützlich, zumindest jedem Host eine Gruppe zuzuordnen.
Das Einrichten von Host- und Servicekonfigurationen erweist sich in der Praxis als sehr zeitintensiv, da keine Autodiscovery-Funktion vorhanden ist. Bloonix stellt Ihnen alternativ die Funktion "Service-Templates" zur Verfügung, mit der Sie Dienste und Dienstparameter bündeln und auf beliebig viele Hosts anwenden. Legen Sie neue Hosts an, greifen die Vorlagen automatisch dort. Über das Menü "Configuration / Templates" greifen Sie auf die Template-Funktion zu. Dort finden Sie eine Auswahl von Vorlagen, die Standardprüfungen für Apache- oder MySQL-Server sowie generische Linux-Checks vorsehen. Über das Web-GUI legen Sie zudem eigene Vorlagen an und weisen den Templates Prüfungen zu. Mithilfe von Variablen definieren Sie verschiedene Schwellenwerte für die Ausgabe von Warnungen oder kritischen Hinweisen. Das Dashboard bündelt die gesammelten Informationen und führt die verschiedenen Hinweise und Warnungen auf. Über diese Visualisierungen klicken Sie sich zu den Detailinformationen und ergreifen so notwendige Maßnahmen.
Fazit
Bloonix ist für das Monitoring von IT-Infrastrukturkomponenten konzipiert und bewältigt dies mit Bravour. Allein das fehlende Autodiscovery betrübt, wird aber durch das umfangreiche Plug-in-Ökosystem wettgemacht. Professioneller Support steht über die zwei kommerziellen Varianten zur Verfügung. Und IT-Verantwortliche werden zudem bei den komplexeren Konfigurationsschritten durch die ausgesprochen gute Dokumentation unterstützt.