Die Schattenseite von Autodiscovery

Das große Problem von automatisch erfassten Umgebungen ist das Prinzip Masse statt Klasse. Ein Blick auf ein Monitoringsystem gibt meist schnell darüber Aufschluss, ob kontrolliert gearbeitet wurde oder schlichtweg alles überwacht wird, was sich NMap und lokalen Agenten nicht entziehen konnte.

Das erstes Problem, das daraus resultiert, ist die meist unqualifizierte Alarmierung die zu Mail-Regeln mit anschließenden Papierkorb-Verschiebungen führt. Alternativ behilft sich der Admin dann damit, dass er alle ihm nicht wirklich bekannten Services auf Downtime setzt oder die Notifizierung deaktiviert. Im Ergebnis weiß dann keiner mehr so genau, was, wie und vor allem warum überwacht wird. Ein weiteres Problem ist das Lifecycle-Management einer solchen Umgebung. Durchläuft das Überwachungs-Setup nicht die klassischen Status Entwicklung, Test/QA und Produktion sind die Konsequenzen leicht abzusehen: Es wird entweder alles, nichts oder das Falsche alarmiert. Unterschiedliche Prioritäten lassen sich schwer qualifizieren, die Admins werden demotiviert und am Ende werden SMS-Alerts konsequent ignoriert.

Wie geht es besser

Macht man sich erst beim Einrichten des Monitoring Gedanken über die vorhandene Infrastruktur, ist schon zuvor einiges schiefgelaufen. Wenngleich die Pflege einer CMDB und die Einführung eines Konfigurationsmanagements mit großen Aufwänden verbunden sind, handelt es sich doch meist um eine lohnende Investition. So ist dann die Hard- und Softwareausstattung aller Systeme schon vor Einbau in das Rack bekannt. Daraus leitet sich dann auch auf logische Weise ein vernünftiges Monitoring ab. Parallel zur Installation des Servers, der Monitoring-Clients und Agenten lassen sich so auch passende Checks deployen und in das Monitoring-System übertragen.

Viel wichtiger jedoch ist die nachhaltige Weiterverarbeitung von Events und Fehlern, die für ein aussagekräftiges Problem-Management notwendig sind. Werden Services also automatisch generiert und eindeutige CI-Informationen wie etwa die CI-ID aus dem CMDB-System an den Check übergeben, können die daraus resultierenden Fehler und die Alarme später wieder dem betroffenen Objekt zugeordnet werden. Aus dem Configuration Item für ein SAN-Volume wird so also ein SAN-Check mit Custom Variable und im Fehlerfall wieder ein Alert, der diese Komponente eindeutig identifiziert. Dann ist es nur noch ein kleiner Schritt, um aus dem Alert die dazu passenden CMDB-Informationen abzurufen.

Zu guter Letzt sei noch ein kurzer Blick über den Tellerrand gestattet: Nagios und Icinga sind zwei hervorragende Monitoringsysteme, die sich nicht nur zum Überwachen von Servern, Switchen oder Storage-Systemen eignen, sondern die auch inventarisieren können. So ist es Nagios oder Icinga beispielsweise möglich, durch kleinere Anpassungen von Standardprüfungen ohne Probleme Seriennummern, Anzahlen von Prozessoren, Arbeitsspeicher oder Festplatten und natürlich deren jeweilige Auslastung zu liefern. Die auf diesem Weg gewonnenen Daten können für spätere Auswertungen einem Business-Report zugutekommen oder schlicht und einfach in die CMDB zurückfließen, was viele immer wiederkehrende Pflegearbeiten spart. (jcb)