Foto: freepik macrovector
Die wenigsten IT-Unternehmen arbeiten heute noch mit einem einzigen, homogenen Netzwerk. Hybride Strukturen mit Systemen vor Ort und in der Cloud, verteilte Niederlassungen und Rechenzentren, digitalisierte Umgebungen, die an die zentrale IT angebunden sind, aber auch funktional unterteilte Netzwerke sind die Normalität. Vor allem bei kleinen und mittleren Unternehmen trägt meist ein zentrales IT-Team die Verantwortung für alle Bereiche und muss daher standortübergreifend laufend über Verfügbarkeit und Performance der relevanten Systeme informiert sein. Aber auch in großen Unternehmen benötigt das IT-Management in der Regel einen zentralen Überblick über die wichtigsten Systeme an den Standorten; vor allem, wenn Prozesse über mehrere Netzwerke bzw. Infrastrukturen greifen wie beispielsweise bei der Anbindung von digitalisierten Umgebungen an die IT. Das Monitoring mehrerer Netzwerke erfordert allerdings zusätzliche Maßnahmen. Das kann je nach eingesetzter Lösung erhöhten Konfigurationsaufwand bedeuten, aber auch zusätzliche Module und Lizenzen – immer vorausgesetzt, die Lösung unterstützt überhaupt das Monitoring verteilter Standorte.
Grundsätzlich gibt es zwei (praktikable) Methoden, verteilte Standorte zentral zu überwachen:
- mittels Polling Engines;
- mit einer zentralen Instanz und Monitoring-Servern an den einzelnen Standorten.
Eine dritte Methode wäre ein agentenbasiertes Monitoring, bei dem die Agenten so konfiguriert werden, dass sie die ermittelten Daten direkt an die zentrale Instanz schicken. Das erfordert allerdings einen derart hohen Aufwand bei der Konfiguration der Netzwerkverbindungen und der Firewalls, dass diese Option nur bei sehr kleinen Szenarien vertretbar ist.
Polling Engines
Je nach Hersteller werden Polling Engines auch als Remote Probes oder Monitoring Engines bezeichnet. Es handelt sich dabei um einen Dienst, der innerhalb eines Netzwerks installiert wird – nicht mit Agenten zu verwechseln, die auf jedem zu überwachenden Gerät installiert werden müssen. Dieser Dienst sammelt über klassische Protokolle wie SNMP, NetFlow, Eventlog u.v.m. Informationen zu Zustand und Performance innerhalb des Netzwerks und schickt die Daten zur Auswertung an die zentrale Monitoring-Instanz. Die Methode bietet eine ganze Reihe von Vorteilen:
- einfache Konfiguration der Firewalls;
- zentrale Auswertung der Monitoring-Daten, die auch erlaubt, überwachte Elemente in Relation zueinander zu setzen – wichtig beim Monitoring übergeordneter Prozesse;
- kann auch zur Skalierung bei großen Monitoring-Szenarien eingesetzt werden.
Monitoring verteilter Netzwerke via Remote Probes (Polling Engines) am Beispiel von Paessler PRTG.
Vor allem sehr große Umgebungen können das Polling Engines-Prinzip an seine Grenzen bringen, wenn nämlich die zentrale Einheit mit der Auswertung der empfangenen Daten überfordert ist. Dann bleibt Methode 2:
Verteilte Monitoring-Server
An jedem Standort läuft eine eigene Instanz der Monitoring-Software. Diese wertet die Monitoring-Daten vor Ort aus und schickt die Ergebnisse an eine zentrale Instanz. Das kann ein einfaches Dashboard sein, das lediglich die Ergebnisse der unterschiedlichen Standorte abbildet. Es kann aber auch eine Lösung sein, die Daten der einzelnen Systeme in Relation setzt und so bereichsübergreifende Prozesse abbilden kann. Letzteres wird umso wichtiger, je größer und je mehr miteinander verbunden die überwachten Umgebungen sind. Bei Tausenden von überwachten Elementen müssen Prozesse oder IT-Services definiert werden, um den Überblick zu behalten, ansonsten droht Chaos. Wenn beispielsweise diverse Festplatten mangelnden Restspeicher melden, kann das bedeuten, dass ein wichtiges Backup nicht mehr durchgeführt werden kann, es könnte sich aber auch um Platten handeln, die lediglich für nachgeordnete Aufgaben benutzt werden – bei Tausenden überwachter Platten erfordert das erst eine Recherche durch die Verantwortlichen. Ist allerdings der Backup-Prozess mit allen involvierten Komponenten als ein IT-Service definiert, kann das Monitoring die entsprechende Priorisierung bei der Benachrichtigung setzen und ein schnelles Eingreifen ermöglichen.
Eine zentrale Einheit sammelt die Ergebnisse der lokalen Monitoring-Server und bietet einen prozessorientierten Überblick.
Einbinden oder ersetzen?
Oft existieren bereits lokale Monitoring-Setups, die auch durchaus ihren Zweck erfüllen, sich aber nicht für das Überwachen mehrerer Standorte eignen. Müssen diese lokalen Umgebungen in ein zentrales Monitoring-Szenario eingebunden werden, gibt es grundsätzlich zwei Optionen: die Integration des lokalen Monitoring-Tools bzw. der Monitoring-Ergebnisse in eine übergeordnete Lösung oder die Ablösung der existierenden Lösung durch eine neue Lösung, die ein homogenes Monitoring für alle Standorte ermöglicht. Existierende Lösungen sind oft maßgeschneidert und haben sich über einen längeren Zeitraum bewährt. Das spart Kosten und Aufwand. Außerdem müssen die Kollegen sich nicht in neue Systeme einarbeiten. Allerdings setzt das voraus, dass sich die vorhandenen Tools in die zentrale Lösung integrieren lassen und auch sonst zukunftssicher sind. Auf der anderen Seite kann das Ersetzen der lokalen Tools durch eine zentrale, neue Lösung auch Vorteile bieten wie etwa neue technische Möglichkeiten beim Monitoring oder eine einheitliche Lösung im gesamten Unternehmen (verringerter Schulungsbedarf, geringere Kosten und Aufwände bei Wartung und Beschaffung). Hier gilt es, gut abzuwägen.
Achtung Falle – Vorsicht beim Preis!
So viele Monitoring-Lösungen es gibt, so viele Lizenzmodelle finden sich dazu. So werden Lizenzen nach Funktionsumfang berechnet, nach Zahl der Nutzer, der überwachten Geräte oder der überwachten Aspekte auf den Geräten. Manche Hersteller packen den kompletten Funktionsumfang in jede Lizenz, andere bieten Baukästen mit zahllosen Modulen und Plugins an. Speziell wenn es um das Monitoring von verteilten Umgebungen geht, kann es schnell sehr teuer werden. So können die Preise für zusätzliche Polling Engines schon mal im fünfstelligen Bereich liegen, oder eine Multi-Server-Lösung (Distributed Edition) kann bei einem ohnehin schon erhöhten Basispreis pro Standort nochmal extra kosten. Auch der Einsatz im MSP-Umfeld schlägt häufig mit speziellen MSP-Lizenzen und zusätzlichen Kosten pro Kunde zu Buche. Hier lautet die Empfehlung, sich zuerst über den Preis zu informieren, bevor man viel Aufwand in die technische Evaluierung steckt, nur um anschließend festzustellen, dass die Lösung jeden preislichen Rahmen sprengt.
Thomas Timmermann, Office of the CEO