Observability

Beobachtbarkeit bezeichnet die Fähigkeit, anhand der von einem Softwaresystem ausgegebenen Telemetriedaten – vor allem Protokollen, Metriken und Traces – zu verstehen, was im System vor sich geht, und neue Fragen zu seinem Verhalten zu beantworten, ohne neuen Code einzuspielen. Der Begriff stammt aus der Regelungstheorie. Rudolf Kálmán definierte 1960 ein System als beobachtbar, wenn sich sein interner Zustand aus seinen Ausgaben bestimmen lässt. Softwareteams übernahmen den Begriff in den 2010er-Jahren, als Systeme auf viele Dienste verteilt waren und Fehler nicht mehr den im Voraus erstellten Dashboards entsprachen. Bei maschinellen Lernsystemen umfasst Beobachtbarkeit auch Daten und Vorhersagen: welche Eingaben ein Modell erhält, was es ausgibt, wie sicher es sich ist und wie sich all dies mit der Zeit verändert.

Protokolle, Metriken und Traces#

Drei Arten von Telemetriedaten, die oft als Säulen der Beobachtbarkeit bezeichnet werden, beantworten unterschiedliche Fragen:

• Metriken: Numerische Zeitreihen wie Anfragerate, Fehlerrate, Latenzperzentile, Arbeitsspeicher und GPU-Auslastung. Sie sind kostengünstig zu speichern und eignen sich für Dashboards und Warnmeldungen. Googles Handbuch zum Site-Reliability-Engineering nennt vier zentrale Messgrößen, die für jeden Dienst erfasst werden sollten: Latenz, Datenverkehr, Fehler und Auslastung.
• Protokolle: Mit Zeitstempeln versehene Aufzeichnungen einzelner Ereignisse. Besonders nützlich sind sie in strukturierter Form, etwa als JSON mit Feldern wie Anforderungs-ID, Modellversion und Eingabegröße, damit sie gefiltert und gezählt werden können.
• Traces: Der Weg einer einzelnen Anfrage durch alle Dienste, die sie durchläuft. Er wird als Baum aus Spans aufgezeichnet, die jeweils einen Namen, eine Startzeit, eine Dauer und Attribute enthalten. So wird sichtbar, wofür die Anfrage Zeit benötigt hat.

OpenTelemetry entstand 2019 durch den Zusammenschluss der Projekte OpenTracing und OpenCensus. Es stellt herstellerneutrale APIs, SDKs und ein Übertragungsprotokoll (OTLP) für alle drei Signalarten bereit. Backends wie Prometheus, Grafana und Jaeger speichern und visualisieren diese Daten. Dieses Beispiel verfolgt eine einzelne Bildklassifizierungsanfrage mit dem OpenTelemetry Python SDK und zeichnet einen übergeordneten Span für die Anfrage sowie einen untergeordneten Span für jede Phase auf:

import torch
import torchvision
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.sdk.trace.export.in_memory_span_exporter import InMemorySpanExporter

# Keep finished spans in memory; a production service exports them over OTLP instead
exporter = InMemorySpanExporter()
provider = TracerProvider()
provider.add_span_processor(SimpleSpanProcessor(exporter))
tracer = provider.get_tracer("classifier")
model = torchvision.models.resnet18().eval()
frame = torch.rand(3, 1080, 1920)

# Trace one request as a parent span with a child span for each stage
with tracer.start_as_current_span("predict", attributes={"model.name": "resnet18", "image.height": 1080}):
    with tracer.start_as_current_span("preprocess"):
        batch = torchvision.transforms.functional.resize(frame, [224, 224]).unsqueeze(0)
    with tracer.start_as_current_span("inference"), torch.inference_mode():
        logits = model(batch)

spans = exporter.get_finished_spans()
names = {span.context.span_id: span.name for span in spans}
for span in spans:
    parent = names[span.parent.span_id] if span.parent else "-"
    print(f"{span.name:<11} {(span.end_time - span.start_time) / 1e6:5.1f} ms  parent: {parent}")

Auf einer Apple M5 Pro CPU gibt es einen Span preprocess von 1,0 bis 1,4 ms und einen Span inference von 7 bis 9 ms aus. Beide haben predict als übergeordneten Span. Ein Span predict dauert 8 bis 10 ms. Der Trace zeigt somit, dass das Modell den größten Teil der Anfragezeit beansprucht. Werden Spans über OTLP exportiert, fügt jeder Dienst, der eine Anfrage verarbeitet, Spans unter derselben Trace-ID hinzu. Ein Backend wie Jaeger stellt sie als gemeinsame Zeitleiste dar.

Beobachtbarkeit im Vergleich zu Überwachung#

Modellüberwachung erkennt bekannte Fehlerbilder mithilfe vordefinierter Metriken, Dashboards und Schwellenwerte für Warnmeldungen, etwa eine Fehlerrate über 1 % oder eine Inferenzlatenz oberhalb eines Zielwerts. Beobachtbarkeit ist das umfassendere Konzept: Sie ermöglicht die Untersuchung unerwarteter Fehler, indem detaillierte Telemetriedaten nachträglich nach Kunde, Modellversion, Kamera oder einem anderen Merkmal aufgeschlüsselt werden. Das Google-SRE-Handbuch verlangt, dass die Überwachung zwei Fragen beantwortet: Was ist defekt und warum? Bei der Untersuchung führt der Weg über alle drei Signalarten von der ersten zur zweiten Antwort:

Erklärbare KI ist ein eigenständiges Fachgebiet, das erklärt, warum ein Modell anhand seiner Eingabemerkmale oder internen Aktivierungen eine bestimmte Ausgabe erzeugt hat. Die Zuordnungen können als zusätzliches Signal protokolliert werden.

Beobachtbarkeit für maschinelles Lernen#

Systeme für maschinelles Lernen versagen oft unbemerkt: Ein Computer-Vision-Modell kann jede Anfrage mit HTTP 200 beantworten, während seine Vorhersagen schlechter werden, weil die Kamera verschoben wurde, sich die Beleuchtung geändert hat oder ein neues Produkt hinzugekommen ist. Die Beobachtbarkeit von ML ergänzt daher die üblichen Dienstsignale um Telemetriedaten zu Daten und Vorhersagen. Teams erfassen Eingabestatistiken wie Bildgröße und Helligkeit, um Daten-Drift zu erkennen, verfolgen Vorhersageverteilungen wie Klassenhäufigkeiten, leere Ergebnisse und mittlere Konfidenz und berechnen die Genauigkeit nach Segment, sobald – oft erst Tage später – Referenzlabels vorliegen. Beim Training übermitteln Callbacks Verlustkurven, Metriken und Systemauslastung für jeden Lauf an Werkzeuge zur Versuchsverfolgung wie TensorBoard und MLflow. Bei Anwendungen mit KI-Agenten und großen Sprachmodellen erfassen Traces jeden Prompt, Abruf, Werkzeugaufruf und jede Antwort. Die semantischen OpenTelemetry-Konventionen für GenAI standardisieren Attribute wie gen_ai.usage.input_tokens, sodass die Anzahl und Kosten von Tokens toolübergreifend vergleichbar sind.

Für jeden dedizierten Endpunkt auf der Ultralytics Platform ist eine Überwachung der Bereitstellung integriert: Karten mit Anfrageanzahl, Fehlerrate und p95-Latenz, ein Protokoll-Tab mit Schweregraden und einem Fehlerfilter für Fehlermeldungen und Warnungen sowie Vorhersagestatistiken. Diese zeigen die häufigsten Klassen, die mittlere Konfidenz im Zeitverlauf, Vorhersagen pro Bild und die Modellinferenzzeit getrennt von der Anfragelatenz. Eine sinkende Konfidenzkurve oder eine Verschiebung bei den häufigsten Klassen ist in diesen Diagrammen erkennbar, selbst wenn jede Anfrage erfolgreich ist.