KVM etabliert sich als Standardlösung zur Virtualisierung unter Linux. Der ADMIN-Schwerpunkt hilft beim Bau virtueller Linux-Maschinen, stellt das ... (mehr)

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 )

Mehr auf der OSMC

Mehr zum Thema Autodiscovery für Monitoringlösungen gibt es auch auf der Open Source Monitoring Conference [7] , die der IT-Dienstleister Netways GmbH in der Zeit vom 17. bis zum 18. Oktober 2012 in Nürnberg ausrichtet, und auf dem ersten PuppetCamp in Deutschland [8] . Mit ähnlichen Themen wie sie dieser Artikel aufgreift, beschäftigen sich dort mehrere Vorträge namhafter Referenten.

Der Autor

Bernd Erk ist Managing Director der Nürnberger NETWAYS GmbH, die sich seit über 15 Jahren auf das Thema Open Source Systems Management spezialisiert hat.

comments powered by Disqus
Mehr zum Thema

Workshop: Eigene Skripte für Nmap entwickeln

Wer möglichen Angriffen auf die eigene Infrastruktur zuvorkommen will, sollte sein Netzwerk typischen Hacker-Attacken aussetzen und die Umgebung kontinuierlich mit Sicherheitsscannern und Penetrationstests unter die Lupe nehmen. Bei Standardaufgaben leisten Nmap & Co. hervorragende Arbeit. Für spezifische Sicherheitsanalysen sollten Sie Ihre eigenen Testskripte entwickeln. Das ist mit der Nmap Scripting Engine möglich. In diesem Workshop bereiten wir den Weg zur Entwicklung eigener Nmap-Skripte.
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