In diesem kurzen Artikel zeige ich wie einfach es ist, in Sensu Go mithilfe von Ansible und dem Nagios-Plugin check_nwc_health, ein Netzwerkmonitoring mit einer beliebigen Anzahl von Geräten einzurichten.

Mithilfe von Ansible das Netzwerkmonitoring mit check_nwc_health in Sensu Go automatisieren

Sensu Go bietet eine RESTful API, über die alle Elemente (Entities, Checks, Handler, Filter, etc.) erstellt, abgefragt, verändert und gelöscht werden können – es lässt sich somit komplett über die API betreiben.

Für das Monitoring von Netzwerkgeräten existieren bereits viele verschiedene Plugins von unterschiedlichen Monitoringlösungen. Eines davon ist check_nwc_health. Es unterstützt eine sehr große Anzahl der gängigsten und am meisten verbreitetsten Hersteller und Modelle von Routern und Switchen. Für die Abfragen kann die SNMP Version 1, 2c oder 3 genutzt werden.

Da auf den Netzwerkgeräten kein Sensu Agent installiert werden kann, werden diese in Sensu Go als “Hüllen” angelegt – sogenannte Proxy-Entities. Die Konfiguration einer solchen Proxy-Entitiy sieht bspw. wie folgt aus. Die verwendeten ‘labels’ sind dabei benutzerdefiniert und werden später in dem Check verwendet.

Für jedes Netzwerkgerät wird nun für Ansible ein derartiges Jinja2-Template in dem Template-Ordner der Rolle, die mit der Sensu API spricht, angelegt. Die Ansible-Tasks dazu sehen bspw so aus:

Können nun alle x-Tausend Geräte automatisiert angelegt werden, fehlen noch die Monitoring-Checks. Einer der Modes, die das Plugin bietet, nennt sich ‘interface-health’. In diesem Modus fragt das Plugin die Auslastung, Error- und Discard-, sowie Broadcast-Pakete, eingehend und ausgehend von allen Interfaces des Gerätes ab. Für die Berechnung der Deltas legt es hierzu eine temporäre Datei im Dateisystem (standardmäßig unter /var/tmp/) ab. Die Checkkonfiguration in Sensu Go sieht nun wie folgt aus:

Damit der Check ausgeführt werden kann, benötigt es mindestens ein System, welches den Sensu Agenten installiert hat und auf die Subscription “network_poller” horcht. Das Attribut “proxy_requests” fungiert anschließend wie eine Art foreach-Schleife und ruft für jede Entity, die der Entity-Klasse “proxy” entspricht, diesen Check aus. Es ist also nicht notwendig, den Check für jedes Netzwerkgerät einzeln anzulegen. Auch Massenänderungen sind somit nicht mehr notwendig. Gleichzeitig unterstützt Sensu Go das Format der Nagios Plugins, wodurch es den Check-Output verarbeiten und wunschgemäß weiterleiten kann – z. B. in eine TimeSeries Datenbank wie InfluxDB, die als Quelle für Visualisierungen mit Grafana dient.

Wer noch einen Schritt weiter gehen möchte, verbindet seine CMDB (Configuration Management Database) mit Sensu Go bzw. Ansible und erstellt darüber automatisiert alle Geräte, die in dem Monitoring enthalten sein sollen.

Bei becon haben wir eine Schnittstelle zwischen der CMDB i-doit und Sensu Go über Ansible realisiert und verteilen damit auch Sensu Go Agenten, sowie deren Konfiguration. Durch das Zuweisen neuer Subscriptions können sich Hosts / VMs / Container ohne weitere Konfigurationsanpassungen in Sensu Go neue Checks abbonieren und ausführen.

Mit diesem Setup dauert es nur wenige Minuten, um das Monitoring einer großen Umgebung zu administrieren und neue Checks, sowie Geräte zu implementieren.

Die Kombination aus Sensu Go, Ansible und dem Plugin check_nwc_health ist ein sehr mächtiges Toolset zum Überwachen und Administrieren von Netzwerkumgebungen beliebiger Größe.

 

Weitere Hinweise zur Verwendung

Je nach Größe der Umgebung reicht ein Agent, der alle Netzwerkgeräte prüfen soll, eventuell nicht mehr aus. In diesem Fall kann ganz einfach ein zweiter Agent mitbenutzt werden. Diesem muss dafür die passende Subscription zugewiesen werden (“network_poller”). Wichtig ist dann auch die Funktion “round-robin: true” in der Checkkonfiguration zu nutzen. Diese stellt sicher, dass auf beide Agenten gleichmäßig verteilt wird.

Da das Plugin für das automatische Errechnen von Deltas temporäre Dateien auf dem ausführenden System anlegt, können in einem Setup mit mehr als einem verantwortlichen Agenten Fehlberechnungen entstehen. Aus diesem Grund sollten die temporären Dateien über eine beliebige Methode (fileshare, rsync, lsyncd, etc.) zwischen den verantwortlichen Agenten synchronisiert werden. Alternativ können auch andere Plugins verwendet werden, die nicht mit temporären Dateien arbeiten. Im Optimalfall bietet das Plugin eine Option, die es erlaubt die unverarbeiteten Raw-Daten auszugeben. Werden diese in einer Datenbank gespeichert, kann die Berechnung später ganz einfach in Grafana vorgenommen werden.

Photo by Anastasia Dulgier on Unsplash.
Code-Beispiele Copyright by Sensu Inc.

Webinar: Sensu Go | Die neue Monitoring Event Pipeline. Von der Architektur über Funktionen bis hin zu ersten einfachen Anwendungsbeispielen. Jetzt reinklicken!

Monitoring Studie

Open Source Monitoring Guide

Dieses Whitepaper betrachtet die am häufigsten eingesetzten und momentan angesagtesten Open Source Monitoring Lösungen am Markt. Sie erhalten mit diesem Entscheider- und Experten-Guide geballte Informationen ohne Dampfplauderei. Neben der Betrachtung der unterschiedlichen Stärken und Schwerpunkte der Lösungen, erhalten Sie einen Einblick in Einsatzgebiete und Anwendungsszenarien von Nagios, Icinga, Icinga2, Naemon, Check_MK, OpenNMS, Zabbix, Prometheus und Sensu. Für die Erstellung der Inhalte haben wir uns mit den Branchenexperten Christian Michel, André Niemann, Dr. Michael Schwartzkopff, Heiko Strugalla und Markus Thiel zusammengetan, die ihre langjährige Praxiserfahrung einfließen ließen.

blog

Ähnliche Blogartikel

Kontakt

Ihr direkter Draht zu uns

Sie haben Fragen, Anregungen, Wünsche oder stehen vor einer besonderen Herausforderung? Wir freuen uns, von Ihnen zu hören!