Im Sommer 2021 habe ich in einem Blog geschildert, wie eine Konfigurationsänderung, gepaart mit vielen Spam-E-Mails, einen Puffer-Speicher eines SMTP-Relays überlaufen ließ, sodass keine E-Mails mehr von außen empfangen werden konnten.
Reine Hardware- und Server-Überwachung reicht nicht aus
Im oben genannten Beispiel haben die involvierten Komponenten, einschließlich Switches, Router, physischer und virtueller Server zu keiner Sekunde aufgehört zu funktionieren. Jede Überwachung auf Basis gängiger Verfahren wie ICMP (Internet Control Message Protocol, genutzt für Ping) oder SNMP (Simple Network Management Protocol) hätte zu keiner Zeit eine Anomalie aufgezeigt. Trotzdem ist ein wichtiger Dienst ausgefallen. Nur ein Beispiel dafür, dass reine Hardware- und Server-Überwachung, wie wir sie seit ca. 30 Jahren betreiben, nicht ausreicht. Das ist auch keine neue Erkenntnis. Ich kann mich erinnern, dass wir in den 1990er Jahren per Skript alle paar Minuten eine Testmail an eine externe E-Mail-Adresse gesendet haben. In dem zu jener externen Adresse gehörenden E-Mail-Account war eine Weiterleitung zu einer Test-E-Mail-Adresse auf unserem internen Mail-Server eingerichtet. Blieb für eine bestimmte Zeit (mehr als das Intervall zwischen zwei Test-E-Mails) der Empfang der E-Mail auf unserem internen System aus, wurde ein Alarm ausgelöst. In diesem Fall sind wir davon ausgegangen, dass entweder Versand oder Empfang von externen E-Mails oder beides nicht mehr funktionierte.
Minor Issue oder Major Issue?
Kollege Dr. Wetzlar sagte mir neulich, dass ein Monitoring-Tool sogenannte Flapping Links als „Minor Issue“ (nachrangiges Ereignis) einstuft. Angesichts der vielen anderen Minor Issues geht die Meldung über einen Flapping Link unter. Dabei kann ein Flapping Link, d.h. eine instabile physische Netzverbindung, zu so vielen Paketverlusten, instabilen Routing-Tabellen etc. führen, dass wichtige Applikationen nicht mehr funktionieren. Letzteres auch dann, wenn das Netz knoten- und kantenredundant aufgebaut ist. Im Netz ist kaum etwas bösartiger als eine instabile Verbindung. Sie führt zu nicht deterministischen Zuständen. Dann nutzt Redundanz auch nichts. Interessant ist, dass dieses Wissen zuweilen auch auf hohen Ebenen der Politik angekommen ist, wie eine öffentliche Stellungnahme eines Ministers der Landesregierung von Nordrhein-Westfalen in der Analyse eines Netzausfalls zeigt (siehe Plenarprotokoll 17/125 des Landtages NRW, ab Seite 96). Ich habe ein halbes Jahr später als Sachverständiger die Ausführungen des Ministers nachvollzogen und im Wesentlichen plausibel gefunden (siehe Stellungnahme 17/4516 für den Landtag NRW). Wer Zeit und Lust hat, kann sich die Video-Aufzeichnung der Sitzung des zuständigen Landtagsausschusses anschauen.
Ziel: Fehlererkennung vor den Benutzern
Nun könnte man meinen, auch reaktives Incident Management sei zulässig und als Disziplin im IT-Betrieb vorgesehen. Warum also viel Aufwand in Service- und Applikations-Monitoring investieren, wenn sich die Benutzer bei Ausfällen von Anwendungen schon melden werden?
Ziel vieler Betreiber von IT-Umgebungen ist jedoch, Ausfälle und auch aufkommende Probleme vor den Benutzern zu erkennen. Dafür gibt es triftige Gründe:
- Erstens kann das Warten auf Fehlermeldungen der Benutzer, die manchmal auch irreführend sind, die Ausfallzeit unnötig verlängern.
- Zweitens kann vorzeitiges Erkennen eines Ausfalls dazu genutzt werden, alle betroffenen Benutzer über die Erkennung des Ausfalls zu informieren. So wird Zeit und Aufwand gespart: bei den Benutzern und bei der ersten Anlaufstelle für ihre Fehlermeldungen.
- Drittens kann Service- und Applikations-Monitoring auch aufkommende Probleme erkennen, bevor es zu einem Ausfall kommt, den die Benutzer wahrnehmen.
- Viertens profitiert das Ansehen des IT-Betriebs bei den Benutzern von der frühzeitigen Erkennung und Kommunikation von Incidents sowie Problemen.
Fazit
Service- und Applikations-Monitoring ist nicht erst heute dringend nötig. Immer wenn kritische Abläufe von IT abhängig sind, sind sie nicht nur von IT-Infrastruktur, sondern auch von Services und Anwendungen abhängig. In vielen Fällen werden auf der Ebene IT-Infrastruktur keine Fehler erkannt, jedoch auf der Ebene der Services und Applikationen. Monitoring muss auch Letzteres leisten. Nennen wir es Next Generation Monitoring. Es liegt in der Natur von Service- und Applikations-Monitoring, dass die zu überwachenden Zustände in der Regel anwendungsspezifisch sind. Das macht die Überwachung nicht einfacher. Doch dafür ist die Rechnung einfach: Eine Stunde Ausfall einer kritischen Applikation kann je nach Anzahl der betroffenen User um Größenordnungen teurer sein als der Aufwand, der in das Monitoring der Applikation investiert wird.
