Smartes Monitoring
Ein solides Monitoring ist das A und O jeder IT-Infrastruktur, jedes Systemes und jedes Services. Was aber macht ein Monitoring zu einem besseren oder smarteren Monitoring? Wir geben einen Einblick, wie wir das bei der SmartIT umsetzen.
Die SmartIT Services AG setzt auf den PRTG Network Monitor von Paessler in Kombination mit Derdack Enterprise Alert. In den vergangenen Monaten wurde viel Zeit, Energie und Herzblut in die Entwicklung des bestehenden Monitorings hin zu einem konzeptionell neuen Monitoring investiert.
Was am Anfang als Nebenprojekt startete, zog auf Dauer viele zusätzliche Aufwände und Anpassungen mit sich. Schlussendlich wurde das Monitoring 2.0 fast komplett neu gebaut und alle zu überwachenden Devices überführt. Ein zentrales Argument für den Neubau des Monitorings war der Anspruch die Sicherheit des Monitorings zu verbessern, zu standardisieren und so viel wie möglich zu automatisieren.
Zeitgleich wurde in der SmartIT nach einer Plattform für die Verwaltung und Koordination der Pikett-Dienste gesucht. Mit Enterprise Alert von Derdack wurden wir fündig und zugleich mit der Frage konfrontiert: Monitoring und Alarme - schön und gut. Aber was geschieht nach dem Alarm? Neu leiten wir den Alarm an Enterprise Alert weiter und koppeln dadurch das Monitoring an den Pikett-Dienst.
5 vertiefte Einblicke in das Monitoring der SmartIT
1. Sichere Grundlage Um das angestrebte Sicherheitslevel zu erreichen wurde ein eigenes Zonenkonzept erstellt. Das Ziel ist es, die einzelnen Probes optimal zu verteilen. So wurde für jede interne Domäne, bereits vorhandene Zonen und Cloud* Infrastrukturen, eine separate Probe definiert und implementiert.
Alle Probes sind mittels Firewall Regeln und vLans voneinander getrennt. Sie haben immer nur eingeschränkt auf die zur Überwachung benötigten Ports, in die für sie vorgesehenen Netzwerke und darin enthaltenen Devices Zugriff. Sämtliche überwachte Devices werden ausschliesslich durch sogenannte Remote Probes überwacht und übermitteln ihre Daten an die zentrale Core Probe. Bei der Verbindung der Remote Probes zur Core Probe handelt es ich um eine Einweg-Kommunikation. Damit stellen wir sicher, dass sich eine Kompromittierung der Core Probe nicht auf weitere Probes und deren Netzwerke auswirkt.
Weiter wurde das neue Monitoring von Anfang an als Cluster (aktiv/passiv) aufgebaut. Das ermöglicht uns eine nahezu unterbruchsfreie Überwachung.
Da wir unseren Kunden anbieten ihre IT-Infrastruktur vor Ort zu Überwachen und es zwingend notwendig ist, von überall und jederzeit auf das Monitoring zugreifen zu können, muss das Monitoring zwangsläufig ins Internet publiziert werden und daraus erreichbar sein. Aus dem Grund ist es elementar, das Monitoring auch vor externen Angriffen zu schützen. Dies wurde zum einen mittels restriktiver Eingrenzung für die Verbindungen von Probes aus dem Internet und zum anderen mit vorgeschaltetem Reverse Proxy mit PreAuthentication und MFA für den Zugriff auf das Dashboard sichergestellt.
2. Zugriffe und Berechtigungen Um unseren Kunden den Zugriff auf das Monitoring zu ermöglichen, wurde ein Berechtigungskonzept erarbeitet. Darin wird geregelt, wer auf was und wie Zugriff hat.Dies wurde mittels einer Active Directory (AD) Anbindung umgesetzt, in welcher das Management der Benutzer und Gruppen geführt wird.
Innerhalb des Monitorings ist jede AD-Gruppe entsprechend integriert und auf die entsprechenden Probes, Ordner oder Devices im Monitoring berechtigt. Diese detaillierte Zugriffberechtigung hat auch intern viele Vorteile. So werden unseren Smarties nur die für sie relevanten und in ihrem Verantwortungsbereich enthaltenen Devices und Sensoren angezeigt.3.
3. Alarmierung Was, wenn ein Server- Dienst beendet wird oder bei einem Netzwerk-Switch die Hardware defekt ist? Wird ein Fehler durch das Monitoring erkannt, wird eine entsprechende Alarm-Meldung innerhalb des Monitorings ausgelöst. Nach einer definierten Anzahl von Samples, wird der Alarm an ServiceNow weitergeleitet, welches ein Ticket eröffnet und an das zuständige Team leitet. Als Basis Service vergehen maximal 15 Minuten zwischen einem Fehler und der Eröffnung des entsprechenden Tickets. Dies ist jedoch individuell anpassbar, entsprechend dem SLA zwischen der Kundin / dem Kunden und der SmartIT Services AG. Die kleinste implementierte Zeit beträgt zwei Minuten zwischen Alarm und entsprechendem Ticket.
Für das Daily Business und die meisten Komponenten einer IT-Infrastruktur ist die Standardalarmierung allerdings ausreichend. Was ist dagegen mit geschäftskritischen und zentralen Systemen, welche unter Umständen 7/24 zur Verfügung stehen müssen? Zum Beispiel bei Komponenten wie Core Switches, Firewall oder physischen Host im Datacenter, auf welcher unsere SmartIT Cloud betrieben wird.
Hier setzten wir Enterprise Alert von Derdack ein. Alle essenziellen Sensoren, welche für das Datacenter überlebenswichtig sind, sind einer speziellen Library hinzugefügt. Diese hat eine separate Alarmierung, welche parallel zum standardmässigen Alarmierungs-Prozess implementiert ist. In diesem Fall wird der Alarm zusätzlich zu ServiceNow auch an Enterprise Alert übergeben. Enterprise Alert löst einen Pikett-Alarm aus, welcher an alle Datacenter Engineers übermittelt wird. Der bleibt so lange aktiv, bis der Alarm von einem Engineer bestätigt wird. Somit kann sichergestellt werden, dass bei kritischen Alarmen der Alarm auch übermittelt, bestätigt und behoben wird. Innerhalb von Enterprise Alert ist jeder Alarm nachvollziehbar und rückverfolgbar protokolliert.
Eine entsprechende Implementierung für Kunden-Systeme oder eine Alarmierung an den Kunden kann nach Wunsch jederzeit aufgeschaltet werden.
4. Automatisierung Kommen wir zum Herzstück, wieso unser Monitoring smarter ist. Die Automatisierung diverser Tasks, Vorgänge und Arbeiten. Ein Monitoring ist dynamisch und es bedarf einer kontinuierlichen Pflege.
Insbesondere wenn es um das Monitoring unserer Kunden-System geht. Dazu wurde viel Zeit und PowerShell Code-Zeilen investiert, um auf Änderungen und Anpassungen in unserer SmartIT-Cloud automatisch zu reagieren und jederzeit eine komplette und korrekte Überwachung zu gewährleisten.
Im Detail gehen wir auf ein paar implementierte Automatisierungen ein.
Automatischer Abgleich: Damit kein Kunden-System, welches in unserer SmartIT-Cloud betrieben wird, im Monitoring vergessen geht, wird ein automatischer Abgleich aller Virtuellen Maschinen VM und den vorhandenen Devices im Monitoring durchgeführt. Sollte eine VM nicht im Monitoring vorhanden sein, wird diese automatisch im Monitoring aufgenommen und das entsprechende Discovery-Template ausgeführt.
Monitoring anhand der Ausprägung: Anhand der Ausprägung eines Kunden-Systems wird definiert, wie und was bei der entsprechenden VM überwacht wird. Dies wird beim automatischen Abgleich erkannt und mittels den vordefinierten Standard-Templates im Monitoring sichergestellt.
Wartungsfenster: Wer PRTG kennt, kennt auch die Problematik bei der Langzeit-Planung von Wartungsfenstern. Dies konnten wir umgehen, indem wir auf die im PRTG vorhandenen Möglichkeiten verzichten und die Wartungsfenster von extern im Monitoring übersteuern, sprich Devices oder Sensoren für einen definierten Zeitraum pausieren.
Fast alle unsere implementierten Automatisierungen werden mittels Tagging gelöst. Jedem System, jeder VM und jedem Device ist ein Standardsatz an Tag’s zugewiesen, welche Auskunft über den hinterlegten Managed Service, Backupretention, Ausprägung und viele weitere Informationen liefern. Anhand dieser Tag’s kann die Automatisierung erkennen, welche Sensoren ein Device benötigt, wem ein Ticket im Alarmfall zugewiesen werden muss und um welchen Kunden es sich bei der VM handelt.
Unserer Automatisierungen im Datacenter sind unabhängig von Hypervisor, Plattform und Betriebssystem.
5. Reporting Damit wir regelmässig einen Überblick erhalten, was in unserer SmartIT-Cloud und im Monitoring vorgeht, wurden diverse Reports und Exports erstellt und automatisiert. So wird zum Beispiel monatlich ein Export der Kunden-Systeme in der SmartIT-Cloud erstellt, welcher dann mit der CMDB im ServiceNow abgeglichen wird.
Beispiele für weitere eingesetzte Reports:
- Uptime Report der Devices im Monitoring: Dieser enthält alle Devices, welche länger als 60 Tage nicht neugestartet wurden.
- Report der Virtuellen Umgebungen: Dieser enthält eine Auflistung aller Kunden und derer Systeme.
- Report der Performance einzelner Devices im Monitoring
Das Reporting wird stehts erweitert. Reporting-Anforderungen von Kunden können nach Wunsch jederzeit aufgeschaltet werden.
Damit unser Monitoring auch in Zukunft stetig smarter wird, ist das Datacenter-Team jeden Tag am Optimieren, Verbessern und Erweitern. So können wir unseren Kundinnen und Kunden das Vertrauen und die Sicherheit bieten, die sie erwarten und verdienen.
* Die SmartIT Services AG hat im Bereich IT Infrastruktur Services, drei Arten von Clouds. Die Private Cloud, welche beim Kunden vor Ort ist, unsere SmartIT Cloud und die Public Cloud bei Azure.