Mobile-Menu

Mehr als klassisches IT-Monitoring Warum intelligente Observability zum strategischen Hebel für Resilienz wird

Von Klaus Kurz 6 min Lesedauer

IT-Ausfälle kosten deutsche Unternehmen jährlich 147 Millionen Euro. Wer Störungen vermeiden und Ursachen schnell aufdecken will, braucht einen ganzheitlichen Blick auf Infrastruktur, Applikationen, Netzwerkpfade und Endnutzer – in Echtzeit und aus einer einzigen Datenquelle. Observability ermöglicht genau das.

Observability ermöglicht den ganzheitlichen Blick auf Infrastruktur, Applikationen, Netzwerke und Endnutzer.(Bild:  New Relic)
Observability ermöglicht den ganzheitlichen Blick auf Infrastruktur, Applikationen, Netzwerke und Endnutzer.
(Bild: New Relic)

Die IT bildet heute die Basis für nahezu alle Geschäftsprozesse. Kommt es zu Latenzen oder Störungen, wirkt sich das unmittelbar auf die Produktivität und Nutzererfahrung aus: Kunden brechen Bestellprozesse ab und Mitarbeiter können nicht mehr auf wichtige Daten und Systeme zugreifen. Die Folgen sind schmerzlich spürbar. Durch schwerwiegende IT-Ausfälle entsteht deutschen Unternehmen jährlich ein Schaden von 147 Millionen Euro, so eine Studie von New Relic. 46 Prozent der Befragten verzeichnen mindestens einmal pro Woche einen solchen High-Business-Impact-Ausfall.

Mit Full Stack Observability (FSO) können Unternehmen diese Zahlen erheblich senken und ihre Ausfallkosten halbieren. FSO bezeichnet die Fähigkeit, das Verhalten eines IT-Systems Ende zu Ende nachzuvollziehen – von der Infrastruktur über Applikationen und Services bis hin zum Endnutzer. Um dabei Transportprobleme von Applikationsproblemen zu trennen, ist die Transparenz über Netzwerkzustände und -pfade inklusive WAN/SD WAN, DNS, Load Balancer und Cloud-Netzwerke zentral. Dafür werden Echtzeit-Daten in einer zentralen Plattform gesammelt, korreliert und analysiert. So gewinnen Unternehmen umfassende Transparenz in der IT-Umgebung und können Probleme schneller beheben.

Von MELT zu MELTX: Was IT-Ausfälle wirklich kosten

Traditionell stützt sich Observability auf vier Datentypen, die unter dem Akronym MELT zusammengefasst werden: Metrics, Events, Logs und Traces. Moderne Lösungen erweitern dieses Betrachtungs-Modell um eine fünfte Dimension: MELTX. Das X steht dabei für individuelle Business-Metriken aus dem Geschäftsbetrieb, etwa wie viele Transaktionen pro Stunde ein Unternehmen üblicherweise abwickelt oder wie lange ein Bestellprozess dauert. Für NetOps wird das besonders greifbar, wenn Business-KPIs mit Netzwerk-KPIs wie Round-Trip-Time, Paketverlust, Jitter, DNS-Lookup-Zeit oder WAN-Auslastung korreliert werden. Indem man solche Business-KPIs direkt in Korrelation zu Daten aus dem technischen Monitoring setzt, wird messbar, wie sich IT-Störungen auf den Geschäftserfolg auswirken.

Laut dem aktuellen Observability-Report verursacht eine Stunde Downtime durchschnittlich zwischen 800.000 und 2,5 Millionen Euro Umsatzeinbußen. Unternehmen, die ihre Ausfallzeiten reduzieren, können nicht nur Ausfallkosten halbieren, sondern auch die Produktivität steigern. Systeme laufen stabiler, IT-Teams verbringen weniger Zeit mit der Fehlersuche und können Störungen schneller beheben. Investitionen in eine Observability-Lösung zahlen sich also in mehrfacher Hinsicht aus und spielen eine entscheidende Rolle für die geschäftliche Resilienz. FSO zu etablieren ist daher kein reines IT-Thema mehr, sondern wird zur Chefsache.

Mehrwert von intelligenter Observability in der Praxis: Retail

Im Einzelhandel hängt der Geschäftserfolg heute unmittelbar an der Verfügbarkeit und Performance digitaler Systeme. Denn ein Online-Shop, der nicht erreichbar ist oder beim Checkout Latenz zeigt, generiert weniger Umsatz pro Stunde. Gleichzeitig ist die zugrundeliegende Architektur stark auf Microservices und verschiedene Dienstleister verteilt, was die Fehlersuche komplex macht.

Typischerweise durchläuft ein Bestellprozess das Webshop-Frontend, den Produktkatalog, den Warenkorb, die Preis- und Steuerberechnung, Verfügbarkeitsprüfung, einen externen Payment-Provider, eine Fraud-Detection und schließlich die Anbindung an den Versanddienstleister. Tritt im Checkout eine Verzögerung auf, sieht man mit klassischem Monitoring lediglich, dass die Transaktion statt einer Sekunde plötzlich 50 Sekunden gedauert hat. An welchem Service die Latenz tatsächlich entstanden ist, lässt sich nicht erkennen. Häufig entsteht die Verzögerung jedoch nicht in einem Service, sondern auf dem Weg dorthin – etwa durch Paketverlust auf der WAN-Strecke, fehlerhafte DNS-Auflösung, MTU-Probleme oder Engpässe am Cloud-Egress.

Eine Observability-Plattform sollte deshalb neben Traces auch Netzwerk- und Pfaddaten einbeziehen, um die Ursache eindeutig dem eigenen Netz, einem Provider oder der Cloud zuordnen zu können. Fortschrittliche Observability zahlt daher unmittelbar auf die Kundenerfahrung, Markenreputation und Conversion-Rate ein.

KI-gestützte Korrelation vermeidet Alert Fatigue

Eine große Erleichterung ist die KI-gestützte Alert-Korrelation. Aufgrund der Vielzahl von Abhängigkeiten in komplexen IT-Architekturen sind IT-Teams heute mit einer Unmenge an Warnmeldungen konfrontiert. So löst ein Fehler in einer Datenbank Probleme in sämtlichen damit verknüpften Anwendungen aus. Ähnlich wirkt im Netzwerk ein einzelner Auslöser – etwa ein Link-Flap, eine fehlerhafte Routing-Änderung oder eine gestörte Provider-Strecke – der in kurzer Zeit eine Vielzahl abhängiger Alarme erzeugt. Angesichts der Flut an Alarmen kommt es zum so genannten Alert Fatigue-Phänomen: Mitarbeiter laufen Gefahr, wichtige Meldungen zu übersehen. KI erkennt dagegen, welche Alarme auf dieselbe Fehlerursache zurückzuführen sind, und korreliert sie zu einem einzigen Incident. Das reduziert das operative Grundrauschen erheblich. So können sich Mitarbeiter auf die Ursachenfindung konzentrieren, statt einzelne Symptome zu behandeln.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Netzwerktechnik, IP-Kommunikation und UCC

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Schnell und einfach starten

Der Einstieg in eine Observability-Plattform ist meist niedrigschwelliger als gedacht. Die meisten Anbieter stellen kostenlose Accounts bereit, mit denen Unternehmen eine Testumgebung aufbauen und erste Use Cases ohne Lizenzkosten ausprobieren können. Typische Anwendungsfälle sind zum Beispiel Infrastruktur- und Application-Performance-Management sowie die Überprüfung von SLAs gegenüber externen SaaS-Providern. Wenn der Observability-Bedarf wächst, lässt sich die Testumgebung in einen Proof of Value (POV) überführen, in dem für einen definierten Zeitraum unlimitiert User und Datenmengen zur Verfügung stehen. Gemeinsam mit dem Kunden baut der Anbieter dann Account-Strukturen, Rollenmodelle, Instrumentierung, Dashboards und Alerts auf.

Das Infrastructure Observability Dashboard von New Relic.(Bild:  New Relic)
Das Infrastructure Observability Dashboard von New Relic.
(Bild: New Relic)

Netzwerkseitig ist der Einstieg oft sogar ohne Code möglich – etwa über APIs von SD WAN-, WLAN- und Firewall-Controllern. Ergänzend liefern synthetische Messungen aus verschiedenen Standorten früh Hinweise auf Pfad- oder Provider-Probleme. Für eine tiefere Integration wird ein Agent installiert, der Daten aus der Applikation, dem Netzwerk oder der IT-Infrastruktur sammelt und an die Observability-Plattform liefert. Technisch ist dies meist mit wenigen Codezeilen erledigt.

Metriken aus externen Diensten oder IoT-Systemen, auf denen kein Agent installiert werden kann, lassen sich über Kollektoren an den Schnittstellen abgreifen. In Kubernetes- und anderen Linux-Umgebungen lässt sich die Netzwerkbeobachtung über extended Berkeley Packet Filter (eBPF) ergänzen: Statt mehrere Komponenten zu verteilen, wird ein zentraler Agent im Cluster ausgerollt, der Verbindungs- und Namensauflösungsdaten wie TCP und DNS direkt am Betriebssystem erfasst. Dadurch entstehen präzise, konsistente Messdaten, ohne dass Applikationen instrumentiert oder neu ausgerollt werden müssen – besonders hilfreich für heterogene Workloads und schnelle Rollouts.

Um Browser-Daten wie Klicks und Ladezeiten für das End User Monitoring zu sammeln, genügt es, ein paar Zeilen JavaScript-Code in der Website zu integrieren. Die Observability-Plattform analysiert dann die eingehenden Daten und gibt automatisch Warnmeldungen aus, sobald sich ein kritischer Fehler abzeichnet. Dabei erkennt sie, welches Systemverhalten normal ist, und identifiziert Abweichungen. Parallel dazu können Unternehmen auch eigene Alert-Trigger definieren.

Fazit: Worauf Unternehmen achten sollten

Intelligente Observability ist heute weit mehr als ein IT-Thema: Sie ist ein strategischer Hebel für Profitabilität und Widerstandsfähigkeit. Wer Infrastruktur, Anwendungen, Netzwerke und die Endnutzererfahrung in einer zentralen Plattform bündelt, erkennt Störungen früher, behebt sie schneller und senkt die wirtschaftlichen Auswirkungen von Ausfällen deutlich.

Da eine Observability-Plattform Unternehmen oft über viele Jahre begleitet und sich direkt auf Kosten, IT-Effizienz und Geschäftsergebnis auswirkt, empfiehlt es sich bei der Wahl des Anbieters genau hinzusehen. An erster Stelle steht Transparenz – und zwar nicht nur in den Daten, sondern auch im Preismodell. Die Plattform sollte sich leicht integrieren lassen und problemlos Informationen aus allen relevanten internen und externen Bereichen sammeln und analysieren.

Klaus Kurz.(Bild:  New Relic)
Klaus Kurz.
(Bild: New Relic)

Aus Netzwerksicht ist wichtig, dass sich Topologien und Ende-zu-Ende-Pfade (On-Prem, WAN, Cloud, SaaS) nachvollziehen lassen und dass Netzwerkdaten zuverlässig korreliert werden. Ebenso hilfreich sind Funktionen für SLA-/Provider-Transparenz und die Korrelation von Incidents mit Änderungen beim Routing-, Policy- oder Konfigurationswechsel. Dabei sollten die Kosten stets kalkulierbar und fair bleiben.

Über den Autor

Klaus Kurz ist Senior Director Solution Consulting CE/EE/MENA bei New Relic.

(ID:50902245)