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 Management-System neu starten. In Icinga übernimmt das der so genannte 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. Als bestes Beispiel wären Konnektoren für Ticketsysteme zu nennen. 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. So wären standortbezogene Management-Server denkbar, die ihren Status an einen zentralen Server schicken. Dadurch erfolgt auch eine Lastverteilung. 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. (ue)