System-Management

Microsoft SCOM versus Nagios

20.12.2011
Von Markus Bäker

Das Data Warehouse

Betrachtet man bei den beiden Systemen das "Data Warehouse", also die Ablage der gewonnenen Daten, so treten gravierende Unterschiede zu Tage. Während SCOM auf den etablierten SQL Server setzt, sind die Ansätze bei Nagios, eine Datenbank wie MySQL zu verwenden, bisher eher von mäßigem Erfolg. Tatsächlich setzt ein Großteil der Nagios-Server immer noch auf die Speicherung in Dateien. Dass dies zu Problemen bezüglich Performance etwa aufgrund von Größe und Locking führt, dürfte klar sein. Erfreulich ist allerdings, dass die Icinga-Entwickler sich insbesondere diesen Punkt auf die Fahnen geschrieben haben. Eine Historie von Performance-Daten (Antwortzeiten, Füllstand, etc.) kann mit Icinga nur sinnvoll über Add-Ons erreicht werden, die einfach zu integrieren sind. Der SCOM sammelt die Daten per Agent und ermöglicht von Hause aus entsprechende Statistiken.

Relevant ist auch, wie zu überwachenden Systeme erfasst werden. SCOM bietet hier ein Auto-Discover, sowohl (sub-)netzwerkbasierend, als auch Active-Directory-integriert, wohingegen Icinga seine Informationen aus einer oder aus mehreren Textdateien bezieht. Diese werden zwar von einigen Administratoren automatisch generiert, in den meisten Fällen jedoch nach wie vor von Hand gepflegt, was recht fehleranfällig ist. Diese Fehleranfälligkeit lässt sich jedoch durch sinnvolle Vorlagendefinitionen für die einzelnen Überprüfungen erheblich reduzieren. Hintergrundinformationen über das System selbst, also Hauptspeicher, Prozessortyp, Betriebssystem etc. werden in Icinga über eine so genannte extended Host Information ebenfalls von Hand erfasst. Der SCOM liest diese Infos direkt aus und stellt sie zur Verfügung. Durch die seit einiger Zeit erhältlichen Cross Platform Extensions ist dies nicht nur auf Windows-Systeme beschränkt. Der Zugriff auf diese möglichst aktuellen Information kann eine wertvolle Hilfe bei einer Störungsbeseitigung oder Fehlersuche sein.

Einführung von Überwachungssystemen

  • Klar definieren, was und wie tief überwacht werden soll;

  • Lizenzkosten den geschätzten Aufwänden gegenüberstellen;

  • Automatisierung von Problemlösungen vorantreiben;

  • nicht als eigenständiges System betrachten, sondern als Komponente in einer Systemlandschaft (Tickettools);

  • gegebenenfalls Produkte kombinieren, zum Beispiel über SCOM2Nagios.

Customizing und Pflege

Ein wesentlicher Aufwand bei der Einrichtung einer Überwachungssoftware entsteht durch das Customizing beziehungsweise die Pflege des Systems. Gerade die Einrichtung neuer Überwachungen und Alarme sowie das Anpassen der Schwellwerte stellen den größten Aufwand innerhalb eines Einführungsprojekts dar. Es ist somit von Vorteil, wenn auf fertige Skripte zurückgegriffen werden kann. Für Nagios hat die sehr aktive Community bereits über 390 nützliche Add-ons bereitgestellt. Auch im SCOM-Umfeld existiert eine starke Community, die Management Packs (MP) vorhält. In diesen MPs werden alle Informationen hinterlegt, die für die Erkennung, Überwachung, Alarmierung und das Reporting der zu überwachenden Systemen benötigt werden. Das MP wird in SCOM importiert und automatisch an die Agenten verteilt. Durch Discovery Tasks entscheiden diese, ob die Überwachung für sie relevant ist.

Dieser Aufbau ist ein großer Vorteil von SCOM in einer Microsoft-lastigen Umgebung, da umfangreiche und kostenlose Management Packs zu allen wesentlichen Produkten von Microsoft angeboten werden. In diesen ist zum Beispiel das fundierte Produktwissen der Exchange-Entwickler hinterlegt, die sinnvolle Schwellwerte und mögliche Lösungen eines Problems in der integrierten Knowledge Base beschrieben haben. So beinhaltet das Active Directory Server 2008 Management Pack über 850 fertige Regeln zu Überwachung des ADDS. Auch viele Drittanbieter bieten MPs an.