Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Open IT-Cockpit

In dasselbe Horn stößt auch Open IT-Cockpit [4] .

Open IT-Cockpit: "Open IT-Cockpit bietet deutlich mehr als nur reines technisches Infrastruktur-Monitoring – im Unterschied zu den meisten Nagios-basierten Varianten oder Forks. Der Fokus des Projektes liegt darauf, Business-Anforderungen an intelligente Überwachungssysteme zu erfüllen. Dazu gehören zum Beispiel die Geschäftsprozessüberwachung, IT-Service-Dashboards, SLA-Monitoring, SAP-Monitoring, End-to-End-Messungen, Eventkorrelation, Reporting und vor allem die Integration von angrenzenden Applikationen wie Ticketsystemen oder CMDBs über eine entsprechende API. Open IT-Cockpit besitzt zudem ein umfangreiches und leicht zu bedienendes Webfrontend zur Konfiguration und Administration von Nagios. Benötigte man für die Verwaltung des Originals noch erweiterte Nagios- und Linux-Kenntnisse, lässt sich Open IT-Cockpit einfach und intuitiv von jedermann bedienen.

Open IT-Cockpit bietet ein Webfrontend, das mehrere Open-Source-Tools integriert und zu einer Einheit verschmilzt (Umbrella Management System). Ein Beispiel: Während bei anderen Projekten bereits eine eigene Kartenverwaltung kostenpflichtig hinzubestellt werden muss, ist für diese Zwecke bei Open IT-Cockpit ohne Aufpreis NagVis implementiert. Open IT-Cockpit eignet sich besonders zur Überwachung komplexer, unübersichtlicher oder über mehrere Standorte verteilter Infrastrukturen."

Shinken

Auch die Entwickler von Shinken [5] sind sich sicher, manches besser machen zu können als das Vorbild. Sie integrieren allerdings das originale Nagios nicht, sondern entwickeln es in Python von Grund auf neu. Was kann ihre Lösung, was Nagios nicht kann? Die Antworten kommen Schlag auf Schlag:

Shinken: "Zum Beispiel skalieren. Durch die Aufteilung in spezialisierte Prozesse wird bei Shinken bereits ein Minimalsystem so weit entzerrt, dass Bottlenecks vermieden werden. Jede Komponente einer Shinken-Installation kann in beliebiger Zahl vorhanden sein und auf einem beliebigen Rechner laufen. Bei wachsender Anzahl von überwachten Objekten wächst das Monitoring-System einfach mit. Dies kann auch dynamisch geschehen, indem man Worker-Prozesse in eine Cloud verlagert und einfach zu- oder abschaltet. Trotz dieser flexiblen Architektur wird nur eine einzige Konfiguration gepflegt. Shinken kümmert sich um die ausgewogene Verteilung der Monitoring-Aufgaben.

Shinken bietet zudem mehr Ausfallsicherheit. Die Möglichkeit, mehrere Prozesse des gleichen Typs laufen zu lassen, dient nicht nur der Lastverteilung. Beim Ausfall eines Prozesses übernehmen die anderen dessen Aufgaben. Auch ist es möglich, Prozesse nur im Standby-Modus zu starten. Shinken kümmert sich dabei selbstständig um das Failover.

Dedizierte Worker-Prozesse (die Plugins ausführen) können dort laufen, wo sie benötigt werden, beispielsweise in einer DMZ oder an einem Außenstandort. Checks für entsprechend markierte Hosts werden von Shinken automatisch zu diesen Workern geroutet.

Eine eigene Logik für Business-Prozesse ist nativ in Shinken enthalten. Services können ein vordefiniertes Kommando »bp_rule« verwenden, dessen Argumente logische Verknüpfungen mit anderen Services sind. Der Status wird dann durch die Berechnung dieser logischen Formeln ermittelt.

Im Unterschied zu Nagios kennt Shinken Prioritäten für Objekte. Das neue Attribut »business_impact« erlaubt die Kategorisierung von Hosts und Services nach ihrer Wichtigkeit. Dazu vergibt man Werte von » « (unwichtig, Testsystem) bis »5« (hoch kritisch). Man kann damit etwa einstellen, dass nachts nur bei Ausfüllen von Hosts oder Services mit einem »business_impact« größer »3« Notifications verschickt werden.

Probleme und Impacts: Für Shinken ist Critical nicht gleich Critical. Fällt zum Beispiel ein Switch aus, so wird er und alle dahinter hängenden Hosts als defekt angezeigt. Vorausgesetzt, es wurde eine Parent-Child-Beziehung zwischen dem Switch und den Hosts definiert, erkennt Shinken, dass der kaputte Switch ein Problem und die als Down angezeigten Hosts daraus resultierende Impacts sind. In der GUI gibt es eine eigene Sicht dafür. Man kann sich also durch Klick auf einen Host die Ursache anzeigen lassen sowie durch einen Klick auf den Switch die Auswirkungen des Defekts."

Ähnliche Artikel

comments powered by Disqus
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