Observability für LLM-Systeme: Metriken, Traces, Logs und Testing in der Produktion

LLM-Systeme versagen auf Arten, die herkömmliches API-Monitoring nicht aufdecken kann – Warteschlangen füllen sich stillschweigend, der GPU-Speicher sättigt lange bevor die CPU ausgelastet wirkt, und die Latenz steigt im Batching-Layer an, nicht im Anwendungslayer.

Dieser Leitfaden behandelt eine durchgängige Beobachtbarkeitsstrategie für LLM-Inferenz und LLM-Anwendungen: was gemessen werden soll, wie dies mit Prometheus, OpenTelemetry und Grafana instrumentiert wird und wie die Telemetrie-Pipeline im großen Maßstab bereitgestellt wird.

Vollständige Assistenz-Stacks fügen Retrieval, Tool-Aufrufe und Routing auf der Basisinferenz hinzu; AI-Assistenten-Architektur zeigt, wo Beobachtbarkeit in diesen Schichten angesiedelt ist.

TL;DR (Zusammenfassung)

LLM-Systeme degradieren auf Arten, die klassisches „HTTP-Latenz + Fehlerrate“-Monitoring nicht erklären kann. Produktionsreife Beobachtbarkeit für LLM-Systeme muss schnell und nachvollziehbar beantworten:

• Ob die Benutzererfahrung leidet (Endlatenz, Zeit bis zum ersten Token, Inter-Token-Latenz, Fehler und Abbrüche).
• Wo Zeit verbracht wird (Warteschlange vs. Batching vs. Modellausführung; Retrieval/Tools/Sicherheitsfilter vs. Inferenz).
• Was zuerst sättigt (GPU-Auslastung und Speicherdruck, KV-Cache/Warteschlangen-Druck, CPU-Tokenisierung).
• Wie sich Kosten und Kapazität verschieben (Tokens pro Anfrage, Tokens/Sekunde pro GPU, Cache-Trefferquote, verschwendete Generierungen).
• Ob die Telemetriedaten sicher gespeichert werden können (Prompts können PII enthalten; verhindern Sie das Lecken sensibler Daten in Logs/Attribute).

Das widerstandsfähigste Design ist eine Multi-Signal-Pipeline:

• Metriken für schnelle Erkennung und Kapazitätsplanung (Prometheus + PromQL; optionale Langzeitspeicherung via Thanos/Cortex/Mimir/VictoriaMetrics).
• Traces für kausale Zusammenhänge auf Anfrageebene (OpenTelemetry mit OTLP; Backends wie Tempo/Jaeger/Zipkin/Elastic APM).
• Logs für Kontext, korreliert mit Traces (Loki/Elastic/OpenSearch), ausgelegt auf Metadaten mit niedriger Kardinalität.
• Profiling für CPU-/Speicher-Hotspots und Endlatenz (Grafana Pyroscope).
• Synthetische + Lasttests zur Erkennung von Regressionen, bevor Benutzer sie bemerken (Grafana k6; Probing im Blackbox-Stil).
• SLOs zur Messung von Benutzerergebnissen und zur Steuerung aktionsorientierter Alerting (Error Budgets; Burn-Rate-Stil).

Was die Beobachtbarkeit für LLM-Systeme unterscheidet

Gültigkeitsbereich: Das Ziel-LLM-Framework ist nicht spezifiziert. Die Beispiele in diesem Artikel decken gängige Server/Frameworks ab (Triton, vLLM, TGI, LangChain/LangSmith) und bleiben durch Substitution äquivalenter Metriken und Spans auf andere Stacks anwendbar.

LLMs introduce operative Verhaltensweisen, die sich von herkömmlichen Webdiensten unterscheiden:

• Variable Arbeitslast pro Anfrage: Token-Anzahlen (Eingabe/Ausgabe) variieren stark, sodass „Anfragen pro Sekunde“ stabil aussehen können, während der Token-Throughput zusammenbricht. TGI und vLLM exportieren explizit Token- und Token-Latenz-bezogene Telemetriedaten, um diese Art des Monitorings zu unterstützen.
• Warteschlangen + kontinuierliches Batching: Der Durchsatz hängt von Batching-/Warteschlangendisziplinen ab; Warteschlangenlänge und Batchgröße werden zu Indikatoren erster Ordnung (TGI gibt beide frei).
• Streaming-Benutzererfahrung: Benutzer interessieren sich für TTFT (Time-to-First-Token) und Inter-Token-Latenz mindestens genauso sehr wie für die Gesamtantwortzeit; OpenTelemetry standardisiert Server-TTFT/Zeit-pro-Token-Metriken sogar unter GenAI-Semantik-Konventionen.
• GPU-Druck dominiert Ausfallmodi: GPU-Auslastung und GPU-Speicher (einschließlich genutzter Speicher) sind zentral für die Zuverlässigkeit; NVIDIAs DCGM-Exporter existiert speziell, um GPU-Telemetriedaten an einem Prometheus /metrics-Endpunkt freizugeben.
• Mehrstufige Pipelines: Retrieval, Tool-Aufrufe, Sicherheitsfilter und Nachbearbeitung bedeuten, dass die End-to-End-Latenz eine Komposition mehrerer Spans/Warteschlangen ist – was verteilte Tracing und sorgfältiges Metrik-Design essentiell macht.

Konkrete Beispiele aus beliebten Inferenzservern hervorheben dies:

• NVIDIA Triton Inference Server gibt Metriken als Klartext über /metrics (häufig :8002/metrics) frei und bietet Flags zum Aktivieren/Deaktivieren von Metriken und zur Auswahl eines Metriken-Ports.
• vLLM gibt einen umfangreichen Prometheus /metrics-Endpunkt mit einem vllm:-Präfix frei; seine Dokumentation enthält Zähler für Generierungstokens und Histogramme wie Zeit bis zum ersten Token.
• Hugging Face TGI dokumentiert einen /metrics-Endpunkt mit Warteschlangenlänge, Batchgröße, End-to-End-Anfrage-Dauer, generierten Tokens und Warteschlangendauer.

Kernaufgaben der Beobachtbarkeit und erforderliche LLM-Telemetrie

Beobachtbarkeit für LLM-Systeme ist am einfachsten zu implementieren, wenn Sie Aufgaben → Signale → Tools abbilden und Kardinalität sowie Sampling von Tag eins an einschränken.

Metriken: Für Online-Serving-Systeme hebt die eigene Instrumentierungsanleitung von Prometheus Abfrageanzahl, Fehler und Latenz als Schlüsselmetriken hervor; LLMs erweitern dies um TTFT, pro-Token-Throughsatz/Latenz, Warteschlangenlänge, Batchgröße und GPU-Auslastung.

Traces: Traces sind der Weg, um Latenz und Fehler über Retrieval/Tools/Sicherheit/Inferenz-Stufen hinweg zuzuordnen; OpenTelemetry rahmt Traces/Exporter als einen vendor-neutralen Weg ein, Telemetriedaten an Sammler oder Backends zu senden.

Logs: Logs bieten menschlich lesbaren Kontext und das „Warum“, bleiben aber nur im großen Maßstab nutzbar, wenn Sie das Indizieren unbegrenzter Werte vermeiden (Beispiel: Loki indiziert nur Labels und speichert komprimierte Log-Chunks in Object Storage).

Profiling: Kontinuierliches Profiling fängt Produktions-CPU-/Speicherverhalten mit geringem Overhead durch Sampling ein; Grafana Pyroscope ist explizit dafür positioniert.

Synthetische Tests und Lasttests: Grafana k6 ist ein Open-Source-Lasttesttool, und Grafana gibt an, dass Synthetic Monitoring von k6 angetrieben wird und über einfache Protokollchecks hinausgeht.

SLOs: Googles SRE-Anleitung definiert ein SLO als Zielwert/-bereich für ein Service Level, gemessen durch ein SLI, und bietet Anleitung für Alerting auf SLOs (Zielkonflikte Präzision/Rückruf/Erkennungszeit).

Schlüssel-LLM-Metriken-Blaupause

OpenTelemetry GenAI-Semantik-Konventionen zur Standardisierung

OpenTelemetry stellt GenAI-Semantik-Konventionen bereit (Status: „In Entwicklung“) mit Standardbenennung für GenAI-Metriken wie:

• gen_ai.client.token.usage und gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token und gen_ai.server.time_to_first_token

Diese Standardisierung ist ein praktischer Hebel für portable Strategien zur „Überwachung von LLM-Modellen mit OpenTelemetry“: einmal emittieren und dieselbe Telemetrie später zu OSS- oder Vendor-Backends routen.

Design der Telemetrie-Pipeline

Pull vs. Push

Prometheus ist pull-basiert. Prozesse geben Metriken in einem unterstützten Expositionformat frei, und Prometheus scrapt sie gemäß konfigurierten Scrape-Jobs.

Push ist für Ausnahmen. Die Prometheus-Anleitung „Wann man das Pushgateway verwendet“ empfiehlt das Pushgateway explizit nur in begrenzten Fällen (nicht als allgemeinen Push-Ersatz), und die Pushgateway-README betont, dass es Prometheus nicht „in ein push-basiertes Monitoring-System verwandeln“ kann.

Praktisches Muster für LLMs:

• Verwenden Sie Pull für Inferenzserver/Exporter (Triton/vLLM/TGI-Metriken-Endpunkte; DCGM-Exporter; Node-Metriken).
• Verwenden Sie OTLP-Push für Traces/Logs/OTel-Metriken (OpenTelemetry Protocol definiert Transport/Kodierung/Lieferung zwischen Quellen, Sammlern und Backends).
• Verwenden Sie Remote Write, wenn Sie über ein einzelnes Prometheus hinaus skalieren (Prometheus bietet Tuning-Anleitungen für Remote Write; Mimir/Thanos/Cortex bieten Optionen für Langzeit- und/oder HA-Speicherung).

Agent vs. Sidecar vs. Gateway-Sammler

OpenTelemetry dokumentiert ein Agent-Bereitstellungsmuster, bei dem Telemetriedaten an einen Collector gesendet werden, der neben der Anwendung oder auf demselben Host (Sidecar/DaemonSet) läuft, und dann exportiert wird.

Für Kubernetes wird Sidecar-Injection via dem OpenTelemetry Operator unterstützt (annotation-basierte Injection).

Pragmatische Daumenregel für LLM-Stacks:

• Verwenden Sie einen DaemonSet-Agent für Host-Level-Anreicherung und geteilte Pipelines über viele Pods hinweg.
• Verwenden Sie einen Sidecar, wenn Sie strikte Isolierung pro Workload oder dediziertes lokales Filtering benötigen (häufig, wenn Prompts sensible Daten enthalten können).
• Verwenden Sie einen Gateway-Collector für zentralisiertes Tail-Sampling, Batching, Wiederholungen und Export-Fan-out.

Sampling und Kardinalitätskontrolle

OpenTelemetry klärt, dass Tail-Sampling Sampling-Entscheidungen auf Basis von Kriterien erlaubt, die aus einem Trace abgeleitet sind (nicht möglich mit reinem Head-Sampling).

Die Instrumentierungsanleitung von Prometheus warnt vor übermäßigem Label-Einsatz, bietet eine Daumenregel zur Niedrighaltung der Kardinalität und rät zur Neugestaltung von Metriken, wenn die potenzielle Kardinalität ~100 überschreitet.

LLM-spezifische „Kardinalitätsfallen“, die früh verboten werden sollten:

• Prompt-Text, Antworttext, Konversations-IDs, Anfrage-IDs als Labels/Attribute.
• Tool-Argument-Blobs als Span-Attribute.
• Ungebundene „user_id“-Labels.

Bevorzugen Sie gebundene Dimensionen: model, model_family, endpoint, region, status_code, deployment, tenant (nur wenn gebunden).

Vergleich der LLM-Beobachtbarkeitstools

Tools zugeordnet zu Beobachtbarkeitsaufgaben

Grafana vs. Alternativen für Visualisierung

• Grafana-Dashboards bestehen aus Panels, die Datenquellen (einschließlich Loki und Mimir) abfragen, um Charts und Visualisierungen zu erzeugen.
• Kibana stellt Dashboards/Visualisierungen als UI-Schicht innerhalb des Elastic Stack bereit.
• OpenSearch Dashboards stellt Datenvisualisierungstools für OpenSearch bereit.
• Die Dokumentation von InfluxData positioniert Chronograf als Visualisierungskomponente innerhalb des Influx-Ökosystems.

Prometheus vs. Alternativen für Metriken-Backends

• Prometheus-Local-Storage-Standardwerte: Wenn Retention-Flags nicht gesetzt sind, standardisiert die Retention auf 15d (planen Sie Retention/Kosten frühzeitig).
• Grafana Mimir wird als horizontal skalierbar, HA, multi-tenant Langzeitspeicher für Prometheus- und OpenTelemetry-Metriken beschrieben.
• Thanos wird als hochverfügbares Prometheus-Setup mit Langzeitspeicher-Fähigkeiten beschrieben.
• Cortex beschreibt sich selbst als horizontal skalierbare, HA, multi-tenant Langzeitspeicher-Lösung für Prometheus- und OpenTelemetry-Metriken.
• VictoriaMetrics Cloud dokumentiert Prometheus-Remote-Write-Integration für Langzeitspeicherung.
• Amazon Managed Service for Prometheus beschreibt ein verwaltetes Angebot, das mit Ingestion-/Query-Anforderungen skaliert und PromQL sowie Remote Write unterstützt.

Praktische Implementierungs-Kochbuch

Metriken-Namen und -Typen, die heute implementiert werden sollten

OpenTelemetry GenAI-Semantik-Konventionen (Status: In Entwicklung) definieren Metriken-Namen, die Sie sofort standardisieren können:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

Serverseitige Beispiele, die Sie sofort scapen können:

• Der Prometheus-Endpunkt von vLLM enthält Zähler (z. B. Gesamtzahl der Generierungstokens) und Histogramme (TTFT) und dokumentiert eine model_name-Label-Strategie.
• TGI dokumentiert Metriken einschließlich Warteschlangenlänge, Anfrage-Dauer, generierte Tokens und mittlere Zeit pro Token.
• Triton dokumentiert /metrics-Freigabe und Metriken-Toggles.

PromQL-Beispiele für LLM-Latenz- und Durchsatz-Dashboards

# p95 End-to-End-Latenz für ein Anwendungshistogramm
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Fehlerrate in Prozent (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Tokens/Sekunde (Ausgabe) über alle Modelle
sum(rate(llm_tokens_total{direction="out"}[5m]))

# TGI-Warteschlangenlänge (Gauge)
max(tgi_queue_size) by (instance)

# vLLM TTFT p95
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

Die Histogramm-Anleitung von Prometheus erklärt, dass Histogramm-Quantile serverseitig aus Buckets unter Verwendung von histogram_quantile() berechnet werden.

OpenTelemetry-Instrumentierungsnotizen für LLM-Systeme

• OTLP ist das OpenTelemetry Protocol, das spezifiziert, wie Telemetriedaten zwischen Quellen, Sammlern und Backends kodiert/übertragen werden.
• OpenTelemetry SDK-Konfigurationsdokumente Umweltvariablen wie OTEL_EXPORTER_OTLP_ENDPOINT (und Protokolloptionen) für das Exportieren von Telemetriedaten.
• OpenTelemetry Python contrib dokumentiert FastAPI-Instrumentierungsunterstützung für automatische und manuelle Instrumentierung.
• GenAI-Semantik-Konventionen umfassen einen opt-in-Stabilitätsmechanismus via OTEL_SEMCONV_STABILITY_OPT_IN für die Migration von GenAI-Konventionen.

Kurzes Python-Beispiel: Metriken + Traces + Logs

Das folgende Snippet demonstriert:

• Prometheus-Metriken-Exposition (/metrics) für „Monitoring von LLM-Inferenz mit Prometheus“
• OpenTelemetry-Traces, exportiert via OTLP (vendor-neutral)
• Strukturierte Logs, korreliert mit Trace-Kontext, mit einem datenschutzsicheren Standard (nicht rohe Prompts loggen)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (pull-basierte Metriken)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (OTLP-Traces)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="LLM Inferenz-API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Logging (datenschutzsicherer Standard) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Prometheus-Metriken ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLM-Anfragen gesamt",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "End-to-End-LLM-Anfrage-Latenz (Sekunden)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- OpenTelemetry-Tracer-Provider ---
resource = Resource.create({"service.name": "llm-inferenz-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # konfigurieren via OTEL_EXPORTER_OTLP_* Umgebungsvariablen
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "nicht spezifiziert"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # Vermeiden Sie das Protokollieren des vollständigen Prompts; emittieren Sie sichere Metadaten
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Ersetzen Sie mit tatsächlicher LLM-Aufruf (Triton/vLLM/TGI-Client)
        time.sleep(0.15)
        output = "Hallo vom Modell."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_anfrage_abgeschlossen",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # Loggen Sie KEINE rohen Prompts/Ausgaben, es sei denn, die Richtlinie erlaubt es.
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Bereitstellung, Skalierung, Sicherheit und Fehlerbehebung

Bereitstellungsoptionen

Skalierung und Retention: praktische Einschränkungen

• Prometheus-Local-Storage: Ohne explizite Size/Time-Flags standardisiert die Retentionszeit auf 15d.
• Prometheus-Remote-Write: Prometheus dokumentiert Remote-Write-Tuning für die Skalierung über „sinnvolle Standardwerte“ hinaus.
• Grafana Tempo: Positioniert als hochskalierbares Tracing-Backend und kann Metriken aus Spans erzeugen unter Verwendung des metrics-generator (Remote-Writes an eine Prometheus-Datenquelle).
• Loki-Speicherung: Lokis Docs betonen Label-nur-Indizierung und komprimierte Chunk-Speicherung (Object Storage), was Label-Strategie zentral für Skalierung und Kosten macht.

Sicherheit und Privatsphäre: Prompts können PII enthalten

OpenTelemetries Sicherheitsanleitung betont, dass Telemetrie-Sammlung unbeabsichtigt sensible/persönliche Informationen erfassen kann; Sie sind dafür verantwortlich, diese angemessen zu behandeln.

Das Sicherheitsmodell von Prometheus warnt davor, Prometheus-Endpunkte öffentlich zugänglichen Netzwerken (wie dem Internet) zu exponieren, da sie Informationen über überwachte Systeme bereitstellen.

Operative Datenschutzkontrollen, die „Beobachtbarkeit für LLM-Systeme“ sicher halten:

• Standardmäßig nicht rohe Prompts/Antworten loggen; loggen Sie stattdessen Token-Anzahlen, Modellnamen, Latenz und Trace-IDs.
• Redigieren/droppe sensible Attribute in Sammlern/Pipelines (Collector-Level-Filterung ist ein gängiger Ansatz in Ökosystemen).
• Erzwingen Sie RBAC und Retention-Richtlinien für Logs/Traces; erwägen Sie Scanner für sensible Daten, wo angemessen (z. B. dokumentieren Vendor Scanner für Telemetrie).

Fehlerbehebungs-Checkliste

Wenn Ihr Grafana-Dashboard für LLM-Latenz falsch aussieht, debuggen Sie in dieser Reihenfolge:

• Ingestion-Gesundheit
  • Prometheus: Validieren Sie Scrape-Erfolg und Konfigurationssemantik (Prometheus-Konfiguration definiert Scrape-Jobs/Instanzen).
  • OTLP: Bestätigen Sie Exporter-Endpunkt-Konfiguration (SDKs verwenden OTEL_EXPORTER_OTLP_ENDPOINT, Protokolleinstellungen).
• Schema-Mismatch
  • Dashboard erwartet model, aber Ihr Server emittiert model_name (vLLM dokumentiert model_name-Labels explizit).
• Kardinalitäts-Explosion
  • Jemand hat nach Anfrage-IDs/Prompt-Hashes gelabelt; Prometheus warnt, dass Labelsets RAM/CPU/Disk/Netzwerkkosten erhöhen, und bietet Kardinalitätsanleitung.
• Falsche Verwendung von Histogrammen
  • Stellen Sie sicher, dass Sie Quantile aus _bucket-Serien mit rate() und le berechnen; Prometheus erklärt Zielkonflikte bei der Berechnung von Histogramm-Quantilen.
• Lücken im Trace-Sampling
  • Wenn Sie zu aggressiv head-sample, verschwinden seltene langsame/Fehler-Traces; Tail-Sampling behält „wichtige“ Traces basierend auf vollständigen Trace-Kriterien bei.
• Tempo Span-Metriken-Probleme
  • Wenn Sie Tempo metrics-generator und span-metrics verwenden, bestätigen Sie, dass es aktiviert und getunt ist (Tempo dokumentiert metrics-generator und span-metrics-Processors; Fehlerbehebung existiert für Generator-Probleme).
• GPU-Metriken fehlen
  • Bestätigen Sie, dass DCGM-Exporter bereitgestellt ist und /metrics erreichbar ist (DCGM-Exporter gibt GPU-Metriken über HTTP für Prometheus frei).

Nützliche Links

• Polling Agents in AI Assistants: 11 Implementation Patterns — der Abschnitt zur Beobachtbarkeits-Checkliste deckt genau ab, welche Hintergrund-Agent-Metriken, Log-Felder und Admin-Ansichten für Produktions-Polling-Systeme instrumentiert werden müssen
• Beobachtbarkeit: Monitoring, Metriken, Prometheus & Grafana-Leitfaden
• A2A vs. MCP: Brauchen KI-Agenten wirklich beide Protokolle? — die Abschnitte zu Beobachtbarkeit und Sicherheit dort decken ab, was in Multi-Agent-Systemen zu tracen ist, die beide Protokolle kombinieren
• Multi-Agent-Orchestrierungsmuster — der Abschnitt zur Beobachtbarkeit deckt spezifische verteilte Tracing-Anforderungen für jedes Muster ab: Blackboard-Replay für Swarm, Kostenattribution pro Agent und Konvergenzmonitoring für Mesh
• Google A2A-Protokoll 2026: Adoption, Hype und Realität — die Abschnitte zu Sicherheit und häufigen Fehlern decken genau ab, welche Beobachtbarkeit Sie benötigen, wenn Sie Agenten über A2A-Grenzen hinweg bereitstellen
• Was ist das A2A-Protokoll? Agent Cards und Tasks erklärt — der Abschnitt zur Beobachtbarkeit erklärt, was ein cross-agent Task-Trace erfassen muss: Task-Statusänderungen, Delegationsketten, Artefakte und Agent-to-Agent-Nachrichten
• Prometheus-Monitoring: Einrichtung & Best Practices
• LLM-Leistung: Benchmarks, Engpässe & Optimierung
• LLM-Hosting: Lokal, Self-Hosted & Cloud-Infrastruktur verglichen
• RAG Schritt-für-Schritt-Tutorial
• Prometheus-Konfigurationsdokumentation
• Prometheus-Expositionformate
• Prometheus-Instrumentierungs-Best-Practices
• Prometheus-Metrikbenennung
• Prometheus-Histogramme und Summaries
• Prometheus-Alerting-Regeln
• Prometheus-Alerting-Übersicht
• Alertmanager-Konfiguration
• Grafana-Dashboard-JSON-Modell
• Grafana-Provisioning
• NVIDIA Triton Inference Server-Metriken
• TorchServe-Metriken-API
• NVIDIA DCGM-Exporter
• kube-prometheus-stack Helm-Chart
• Prometheus Operator-Einführung
• OpenTelemetry-Prometheus-Exporter-Spezifikation
• Prometheus-Leitfaden für OTLP-Empfang
• LangSmith-Tracing mit OpenTelemetry