Mehr Daten erklären noch keine Störung (Observability Teil 2)
03.11.2026 von Thomas Gmeiner

Router liefern Leistungswerte, Sicherheitskomponenten protokollieren Ereignisse, und der Service Desk dokumentiert Beschwerden. Trotzdem beginnt die Suche nach der Ursache einer langsamen Cloud-Anwendung häufig mit dem manuellen Zusammensuchen von Informationen. Es fehlen die Verbindungen zwischen vorhandenen Daten: Welcher Messwert gehört zu welchem Standort, welchem Zugriff und welcher Anwendung?
Während Monitoring technische Zustände und Entwicklungen sichtbar macht, braucht Observability zusätzlich einen nachvollziehbaren Zusammenhang zwischen den Beobachtungen. Entscheidend ist, welche Betriebsfrage sich mit den Daten beantworten lässt. Daraus ergibt sich, welche Signale benötigt werden und mit welchem Kontext sie verknüpft werden müssen.
Welche Signale welche Fragen beantworten
Verschiedene Datenarten liefern unterschiedliche Einblicke in das Verhalten eines Services:
- Metriken beschreiben messbare Eigenschaften wie Netzauslastung, Latenz oder Paketverlust. Sie zeigen Entwicklungen und Abweichungen, erklären deren Ursache aber nicht allein.
- Logs dokumentieren einzelne Ereignisse, etwa einen fehlgeschlagenen Zugriff oder eine angewendete Sicherheitsregel. Ihr Nutzen hängt davon ab, ob die relevanten Vorgänge tatsächlich protokolliert werden.
- Flow-Daten beschreiben Kommunikationsbeziehungen und übertragene Datenmengen. Sie helfen zu untersuchen, welche Systeme miteinander kommunizieren und wie sich der Datenverkehr verändert.
- Synthetische Tests führen definierte Testzugriffe aus. Sie zeigen, wie sich ein Service vom jeweiligen Messpunkt aus verhält. Ein Test aus einem Rechenzentrum bildet jedoch nicht automatisch die Erfahrung eines Mitarbeitenden im lokalen WLAN ab.
Für die Untersuchung einer verzögerten Anwendung können mehrere dieser Perspektiven erforderlich sein. Umfang und Auswahl richten sich nach dem betroffenen Service und den möglichen Ursachen entlang des gesamten Netzwerkpfads.
Vom Messwert zum Zusammenhang
Ein Beispiel: Beschäftigte einer Niederlassung melden morgens lange Antwortzeiten einer Cloud-Anwendung. Ein synthetischer Test vom Standort bestätigt die Verzögerung. Gleichzeitig steigt dort die Netzauslastung. Die erste Vermutung liegt nahe: Die Standortanbindung ist überlastet.
Um diese Hypothese zu prüfen, müssen die Messungen zeitlich und technisch zusammenpassen. Nutzt der Test denselben Verbindungspfad wie die Anwendung? Betrifft die Auslastung den dafür verwendeten Anschluss? Zeigen die Messwerte tatsächlich denselben Zeitraum? Erst mit diesen Zuordnungen lässt sich bewerten, ob die Beobachtungen zusammengehören.
Weitere Informationen können die Untersuchung verändern. Flow-Daten könnten zeigen, dass zeitgleich ein umfangreicher Datentransfer über den betroffenen Anschluss läuft. Hinweise auf Paketverluste würden die Prüfung der Anbindung ergänzen. Sind dagegen nur Mitarbeitende im lokalen WLAN von den Verzögerungen betroffen, während ein kabelgebundener Testzugriff unauffällig bleibt, sollte auch das Funknetz untersucht werden.
Dafür braucht Observability ein gemeinsames Kontextmodell. Es beschreibt, wie Standorte, Geräte, Provider, Anwendungen und Verbindungspfade zusammenhängen. Hinzu kommen Informationen über Sicherheitsregeln und vorausgegangene Änderungen. So wird nachvollziehbar, auf welchen Teil des Services sich ein Messwert oder Ereignis bezieht. Ein zeitliches Zusammentreffen liefert dabei einen Untersuchungsansatz; eine Ursache muss durch weitere Prüfung bestätigt werden.
Bestehende Systeme gezielt verbinden
Diese Zusammenhänge lassen sich auch über mehrere spezialisierte Systeme hinweg herstellen. Monitoring, Security-Werkzeuge, Cloud-Systeme und Service Desk können ihre jeweiligen Funktionen behalten. Für eine gemeinsame Analyse müssen die relevanten Informationen über Schnittstellen verbunden und konsistent zugeordnet werden können.
IT-Verantwortliche sollten deshalb vor einer Erweiterung der Datenerfassung prüfen, ob vorhandene Quellen bereits nutzbar sind. Sind Standort- und Servicezuordnungen aktuell? Sind Zeitangaben vergleichbar? Reicht die zeitliche Auflösung, um kurzzeitige Beeinträchtigungen zu erkennen? Fehlende oder veraltete Zuordnungen können auch bei umfangreicher Datenerfassung zu falschen Schlussfolgerungen führen.
Für einen konkreten Service lässt sich der Bedarf in einem einfachen Raster festhalten: Betriebsfrage, benötigtes Signal, Datenquelle und erforderlicher Kontext. Zeigt dieses Raster Lücken, lässt sich gezielt entscheiden, ob zusätzliche Messungen oder bessere Verknüpfungen vorhandener Informationen gebraucht werden. Auch KI-gestützte Analysen setzen eine belastbare Datenbasis und nachvollziehbare Zuordnungen voraus.
Sie möchten beurteilen, welche Daten für Ihre wichtigsten Services tatsächlich weiterhelfen? Unsere Experten unterstützen Sie dabei, vorhandene Quellen, fehlenden Kontext und sinnvolle Integrationen einzuordnen.
Bild: mit KI erstellt