Observability 2.0: OpenTelemetry, AIOps und Observability als Plattform-Anliegen

Für den größten Teil der 2010er‑Jahre war Observability etwas, das Teams nachträglich hinzufügten. Jeder Dienst hatte seine eigene Logging‑Bibliothek, sein eigenes Metrik‑Format, sein eigenes Tracing‑Setup oder hatte gar kein Tracing. Eine langsame Anfrage über fünf Dienste hinweg zu korrelieren, bedeutete, fünf Dashboards zu öffnen und Zeitstempel manuell abzugleichen. Da jedes Dashboard die Daten in einem eigenen Schema darstellte, musste man die Zeitstempel per Hand angleichen, was jedes Mal eine mühsame manuelle Synchronisation erforderte.

Dieser Ansatz skaliert nicht. Observability 2.0 erkennt, dass Observability ein Plattform‑Anliegen sein muss – standardisiert, automatisch und standardmäßig für jeden Dienst verfügbar – und keine Implementierungsentscheidung pro Team ist. Wenn die Zahl der Micro‑Services steigt, vervielfacht sich der manuelle Aufwand exponentiell, weil jede neue Komponente ein weiteres Dashboard und weitere Zeitabgleiche bedeutet.

Die drei Säulen und warum sie verbunden sein müssen

Observability wird konventionell als drei Säulen beschrieben: Logs, Metriken und Traces. Die Säulen sind nur dann nützlich, wenn sie miteinander verbunden sind.

• Logs zeichnen diskrete Ereignisse auf: eine Anfrage kam an, ein Fehler trat auf, eine Zahlung wurde verarbeitet. Sie sind hohe Kardinalität und menschlich lesbar, aber teuer zu speichern und langsam bei großem Maßstab abzufragen. Da jede Log‑Zeile eindeutige Identifikatoren enthalten kann, wächst das Datenvolumen schnell in die Millionen pro Sekunde, was Speicher‑ und Abfragekosten explodieren lässt.
• Metriken zeichnen aggregierte Messungen im Zeitverlauf auf: Anfragerate, Fehlerrate, Latenz‑Perzentile, CPU‑Auslastung. Sie sind günstig zu speichern und schnell abzufragen, verlieren aber das Detail, das zur Diagnose einzelner Ausfälle benötigt wird. Aggregationen fassen die Rohdaten in Buckets zusammen; sobald ein Anomalie‑Signal erscheint, fehlt der direkte Bezug zu einer einzelnen Anfrage, sofern nicht ein zusätzlicher Kontext bereitgestellt wird.
• Traces zeichnen den Pfad einer einzelnen Anfrage durch ein verteiltes System auf: welche Dienste sie berührte, wie lange jeder dauerte, wo sie fehlschlug. Sie sind unerlässlich für die Diagnose von Latenz und Fehlern in verteilten Systemen, erfordern aber Instrumentierung an jeder Dienstgrenze. Fehlt an einer Stelle die Instrumentierung, bricht die Kette ab und das End‑zu‑End‑Bild wird lückenhaft.

Das Problem mit der Behandlung dieser als separate Säulen: Ein Anstieg in der Fehlerrate‑Metrik sagt Ihnen, dass etwas falsch ist, aber nicht warum. Um herauszufinden, warum, müssen Sie von der Metrik zu den Logs für dieses Zeitfenster springen, dann die Trace‑ID in den Logs finden, dann den Trace öffnen. Wenn diese drei Systeme unterschiedliche Bezeichner, unterschiedliche Zeitstempel oder unterschiedliche Dienstnamen verwenden, ist diese Korrelation manuell und fehleranfällig. Ohne ein einheitliches Identifikationsschema wird jede manuelle Zuordnung zu einer potenziellen Fehlinterpretation führen. OpenTelemetry löst dieses Problem, indem es das Datenmodell und die Instrumentierungs‑API über alle drei Signale hinweg standardisiert.

OpenTelemetry: Der De‑Facto‑Standard

OpenTelemetry (OTel) ist ein CNCF‑Projekt, das ein herstellerunabhängiges SDK, eine API und einen Collector für die Generierung, Sammlung und den Export von Telemetriedaten bereitstellt. Es ist zum De‑Facto‑Standard für Instrumentierung in cloud‑nativen Systemen geworden. Durch diese Trennung können Entwickler ihre Anwendungen einmal instrumentieren und später beliebig zwischen Observability‑Backends wechseln, ohne den Code zu verändern.

Die Schlüsselentwurfsentscheidung: OpenTelemetry trennt Instrumentierung von Export. Sie instrumentieren Ihren Code einmal mit der OTel‑API. Sie konfigurieren den Collector, um in jedes gewünschte Backend zu exportieren – Jaeger, Prometheus, Grafana Tempo, Datadog, Honeycomb oder jedes andere OTel‑kompatible Backend. Das Wechseln von Backends erfordert keine Neu‑Instrumentierung Ihres Codes. Der Collector fungiert dabei als Übersetzer, der das einheitliche Datenformat in das jeweilige Backend‑Protokoll überführt.

// OpenTelemetry-Instrumentierung - einmal instrumentieren, überall exportieren
import { trace, metrics } from '@opentelemetry/api';

const tracer = trace.getTracer('order-service', '1.0.0');
const meter = metrics.getMeter('order-service', '1.0.0');

const orderCounter = meter.createCounter('orders.created', {
  description: 'Anzahl erstellter Bestellungen',
});

async function createOrder(orderData: OrderInput): Promise<Order> {
  return tracer.startActiveSpan('createOrder', async (span) => {
    try {
      span.setAttributes({
        'order.customerId': orderData.customerId,
        'order.itemCount': orderData.items.length,
      });

      const order = await orderRepository.save(orderData);
      orderCounter.add(1, { 'order.channel': orderData.channel });
      span.setStatus({ code: SpanStatusCode.OK });
      return order;
    } catch (error) {
      span.recordException(error as Error);
      span.setStatus({ code: SpanStatusCode.ERROR });
      throw error;
    } finally {
      span.end();
    }
  });
}

Auto‑Instrumentierung

Für gängige Frameworks und Bibliotheken bietet OTel Auto‑Instrumentierungspakete, die Tracing und Metriken hinzufügen, ohne Anwendungscode zu ändern:

// sdk.ts - vor Anwendungscode geladen
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4318/v1/traces' }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Damit können Entwickler sich auf die Geschäftslogik konzentrieren, während das Laufzeit‑Environment die erforderlichen Signale aufzeichnet. Die automatische Erfassung reduziert das Risiko, dass kritische Pfade uninstrumentiert bleiben.

Observability als Plattform‑Anliegen

Der Wechsel von per‑Team‑Observability zu Plattform‑Observability bedeutet, dass Instrumentierung, Sammlung und Basis‑Dashboards von der Plattform bereitgestellt werden – nicht von jedem Team implementiert.

Ein Plattform‑Observability‑Setup bietet typischerweise:

• Auto‑Instrumentierung standardmäßig: Dienste erhalten Traces und Metriken ohne Instrumentierungscode, durch Sidecar‑Injektion oder SDK‑Standardwerte. Die Plattform injiziert das OTel‑SDK beim Container‑Start, sodass jede Anfrage automatisch erfasst wird.
• Standardisierte Dienst‑Metadaten: Jeder Span und jede Metrik trägt konsistente Attribute – service.name, service.version, deployment.environment, k8s.pod.name – sodass Abfragen über alle Dienste hinweg funktionieren. Damit lassen sich Filter wie „Version 2.1“ einheitlich über Logs, Metriken und Traces anwenden.
• Basis‑Dashboards: Jeder Dienst erhält automatisch ein RED‑Dashboard (Rate, Errors, Duration) ohne teamspezifische Konfiguration. Die Dashboards visualisieren die drei Kernkennzahlen und ermöglichen ein sofortiges Erkennen von Regressionen.
• Automatisch propagierte Korrelations‑IDs: Eine am API‑Gateway generierte Trace‑ID wird durch jeden nachgelagerten Dienstaufruf propagiert. Da die ID in HTTP‑Headern mitgeschickt wird, entsteht ein lückenloser End‑zu‑End‑Trace ohne manuelles Zusammenfügen.

Vorteil: Ein neuer Dienst ist von Tag eins an beobachtbar, ohne Observability‑Arbeit des aufbauenden Teams. Teams können neue Services in Wochen statt in Monaten bereitstellen, da die Plattform die gesamte Observability‑Kette out‑of‑the‑box liefert.

AIOps: KI‑gestützte Anomalieerkennung und Ursachenanalyse

Standard‑Observability sagt Ihnen, was passiert ist. AIOps verwendet maschinelles Lernen, um Ihnen zu sagen, was ungewöhnlich ist und warum.

Anomalieerkennung

Traditionelles Alerting verwendet statische Schwellenwerte: Alarmieren Sie, wenn die Fehlerrate 1 % überschreitet. Statische Schwellenwerte erzeugen falsch‑positive Ergebnisse bei erwarteten Traffic‑Spitzen und verpassen Anomalien, die unter dem Schwellenwert bleiben. ML‑basierte Anomalieerkennung lernt das normale Muster für jede Metrik – einschließlich Saisonalität, Wochentag‑Effekte und Deployment‑korrelierte Änderungen – und alarmiert, wenn das Muster unerwartet abweicht. Das Modell aktualisiert kontinuierlich seine Basislinie, sodass ein plötzlicher Rückgang nach einem Rollout sofort eine Warnung auslöst, selbst wenn der absolute Wert noch im normalen Bereich liegt.

Ursachenanalyse

Wenn ein Vorfall auftritt, ist der schwierigste Teil oft die Identifizierung der Ursache über Dutzende von Diensten und Hunderte von Metriken hinweg. AIOps‑Tools können Anomalien über Dienste hinweg korrelieren, identifizieren, welche Metrik sich zuerst änderte (die wahrscheinliche Ursache statt des Symptoms), und die relevanten Traces und Logs automatisch aufzeigen. Sie erzeugen eine zeitlich sortierte Übersicht, die den frühesten Abweichungspunkt hervorhebt, sodass das Team gezielt den betroffenen Codebereich prüfen kann. Das ersetzt kein menschliches Urteil. Ein KI‑System, das identifiziert „Datenbankabfrage‑Latenz stieg 300 ms, bevor die API‑Fehlerrate anstieg“, liefert eine nützliche Hypothese, keine bestätigte Diagnose.

Praktische Grenzen

AIOps‑Tools sind am nützlichsten für bekannte Fehlermuster – die Art von Vorfällen, die schon einmal passiert sind und ein Muster in der Telemetrie hinterlassen haben. Neuartige Fehlermodi, Konfigurationsfehler und Logikfehler erzeugen oft nicht die Art von Metrik‑Anomalien, für die ML‑Modelle trainiert sind. Menschliche Untersuchung bleibt unerlässlich.

Das Observability‑Reifegradmodell

Ebene	Merkmale
0, Blind	Kein strukturiertes Logging, keine Metriken, kein Tracing
1, Reaktiv	Logs existieren; Metriken sind ad hoc; Debugging erfordert SSH
2, Proaktiv	Strukturierte Logs, grundlegende Metriken, Alerting bei Schwellenwerten
3, Korreliert	Traces verbinden Logs und Metriken; RED‑Dashboards für alle Dienste
4, Plattform	Auto‑Instrumentierung, standardisierte Metadaten, Basis‑Dashboards standardmäßig
5, Intelligent	Anomalieerkennung, automatisierte Korrelation, KI‑gestützte Ursachenanalyse

Die meisten Organisationen befinden sich auf Ebene 2 oder 3. Der Sprung zu Ebene 4 – Plattform‑Observability – ist die Investition mit dem höchsten Hebel, weil sie jeden nachfolgenden Dienst ohne zusätzliche Arbeit beobachtbar macht. Einmal implementiert, profitieren alle bestehenden und zukünftigen Services von einheitlichen Signalen, wodurch spätere Optimierungen kaum zusätzlichen Aufwand erfordern.

Warum diese Reihenfolge wichtig ist

Die Reifestufen sind nicht willkürlich. Jede Stufe ist Voraussetzung für die nächste. AIOps (Stufe 5) ist ohne korrelierte Signale (Stufe 3) nicht sinnvoll möglich, weil ML‑Anomalieerkennung ein konsistentes Datenmodell benötigt, um über Dienste hinweg zu korrelieren. Korrelierte Signale sind ohne standardisierte Instrumentierung (Stufe 4) nicht erreichbar, weil Korrelation gemeinsame Bezeichner – Trace‑IDs, Dienstnamen, Zeitstempel – voraussetzt, die nur existieren, wenn jeder Dienst sie im selben Format ausgibt. Fehlt diese Basis, erzeugen die KI‑Modelle nur Rauschen, das zu unzuverlässigen Alarmen führt. Deshalb erzielen Teams, die direkt zu AIOps‑Tooling springen, ohne zuerst Plattform‑Observability zu erreichen, schlechte Ergebnisse: Die ML‑Modelle korrelieren inkonsistente Daten und produzieren rauschige, unzuverlässige Alarme. Die Investition in Standardisierung zahlt sich auf jeder nachfolgenden Stufe aus. Ein sauberer, einheitlicher Datenfluss senkt die Fehlalarm‑rate und verkürzt die Zeit von der Erkennung bis zur Behebung.