Observability: Von Logs zu Telemetrie im Produktionssystem

Ein Produktionssystem ohne Observability ist wie Autofahren bei Nacht ohne Scheinwerfer — Sie bewegen sich, aber sehen nicht wohin. 2026 reichen das Durchsuchen von Logs und ein paar Grafana-Dashboards nicht mehr aus. Verteilte Systeme, Microservices und Event-Driven-Architekturen erfordern Telemetrie, die Logs, Metriken und Traces zu einem kohärenten Bild verbindet. So geht es.

Warum Logs nicht ausreichen — Drei Säulen der Observability¶

Die meisten Teams beginnen mit Logs. Und auf einem Monolithen mit einem Server funktioniert das. Das Problem entsteht, wenn Sie 40 Microservices haben, ein Request durch sechs davon geht und Sie nicht wissen, wo zwei Sekunden Latenz verloren gingen. Logs sagen Ihnen, was in einem Prozess passiert ist. Sie sagen Ihnen nicht, warum das gesamte System langsam ist.

Deshalb hat sich Observability in den letzten Jahren auf drei Säulen eingependelt — und keine davon reicht allein aus.

Logs¶

Diskrete Ereignisse mit Kontext. Sie sagen was passiert ist. Strukturierte Logs (JSON) mit Correlation IDs sind die Grundlage — Plain-Text-Logs in Produktion sind 2026 nicht akzeptabel.

Metriken¶

Numerische Zeitreihen. Sie sagen wie viel und wie schnell. Request Rate, Error Rate, Latenz (RED), Ressourcen-Sättigung. Aggregiert, günstig zu speichern, ideal für Alerting.

Traces¶

Der Weg eines Requests durch das gesamte System. Sie sagen wo und warum. Distributed Tracing zeigt, welcher Dienst bremst, wo Retries fehlschlagen und wie sich Latenz ausbreitet.

Der Schlüssel ist die Verknüpfung. Wenn Sie einen Spike in der Error Rate sehen (Metrik), wollen Sie zu den konkreten Traces durchklicken, die fehlgeschlagen sind, und vom Trace zu den Logs einzelner Spans gelangen. Ohne diese Verknüpfung haben Sie drei separate Tools statt eines Observability-Systems.

OpenTelemetry als Standard — Warum und wie¶

Vor OpenTelemetry (OTel) hatten Sie herstellerspezifische Agenten: Datadog Agent, New Relic Agent, Jaeger Client, Prometheus Client Library — jeder mit eigenem Format, eigenem SDK und eigenem Lock-in. Der Wechsel zu einem anderen Backend bedeutete, die Instrumentierung der gesamten Anwendung umzuschreiben.

OTel löst das. Es ist ein herstellerneutraler Standard zum Generieren, Sammeln und Exportieren von Telemetrie. 2026 ist OTel de facto Standard — Traces und Metriken sind stabil, Logs haben GA-Stabilität erreicht. Hauptvorteile:

• Ein SDK für alle drei Signale. Sie instrumentieren Ihre Anwendung einmal und exportieren überallhin — Prometheus, Jaeger, Datadog, Grafana Cloud.
• Auto-Instrumentierung. Für Go, Java, Python, .NET und Node.js existieren Agenten, die automatisch HTTP, gRPC, Datenbank-Clients und Messaging-Frameworks ohne Codeänderungen instrumentieren.
• OTel Collector als zentraler Punkt. Ein einzelner Prozess empfängt Telemetrie aus dem gesamten Cluster, verarbeitet sie (Filterung, Sampling, Enrichment) und routet sie zu Backends. Neues Backend hinzufügen? Einen Exporter zur Config hinzufügen — keine Änderungen in Anwendungen.
• Kein Vendor Lock-in. Heute nutzen Sie Prometheus + Loki + Tempo. Nächstes Jahr wollen Sie zu Datadog migrieren? Ändern Sie die Exporter im Collector. Die Anwendung bleibt unberührt.

OTel Collector Konfiguration¶

Eine typische Produktions-Pipeline sieht so aus. Der Collector empfängt OTLP-Daten, verarbeitet sie in Batches, reichert sie mit Kubernetes-Metadaten an und exportiert zu drei Backends:

`# otel-collector-config.yaml

receivers:

otlp:

protocols:

  grpc:

    endpoint: "0.0.0.0:4317"

  http:

    endpoint: "0.0.0.0:4318"

processors:

batch:

timeout: 5s

send_batch_size: 1024

k8sattributes:

extract:

  metadata:

    - k8s.namespace.name

    - k8s.deployment.name

    - k8s.pod.name

tail_sampling:

policies:

  - name: errors-always

    type: status_code

    status_code: { status_codes: [ERROR] }

  - name: slow-requests

    type: latency

    latency: { threshold_ms: 2000 }

  - name: probabilistic

    type: probabilistic

    probabilistic: { sampling_percentage: 10 }

exporters:

prometheusremotewrite:

endpoint: "http://mimir:9009/api/v1/push"

loki:

endpoint: "http://loki:3100/loki/api/v1/push"

otlp/tempo:

endpoint: "tempo:4317"

tls:

  insecure: true

service:

pipelines:

metrics:

  receivers: [otlp]

  processors: [batch, k8sattributes]

  exporters: [prometheusremotewrite]

logs:

  receivers: [otlp]

  processors: [batch, k8sattributes]

  exporters: [loki]

traces:

  receivers: [otlp]

  processors: [batch, k8sattributes, tail_sampling]

  exporters: [otlp/tempo]`

Ein wichtiges Detail: Tail Sampling. In der Produktion können Sie nicht 100 % der Traces speichern — es ist teuer und unnötig. Tail Sampling stellt sicher, dass Fehler und langsame Requests immer gespeichert werden und aus dem normalen Betrieb nur eine Stichprobe genommen wird. Im Gegensatz zu Head Sampling (Entscheidung am Anfang des Trace) sehen Sie den gesamten Request-Verlauf vor der Entscheidung.

Praktischer Stack: Grafana + Prometheus + Loki + Tempo¶

Warum gerade dieser Stack? Weil er Open-Source, praxiserprobt und skalierbar ist. Und vor allem — alle Komponenten sind darauf ausgelegt, zusammenzuarbeiten.

• Prometheus / Mimir — Metriken. Prometheus für kleinere Deployments, Grafana Mimir für Long-term Storage und Multi-Tenancy. PromQL ist die Lingua Franca der Metriken — jeder SRE, jeder Exporter und jedes Dashboard kennt sie.
• Loki — Logs. Indiziert nicht den Log-Inhalt (im Gegensatz zu Elasticsearch), sondern nur Labels. Das bedeutet deutlich niedrigere Speicherkosten und betriebliche Einfachheit. Die LogQL-Syntax ist nah an PromQL, der Umstieg ist schmerzlos.
• Tempo — Traces. Spaltenorientiertes Backend, optimiert für Trace-Speicherung. Unterstützt direkte Integration mit Loki und Prometheus — vom Trace klicken Sie zu den Logs durch, von Metriken zu Traces. Diese Verknüpfung macht aus einzelnen Tools ein System.
• Grafana — Visualisierung und Korrelation. Eine UI für alle drei Signale. Explore-Modus für Ad-hoc-Debugging, Dashboards für den Überblick, Alerting für Benachrichtigungen. Grafana kann 2026 Metriken → Traces → Logs in einem Flow korrelieren.

Alternativen gibt es — Elastic Stack (ELK), Datadog, New Relic, Splunk. Die Wahl hängt vom Kontext ab. Für Teams, die Kontrolle über ihre Daten wollen, keine Per-Host-Gebühren und die Möglichkeit von Self-Hosted- oder Managed-Deployment — der Grafana-Stack ist schwer zu schlagen.

Alerting, das funktioniert — nicht das, das das ganze Team weckt¶

Schlechtes Alerting ist schlimmer als gar kein Alerting. Wenn das Team 50 Alerts am Tag bekommt und 48 davon Rauschen sind, lernt es, Alerts zu ignorieren. Und wenn der echte kommt, reagiert niemand. Dieses Phänomen — Alert Fatigue — ist ein reales Problem, das Incident Response tötet.

Drei Regeln für gutes Alerting¶

• Actionable. Jeder Alert muss eine klare Aktion haben. Wenn Sie nicht wissen, was Sie mit einem Alert tun sollen, sollte er nicht existieren. „CPU ist bei 80 %” ist kein actionable Alert — was tun Sie damit? „Error Rate von payment-service hat 5 % in den letzten 5 Minuten überschritten” ist actionable, weil Sie wissen, dass Kunden nicht bezahlen können.
• Runbook. Jeder Alert hat einen Link zu einem Runbook. Ein Dokument, das sagt: was der Alert bedeutet, welche Auswirkungen er hat, wie man die Ursache diagnostiziert und wie man eskaliert. Ein On-Call-Ingenieur um 3 Uhr morgens soll nicht nachdenken müssen — er soll einem Ablauf folgen.
• SLO-basiert. Der Alert feuert, wenn Sie sich einer SLO-Verletzung nähern — nicht wenn Sie einen willkürlichen Schwellenwert überschreiten. Mehr dazu gleich.

Praktische Tipps: Nutzen Sie Grouping (verwandte Alerts zu einer Benachrichtigung zusammenfassen), Inhibition (wenn der gesamte Cluster down ist, brauchen Sie nicht 200 Alerts für jeden Pod) und Silencing für geplante Wartung. Alertmanager beherrscht all das out of the box.

SLO/SLI-getriebener Ansatz — Sie messen, was zählt¶

SLI (Service Level Indicator) ist eine Metrik, die die Servicequalität aus Benutzersicht misst. SLO (Service Level Objective) ist der Zielwert des SLI. Klingt einfach — in der Praxis ist es ein paradigmatischer Wandel in der Art, wie Sie über Monitoring denken.

Statt Hunderten von Alerts auf Infrastrukturmetriken haben Sie eine Handvoll SLOs, die sagen, ob Benutzer eine gute Erfahrung haben. Beispiele:

• Verfügbarkeit: 99,9 % der Requests an /api/checkout liefern 2xx in den letzten 30 Tagen.
• Latenz: 95 % der Requests an /api/search haben eine Antwort unter 200 ms.
• Korrektheit: 99,99 % der Zahlungstransaktionen werden korrekt verarbeitet.

Das Schlüsselkonzept ist das Error Budget. Wenn Ihr SLO 99,9 % Verfügbarkeit ist, haben Sie ein monatliches Budget von 0,1 % — also ca. 43 Minuten Ausfallzeit. Solange Sie Budget haben, können Sie deployen, experimentieren, riskante Änderungen vornehmen. Wenn das Budget knapp wird, verlangsamen Sie und konzentrieren sich auf Stabilität.

Error Budget Burn Rate Alerting ist weitaus effektiver als statische Schwellenwerte. Der Alert feuert, wenn Sie Budget schneller verbrauchen als nachhaltig — also nicht „Error Rate ist 1 %”, sondern „bei der aktuellen Fehlerrate erschöpfen Sie Ihr monatliches Budget in 6 Stunden.” Das ist ein Alert, auf den Sie reagieren.

Grafana hat native SLO-Unterstützung — Sie definieren die SLI-Query, den Zielwert und die Periode, und Grafana generiert automatisch Dashboards und Alerting-Regeln für Burn Rate. Prometheus Recording Rules berechnen das Error Budget in Echtzeit.

Wie wir es bei CORE SYSTEMS aufbauen¶

Bei CORE SYSTEMS betrachten wir Observability als grundlegende Infrastrukturschicht, nicht als Nice-to-have. Jedes System, das wir in Produktion liefern — ob Informationssystem, Datenplattform oder KI-Agent — hat einen Observability-Stack als Teil der Delivery.

Unser Ansatz ist pragmatisch und basiert auf bewährten Prinzipien:

• Observability ab Tag null. Wir kümmern uns um Instrumentierung von Projektbeginn an, nicht als nachträglicher Gedanke nach dem ersten Produktions-Incident. Das OTel SDK ist Teil des Application Template, der OTel Collector läuft in jedem Cluster.
• SLO-first Alerting. Bevor wir die erste Alert-Regel schreiben, definieren wir SLOs mit dem Business Owner. Was ist akzeptable Latenz? Welche Verfügbarkeit? Alerts leiten sich dann aus der Error Budget Burn Rate ab — nicht aus willkürlichen Schwellenwerten.
• Runbook zu jedem Alert. Ein Alert ohne Runbook ist nur Rauschen. Unsere Alerts haben immer einen Link zu einem Diagnostik-Ablauf, einer Eskalationsmatrix und dem Kontakt des verantwortlichen Teams.
• Dashboards as Code. Wir versionieren Grafana-Dashboards in Git, deployen über CI/CD, nutzen Jsonnet/Grafonnet für Templating. Kein manuelles Klicken in der UI, kein „Wer hat dieses Dashboard geändert.”
• Kostenbewusste Telemetrie. High-Cardinality-Metriken und Full-Fidelity-Traces sind teuer. Wir helfen Kunden, das richtige Gleichgewicht zwischen Sichtbarkeit und Kosten zu finden — Tail Sampling, Metric Relabeling, Log Level Management.

Wir arbeiten mit Kunden im Bankwesen, in der Logistik und im Retail — also in Branchen, in denen Ausfallzeiten echtes Geld kosten und Regulierer einen Audit Trail verlangen. Observability ist dort kein Luxus. Es ist eine betriebliche Notwendigkeit.

Fazit: Observability ist eine Investition, kein Kostenfaktor¶

Ein qualitativ hochwertiger Observability-Stack zahlt sich beim ersten Produktions-Incident aus. Statt stundenlangem blindem Suchen in Logs — Minuten gezieltes Debugging. Statt Alert Fatigue — handlungsrelevante Benachrichtigungen. Statt „Ich glaube, es funktioniert” — ein SLO-Dashboard, das objektiv sagt, wie es steht.

Die Technologien sind verfügbar und Open-Source. OpenTelemetry hat die Instrumentierung vereinheitlicht. Der Grafana-Stack bietet eine vollständige Lösung ohne Vendor Lock-in. Was bleibt, ist die Entscheidung, es richtig zu machen — von Anfang an instrumentieren, SLOs definieren, Alerting einrichten, das Sinn macht, und vor allem alle drei Säulen zu einem System verbinden. Denn Observability dreht sich nicht um Tools. Es geht darum, in Ihr System hineinzusehen und Entscheidungen auf Basis von Daten zu treffen.