Alles grün. Warum die Anwendung trotzdem langsam ist (Observability Teil 1).

In mehreren Niederlassungen reagiert eine geschäftskritische Anwendung verzögert. Die Mitarbeitenden warten auf Antwort vom System, der Service Desk erhält Beschwerden. Doch die Netzwerkverbindungen sind erreichbar, die Geräte melden keinen Ausfall, und die überwachten Werte liegen innerhalb ihrer Grenzbereiche. Wo beginnt die Ursachenanalyse?

Eine solche Situation zeigt, weshalb Unternehmen mit verteilten Standorten ihren Netzwerkbetrieb stärker aus der Perspektive der genutzten Services betrachten sollten. Observability hilft dabei, technische Beobachtungen mit ihren Abhängigkeiten zu verbinden und in einen Kontext zu setzen. So lässt sich gezielter untersuchen, warum ein Service beeinträchtigt ist und welche Standorte betroffen sind.

Was ein grüner Status tatsächlich aussagt

Monitoring bleibt eine wichtige Grundlage des Betriebs. Es zeigt beispielsweise, ob Verbindungen verfügbar sind, die Netzauslastung steigt oder Paketverluste auftreten. Ein grüner Status bedeutet zunächst, dass die jeweils überwachten Parameter innerhalb definierter Grenzwerte liegen. Ob eine Anwendung für die Nutzer zufriedenstellend funktioniert, lässt sich daraus allein nicht ableiten.

Zwischen dem Endgerät des Mitarbeitenden und der Anwendung liegen mehrere technische Stationen. Das lokale WLAN, die Verbindung ins Weitverkehrsnetz, die Namensauflösung über DNS und Sicherheitsprüfungen können die Antwortzeit beeinflussen. Hinzu kommen Abhängigkeiten von Providern und Cloud-Diensten. Eine einzelne Komponente kann aus ihrer eigenen Perspektive unauffällig arbeiten, während das Zusammenspiel aller Komponenten entlang des gesamten Netzwerkpfads die Nutzung beeinträchtigt.

Für die zentrale IT wird die Analyse besonders aufwendig, wenn die beteiligten Teams jeweils nur einen Ausschnitt sehen. Der Netzwerkbetrieb prüft Verbindungswerte, das Security-Team seine Ereignisse und der Cloud-Betrieb die Plattform. Jede Beobachtung kann korrekt sein. Trotzdem fehlt möglicherweise die gemeinsame Erklärung.

Wie Observability die Analyse erweitert

Observability führt relevante Signale mit Informationen über Standorte, Services und technische Abhängigkeiten zusammen. Dazu gehören auch die genutzten Verbindungspfade und vorausgegangene Änderungen. Dieser Kontext hilft, einzelne Auffälligkeiten einzuordnen und mögliche Ursachen systematisch zu prüfen.

Zurück zum Beispiel: Die Verzögerungen betreffen nur Niederlassungen, deren Zugriffe seit einer Policy-Änderung über denselben Sicherheitsdienst laufen. Für die Untersuchung werden nun mehrere Beobachtungen miteinander verknüpft: Welche Standorte melden Probleme? Welcher Pfad wurde genutzt? Wann trat die Verzögerung auf, und was wurde zuvor geändert?

Damit entsteht eine prüfbare Ursachenhypothese. Der zeitliche Zusammenhang beweist noch nicht, dass die Änderung verantwortlich ist. Er gibt dem Team aber einen konkreten Ansatz für weitere Tests. Ebenso könnte sich zeigen, dass die betroffenen Standorte eine lokale WLAN-Konfiguration gemeinsam haben und der Sicherheitsdienst als Ursache weniger wahrscheinlich ist.

Die Grenze zwischen Monitoring und Observability verläuft dabei nicht entlang einzelner Produktbezeichnungen. Auch Monitoring-Systeme können Zusammenhänge auswerten. Entscheidend ist, wie gut sich aus den verfügbaren Informationen das Verhalten eines Service über mehrere technische Bereiche hinweg erklären lässt.

Drei Fragen an den eigenen Netzwerkbetrieb

IT-Verantwortliche können ihre Ausgangslage bzw. ihren Reifegrad hinsichtlich Observability anhand von drei Fragen prüfen:

1. Können wir erkennen, welche Services und Standorte betroffen sind? Technische Alarme sollten sich einem betrieblichen Zusammenhang zuordnen lassen. Erst dann lässt sich beurteilen, wie dringend eine Beeinträchtigung ist.

2. Können wir Beobachtungen über Team- und Providergrenzen hinweg verbinden? Wenn jede Untersuchung mit manuellen Datenabgleichen beginnt, fehlt möglicherweise eine gemeinsame Grundlage für die Analyse.

3. Können wir Änderungen mit späteren Auswirkungen vergleichen? Wer nachvollziehen kann, welcher Pfad oder welche Policy zu einem bestimmten Zeitpunkt galt, kann Ursachenhypothesen gezielter überprüfen.

Der nächste Schritt ist, eine wiederkehrende Störung eines wichtigen Dienstes oder einer Anwendung auszuwählen und den heutigen Analyseweg nachzuzeichnen. Wo müssen Teams Informationen zusammensuchen? Welche Abhängigkeiten bleiben unklar? Daraus ergibt sich, welche zusätzliche Sicht für diesen Service tatsächlich gebraucht wird.

Sie möchten prüfen, wo Ihrem Netzwerkbetrieb dieser Zusammenhang fehlt? Unsere Experten unterstützen Sie dabei, relevante Services, vorhandene Datenquellen und den konkreten Analysebedarf einzuordnen.


Bild: mit KI erstellt