Observability Beyond Logs — OpenTelemetry und Monitoring-Zukunft

Observability 8. Februar 2026 ~12–14 Min. Lesezeit

Wenn Ihr Monitoring hauptsächlich auf Logs basiert, kämpfen Sie 2026 wahrscheinlich mit zwei Problemen: zu viele Daten und zu wenige Antworten. Logs sind großartig für forensische Analyse und Kontext, aber ohne Tracing, Metriken und Profile „beleuchten” sie oft nur das Problem — sie zeigen Ihnen nicht wo und warum es entstanden ist. OpenTelemetry (OTel) hat Observability von einer Sammlung von Tools zu einem einheitlichen Telemetrie-Standard verschoben, der signalübergreifende Korrelation ermöglicht und damit sinnvolle Automatisierung (AIOps) ohne Rauschen.

Was sich geändert hat: Warum „Observability Beyond Logs”¶

Moderne Systeme bestehen aus Microservices, Managed Services, Serverless-Funktionen, Frontends, Event Buses und Drittanbietern. In einer solchen Welt ist ein Log als Diagnoseeinheit oft zu lokal. In der Praxis führt das zu drei typischen Situationen:

• Ein Incident sieht aus wie „alles ist langsam”, aber ohne Tracing wissen Sie nicht, welche Dependency die Ursache ist.
• Ein Metriken-Graph zeigt einen Spike, aber ohne Kontext wissen Sie nicht, welche Requests und Code-Pfade ihn verursacht haben.
• Logs sind teuer (Speicher + Index) und gleichzeitig das am schwierigsten zu normalisierende Signal.

Das Ziel der Observability 2026 ist nicht „Daten haben”. Das Ziel ist MTTR reduzieren und Zuverlässigkeit erhöhen durch: (1) gute Signale, (2) konsistente Semantik, (3) Korrelation und (4) automatisierte Workflows.

Prinzip: Definieren Sie zuerst, welche Fragen Sie beantworten wollen (SLO/SLI, Golden Signals). Erst dann entscheiden Sie, wie viele Logs Sie wohin senden.

OpenTelemetry in einem Satz (und warum es gewonnen hat)¶

OpenTelemetry ist ein herstellerunabhängiger Standard zum Sammeln, Transportieren und Beschreiben von Telemetrie (Traces, Metriken, Logs und neu auch Profile), aufgebaut auf drei Bausteinen:

1. API/SDK in der Anwendung (Instrumentierung + Context Propagation)
2. OTLP-Protokoll (Transport) + Semantic Conventions (Semantik)
3. OpenTelemetry Collector (Receivers → Processors → Exporters)

Dies ist der fundamentale Unterschied zu den „Agenten” der Vergangenheit: OTel ist kein einzelnes Produkt. Es ist ein Standard und Ökosystem, das den Wechsel des Backends ermöglicht, ohne Anwendungen umzuschreiben.

Signale: Traces vs Metriken vs Logs vs Profile¶

Die meisten Teams haben 2026 erkannt, dass drei Signale keine Konkurrenten, sondern Schichten sind. Jedes beantwortet andere Fragen:

• Metriken: „Was passiert?” (SLO, Kapazität, Sättigung, Trends). Geringes Volumen, hohe Stabilität.
• Traces: „Wo passiert es?” (Latenz in einem verteilten Request, Dependency Map). Mittleres Volumen.
• Logs: „Warum ist es passiert?” (Kontext, Domänen-Events, Exceptions). Höchstes Volumen, teuerste.
• Profile (Continuous Profiling): „Welcher Code und welche Zeile verbrennt CPU/Speicher?” (Hot Paths, Contention). Kritisch für Performance und Kosten.

Praktische Korrelation: Eine Metrik zeigt „CPU-Spike”, ein Trace zeigt „wer ihn verursacht hat” (konkreter Endpoint), und ein Profil sagt „wo genau im Code” Zeit/CPU verloren ging.

OTel-Architektur in der Praxis: Wie Telemetrie fließt¶

Der grundlegende Datenfluss sieht so aus:

App (OTel SDK/Auto-instrumentation)
  └── OTLP (gRPC/HTTP)
       └── OTel Collector (Agent oder Gateway)
            ├── receivers: otlp, prometheus, filelog, ...
            ├── processors: batch, memory_limiter, k8sattributes, transform, tail_sampling, ...
            └── exporters: otlp, prometheusremotewrite, loki, tempo/jaeger, ...
                 └── Backend (Grafana Stack / SaaS / Data Lake)

Das Schlüsselelement ist die Collector-Pipeline. Sie ermöglicht Dinge, die Sie nicht in jeder Anwendung einzeln implementieren möchten:

• Batching, Retry, Backpressure, Buffering
• Anreicherung (Kubernetes-Metadaten, Cloud-Resource-Attribute)
• PII-Redaktion und Sicherheitsrichtlinien
• Tail-Based Sampling (Sampling erst nach „Bewertung” des Trace)
• Routing (verschiedene Exporte für verschiedene Signale / Tenancy)

Agent vs. Gateway: Zwei Deployment-Muster¶

2026 haben sich zwei Deployment-Muster stabilisiert:

• Agent (DaemonSet / Node Agent): Collector läuft auf jedem Node und sammelt lokale Telemetrie (OTLP von Pods, Host-Metriken, Logs, eBPF). Vorteil: niedrige Latenz, lokale Sammlung, bessere Isolation.
• Gateway (zentrale Collectors): Collector als skalierter Service, der schwere Verarbeitung übernimmt (Tail Sampling, Routing, Multi-Tenant-Policy). Vorteil: zentrale Kontrolle und weniger Komplexität auf dem Node.

Die häufigste Architektur ist eine Kombination: Der Agent sammelt und reichert an, das Gateway aggregiert und entscheidet (Sampling/Routing).

eBPF: Telemetrie ohne Instrumentierung (und warum es kein „Silver Bullet” ist)¶

eBPF hat die Observability in den Kernel verschoben: Statt Anwendungen zu modifizieren, können Sie Events auf OS-Ebene (Netzwerk, Syscalls, Scheduling) erfassen und Signale selbst von „Black-Box”-Prozessen erhalten. In der OTel-Welt ergänzt eBPF typischerweise drei Bereiche:

• Netzwerk-Maps und Latenz zwischen Prozessen/Pods (wer kommuniziert mit wem)
• Sicherheit und Runtime-Evidenz (unerwartete Binärausführung, Netflow-Anomalien)
• Profiling (systemweite Stack-Traces über Sprachen hinweg)

Hinweis: eBPF liefert Ihnen Signale auch ohne Code, aber löst keinen Domänenkontext. Ohne gut definierte Services, Resource Attributes und Semantik (semconv) haben Sie nur einen weiteren Datenstrom.

Continuous Profiling: Das vierte Signal, das das Spiel verändert¶

Profiling war lange „ad hoc” (Profiler einschalten, wenn es ein Problem gibt). Aber Performance- und Kostenprobleme sind oft intermittierend und lastabhängig. Continuous Profiling bietet die Möglichkeit, Performance über die Zeit zu verfolgen, mit Labels (Service, Endpoint, Region, Build) und mit Incidents zu korrelieren.

Im OTel-Ökosystem ist in den letzten Jahren ein neues Profiles-Signal erschienen, und der Collector kann bereits Profile über OTLP empfangen und senden (zum Zeitpunkt des Schreibens typischerweise als experimentell / mit Feature Gate). Auch die Arbeit rund um eBPF-Profiling ist wichtig: Ein Open-Source-Linux-eBPF-Profiler existiert innerhalb des OpenTelemetry-Projekts und zielt darauf ab, sich langfristig als Collector-Receiver zu integrieren.

Wann Profile zuerst deployen¶

• Latenzprobleme ohne klaren Bottleneck im Trace
• Unerklärte CPU/Speicher-Spitzen (Garbage Collector, Contention, Locks)
• Kostenoptimierung (CPU-Zeit pro Request, Hot Functions)
• Vermutete Regression nach einem Release (Profil nach build_sha)

AIOps und Korrelation: Realität vs. Hype¶

„AIOps” 2026 bedeutet nicht, dass KI auf magische Weise einen Incident löst. Es funktioniert hauptsächlich als Korrelations- und Assistenzschicht auf qualitativ hochwertiger Telemetrie:

• Deduplizierung und Gruppierung von Alerts (ein Incident statt 200 Pager-Seiten)
• Root-Cause-Kandidaten basierend auf Service-Topologie und Änderungen (Deploy, Config, Infra)
• Automatisierte Abfragen in Trace/Log/Metrik-Stores und vorgeschlagene nächste Schritte (Runbook)
• Anomalieerkennung bei Metriken- und Profilsignalen (z. B. veränderter Hot Path)

Die Bedingung ist einfach: KI kann nicht korrelieren, was nicht konsistent benannt und verbunden ist. Deshalb sind in OTel Dinge wie Resource Attributes, Trace/Span ID in Logs, konsistenter service.name und Semantic Conventions der Schlüssel.

Implementierungsleitfaden: Wie Sie mit OTel starten (ohne Big Bang)¶

1) Definieren Sie Fragen, nicht Dashboards¶

Beginnen Sie mit SLOs. Wählen Sie 2–4 wichtige User Journeys und führen Sie SLIs (Latenz, Fehlerrate, Verfügbarkeit) dafür ein. Erst dann erweitern Sie die Telemetrie-Abdeckung.

2) Führen Sie minimale Semantik ein (Benennung und Attribute)¶

• service.name und service.version obligatorisch
• Umgebungsidentität: deployment.environment (prod/stage)
• Build-Metadaten: Commit SHA, Release Tag
• Standard-HTTP/DB/RPC-Attribute gemäß semconv (vermeiden Sie „Custom-Chaos”)

3) Instrumentierung: Auto vs. Manuell¶

Auto-Instrumentierung (wo sinnvoll) erstellt schnell grundlegende Traces und Metriken. Aber für Domänenoperationen brauchen Sie auch manuelle Spans:

• „place_order”, „calculate_price”, „reserve_inventory”
• Attribute: order_id (keine PII), tenant, payment_method

4) Logs: Korrelation statt „alles loggen”¶

Werfen Sie Logs nicht weg — aber machen Sie sie zu strukturierten Events. Der größte Gewinn ist Korrelation: Ein Log-Eintrag sollte trace_id / span_id tragen, sodass Sie von einem Trace zu den relevanten Logs „springen” können.

5) Collector: Starten Sie mit einer vernünftigen Pipeline¶

Unten ist ein minimalistisches Beispiel für Traces/Metriken/Logs (OTLP Receiver) mit Batching und grundlegender Hygiene. In der Produktion fügen Sie typischerweise K8s-Anreicherung und Sampling hinzu.

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch:
    send_batch_size: 8192
    timeout: 2s

exporters:
  otlp:
    endpoint: YOUR_BACKEND_OTLP_ENDPOINT:4317
    tls:
      insecure: false

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]

Wenn es ernst wird: Anreicherung, Redaktion und Tail Sampling¶

Sobald Sie die ersten Services instrumentiert haben, kommt der größte Unterschied von der „Telemetrie-Hygiene” im Collector: einheitliche Attribute aus Kubernetes/Cloud, Filterung sensibler Daten und Tail Sampling, das nur das wirklich Wichtige behält.

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 1024

  # Fügt Metadaten aus Kubernetes hinzu (Namespace, Pod, Labels…)
  k8sattributes:
    extract:
      metadata:
        - k8s.namespace.name
        - k8s.pod.name
        - k8s.node.name

  # Resource-Attribut-Erkennung (Cloud, Host, Region…)
  resourcedetection:
    detectors: [env, system]

  # Redaktion sensibler Werte (Beispiel — an Ihre Policy anpassen)
  attributes/redact:
    actions:
      - key: enduser.id
        action: delete
      - key: http.request.header.authorization
        action: delete

  # Tail Sampling: Entscheidung erst nach Trace-Vervollständigung
  tail_sampling:
    policies:
      - name: errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: slow_requests
        type: latency
        latency:
          threshold_ms: 1000
      - name: baseline
        type: probabilistic
        probabilistic:
          sampling_percentage: 2

  batch:
    send_batch_size: 8192
    timeout: 2s

exporters:
  otlp:
    endpoint: YOUR_BACKEND_OTLP_ENDPOINT:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, resourcedetection, attributes/redact, tail_sampling, batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, resourcedetection, attributes/redact, batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, resourcedetection, attributes/redact, batch]
      exporters: [otlp]

Tipp: Machen Sie Tail-Based Sampling (z. B. Fehler + langsame Requests) auf dem Gateway-Collector. So treffen Apps keine „blinden” Entscheidungen (Head Sampling).

6) Profile: Planen Sie voraus, auch wenn das Signal noch jung ist¶

Profiling entwickelt sich im OTel-Ökosystem rasant weiter. OpenTelemetry hat offiziell die Unterstützung für ein „Profiling”-Signal angekündigt, und OTLP/Collector-Unterstützung wird schrittweise erweitert. In der Praxis heute bedeutet das: erwarten Sie Iterationen (Datenmodelländerungen, Kompatibilität) und starten Sie dort, wo Sie die größten Performance- oder Kosten-Pain-Points haben.

Wichtig: Der Idealzustand ist nicht nur „ein Flamegraph haben”. Das Ideal ist Profile ↔ Trace Linking: Von einem langsamen Request zu einem Profil im selben Zeitfenster springen und die Hot Function finden.

# Observability Beyond Logs — OpenTelemetry und die Zukunft des Monitorings 2026
receivers:
  otlp:
    protocols:
      grpc:

exporters:
  otlp:
    endpoint: YOUR_BACKEND_OTLP_ENDPOINT:4317

service:
  pipelines:
    profiles:
      receivers: [otlp]
      exporters: [otlp]

Hinweis: In einigen Collector-Versionen kann Profil-Unterstützung hinter einem Feature Gate / Konfigurationsflag stehen. Nehmen Sie es als Signal, dass es angemessen ist, es zunächst als Pilot zu deployen (z. B. auf einem Node-Pool / einem Service) und die Backend-Kompatibilität zu überwachen.

Praktischer Ansatz:

1. Starten Sie in einer Domäne (z. B. JVM- oder Go-Services mit dem höchsten CPU-Verbrauch).
2. Sammeln Sie eine Baseline (vor der Optimierung) und definieren Sie KPIs (CPU/Request, p95-Latenz).
3. Erst dann automatisieren Sie die Profile ↔ Trace-Korrelation (wo das Backend es unterstützt).

7) eBPF: Gezielt einsetzen¶

eBPF liefert den besten ROI auf Linux-Nodes, wo Sie:

• Telemetrie von Prozessen erhalten möchten, die Sie nicht instrumentieren können
• den „gesamten Node” profilieren und Noisy Neighbors / Contention aufdecken möchten
• validieren möchten, ob Anwendungsdaten mit der Realität auf Netzwerk- und OS-Ebene übereinstimmen

Häufigste Fehler (und wie man sie vermeidet)¶

• OTel ohne Collectors: Direktes Senden aus Anwendungen funktioniert für den Anfang, aber Sie verlieren zentrale Policy (Sampling, PII, Routing).
• Inkonsistenter service.name: Bricht Korrelation und Topologie.
• „Alles in Logs”: Teuer und langsam. Bevorzugen Sie Metriken + Traces für die meisten Fragen.
• Fehlendes Ownership: Telemetrie ist ein Produkt. Sie braucht Standards, Review und CI-Checks (Lint semconv, Sampling Policy).
• PII in Attributen: Trace-Attribute werden leicht indiziert — achten Sie darauf, was Sie hineinschreiben.

Wohin die Reise geht: Observability 2026 → 2027¶

Die Richtung ist klar: Vereinheitlichte Telemetrie erweitert sich um Profile, eBPF macht die Signalerfassung aus der Infrastruktur günstiger, und AIOps entwickelt sich vom „Chatbot” zu Workflows, die die Untersuchung verkürzen. Und was am wichtigsten ist: Die erfolgreichen Teams verstehen, dass Observability nicht der Kauf eines Tools ist, sondern eine Disziplin (Semantik, Datenqualität, Korrelation und klare SLOs).

Möchten Sie Hilfe? Der schnellste Weg ist ein Observability-Assessment: Signale, Kosten, SLO-Abdeckung kartieren und eine OTel-Roadmap entwerfen (Instrumentierung → Collectors → Korrelation → Profiling).