Was der Dienstleister beim Netzwerk- und Server-Monitoring tatsächlich meldet

Monitoring ist oft nur ein Wort im Vertrag

In fast jedem Angebot für IT-Betreuung findet sich ein Satz zum Monitoring. Für sich genommen bedeutet das nichts. Man kann ein Werkzeug einsetzen, das jede Minute prüft, ob die Server auf einen Ping antworten, und das Ganze Monitoring nennen. Es kann Diagramme geben, die sich niemand ansieht. Alarme können in einem Postfach landen, in dem bereits tausend liegen.

Der Unterschied zwischen vorhandenem Monitoring und dem Wissen darüber, was tatsächlich geschieht, lässt sich an drei Fragen festmachen. Wird überwacht, was in der Praxis ausfällt? Erreicht eine Abweichung vom Normalzustand eine bestimmte Person? Setzt sich jemand einmal im Monat hin und erklärt, welche Schlüsse daraus zu ziehen sind?

Es gibt einen einfachen Test. Fragen Sie Ihren Dienstleister, wie oft das Monitoring im vergangenen Quartal ein Problem erkannt hat, bevor es jemand aus der Belegschaft gemeldet hat. Eine konkrete Antwort zeigt, dass das Werkzeug funktioniert. Eine allgemeine Antwort bedeutet meist, dass das Monitoring Störungen bestätigt, statt sie frühzeitig zu erkennen.

Das ist kein Vorwurf an die Dienstleister. Monitoring ist der Teil eines Vertrags, der am leichtesten eine bloße Absichtserklärung bleibt, weil ihn niemand prüft, solange alles funktioniert. Es lohnt sich, das vorher nachzuprüfen.

Was wirklich überwacht werden muss

Die Liste ist kurz und kein Geheimnis. Es lohnt sich, sie griffbereit zu haben, denn sie zeigt sehr schnell, was in einem Vertrag fehlt:

• Verfügbarkeit, also ob der Dienst reagiert. Dabei geht es nicht nur darum, ob der Server auf einen Ping antwortet, sondern ob das funktioniert, was die Beschäftigten nutzen: Website, Datenbank, E-Mail, Dateifreigabe und Vertriebssystem
• Auslastung der Leitungen. Eine Leitung, die während der Arbeitszeit an ihrer Kapazitätsgrenze läuft, ist formal verfügbar. Alles, was darüber läuft, wird jedoch langsamer, und niemand kann sagen, warum
• Antwortzeiten der Netzwerkknoten. Steigende Latenzen und Paketverluste treten meist lange vor dem Ausfall auf, der schließlich jemanden bei der Arbeit blockiert
• verfügbarer Speicherplatz. Eine volle Festplatte stoppt eine Datenbank, eine E-Mail-Warteschlange oder einen Datensicherungsauftrag. Zugleich ist dies der am leichtesten vorhersehbare Ausfall in der gesamten IT
• Prozessor- und Speicherauslastung, als Trend betrachtet und nicht als Einzelwert. Ein Server, dessen Auslastung seit drei Monaten langsam steigt, erreicht irgendwann seine Grenze
• Status der Datensicherungen. Zu prüfen ist nicht nur, ob der Auftrag ausgeführt wurde, sondern auch, ob er die vorgesehenen Daten umfasste, wie lange er dauerte und ob er in das Sicherungsfenster passte
• Fehler in den Protokollen von Systemen und Geräten. Nicht alle Fehler, sondern nur ausgewählte Muster, denn sonst liest sie niemand auch nur ein einziges Mal
• ablaufende Zertifikate. Bei diesem Ausfall steht das Datum im Voraus fest. Es gibt daher keinen Grund, warum er jemanden überraschen sollte

Darüber hinaus gibt es unternehmensspezifische Punkte. Der Zustand der USV-Anlagen, die Temperatur im Serverschrank, Warteschlangen im Lagerverwaltungssystem oder die Antwortzeit einer einzigen Anwendung, von der die Arbeit der gesamten Abteilung abhängt. Ein Dienstleister, der Ihre Umgebung kennt, fragt von sich aus danach. Wurde nicht danach gefragt, ist das Monitoring wahrscheinlich nach einer Vorlage eingerichtet.

Zertifikate laufen immer häufiger ab

Ein ablaufendes Zertifikat ist der am leichtesten vorhersehbare Ausfall in der Unternehmens-IT und zugleich einer der häufigsten. Die Folgen treten sofort ein und sind für Kunden sichtbar: eine Warnmeldung im Browser, eine unterbrochene Integration zwischen Systemen oder eine Smartphone-App, die keine Verbindung mehr zum Server herstellen kann.

Dieses Thema ist gerade schwieriger geworden. Das CA/Browser Forum hat im April 2025 einen Zeitplan zur Verkürzung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate beschlossen. Bis zum 14. März 2026 betrug sie 398 Tage. Seit dem 15. März 2026 gilt eine Obergrenze von 200 Tagen, ab dem 15. März 2027 sind es 100 Tage und ab dem 15. März 2029 nur noch 47 Tage. Auch der Zeitraum, in dem eine frühere Domainvalidierung erneut verwendet werden kann, wird verkürzt, letztlich auf 10 Tage.

In der Praxis bedeutet das eines. Ein Zertifikat, das bisher einmal jährlich zusammen mit anderen Arbeiten erneuert wurde, muss künftig mehrmals im Jahr und in einigen Jahren fast jeden Monat erneuert werden. Eine Liste in einer Tabelle und eine Erinnerung im Kalender reichen dann nicht mehr aus, weil bei einem der vielen aufeinanderfolgenden Termine ein Fehler passieren wird.

Die Frage an den Dienstleister ist daher sehr konkret. Woher wissen Sie, wann jedes unserer Zertifikate abläuft? Wie viele Tage im Voraus werden wir darüber informiert? Erfolgt die Erneuerung automatisiert? Wenn die Antwort lautet, dass jemand daran denkt, ist das keine Antwort.

Ein Alarm und ein Bericht sind zwei verschiedene Dinge

Ein Alarm betrifft das, was gerade geschieht. Er soll eine bestimmte Person darüber informieren, und zwar früh genug, damit sie noch vor den Folgen reagieren kann. Ein Alarm ohne Empfänger ist kein Alarm, sondern nur ein Eintrag im Verlauf.

Ein Bericht zeigt die Entwicklung. Er soll darstellen, was im Laufe eines Monats geschehen ist, was sich verschlechtert und was getan werden sollte, bevor daraus ein Ausfall wird. Ein Bericht dient nicht dazu, zu beweisen, dass alles in Ordnung war. Er dient Entscheidungen über Geld: ob weitere Festplatten benötigt werden, ob die Bandbreite einer Leitung erhöht werden muss oder ob ein Switch zu ersetzen ist, der Pakete verliert.

Diese beiden Dinge zu vermischen, ist ein typischer Fehler. Eine Aufstellung aller Alarme des vergangenen Monats ist kein Bericht, sondern ein Ausdruck. Umgekehrt beschreibt ein Bericht, in dem jeder Messwert grün angezeigt wird, obwohl sich die Benutzer drei Wochen lang über langsames Arbeiten beschwert haben, nicht das Unternehmen, sondern nur ausgewählte Diagramme.

Ohne Schwellenwert und Empfänger ist ein Alarm nur ein Diagramm

Monitoring funktioniert ab dem Moment, in dem jemand die Schwellenwerte festlegt. Es reicht nicht, allgemein festzustellen, dass eine Festplatte voll wird. Entscheidend ist: Bei welchem Wert erscheint eine Warnung, bei welchem ein Alarm und wie lange muss dieser Zustand anhalten, bevor eine Benachrichtigung versendet wird? Ohne die letzte Bedingung weckt ein kurzer Ausschlag jemanden nachts ohne Grund.

Der zweite Punkt ist der Empfänger. Ein Alarm sollte eine bestimmte Person oder eine Rufbereitschaft erreichen. Außerdem braucht er einen der Dringlichkeit entsprechenden Kanal und einen festgelegten Eskalationsweg für den Fall, dass niemand reagiert. Benachrichtigungen können je nach Dringlichkeit und Uhrzeit per E-Mail, SMS oder über den Teamchat versendet werden. Entscheidend ist, diese Zuordnung im Voraus festzulegen und nicht erst während eines Ausfalls auszuwählen.

Der dritte Punkt ist die Alarmhygiene. Ein Alarm, der jeden Tag ausgelöst wird und keine Bedeutung hat, wird nach zwei Wochen nicht mehr gelesen. Zusammen mit ihm werden auch alle anderen Alarme ignoriert. Deshalb müssen Schwellenwerte angepasst und Benachrichtigungen, die zu keiner Handlung führen, einfach entfernt werden. Das gehört zum normalen Betrieb und ist kein Beweis dafür, dass das Monitoring falsch eingerichtet wurde.

Wenn im Vertrag weder Schwellenwerte noch ein Empfänger festgelegt sind, ist das Monitoring nur ein Diagramm. Ein schönes zwar, aber es wird niemanden wecken.

Wie ein ehrlicher Monatsbericht aussieht

Ein ehrlicher Bericht lässt sich in wenigen Minuten lesen und macht deutlich, was zu tun ist. Er muss nicht lang sein. Er muss die Punkte enthalten, die aus der laufenden Korrespondenz nicht hervorgehen:

• was geschehen ist: Tickets und Ausfälle, wann sie eingingen, wann sich jemand darum gekümmert hat und wann sie abgeschlossen wurden
• wie viele Probleme das Monitoring erkannt hat, bevor ein Benutzer sie gemeldet hat, denn nur diese Kennzahl zeigt, ob das Monitoring tatsächlich arbeitet
• Kapazitätstrends: Festplatten, Leitungen und Arbeitsspeicher, mit einer klaren Aussage dazu, wann die Reserve aufgebraucht ist
• Stand der Datensicherungen, einschließlich der Information, ob in diesem Zeitraum eine testweise Datenwiederherstellung durchgeführt wurde und mit welchem Ergebnis
• welche Änderungen an der Infrastruktur vorgenommen wurden, wer sie beauftragt hat und wann
• offene Risiken und begründete Empfehlungen, nicht nur eine Einkaufsliste

Ein Bericht, in dem kein einziger Punkt auftaucht, der nicht nach Plan lief, verdient besondere Aufmerksamkeit. In keiner Infrastruktur vergeht ein Monat, ohne dass etwas schiefläuft. Ein Dienstleister, der solche Vorkommnisse von sich aus beschreibt, ist in der Zusammenarbeit angenehmer als einer, bei dem alles erst bei einer größeren Störung ans Licht kommt.

Gesondert sollte geklärt werden, ob der Bericht automatisch versendet wird oder ob ihn vor dem Versand jemand liest. Ein automatisiertes System verschickt jeden Monat dasselbe. Ein Mensch ergänzt einen Satz dazu, was ihn beunruhigt hat. Dieser Satz kostet in der Regel weniger als die Störung, vor der er warnt.

Fragen, die Sie Ihrem Dienstleister stellen sollten

Das ist der direkteste Weg, um herauszufinden, wie es bei Ihnen aussieht. Keine dieser Fragen ist konfrontativ, und jede lässt sich in wenigen Sätzen beantworten:

• was genau überwacht wird. Bitten Sie um eine Liste der Geräte und Dienste, nicht um eine bloße Zusicherung
• welche Warn- und Alarmschwellen für Festplatten, Leitungen, Prozessor und Arbeitsspeicher gelten
• wer mitten in der Nacht und am Wochenende einen Alarm erhält und was geschieht, wenn diese Person nicht reagiert
• ob die Rufbereitschaft außerhalb der Geschäftszeiten vertraglich geregelt ist oder vom guten Willen des Dienstleisters abhängt
• wo das Monitoring physisch betrieben wird und wem die erhobenen Daten gehören
• was bei Ihnen verbleibt, wenn Sie den Dienstleister wechseln: Konfiguration, Verlauf und Zugriff auf die Daten
• wie lange Metriken und Protokolle aufbewahrt werden, denn ohne historische Daten lässt sich kein Trend erkennen
• ob Sie einen Nur-Lese-Zugriff auf ein Dashboard mit dem aktuellen Status erhalten können
• ob Datensicherungen durch testweise Wiederherstellungen geprüft werden und wie häufig
• ob Sie einen beispielhaften Monatsbericht einsehen können, auch wenn die Daten eines anderen Kunden darin geschwärzt sind

Die letzte Frage ist meist besonders aufschlussreich. Ein Dienstleister, der regelmäßig Berichte erstellt, hat ein solches Dokument griffbereit und kann es ohne Vorbereitung zeigen. Muss der Musterbericht erst erstellt werden, gab es ihn bisher nicht.

So setzen wir es selbst um

Wir betreiben das Monitoring mit dem Elastic Stack in der Infrastruktur des Kunden. Logstash erfasst Daten von Netzwerkgeräten über SNMP und Syslog. Daten von Servern und Systemen liefern Filebeat, Winlogbeat und Metricbeat. Alarme versenden wir je nach Schweregrad per E-Mail, SMS oder in einen Chat. Mit diesem Modell betreuen wir mehrere Tausend Geräte.

Die Lösung beim Kunden haben wir bewusst gewählt. Die Daten bleiben im Unternehmen, die Schwellenwerte stimmen wir auf die konkrete Umgebung ab, und die operative Ansicht gestalten wir so, dass sie in einer knappen Minute zeigt, welches Problem gerade besteht. Den Umfang der Unterstützung, einschließlich einer Rufbereitschaft rund um die Uhr, vereinbaren wir im Vertrag. Diese Bedingung sollte dort festgehalten werden und nicht als selbstverständlich gelten. Die Bearbeitungsreihenfolge der Tickets richtet sich danach, was den Betrieb am stärksten aufhält.

Wenn Sie einfach prüfen möchten, was in Ihrer Infrastruktur aktuell überwacht wird und was nicht, gehen Sie die Fragen aus diesem Beitrag gemeinsam mit Ihrem derzeitigen Dienstleister durch. Aus den Antworten ergibt sich meist ein sehr klares Bild. Wenn dieses Bild mehr Lücken als Gewissheit zeigt, sehen wir uns das gern gemeinsam mit Ihnen an.

Dieses Projekt ansehen