MLflow LangGraph Tracing: jeden Agent-Schritt sichtbar machen

Pexon Consulting | 10 Min. Lesezeit | 10.06.2026

TL;DR

MLflow LangGraph Tracing löst das Observability-Problem produktiver Agent-Pipelines: Ohne Tracing siehst du nur Input und Output eines LangGraph-Runs — der Weg dazwischen, mit allen Tool-Calls, Subgraph-Aufrufen, LLM-Calls und Konditional-Edges, ist eine Blackbox. Mit MLflow Tracing bekommt jeder Knoten seinen eigenen Span, mit Eingabe, Ausgabe, Latenz, Cost und Custom-Metadata. Pexon Consulting setzt MLflow als Standard-Observability für LangGraph-Setups ein — Open Source, self-hosted, DSGVO-tragfähig.

Warum LangGraph Observability ein eigenes Problem ist

Wer eine LangGraph-Pipeline mit drei Knoten im Tutorial baut, denkt nicht über Observability nach — der Graph läuft, der Output passt, alles gut. Wer drei Monate später eine produktive Pipeline mit 12 Knoten, vier Subgraphs, externen Tool-Calls und konditionalen Edges hat, weiß plötzlich nicht mehr, warum ein bestimmter Lauf 47 Sekunden gebraucht hat statt der typischen 8.

Das Problem ist nicht LangGraph-spezifisch — es ist klassische Verteilte-System-Observability, übertragen auf Agent-Pipelines. Du brauchst Spans pro Knoten, Hierarchie der Aufrufe, Eingabe und Ausgabe jedes Tool-Calls, Token-Counts und Cost pro LLM-Call, Latenz-Verteilung über mehrere Runs. Ohne das fliegst du blind, sobald die Pipeline komplexer wird.

Die Standard-Antwort dafür war jahrelang LangSmith (von LangChain Inc.) oder kommerzielle Tools wie Langfuse, Helicone, Braintrust. MLflow Tracing — seit Version 2.14 produktiv — ist die Open-Source-Antwort, die seit Mitte 2025 stark wächst. Vorteile: voll self-hosted, DSGVO-trivial, integriert in das bestehende MLflow-Ökosystem (Experimente, Modell-Registry, Deployment-Tracking).

Was MLflow Tracing macht

Architektur in drei Komponenten.

Komponente 1: Tracing-Library im LangGraph-Code. Eine Zeile mlflow.langchain.autolog() aktiviert automatisches Span-Tracing für alle LangGraph-Knoten. Jeder add_node-Aufruf wird automatisch zu einem Span, jeder LLM-Call zu einem Sub-Span, Tool-Use zu einem weiteren Sub-Span. Hierarchie und Verschachtelung werden korrekt abgebildet.

Komponente 2: MLflow Tracking Server. Self-hosted Postgres-basierter Server, der die Traces persistiert. Läuft als Docker-Container oder als Python-Service. UI zur Trace-Inspektion, mit Span-Tree-Visualisierung, Eingabe-Ausgabe-Diff pro Span, Latenz-Histogramme.

Komponente 3: Aggregations- und Analyse-Layer. MLflow speichert Traces mit konfigurierbaren Tags, sodass du nach Conversation-ID, User, Feature-Branch oder anderen Dimensionen filtern kannst. Plus eingebaute Eval-Hooks, sodass aus einem produktiven Trace direkt ein Eval-Beispiel werden kann.

Auto-Instrumentation: das Minimal-Setup

import mlflow
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic

mlflow.set_tracking_uri("http://mlflow.intern:5000")
mlflow.set_experiment("customer-support-agent")
mlflow.langchain.autolog()

llm = ChatAnthropic(model="claude-sonnet-4-6", temperature=0.0)
graph = create_react_agent(llm, tools=[search_crm, get_order_status, ...])

result = graph.invoke({
    "messages": [{"role": "user", "content": "Wo ist meine Bestellung 4711?"}]
})

Was im Hintergrund passiert: Jeder Knoten des ReAct-Agents (Planning, Tool-Selection, Tool-Execution, Response-Generation) wird als Span getrackt. Jeder LLM-Call bekommt einen Sub-Span mit Tokens, Model, Latenz. Jeder Tool-Call wird mit Input, Output, Latenz protokolliert. Im MLflow-UI siehst du anschließend den vollständigen Aufruf-Baum, mit Drill-Down auf jeden Span.

Beispiel-Trace-Output für die obige Anfrage:

Bei dieser Tiefe ist Debugging trivial. Latenz-Spike? Sofort sichtbar in welchem Knoten. Tool-Output unerwartet? Direkt nachsehbar. Token-Cost zu hoch? Pro Knoten und Modell aufgeschlüsselt.

Custom Spans für business-spezifische Schritte

Auto-Instrumentation gibt dir die Standard-Spans (Node-Aufrufe, LLM-Calls, Tool-Calls). Für business-spezifische Logik nutzt du explizite Custom-Spans.

from mlflow import trace, start_span

@trace(name="customer_verification")
def verify_customer(customer_id: str) -> dict:
    with start_span("crm_lookup") as span:
        customer = crm.get(customer_id)
        span.set_attribute("customer_tier", customer.tier)
    
    with start_span("permission_check") as span:
        allowed_actions = check_permissions(customer)
        span.set_attribute("allowed_actions_count", len(allowed_actions))
    
    return {"customer": customer, "permissions": allowed_actions}

Mit diesem Pattern bekommst du Spans für deine eigene business-Logik mit Custom-Attributen, die im UI durchsuchbar sind. Bei einem Pilotkunden haben wir damit gezielt nach „Sessions mit Customer-Tier=Premium und Latenz > 5s“ gefiltert und so ein Tier-spezifisches Latenz-Problem in der Permission-Check-Routine identifiziert.

Vergleich: MLflow vs LangSmith vs Langfuse

Pexon-Empfehlung: Für reine LangGraph-Setups bei Mittelständlern mit DSGVO-Fokus ist MLflow Tracing die saubere Default-Wahl — self-hosted, voll Open Source, integriert ins MLflow-Ökosystem das ihr für ML-Workflows ohnehin braucht. LangSmith ist die Empfehlung bei Teams, die schon stark in LangChain investiert sind und die Cloud-Variante mit EU-Region akzeptieren. Langfuse ist die Empfehlung bei Multi-Modell-Setups (nicht nur LangGraph), die framework-agnostisches Tracing brauchen.

Production-Setup mit Pexon

Wir bauen MLflow-Tracing-Setups als Komponente in unseren LangGraph-Sprints. Lieferumfang typisch: MLflow Tracking Server in eurem K8s oder als systemd-Service, Postgres-Persistenz mit Backup, Anbindung an LangGraph-Pipeline mit Autolog plus Custom-Spans für business-Logik, optionale Anbindung an euer SIEM für Long-Term-Retention, Schulung der Engineering-Team-Mitglieder auf das Tracing-UI.

Investment je nach Scope 25-65k EUR. Bei Standard-Setups ist das Teil eines größeren LangGraph-Production-Sprints und nicht separat berechnet. Laufende Kosten typisch 50-200 EUR pro Monat für Hosting, plus Storage je nach Retention-Vorgabe.

Häufig gestellte Fragen

Wie groß ist der Performance-Overhead?

Bei richtig konfiguriertem MLflow Tracing typisch unter 3% Latenz-Overhead pro Run. Spans werden asynchron in den MLflow-Server geschickt, blocken den Graph-Lauf nicht. Bei sehr hochfrequenten Setups (>100 Runs pro Sekunde) bauen wir Sampling ein, sodass nicht jeder Run getracked wird — typisch 10-20% Sampling reicht für Eval und Debugging.

Können wir Traces später durchsuchen, wenn ein Vorfall passiert?

Ja, das ist der eigentliche Wert. MLflow-Tracking-Server hat Search-API für alle Trace-Attribute. Nach einem Vorfall („welche Customer-Sessions hatten in den letzten 24h Tool-Call-Errors“) liefert eine Query die relevanten Traces in Sekunden. Wir setzen Standard-Retention auf 90 Tage produktive Traces plus 1 Jahr aggregierte Statistiken.

Wie integriert sich das in MLflow-Experimente und Modell-Registry?

Voll. Wenn ihr MLflow bereits für ML-Experimente nutzt, läuft das Tracing in der gleichen Tracking-DB. Du kannst einen Trace mit einem Experiment-Run verknüpfen, sodass Modell-Versionierung, Eval-Resultate und produktive Traces nachvollziehbar zusammenhängen. Bei Teams mit reifer MLflow-Praxis ist das ein erheblicher Synergie-Effekt.

Funktioniert das auch mit Claude Agent SDK oder OpenAI Agents SDK?

Mit Caveats. Claude Agent SDK und OpenAI Agents SDK haben eigene Telemetry-Pfade. Wir nutzen für diese Setups OpenTelemetry-Export aus dem SDK in MLflow (über OTel-Collector). Das funktioniert, ist aber nicht ganz so frictionless wie die LangGraph-Autolog-Integration. Für reine LangGraph-Setups ist MLflow die einfachste Antwort.

Wie schützen wir PII in den Traces?

Wichtige Frage. Wir bauen Custom-Hooks ein, die vor dem Trace-Upload die Eingaben und Ausgaben durch einen PII-Filter laufen lassen. Standard-PII (Namen, E-Mail-Adressen, Telefonnummern) wird durch Tokens ersetzt. Bei sensitiven Branchen erweitern wir das auf domain-spezifische Patterns. Das ist 1-3 Tage Engineering plus Tests, dafür DSGVO-sauber.

Nächster Schritt

Wenn deine LangGraph-Pipeline produktiv läuft und du den Debug-Schmerz spürst: Wir machen einen 45-Minuten-Call mit dir und idealerweise einem Senior-Engineer. Du beschreibst die Pipeline-Komplexität und Observability-Stack, wir skizzieren das MLflow-Setup mit Festpreis.

Verwandte Themen