Wer seine Entscheidung für eine Monitoring-Lösung fundiert treffen möchte, sollte den Blick auf die Lizenzkosten zunächst hintanstellen. Auch auf Basis einer ideologischen Meinung für kommerzielle oder Open-Source-Angebote sollte keine Auswahl getroffen werden. Relevant für einen Entschluss, den man auch Vorgesetzten gegenüber begründen kann, ist eine objektive Abwägung der Vor- und Nachteile inklusive der geschätzten Gesamtkosten für die Einführung und den Betrieb der Software.
Den Ausgangspunkt für die Auswahl des Monitoring-Tools bilden immer eine Ist-Analyse der Umgebung und die Planung zusätzlicher Systeme für die Zukunft. Die anzufertigende Auflistung umfasst alle Serverarten und deren Betriebssysteme sowie andere Objekte im Netz wie Switches, Firewalls, die Unterbrechungsfreie Stromversorgung (USV), Türsteuerungen, Telefonanlagen oder Anlagensteuerungen. Bei dieser Untersuchung interessiert auch, über welche Schnittstellen ein System verfügt, um an die gewünschten Informationen zu gelangen. Die notwendigen Überwachungsparameter werden ebenso definiert.
Zur Auswahl stehen dann zahlreiche Monitoring-Lösungen, die sich je nach IT-Landschaft sehr unterschiedlich für den individuellen Einsatz eignen. Oft stellt sich auch die Frage, ob man unter den Angeboten auf ein kommerzielles Produkt oder auf ein Open-Source-Werkzeug zurückgreifen soll. Um diese Entscheidung zu erleichtern, werden im Folgenden zwei namhafte Systeme exemplarisch gegenübergestellt:
Das erste System ist Icinga, das im Jahre 2010 von einem Teil der Nagios-Community ins Leben gerufen wurde und seitdem mit beeindruckendem Tempo weiterentwickelt wird. Die Grundfunktionen sind nach wie vor in beiden Open-Source-Systemen ähnlich, daher gelten die hier gemachten Aussagen gleichermaßen für beide Varianten. Bestärkt wird dies durch die uneingeschränkte und beabsichtigte Kompatibilität von Icinga zu Nagios und all seinen Add-Ons.
Für die kommerzielle Seite sticht aus der Reihe der System-Center-Produkte von Microsoft der Operations Manager hervor, der häufig als Erzfeind von Open Source angesehen wird. SCOM liegt aktuell in Version 2007 R2 vor und verfügt mit den integrierten Cross Platform Extensions auch über eine Anbindung an Teile der Nicht-Microsoft-Welt.
Anhand dieser weit verbreiteten Lösungen sollen, was die kommerzielle Seite anbelangt, grundlegende Unterschiede und Gemeinsamkeiten zwischen Monitoring-Systemen aufgezeigt werden.
System Monitoring = Daten sammeln
Einer der Hauptunterschiede zwischen den beiden Monitoring-Systemen ist die Art und Weise, wie die Daten der überwachten Systeme gesammelt werden. Icinga verfolgt hier einen eher zentralistischen Ansatz und sammelt die Daten direkt vom Icinga-Server aus ein, während SCOM dies von Agenten erledigen lässt. Beide Systeme erlauben aber auch die umgekehrte Vorgehensweise. So ist es beispielsweise möglich, auf Icinga-überwachten Systemen einen Dienst zu installieren, der das Sammeln und Versenden der Daten übernimmt (sogenannte passive Checks). Ebenso kann der SCOM-Server aktiv zum Sammeln von Daten bewegt werden, zum Beispiel bei Netzwerkkomponenten oder anderen agentenlosen Systemen.
Beide Vorgehensweisen haben Vor- und Nachteile. Beim Datensammeln müssen alle Konfigurationen und Anpassungen lediglich am zentralen Server vorgenommen werden, da es keine dezentralen Agenten gibt. Beim Einsatz von Agenten wiederum können ein Teil der Sammellogik auf den Client verlagert und damit der Server entlastet werden. So reicht es, wenn der Agent den Füllstand einer Festplatte überprüft und beim Überschreiten eines Schwellenwertes einen Alarm auslöst (Modell SCOM), wohingegen ohne Agent (Modell Icinga) in regelmäßigen Intervallen eine entsprechende Kenngröße an den Server übermittelt wird und dieser dann entscheidet, ob der Alarmknopf gedrückt wird. Dies belastet nicht nur den Server, sondern auch die Netzverbindung. Ein einzelner SCOM-Server ist laut Microsoft für die Überwachung von bis zu 3.000 Agenten ausgelegt.
Natürlich gibt es Dienste, die besser "von außen" überwacht werden, zum Beispiel ein Mail-Server. Ein Versuch der Verbindung mit dem entsprechenden Port muss erfolgreich sein, sonst erfolgt ein Alarm. Das allein reicht jedoch nicht aus: Handelt es sich nur um ein Mail-Relay, so wäre es interessant zu wissen, ob die angenommenen Mails auch zeitnah weitergeleitet werden konnten. Ein Webserver hingegen, der auf eine nachgelagerte Datenbank zugreift, sollte mit einer korrekt generierten Seite antworten und nicht nur mit einer beliebigen Seite. Oft ist demnach die Kombination beider Monitoring-Verfahren sinnvoll, also ein Agent, der den Service und abhängige Komponenten überwacht, im Zusammenspiel mit einem externen Verbindungsversuch, wie ihn auch ein Client vornimmt.
Microsoft löst das Problem der dezentralen Umkonfiguration seiner Agenten dadurch, dass der Administrator die einzelnen Konfigurationsänderungen zentral am Server vornimmt und diese dann automatisch an die Agenten übertragen werden. Icinga hingegen arbeitet mit passiven Checks, die es den Clients erlauben, einen Status an einen zusätzlichen Service auf dem Icinga-Server zu melden und diesen dann in die normale Ereigniskette einzusortieren. Bei diesem Entscheidungskriterium ist also interessant, wie und wo die Mehrzahl der benötigten Informationen gewonnen werden kann. Ein weiteres Kriterium wäre, ob der zu überwachende Server durch eine Firewall geschützt ist. In diesem Fall ist unter Umständen eine Abfrage "von außen" per Icinga nicht möglich, aber ein Senden des SCOM-Agenten "von innen" erlaubt.
Das Data Warehouse
Betrachtet man bei den beiden Systemen das "Data Warehouse", also die Ablage der gewonnenen Daten, so werden gravierende Unterschiede sichtbar. 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. Ein Großteil der Nagios-Server setzt immer noch auf die Speicherung in Dateien. Dass dies zu Problemen bei der Performance etwa aufgrund von Größe und Locking führt, dürfte klar sein. Erfreulich ist allerdings, dass sich die Icinga-Entwickler insbesondere dieses Punkts angenommen 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 Haus aus entsprechende Statistiken.
Relevant ist auch, wie die zu überwachenden Systeme erfasst werden. SCOM bietet hier ein Auto-Discover, sowohl (sub-)netzwerkbasiert als auch Active-Directory-integriert, wohingegen Icinga seine Informationen aus einer oder 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 etwa Hauptspeicher, Prozessortyp oder Betriebssystem, werden in Icinga über eine sogenannte 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 Informationen kann eine wertvolle Hilfe bei einer Störungsbeseitigung oder Fehlersuche sein.
Wichtige Punkte bei der 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 beim Einrichten einer Überwachungssoftware entsteht durch das Customizing beziehungsweise die Pflege des Systems. Gerade das Ei9nrichten 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 mehr als 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 Schwellenwerte und mögliche Lösungen eines Problems in der integrierten Knowledge Base beschrieben haben. So beinhaltet das Active Directory Server 2008 Management Pack mehr als 850 fertige Regeln zu Überwachung des ADDS. Auch viele Drittanbieter offerieren MPs.
Alarmierung und darüber hinaus
Nachdem ein Fehler festgestellt wurde, kann eine bei beiden Produkten ähnliche Alarmierung erfolgen sowie eine automatisierte Problemlösung angestoßen werden. Ein einfaches Beispiel wäre ein SSH-Dienst, der auf einem Linux-System regelmäßig abbricht. Hier kann ein Administrator benachrichtigt werden, der den Fehler manuell behebt, oder man automatisiert die Aufgabe und lässt den Prozess durch das Managementsystem neu starten. In Icinga übernimmt das der sogenannte Event Handler, in SCOM sind dafür Diagnostic beziehungsweise Recovery Tasks zuständig. Der Wunsch nach einer fehlerfreien IT ist so zwar noch nicht erfüllt, durch die Automatisierung von Workarounds ist jedoch immerhin ein weiterer Schritt in diese Richtung getan.
Ein Überwachungssystem steht im Allgemeinen nicht alleine da. Daher ist eine Ankopplung an andere Systeme von Bedeutung. Bestes Beispiel sind Konnektoren für Ticketsysteme. Hier bietet SCOM fertige Schnittstellen zu bekannten Lösungen wie Remedy AR Systems. Da die meisten Systeme auch E-Mail-Nachrichten in Tickets umwandeln können, ist über diesen Weg ebenso eine Verknüpfung mit Icinga möglich.
Hierarchien
Gerade in größeren Umgebungen ist ein hierarchischer Aufbau der Monitoring-Lösung wünschenswert. Denkbar sind standortbezogene Managementserver, die ihren Status an einen zentralen Server schicken. Dadurch wird auch die Last verteilt. Icinga unterstützt diesen Ansatz durch diverse Add-ons wie NSCA oder mod_gearman. Der Operations Manager lässt sich ebenfalls verschachteln. Alternativ ist auch der Einsatz von Gateway-Servern möglich, die die Meldungen von einem Standort sammeln und komprimiert weiterleiten. (hal)
Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation Computerwoche.