Observability am Edge: Tausende Knoten, null Durchblick?

Dass Edge Computing wächst, ist bekannt. Laut dem „Worldwide Edge Spending Guide“ von IDC beliefen sich die weltweiten Ausgaben für Edge Computing im Jahr 2025 auf rund 265 Milliarden US-Dollar und sollen bis 2029 auf etwa 450 Milliarden US-Dollar steigen. Der Weg von zentralen Cloud-Umgebungen hin zu lokalen Recheninfrastrukturen oder Mischformen aus beidem ist kaum umkehrbar. Das bedeutet jedoch nicht, dass Unternehmen im Blindflug agieren dürfen. Für viele Technologieverantwortliche ist Observability eine zentrale Frage beim Blick auf Edge-Projekte.

Observability, also die Fähigkeit, aus den messbaren Ausgaben einer Anwendung, wie etwa Logs, Metriken und Traces, zu erschließen, was intern passiert und warum, ist am Edge genauso wichtig wie in jeder anderen Umgebung. Es wird jedoch schnell kompliziert, wenn ein Unternehmen Einblick in Tausende verteilte, entfernte Geräte gewinnen will. Diese verfügen oft nur über wenig Speicher, Rechenleistung und Energie, liegen physisch weit auseinander und sind über unzuverlässige Netzwerke verbunden.

Diese technische Komplexität ist aber nur die eine Seite. Dazu kommt eine organisatorische: Die Entwicklung hin zu „Managed Edge“ bringt weitere Komplikationen mit sich. Wo genau soll beobachtet werden, wenn „Edge” per Definition Tausende kleiner, verteilter und oft getrennter Standorte bedeutet, statt einer zentralen Cloud-Umgebung oder eines großen Rechenzentrums? Und wenn dieser Edge „verwaltet” wird, bedeutet das, dass jemand anderes als der Kunde die Infrastruktur betreibt? Wenn ja, wer hat die Kontrolle?

Damit stellt sich die Frage, wer verantwortlich ist, wenn im vollständig verwalteten Modell etwas schiefgeht. Fast jedes Managed-Angebot folgt diesem Muster: Es kommt zu gegenseitigen Schuldzuweisungen zwischen lokalen IT-Teams, Telekommunikationsanbietern und Cloud-Anbietern. Das wird besonders bei Patches und Updates deutlich, die unerwartete Ausfallzeiten verursachen können, wenn sie mit angepassten lokalen Anwendungen kollidieren.

Eine Telemetrie-Pipeline auf unterschiedliche Verantwortungsketten abzubilden, erfordert ein Umdenken – insbesondere, wenn ein Unternehmen sicherstellen muss, dass der Managed-Edge-Anbieter an jedem einzelnen Knotenpunkt strenge regionale Datenschutzvorgaben wie die DSGVO einhält.

Und Compliance führt natürlich zur Frage der Datenhoheit. Wenn Observability über Regionen oder Länder hinweg aufgebaut wird, rückt folgende Frage in den Mittelpunkt: Wie viele der Observability-Daten müssen in der Region oder vor Ort bleiben? 

In der Praxis setzt sich zunehmend ein Modell durch, das diese Frage strukturell statt nur vertraglich beantwortet: „Bring Your Own Cloud”. Dabei betreibt der Anbieter die Software, während die Daten- und Infrastrukturhoheit durchgehend beim Kunden bleibt. Der Anbieter erhält nur einen begrenzten, überprüfbaren Zugriff, etwa für Konfiguration und Zustandsprüfung, nicht aber auf die Telemetrie selbst. Die Betriebsverantwortung liegt beim Anbieter, während die Verantwortung für Daten und Zugriff beim Kunden bleibt. Im Streitfall lässt sich diese Aufteilung belegen, statt dass sie nur zugesichert wird.

Laut dem Bitkom Cloud Report 2026 halten inzwischen 85 Prozent der Unternehmensverantwortlichen in Deutschland ihr Land für zu abhängig von US-amerikanischen Cloud-Anbietern. Das ist ein deutlicher Anstieg gegenüber 78 Prozent im Vorjahr. Bei Managed-Edge-Modellen, bei denen ohnehin ein Drittanbieter Zugriff auf die verteilte Infrastruktur hat, dürfte sich dieser Trend besonders bemerkbar machen.

Neben diesen strategischen Fragen zu Eigentum und Compliance gibt es die operativen Fragen der Workloads selbst.

Operative Sichtbarkeit

In Edge-Umgebungen muss Observability in der Regel sowohl die Betriebstechnik (OT) als auch die angrenzende IT-Infrastruktur erfassen, um vollständig zu sein.

Sie muss ressourcenschonend arbeiten, um weder Akkus zu belasten noch kleine Prozessoren zu überfordern, und zugleich in der Lage sein, Daten bei einem Verbindungsausfall lokal zwischenzuspeichern und später zu synchronisieren.

Das kann schnell sehr komplex werden. Wenn ein Unternehmen KI-Inferenz-Workloads an den Edge verlagert, entstehen neue Fehlerarten, die mit klassischem Infrastruktur-Monitoring wenig zu tun haben.

Ein hypothetisches Beispiel: Ein Bahnbetreiber setzt Edge-basierte Bilderkennung an Bahnsteigkameras ein, um aus Sicherheitsgründen eine Überfüllung zu erkennen. Kurz nachdem der Betreiber neue Beleuchtung sowie Beschilderung und Markierungen einführt und dabei von Dunkelblau auf Signalgelb umstellt, beginnt das Erkennungsmodell, das auf den alten Bahnsteigumgebungen trainiert wurde, die gelben Bodenmarkierungen mit Absperrband zu verwechseln. Es meldet wiederholt leere Bahnsteige als „Zutritt zu Sperrzone” und überflutet die Leitstelle mit Fehlalarmen.

Klassisches Monitoring würde das übersehen. Das Kamerabild ist klar, der Edge-Server sendet korrekt, der Speicherverbrauch liegt im normalen Bereich und die Daten kommen einwandfrei an. Rein technisch ist also alles in Ordnung, operativ jedoch nicht.

Dieser Unterschied wird umso wichtiger, je komplexer es wird. Erzeugen Agenten am Edge beispielsweise eigenen Code, muss Observability noch tiefer nachverfolgen können, um vollständig zu bleiben.

All das wirkt sich schließlich auch auf die kommerziellen Modelle aus, die dahinterstehen.

Die Kostenfrage

Edge-Implementierungen können Tausende Knotenpunkte umfassen, wobei das Datenvolumen pro Knoten vergleichsweise gering ist. Preismodelle, die auf Annahmen für zentrale Cloud-Observability beruhen und sich am Ingestionsvolumen orientieren, sind im Edge-Maßstab nicht sinnvoll. Die Kalkulation für einen Kunden mit 20.000 kleinen Standorten unterscheidet sich grundlegend von der für 20 große Rechenzentren.

Und so verlockend es für Anbieter auch sein mag, jedes einzelne Gerät als eigene Abrechnungseinheit zu behandeln oder Observability pro Knotenpunkt zu verkaufen: Für den Kunden wird das schnell zum größten Einzelposten im IT- oder Betriebsbudget. 

Diesen Kosten müssen unmittelbare, harte finanzielle Vorteile gegenüberstehen. Beispielsweise lassen sich Probleme bestätigen, bevor ein Techniker losgeschickt wird, und Fehler exakt aus der Ferne eingrenzen, um Fahrt- und Wartungskosten zu sparen. Daneben verbessert Observability den ROI durch proaktive Zustandsüberwachung sowie Sicherheits- und Manipulationserkennung.

Der größte langfristige Nutzen entsteht jedoch vermutlich dadurch, dass Observability eine intelligente Datenfilterung ermöglicht. Denn über Jahre oder Jahrzehnte hinweg sind nicht die anfängliche Hardware oder die Softwarelizenzierung die größten Kostenpunkte eines Edge-Projekts, sondern die laufenden Kosten für Dateningestion, Speicherung und Egress in der Cloud.

Allzu oft werden Unternehmen zu „Datenhortern“: Sie senden rohe, vollständige Telemetriedaten und erzeugen auf diese Weise massive Cloud-Rechnungen für Daten ohne geschäftlichen Wert. Observability liefert die Kontextinformationen, um zu bestimmen, welche Daten tatsächlich relevant sind.

Unternehmen können ihre Knotenpunkte intelligenter machen, Cloud-Gebühren sparen und gleichzeitig die Reaktionszeit deutlich verbessern, wenn sie Observability als Grundlage für intelligente Datenfilterung nutzen. Der Edge kann ein lauter Ort sein. Observability sorgt dafür, dass Unternehmen genau die Signale wahrnehmen, die tatsächlich von Bedeutung sind.