Zusammen mit unseren Freunden von Sensu freuen wir uns über das erste Stable Release von Sensu Go, welches offiziell am 5. Dezember 2018 veröffentlicht wurde. In dieser dreiteiligen Blogserie möchte ich Neugierigen einen einfachen Einstieg ermöglichen und versuchen verständlich zu erklären was Sensu Go ist und welche Funktionen es bietet.

Nachdem in Teil 1 vom 11.12.2018, der <hier> noch einmal nachgelesen werden kann, der grundlegende Aufbau von Sensu Go und die einzelnen Funktionen des Sensu-Backends erläutert wurden, will ich zu Beginn des zweiten Teils auf die Funktionsweise des Agenten und der Checkverteilung eingehen.

Sensu-Agent

Während das Sensu-Backend die Serverkomponente darstellt, wird der Sensu-Agent auf den zu überwachenden Systemen installiert. Dies können zum Beispiel Server, virtuelle Maschinen oder Container sein. Von dort aus meldet sich der Agent initial an den Backends an, die in seiner Konfigurationsdatei hinterlegt sind,  und sendet ab diesem Zeitpunkt turnusmäßig Keepalive-Nachrichten („Keine Sorge, ich bin noch am leben!“). Im Sensu-Sprachgebrauch wird der Agent als „Entity“ geführt.

Auf dem zu überwachenden System installiert, führt der Sensu-Agent lokal alle Monitoring-Prüfungen durch, für die er zuständig ist. Dies wird mit Abonnements, sogenannten Subscriptions, geregelt. Jedem Agenten und jedem Check wird eine oder mehrere Subscriptions zugewiesen. Diese können auch als Tags zur Gruppierung verstanden werden. Jeder Agent führt somit die Prüfungen durch, die zu seinen Subscriptions passen.

Neben den aktiven Prüfungen zum Ermitteln von Ergebnissen, kann der Agent aber auch Ergebnisse und Alarme von Drittlösungen entgegen nehmen, die bspw. nicht von außen abfragbar sind. Hierfür gibt es gleich mehrere Möglichkeiten, die durch das Setzen eines Parameters in der Konfigurationsdatei des Agenten ganz einfach aktivierbar sind.

Zum einen kann der Agent Events über die Agent-API annehmen. Diese Events leitet der Agent dann an das Backend weiter. Dort werden sie standardmäßig demselben Agenten zugeordnet. Je nach Definition und mit dem passenden Anwendungsfall ist es aber auch möglich, Events einer anderen Entity zuordnen zu lassen.

Zum anderen besteht die Möglichkeit zur Verwendung eines integrierten StatsD Listeners. An diesen können bspw. Metriken im einfachen StatsD Line Protocol übermittelt werden (<metricname>:<value>|<type>), welche anschließend auf dem Backend wieder dem entsprechenden Agenten zugeordnet werden.

Monitoring

Das beschriebene Modell der Gruppierung und Verteilung der Monitoring-Prüfungen wird auch Publish-Subscribe (Pub-Sub) Modell genannt. Es bietet große Vorteile hinsichtlich der Last, die auf dem Monitoringserver erzeugt wird.

Monitoring-Prüfungen in IT-Umgebungen sind erfahrungsgemäß trotz unterschiedlicher überwachter Systeme oft dieselben. Für gleichartige Systeme werden – sinnvollerweise – meist dieselben Prüf-Plugins, aber oft auch exakt gleiche Prüfdefinitionen verwendet. Beispiel: Prüfintervall. Soll der CPU-Check bspw. jede Minute durchgeführt werden, ist das Einsammeln der Metriken der Festplatten alle 5 Minuten ausreichend. Gleichwohl wird aber häufig kein Unterschied darin gemacht, ob der CPU-Check gegen server001 oder server100 durchgeführt wird. Mit der Vorgehensweise des Pub-Sub-Modells können daher mit nur einer angestoßenen Prüfung alle überwachen Systeme diese Prüfanfrage erhalten, lokal ausführen und das Ergebnis zurück übermitteln. Anstelle bspw. 10.000 Prüfungen muss auf dem Monitoringserver somit nur eine geplant und angestoßen werden.

Was kann überwacht werden?

Was alles mit Sensu Go überwacht werden kann, ist nur durch die eingesetzten Plugins begrenzt. Ein Plugin kann jedes von der Commandline ausführbare Skript sein. Somit können nahezu alle Plugins eingesetzt werden, die auch anderen Monitoring-Lösungen bereitstehen. Nativ unterstützt Sensu Go die Ausgabeformate der Nagios Plugins, sowie Graphite Plaintext Protocol, InfluxDB Line Protocol und OpenTSDB Line Protocol. All diese können somit „out-of-the-box“ zum Einsammeln von Metriken verwendet werden.

Für Benachrichtigungen auf Basis von Status werden die Exit-Codes 0 für „ok“, 1 für „warning“, 2 für „critical“ und >2 für „unknown“ herangezogen, wie man es auch von anderen Monitoring-Lösungen gewohnt ist.

Generell ist hier die Tendenz spürbar, nicht mehr für jede eingestellte Prüfung eine Benachrichtigung zu konfigurieren. Vielmehr werden Notifizierungen heute eher nur noch für konkrete Funktionsprüfungen eingerichtet, wie bspw. die Prüfung, ob ein bestimmter Prozess läuft. Alle weiteren Metriken, wie z. B. wie viel Speicher dieser Prozess verbraucht, werden nebenher ohne Statusermittlung eingesammelt und in eine Timeseries Datenbank (TSDB) gespeichert. Diese Daten können somit zur Visualisierung und zur Fehleranalyse mit Grafana verwendet werden. Außerdem können gegen diese Daten in der TSDB im Bedarfsfall auch weitere Prüfungen erfolgen, die im Falle von Schwellenwertverletzungen auch Notifizierungen nach sich ziehen können. Der große Vorteil dabei ist, dass man alle Werte in ein Verhältnis oder in einen Kontext zueinander setzen kann, um anschließend besser abwägen zu können, ob und was für eine Notifizierung notwendig ist.

Soweit bis hier hin mit Teil 2 zu Sensu Go und den Funktionen des Sensu-Agenten sowie der Art der Checkverteilung und dem Pub-Sub-Modell.

Der dritte Teil erscheint hier am 18.12.2018. Dort werde ich erläutern, wie das Monitoring von Netzwerkgeräten mit Sensu Go möglich ist und welche Funktionen mit den angekündigten Updates zu Beginn des kommenden Jahres noch kommen werden.