Icinga als Enterprise-Monitoring-Loesung

Dmitri Zakovorotny, 123RF

Neuland

Eine immer größere Community schart sich um den Nagios-Fork Icinga. Dieser Artikel versucht eine Bestandsaufnahme und stellt das Business-Process-Addon und die LDAP-Konfiguration vor.
Thematischer Schwerpunkt dieser Ausgabe ist die kontinuierliche Überwachung von Servern, Clients und anderen Geräten im Netzwerk: mit dem IPMI-Plugin, dem ... (mehr)

Das als Fork von Nagios entstandene Projekt Icinga [1] hat sich in gut eineinhalb Jahren zur Enterprise-Variante der wohl am weitesten verbreiteten Open-Source-Monitoringlösung weiterentwickelt. Mit über 35 000 Downloads [2] und einer wachsenden Benutzergemeinde bietet Icinga heute eine stabile Version mit allen aus Nagios bekannten Features und darüber hinaus einer Vielzahl an Verbesserungen. Neben vielen Optimierungen im Bereich des Icinga-Core, der neben vereinfachter Installation auch die zusätzliche Unterstützung von Oracle und PostgreSQL beinhaltet, ist beim Webinterface etwas von Grund auf Neues entstanden.

Neben den aus Nagios bekannten CGIs, die auch in Icinga dabei sind und dort mit vielen Features wie Multiselect und einer Export-Schnittstelle erweitert wurden, bietet das auf PHP basierende Interface viele lange von der Community geforderte Funktionen. Dieser Artikel gibt Einblicke in die bestehende Architektur, das technische Konzept, die Funktionen und wichtigsten Erweiterungen, die für Icinga heute verfügbar sind.

Architektur

Wie Abbildung 1 zeigt, bildet die Datenbank in der aktuellen Architektur das zentrale Bindeglied zwischen dem eigentlichen Core-Prozess und dem neuen Webinterface. Alle Daten werden mit der im Core-Teil integrierten Datenbankschnittstelle (IDOUtils) in ein zentrales relationales Schema übertragen. Auf diese Informationen greift Icinga-Web mit PHP-PDO zu, um die Daten unter Berücksichtigung von Filtern und Berechtigungen an den Benutzer auszuliefern.

Abbildung 1: Im Mittelpunkt der Icinga-Architektur steht die Datenbank. Das können nun neben MySQL auch PostgreSQL oder Oracle sein.

Der Datenbankzugriff wird in künftigen Versionen von Icinga mit Doctrine [3] abgebildet, das sich als Object Relational Mapper um die eigentlichen Abfragen kümmert und so die Datenbankunabhängigkeit sicherstellt. Das Webinterface selbst kann auf dem Icinga-Hauptserver oder einem anderen Webserver installiert werden. Das Doku-Team von Icinga hat den Installations- und Upgrade-Prozess ausführlich auf [4] beschrieben.

Zu den wichtigsten Kriterien bei der Entwicklung des neuen Webinterface gehörten die Modularität der Komponenten sowie die Möglichkeit, Erweiterungen von Frontend-Bausteinen, den so genannten Cronks, und Modulen zu vorzunehmen, ohne das eigentliche Core-Framework verändern oder berücksichtigen zu müssen. Auch die Verwendung einer einheitlichen Benutzerverwaltung und Autorisierung von Anwendern gegen das Basisframework war und ist selbstverständlich von großer Bedeutung.

Die Wahl fiel gleich zu Beginn des Projekts auf Agavi, ein auf Mojavi basierendes MVC-Framework, das sich um das Kerngeschäft eines Framework kümmert und dem Entwickler keine Vorschriften zum verwendeten Persistenz-Framework oder Templatesystem macht.

Sinn dieses Model-View-Controller-Konzepts ist die klare Strukturierung einzelner Applikationselemente bei gleichzeitiger Unterstützung eines flexiblen Entwicklungsprozesses. Ein Listing des Icinga-Webfolder lässt den entsprechenden Grundaufbau im Filesystem erkennen. Die eigentlichen Userviews basieren auf HTML, CSS und dem Javascript-Framework Sencha Ext JS.

Der Vorteil dieses Javascript-Framework liegt in der Unterstützung einer Vielzahl von Browsern und der Bereitstellung der klassischen Grundfunktionen, zum Beispiel Tabellen, Layouts und Panelvarianten. Durch Sencha Touch ist vor Kurzem auch noch ein leistungsfähiges Framework für mobile Applikationen hinzugekommen, das bereits in Icinga Mobile [5] Verwendung findet.

Addons

Gerade der Vielzahl an vorhandenen Erweiterungen und Plugins ist die Popularität von Icinga zu verdanken. Neben bestehenden Addons wie Nconf [6] , Nagvis [7] oder PNP4Nagios [8] sind in den letzten Monaten einige neue Erweiterungen hinzugekommen, die gerade in großen Umgebungen die Arbeit mit Icinga erleichtern und die Möglichkeiten der Plattform ausnutzen. Auf die aus Sicht des Autors wichtigsten Addons, nämlich das Business-Process-Addon sowie auf Lconf geht der Artikel im Folgenden genauer ein.

Das Business-Process-Addon für Nagios und Icinga [9] hat dessen Entwickler, Bernd Strössenreuther, erstmalig auf der Nagios-Konferenz 2007 vorgestellt. Motivation war – wie so oft im Open-Source-Umfeld – der eigene Bedarf, komplexe Zusammenhänge zwischen Systemen darzustellen und entsprechend auszuwerten.

Die Erweiterung ist mit einer wachsenden Basis von Icinga- und Nagios-Benutzern aus vielen Umgebungen nicht mehr wegzudenken und wird aufgrund steigender Anforderungen in Bezug auf Service Level Monitoring immer wichtiger. Die Grundfunktion des BP-Addon ist sehr einfach. Es verknüpft die Einzelzustände verschiedener Systeme mit UND- oder ODER-Bedingungen – bei Bedarf auch über mehrere Ebenen hinweg – und erlaubt so die systemübergreifende Zustandsermittlung.

Klassisches Beispiel ist die Webserver-Farm mit einigen Frontend-Servern. Zwar ist der Ausfall eines Servers für den Admin durchaus wichtig, auf den Service und dessen Verfügbarkeit hat er aber keinen tatsächlichen Einfluss und ist auf dieser Ebene somit auch differenziert darzustellen. Ergänzend zur Verbindung von Objekten kann die Konfiguration auch mit Schwellenwerten, in diesem Fall mit der Mindestanzahl verfügbarer Frontend-Server, umgehen und das Ergebnis entsprechend interpretieren.

Das Monitoring von Geschäftsprozessen erlaubt zugleich einen anderen Blick auf die vorhandene Systemlandschaft. Obwohl die Forderung nach einer solchen Sicht meist beim Management oder dem eigentlichen Service-Kunden entsteht, bietet sie auch für Administratoren einen sinnvollen Mehrwert. Er entsteht quasi automatisch durch die Service-orientierte Betrachtung von Warn- und Fehlerzuständen, die den Blick auf das Wesentliche erleichtert und dem Admin die priorisierte Abarbeitung nach den Auswirkungen das Ausfalls ermöglicht.

Erfordert etwa der Ausfall einer redundanten Raid-Disk als Critical-Status zwar das Eingreifen des Admin, ist er dennoch im Vergleich zum Komplettausfall einer wichtigen Datenbank wesentlich niedriger zu priorisieren. Dieser entscheidende Vorteil macht den Einsatz eines solchen Addon unverzichtbar.

Die Schwächen der bestehenden Lösung sind weniger im vorhandenen Featureset zu sehen, sondern eher in der Konfiguration komplexer Prozesse und deren visueller Analyse. Genau hier setzen die Business Cronks for Icinga [10] an. Sie werden neben der PNP4Nagios-Integration im Contrib-Folder von Icinga-Web mitgeliefert und mit Phing, einem PHP-Buildtool, installiert. Die Cronks setzen auf einer bereits installierten BP-Addon-Version auf und kommunizieren mittels HTTP und Json, um die entsprechenden Prozesszustände an das Webinterface zu übertragen.

Die Icinga-Integration des BP-Addon besteht aus zwei Komponenten: dem Editor-Cronk zur Erstellung und Bearbeitung bestehender Konfigurationen und dem Overview-Cronk für die Ansicht der aktuellen Prozesse und deren Status. Beide Elemente stehen nach der Installation in der Sekundärnavigation von Icinga zur Verfügung und lassen sich mittels Doppelklick oder Drag&Drop öffnen.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023