Zusammenspiel von Überwachungs-Tools
Eingebettetes Monitoring
Ist ein Unternehmen auf die Zuverlässigkeit von IT-Diensten angewiesen - sei es, es bietet sie an oder es nutzt sie für den produktiven Einsatz - ist ein Monitoring derselben Pflicht. Nur so lassen sich Ausfälle der häufig komplexen Systeme schnell beheben oder im besten Fall sogar im Vorfeld verhindern. Doch mit dem Monitoring kommt ein weiteres Tool in der oft bereits komplexe Tool-Landschaft. Jedes erfüllt seine Aufgabe, liefert einen Teil des Gesamtbildes. Für einen tatsächlichen Mehrwert sollten alle Informationen zusammenlaufen, damit ein schneller Überblick möglich wird. Doch wie erreicht man dies in einer heterogenen Landschaft?
Ziel sollte es sein, alle relevanten Basisdaten in jedem System zur Verfügung zu haben. Zusätzlich ist es sinnvoll, schnell zwischen den Tools wechseln zu können, um detailliertere Informationen in greifbarer Nähe zu haben. Redundanzen, wie die doppelte Pflege von Inventarisierungsdaten, gilt es zu vermeiden.
Dazu sind bidirektionale Schnittstellen erforderlich, über die die Systeme intelligent miteinander vernetzt sind. Dies ist allerdings nur möglich, wenn die Tools zwei Voraussetzungen erfüllen: Zum einen wird eine Public API (Programmierschnittstelle) benötigt, über die die Systeme miteinander kommunizieren können. Außerdem muss die GUI (Benutzeroberfläche) durch Widgets oder Plugins erweiterbar sein, damit sich Zusatzinformationen einblenden lassen. Wie eine solche Kopplung aussehen kann, ist anhand einer Best-Practice-Lösung gut darzustellen, die sich aus langjähriger Beschäftigung im Bereich ITSM/Monitoring ergeben hat.
Steht das Monitoring-Tools für sich allein, sind nicht alle Mehrwerte nutzbar, und es garantiert nicht für eine schnelle, effiziente Abwicklung von Ausfällen. Zum einen muss das System mit den Infrastrukturdaten "gefüllt" werden, eine Pflege der Daten muss ebenfalls möglich sein. Zum anderen sollen die ist anhand einer Best-Practice- Lösung gut darzustellen Statusdaten nicht nur in der Monitoring-Ansicht zu Verfügung stehen, sondern dort erscheinen, wo sie sinnvoll zur ergänzenden Information beitragen.
Inventarisierungsdaten sind gewöhnlich bereits vorhanden. Sinnvoll ist es, diese in einer CMDB zu pflegen, direkt verknüpft mit Handbüchern und Notfalldokumenten. Im Beispiel kommt das als Open Source verfügbare CMDB-konforme I-doit (siehe Kasten) zum Einsatz.
Die Bearbeitung von Ausfällen sollte in einem Ticketsystem koordiniert sein. So kann jeder sehen, ob und wer an welchem Problem gerade arbeitet und wie der aktuelle Stand ist. Die Beispiellösung nutzt dazu den De-facto-Open-Source-Ticket-Management-Standard OTRS.
Beide Tools verfügen über eine gute Public API, zudem ist die Oberfläche durch Plugins erweiterbar. Das Monitoring als dritte Komponente übernimmt das Open-Source-basierende Snag-View (siehe Kasten), da es einen hohen Funktionsumfang und eine einfache Konfiguration über die Oberfläche mitbringt. Zudem vernetzt es sich gut mit diversen anderen Tools und bietet viele Schnittstellen.
Die Kopplung zwischen I-doit und Snag-View dient in erster Linie dazu, das Monitoring mit Informationen über die zu überwachenden Systeme zu befüllen und aktuell zu halten. Dazu sind in beiden Systemen Module oder Plugins installiert. Das Snag-View-Modul stellt API-Endpunkte bereit, über die das I-doit-Plugin Daten senden und abrufen kann. Einmal eingerichtet, lässt sich nun jedes Objekt, das zu überwachen ist, über eine zusätzliche Kategorie für den Sync mit Snag-View aktivieren. Dies geschieht einmalig, danach wird jede Änderung am Objekt automatisch über die API an Snag-View übermittelt, um die Daten synchron zu halten.
Durch den Sync entsteht zunächst ein leeres Objekt in Snag-View. Die detaillierte Konfiguration der zu überwachenden Services erfolgt anschließend im Monitoring. Standard-Services, die bei jedem Objekt zu überwachen sind, kann der Nutzer auch in Host-Gruppen hinterlegen, die den Objekten direkt in I-doit zugewiesen sind. Auf diese Weise ist es möglich, aus der CMDB heraus voll konfigurierte Überwachungsobjekte zu generieren, ohne ein einziges Mal die Snag-View Oberfläche aufzurufen.
Im Gegenzug zeigt I-doit den aktuelle Status sowie den Zustand der Services des Objekts an. Über einen Link gelangt der Anwender direkt auf die Detailseite in Snag-View, sollte er genauere Informationen benötigen. Bei jedem Objekt, das aus I-doit heraus generiert wurde, erscheint zudem ein spezielles Symbol, das direkt in die CMDB verlinkt.
Mit der I-doit-OTRS-Kopplung kommt die dritte Komponente ins Spiel. Wählt der Anwender im OTRS bei der Ticketerstellung einen Kontakt aus, fragt die Schnittstelle automatisch bei I-doit an, ob diesem Kontakt Objekte zugeordnet sind. Der Abgleich findet über einen definierbaren Parameter statt - im Normalfall die E-Mail-Adresse des Kontakts. Im Ticketformular findet sich nun eine Liste mit allen Inventarobjekten der Person. Diese lassen sich mit dem Ticket verknüpfen.
Über eine Suche kann der Anwender zusätzlich alle in der CMDB gepflegten Objekte mit einem Ticket verknüpfen, auch wenn sie nicht direkt dem ausgewählten Kontakt zugewiesen sind. Anschließend sind sie in der Ticketansicht mit ihren Statusinformationen und einem Link verfügbar. Gleichzeitig zeigt I-doit alle wichtigen Ticket-Informationen an. Über einen entsprechenden Tab kann der Anwender dann alle mit dem Inventarobjekt verknüpften Vorgänge auslesen und deren Status prüfen.
Bis zu diesem Punkt sind bei Incidents allerdings immer noch Tickets per Hand zu erzeugen. Viel sinnvoller wäre es, dies automatisch geschehen zu lassen. Genau dies erledigt die Schnittstelle zwischen Monitoring und OTRS. Durch das Snag-View-Plugin entsteht ein neuer Benachrichtigungsweg. Sobald ein Incident auftritt, kann automatisiert ein OTRS-Ticket zu dem Zwischenfall generiert werden, in dem bereits alle relevanten Daten wie Objektname, Grund (Zustandsveränderung) und die Fehlermeldung des Check-Plugins enthalten sind. Wichtig dabei: Weitere Benachrichtigungen zum selben Zwischenfall generieren kein neues Ticket, sondern ergänzen das bestehende um die aktualisierten Statusdaten.
Die Bearbeitung des Vorfalls kann nun bequem aus dem OTRS heraus erfolgen. Durch die Informationen im Ticket ist es im Normalfall nicht mehr nötig, zu Snag-View zu wechseln. Auch die Bestätigung des Bearbeiters, sich um das Problem zu kümmern, kann aus OTRS heraus erfolgen. Snag-View setzt das Acknowledged Flag und generiert so keine weiteren Benachrichtigungen. Mehr noch: Normalisiert sich während der Überwachung der Status des Objekts wieder, kann Snag-View das OTRS-Ticket sogar automatisch schließen.
Das Snag-View-Objekt ist bei der Erstellung direkt mit dem Ticket verknüpft. Im OTRS erscheinen in einem Widget dessen Live-Status-Daten. Im Gegenzug kann ein Anwender in Snag-View alle mit dem Objekt verknüpften Tickets und deren Status einsehen.
Alle vorgestellten Kopplungen funktionieren unabhängig voneinander. Wenn ein Unternehmen jedoch alle drei Tools mit Schnittstellen gemeinsam nutzt, geht die Kopplung sogar noch weiter: Bei einem Vorfall benachrichtigt Snag-View das OTRS, prüft aber gleichzeitig, ob das Objekt mit I-doit verlinkt ist. Sollte dies der Fall sein, wird neben der Verlinkung zum Snag-View Objekt zusätzlich die Verlinkung zum I-doit-Objekt dem Ticket hinzugefügt.
Drei Tools mit jeweils eigenen Aufgaben
Was hat ein Unternehmen durch Kopplung der Systeme erreicht? Ziel war es, eine intelligente, bidirektionale Bindung zwischen allen drei Tools des Dreiecks herzustellen, um Redundanzen zu vermeiden und Informationen auszutauschen. Zum einen erfüllt jedes Tool nun eine Aufgabe: Die Pflege der Infrastrukturdaten geschieht in I-doit, Snag-View überwacht den Gesundheitszustand und OTRS kümmert sich um das Incident-Management. Durch die klare Trennung der Zuständigkeiten und den bidirektionalen Abgleich muss der Betreiber keine Redundanzen mehr pflegen. Gleichzeitig sind alle relevanten Daten in allen drei Tools verfügbar. Sollten dennoch detailliertere Informationen nötig sein, sind sie per Mausklick erreichbar.
Diese Kombination schafft einen deutlichen Mehrwert der Systeme, sie ergänzen sich sogar gegenseitig. Probleme lassen sich schneller beheben da alle relevanten Informationen schnell verfügbar sind. Der Workflow ist einfacher, da der Betreiber keine Redundanzen pflegen muss.
Vernetzung sinnvoll
Dieses Beispiel verdeutlicht also, wie sinnvoll eine Vernetzung der oft heterogenen Systeme in einem Betrieb ist. Gerade beim Monitoring vereinfacht und beschleunigt die Kopplung den Workflow ungemein. Durch minimalen Aufwand kann ein Unternehmen bestehende Oberflächen durch zusätzliche Informationen ergänzen, ohne gleich eine eigene, umfassende Ober-fläche generieren zu müssen.
OTRS (Open Ticket Request System) ist der führende Open-Source-Helpdesk. Mithilfe des webbasierenden Ticketsystems lassen sich jegliche Arten von Anfragen wie Störungsmeldungen, Service- oder Informationsanfragen über die Meldewege E-Mail, Telefon und Kunden-Webfrontend strukturiert und revisionssicher erfassen, klassifizieren, speichern und weiterverarbeiten.
I-doit ist eine Open-Source-CMDB-konforme Lösung von Synetics, mit deren Hilfe ein Unternehmen sämtliche Infrastrukturabhängigkeiten (Hardware, Software, Assets, QR-Codes, Lizenzen) der eigenen IT-Landschaft verwalten kann. Über diverse Importmöglichkeiten und Schnittstellen zu Inventarisierungs-Tools lassen sich Daten aus diversen Quellen importieren und in I-doit integrieren.
Snag-View ist eine Open-Source-basierende Enterprise-Monitoring-Software. Sie ermöglicht die Erstellung und Pflege komplexer Monitoring-Systeme mithilfe einer leistungsstarke Vererbungshierarchie, komplett über eine leicht zu bedienende Web-Oberfläche.
Nedi. Die Network-Discovery-Suite des Schweizer Netzwerk-Spezialisten Remo Rickli entdeckt und inventarisiert nicht nur automatisch Netzwerkgeräte, sondern erkennt darüber hinaus auch die Topologie des Netzwerks. Regelmäßigen Scans erfassen Veränderungen in der Infrastruktur und machen sie sichtbar.
Lesen Sie mehr zum Thema
