Vergleich - Microsoft SCOM gegen Nagios

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.