Adacor - Hosting

Monitoring von Hosts, Applikationen und Infrastrukturen mit Centreon und Cacti

30. April 2013 von Timo Ament

Unterschiedliche Anforderungen wie Server-Monitoring und Netzwerk-Monitoring erfordern auch zwei verschiedene Monitoring-Systeme. Wie und mit welchen Tools sich ein effizientes Monitoring von Hosts, Applikationen und Infrastrukturen am besten bewerkstelligen lässt, beschreibt unser Beitrag.

Bei Adacor sind aktuell zwei verschiedene Monitoring-Systeme im Einsatz. Cacti und Centreon. Das Backbone-Netz und die Switch/Router-Infrastruktur wird von Cacti überwacht. Die Centreon-Umgebung überwacht alle Kundenhosts und die internen Server von Adacor.

Monitoring mit Centreon

Monitoring von Hosts, Applikationen und Infrastrukturen mit Centreon und CactiCentreon ist streng genommen nur ein Frontend für das weithin bekannte Tool Nagios. Wir haben uns entschieden Centreon einzusetzen, da es viele Vorteile gegenüber einer Standard-Nagios-Umgebung bietet. Vor allem die Administration über Webfront-Ends ist ein nicht zu unterschätzender Vorteil. Aber mal der Reihe nach…

Centreon ist in der Lage, für verschiedene User unterschiedliche ACL (Access Control Lists) zu benutzen. Wir können daher unseren Kunden den direkten Zugriff auf das Monitoring ihrer Hosts und Applikationen gewähren. Wobei die ACL sicherstellen, dass der Kunde ausschließlich Server und Applikationen aus seinem Projekt sieht und nicht auf die Daten anderer Kunden zugreifen kann.

Plug-In-Architektur gewährleistet Flexibilität beim Monitoring

Nagios bietet für das Monitoring von Servern und den darauf arbeitenden Applikationen eine große Flexibilität. Dies realisiert Nagios/ Centreon über seine Plug-In-Architektur.

Ein Plug-In ist ein Script, das beispielsweise in Perl, Phyton oder Bash geschrieben wurde. Dabei werden die zu monitorenden Parameter am Host meist über SNMP abfragt. Hierzu müssen die Daten natürlich serverseitig in den SNMP-Daemon gehoben werden. Dies wird für CPU-Auslastung, Disk-Belegung oder ähnliches per Default gelöst. Man kann allerdings auch über ein lokales Skript Parameter in den SNMP-Daemon „extenden“. Das Nagios-Plug-In fragt nun diese Werte am Server ab und wandelt sie in einen Nagios konformen Output um. Dieser Output kann anschließend vom Monitoring-System analysiert werden.

Centreon vereinfacht die Administration des Systems, da es eine Konfigurations-Oberfläche für Nagios darstellt, die auf MySQL-Basis sämtliche erstellten Konfigurationen speichert und dem darunterliegenden Nagios in seiner eigenen Syntax als Config-Files aufbereitet.

Ein Nagios-System muss direkt in Config-Files administriert werden. Dies bedeutet bei einer Umgebung in unserer Größe einen nicht zu unterschätzenden Aufwand. Durch Centreon kann die Konfiguration über das Web-Frontend erfolgen, welches die Arbeit mit Templates und Service-Checks enorm vereinfacht.

Vorteile des Centreon Frontends gegenüber Nagios

Außerdem bringt Centreon von Haus aus die Möglichkeit mit, sämtliche erhobenen Performance- und Monitoring-Daten in einer Datenbank zu speichern und über entsprechende Tools auswerten zu lassen. Nagios mit seinen Bordmitteln legt lediglich ein Log-File an. Centreon vereinfacht durch sein Frontend ebenfalls den Aufbau einer verteilten Monitoring-Struktur.

Adacor betreibt ein Konstrukt, das aus je einem Web- und einem Datenbank-Server besteht, welche die Daten von zwölf verteilen Pollern zusammenfassen und aufbereiten. Ein Poller ist ein „einfacher“ Nagios-Host, der vom Centreon-Web-Server „ferngesteuert“ wird. Auf jedem der Poller sind die auszuführenden Host- und Service-Checks als Skripte vorhanden. Centreon weiß, wie das Skript anzusprechen ist und welche Werte und Argumente ihm mitgeliefert werden müssen, um den erwünschten Monitoring-Zweck zu erfüllen. Sämtliche Parameter werden von Centreon in die Konfiguration des Nagios-Pollers geschrieben und dieser führt die Checks dann nach einem Zeitplan aus. Sobald der Check ein Ergebnis erzeugt hat, wird dieses von dem Nagios-Poller in die zentrale Centreon-Datenbank eingeliefert. Das Frontend greift zur Darstellung von Alarmen, Fehlern und allgemeinen Zuständen dann auf die in der Datenbank hinterlegten Check-Ergebnisse zurück und bereitet diese graphisch auf.

Cacti-System zum Monitoring des Backbones, der Switch und Router Infrastruktur

Für das Monitoring des Backbone-Netzes und der Switch/Router-Infrastruktur beitreiben wir hingegen ein Cacti-System, da Statistiken und Diagramme beim Monitoring dieser Einheiten eine größere Rolle spielen.

Centreon kann diese zwar auch problemlos anlegen; Cacti ist hingegen darauf optimiert und kann über Plug-Ins Graphen erzeugen.

Cacti erstellt aus diesen Daten Graphen für alle Interfaces und stellt diese dem internen Plug-In „Weathermap“ zur Verfügung. Hier kann man sich graphische Karten seiner Infrastruktur erstellen und die Links zwischen den „Nodes“ direkt einem Graphen zuordnen. Diese „Maps“ lassen wir in einer Rotation auf einem TV an unserer Wand anzeigen und können so Veränderungen in den Auslastungen der Trunks im Switch-Backbone zeitnah erkennen und darauf reagieren.

Des Weiteren ist unser Cacti-System von uns als SNMP-Trap-Empfänger konfiguriert und empfängt die relevanten Log-Einträge unserer Switch-Infrastruktur als Trap und stellt uns diese somit übersichtlich zur Verfügung. Ebenso werten wir über Cacti, die von uns sowieso schon gesammelten Flow-Samples graphisch aus.

Als weitere Plug-Ins benutzen wir „Nectar“, um uns bestimmte relevante Graphen in periodischen Abständen direkt per Mail schicken zu lassen. Besonders hervorzuheben ist das Plug-In „Threshold“, das dem Cacti-System eine Alarmierungsroutine implementiert.

Ein Cacti in Standard-Konfiguration könnte man als ein ´rein sehendes´ System bezeichnen. Nach Hinzufügen des Threshold-Plug-In ist Cacti in der Lage, bei Überschreiten vorher definierter Grenzwerte eine Aktion auszuführen. Dies kann beispielsweise eine Pager-Nachricht oder eine E-Mail sein.

Verwandte Artikel