|
18.07.2026
09:05 Uhr
|
Zwei OpenTelemetry-Experten erklären, warum zu viele Daten schaden – und wie ein Top-down-Ansatz die Zuverlässigkeit der Observability rettet.
Terabytes an Logs, Metriken und Traces landen täglich in den Observability-Backends großer Unternehmen – ohne dass jemand genau sagen kann, wofür. Genau an dieser Stelle setzte der Eröffnungsvortrag der Online-Konferenz Mastering Observability im April 2026 an. Unter dem Titel „Weniger Sammeln, mehr Verstehen – hin zu proaktivem Reliability Engineering“ argumentierten Severin Neumann und Juraci Paixão Kroehling, dass Observability kein Tool-Wettrüsten ist, sondern ein Engineering-Problem. Nicht die Datenmenge entscheidet, sondern ob sich damit die Fragen beantworten lassen, die für die Zuverlässigkeit verteilter Systeme wirklich zählen.
Beide Speaker bringen einschlägige Erfahrung mit: Neumann, Head of Community bei Bronto, sitzt im OpenTelemetry Governance Committee und pflegt als Co-Maintainer die Dokumentation des Projekts. Kroehling ist Mitgründer und CEO von OllyGarden, einer OpenTelemetry-nativen Plattform mit Fokus auf Telemetrie-Qualität, ehemaliger Jaeger-Maintainer und Schöpfer zentraler OTel-Komponenten wie Collector Builder und Operator. Ihre gemeinsame These: Viele Organisationen betreiben angstgetriebene Datensammlung nach dem Motto „erst alles erfassen, später entscheiden“.
Die Folgen dieses „Telemetry Hoarding“ sind konkret: steigende Kosten für Storage, Egress, Ingestion und Verarbeitung, wachsendes Misstrauen gegenüber den eigenen Daten sowie eine längere Mean Time to Repair (MTTR). Statt proaktivem Reliability Engineering bleiben Teams im dauerhaften Fire-Fighting-Modus stecken. Observability definieren die Vortragenden schlicht als die Fähigkeit, Fragen zu stellen und belastbare Antworten zu erhalten – die drei Signale Logs, Metriken und Traces sind dafür nur das Fundament.
Als Denkmodell dient das „2-Uhr-Szenario“: Ein Service bricht mitten in der Nacht zusammen, betroffen sind Nutzer in einer anderen Zeitzone. Welche Frage würde das Bereitschaftsteam um zwei Uhr morgens stellen – und beantwortet die vorhandene Telemetrie sie überhaupt? Diese Perspektive verschiebt den Fokus von „Was können wir alles sammeln?“ hin zu „Was muss ich wissen, damit Nutzer ihr Ziel zuverlässig erreichen?“.
Der vorgestellte Ansatz arbeitet sich von oben nach unten vor: von kritischen Nutzertransaktionen wie Login, Checkout oder Payment über die Service-Grenzen bis hinunter zur Infrastruktur mit Datenbanken, Queues und Netzwerk. Bei den Metriken bilden die Golden Signals – Latency, Traffic, Errors und Saturation – den Einstieg. Alerts sollen nur für Kennzahlen entstehen, die direkt die Zuverlässigkeit der Nutzerziele betreffen, und jeder Alert muss actionable sein, also eine klare Zuständigkeit und erwartbare Maßnahme mit sich bringen.
Traces bilden nach Ansicht der Referenten das Fundament der Strategie. Statt alles zu erfassen, empfehlen sie strategisches Sampling entlang kritischer Kundentransaktionen und selektives Sampeln übriger Pfade, um Datenvolumen und Kosten im Griff zu behalten. Auto-Instrumentierung deckt Dependencies und unterstützende Dienste wie Datenbanken, Message-Broker und externe APIs ab, während code-basierte Instrumentierung den Geschäftskontext einfängt – mit Attributen wie order_value, tenant_id oder feature_flag. Logs wiederum sollen nur gespeichert werden, wenn sie Evidenz liefern, verknüpft mit Trace- und Span-IDs statt generischer Meldungen wie [Error] Transaction failed.
Praktisch heißt das für DACH-Enterprises mit ihren oft strengen Compliance-Anforderungen: Debug-Spam, duplizierte Retry-Logs und Detailmetriken ohne Bezug zu Nutzerzielen fliegen raus. In die Sammlung gehören dagegen Golden Signals der kritischen Transaktionen, trace-basierte Geschäftsprozesse, strukturierte Fehlerlogs und knappe Ressourcenzustandsmetriken. Ein Big-Bang-Umbau ist dafür nicht nötig – der Einstieg über ein oder zwei geschäftskritische Services und eine schrittweise Governance blockiert das Tagesgeschäft am wenigsten.
Ein zentraler Baustein sind die OpenTelemetry Semantic Conventions. Sie sorgen dafür, dass Teams, Tools und Cloud-Anbieter dieselben Begriffe auf dieselbe Weise verwenden. Drei Regeln bringen das auf den Punkt: Konsistenz (etwa einheitlich deployment.environment.name = "production" statt uneinheitlichem env = "live"), Einmaligkeit (ein Name bezeichnet exakt eine reale Sache, nicht zwei Services mit service.name = "api") und Beständigkeit (statt service.name = "checkout-v1" besser service.name = "checkout" plus separates service.version).
Diese Konventionen heben nicht nur das Signal-Rausch-Verhältnis, sie machen Telemetrie auch für Maschinen verständlich. Gerade KI-Agenten und LLM-gestützte Debugging-Workflows sind auf semantisch klare, konsistente Daten angewiesen, um Kausalitäten erkennen zu können. Fehlen einheitliche Konventionen, entsteht ein „Semantic Sprawl“, der Interoperabilität zwischen Backends und Cloud-Diensten erschwert und einen Anbieterwechsel ohne komplette Re-Instrumentierung nahezu unmöglich macht.
Für die Umsetzung nennen die Speaker mehrere schnelle Gewinne. Auf Collector-Ebene lässt sich viel Ballast abwerfen: Ein Audit reduzierte 236 Resource-Attribute auf 85 tatsächlich benötigte, also über 60 Prozent weniger. Connection-Retries, die 300 identische Log-Einträge produzieren, schrumpfen per Deduplizierung auf einen Eintrag pro Vorfall. Auf SDK-Ebene helfen deklarative Konfiguration in YAML statt Boilerplate-Code sowie einheitliche SDK-Wrapper pro Sprache. Tools wie OpenTelemetry Weaver und KI-gestützte Agenten prüfen Code und Telemetrie automatisiert gegen die Conventions.
Severin Neumann ist Head of Community bei Bronto. Er beschäftigt sich seit vielen Jahren mit Observability, verteilten Systemen und der Frage, wie Engineering-Teams komplexe Softwarelandschaften zuverlässig betreiben können. Severin ist Mitglied des OpenTelemetry Governance Committees sowie Co-Maintainer der OpenTelemetry-Dokumentation und engagiert sich aktiv in der Open-Source- und Cloud-Native-Community.
Juraci Paixao Kroehling ist Mitbegründer und CEO von OllyGarden, einer OpenTelemetry-nativen Plattform, deren Schwerpunkt auf der Qualität der Telemetriedaten liegt. Er ist Mitglied des OpenTelemetry Governance Committee, ehemaliger Jaeger-Maintainer und Entwickler zentraler OpenTelemetry-Komponenten, darunter der Collector Builder und der Operator. Als CNCF-Botschafter mit Sitz in Berlin leistet Juraci seit den Anfängen einen Beitrag zum Cloud-Native-Ökosystem.
Mehr zu Observability, aber auch zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim.
Jetzt Tickets zum Frühbucherpreis sichern.
(map)