Das ist ein Span aus einem echten Trace, aufgezeichnet bei der Validierung unseres neuen Tracing Service gegen ein Modell auf dem IONOS CLOUD AI Model Hub.
Das meiste davon ist gewöhnliche Betriebstelemetrie: welches Modellverwendet wurde, wie viele Token hinein- und hinausgingen, wie lange der Aufruf dauerte. Drei Attribute sind jedoch von einer anderen Art. gen_ai.prompt.0.content und gen_ai.prompt.1.content enthalten die System-Anweisung und das, was ein Nutzer eingegeben hat. gen_ai.completion.0.content enthält die Antwort des Modells – wortwörtlich im Monitoring-System gespeichert.
Wer KI-Observability aktiviert, speichert damit auch, was das Modell verarbeitet: Support-Tickets, Patientenkorrespondenz und Lieferantenverträge. Meist geschieht das, ohne dass dies explizit entschieden wurde.
Damit wird die Frage, wo diese Telemetrie liegt, zu einer Datenschutzfrage.
Warum Traces sinnvoll sind
Wenn eine KI-Funktion sich falsch verhält, liegt der Verdacht schnell beim Modell. Meist zu Unrecht.
Nicht das Modell ist die Blackbox, sondern der Weg dorthin.
Ein einzelner Agent-Lauf ist ein verteiltes System im Kleinen: ein Retrieval-Schritt, ein oder zwei Tool-Aufrufe, ein Modellaufruf und anschließend die Nachverarbeitung. Manchmal verfeinert ein zweiter Modellaufruf das Ergebnis des ersten.
Wenn eine Antwort neun Sekunden statt zwei benötigt oder vierzig Cent statt vier kostet, lautet die Erklärung selten „das LLM war langsam“. Sie liegt in der Abfolge der einzelnen Schritte. Ein Retrieval, das zu viel lieferte, ein Prompt, der unbemerkt wuchs, ein Tool-Aufruf, der in ein Timeout lief und wiederholt wurde.
Aus Logs lässt sich dieser Ablauf nicht rekonstruieren. Gebraucht wird der gesamte Lauf als ein zusammenhängendes Objekt, mit Laufzeiten und Token-Zahlen für jeden Schritt. Genau das leistet Distributed Tracing. Es ist jetzt in IONOS CLOUD allgemein verfügbar, als dritte Säule unserer Observability-Plattform neben Logging und Monitoring.
Die unangenehme Konsequenz
Ein Muster, dem wir immer wieder begegnen: Ein Unternehmen wählt sorgfältig einen europäischen Modellanbieter, damit die Inferenz lokal bleibt. Dann leitet es die entstehende Telemetrie in einen US-amerikanischen Monitoring-Stack, den das Team den ohnehin betreibt.
Die Inferenz ist souverän. Die Prompts verlassen die EU trotzdem, durch die Hintertür.
Das ist mehr als ein architektonischer Schönheitsfehler. Prompts können personenbezogene Daten enthalten: Support-Tickets, Korrespondenz oder Vertragstext. Ein Tool, das zur Messung der p99-Latenz angeschafft wurde, ist stillschweigend zu einem Speicher für Kundeninhalte geworden. Meist prüft dann niemand erneut, wo dieser Speicher betrieben wird und wer darauf zugreifen kann.
Damit fällt der Observability-Stack unter die Fragen, die jedem System zu stellen sind, das Kundeninhalte speichert: Wo liegt er, wer betreibt den Stack, wie lange werden Daten aufbewahrt, und weiß Ihre Datenschutzprüfung davon? Diese Antworten waren geklärt, solange das Tool nur Latenz-Perzentile enthielt. Jetzt gelten sie möglicherweise nicht mehr.
Bei KI-Workloads ist der Standort der Telemetrie zugleich der Standort der Inhalte. Observability ist damit nicht mehr nur eine Werkzeugentscheidung.
Warum Prompt-Aufzeichnung eine bewusste Entscheidung sein muss
Das ehrliche Gegenargument: Die Aufzeichnung von Prompts und Completions ist optional und sollte eine bewusste Entscheidung sein, keine Voreinstellung.
Der größte Debugging-Wert liegt tatsächlich im Inhalt. Denn „Warum hat das Modell so geantwortet?“ ist fast immer eine Frage nach dem Prompt. Aber einschalten sollte man es mit offenen Augen.
Sinnvoll ist eine Begrenzung auf die Umgebungen, in denen Prompt-Inhalte wirklich gebraucht werden. Dreißig Tage Aufbewahrung bedeuten dreißig Tage Kundeninhalte. Der Trace-Speicher verdient in der Datenschutzprüfung dieselbe Sorgfalt wie jede andere Datenbank mit Nutzereingaben.
Auch Sampling hilft: Gebraucht wird selten der Inhalt jeder erfolgreichen Anfrage, sondern nur den der fehlgeschlagenen. Die Token-Zahlen bleiben in jedem Fall an jedem Span. Auch ohne Inhalt lässt sich so prüfen, ob Eingabe- und Ausgabelänge in einem sinnvollen Verhältnis zum Ergebnis stehen.
Es geht nicht darum, nichts aufzuzeichnen. Es geht darum, dass ein System, das Prompts speichert, dieselbe Sorgfalt verdient wie ein System, das Tickets speichert.
Drei Grenzen, eine Rechtsordnung
Wir denken den souveränen KI-Stack inzwischen als drei Grenzen statt als ein einzelnes Produkt.
Wo findet die Inferenz statt? Der IONOS CLOUD AI Model Hub stellt offene Modelle über einen OpenAI-kompatiblen Endpunkt in IONOS CLOUD Rechenzentren bereit. Die Anwendung ruft eine Standard-API auf; die Gewichte und Rechenleistung bleiben, wo sie sind.
Was darf der Agent anfassen? Der IONOS CLOUD MCP Server verbindet einen KI-Assistenten über das Model Context Protocol mit dem Cloud-Konto. Der Zugriff ist standardmäßig auf „lesend“ beschränkt. Warum wir uns dazu entschieden haben, haben wir bereits in einem vorherigen Artikel ausgiebig erläutert: Ein Agent, der nur lesen kann, kann kein Rechenzentrum löschen, weil eine Prompt Injection ihn dazu auffordert.
Wo ist festgehalten, was der Agent getan hat? Genau diese Lücke schließt der Tracing Service. Lesender Zugriff begrenzt, was ein Agent tun kann; über das, was er getan hat, sagt er nichts aus. Der Tracing Service hält diese Aufzeichnung in der EU-gehosteten Pipeline: Ausführungspfad, Tool-Aufrufe, Modellaufrufe, Token und Latenz. Die Daten können im selben Grafana wie Logs und Metriken abgefragt werden.
Erst begrenzen, dann beobachten. Keines von beidem genügt allein, und beides wird untergraben, wenn die dritte Box in einer anderen Rechtsordnung steht.
Zur Klarheit, was automatisch geschieht und was nicht: Die Modellaufrufe erscheinen automatisch in den Traces, weil die Instrumentierungs-Bibliothek den Client umschließt. MCP-Tool-Aufrufe werden nicht automatisch erfasst – sie lassen sich mit einem eigenen Span ergänzen, der drei Zeilen Code kostet:
with tracer.start_as_current_span("mcp.list_datacenters") as span:
span.set_attribute("mcp.tool", "list_datacenters")
result = mcp_client.call_tool("list_datacenters", {})Wer das tut, sieht die Argumentation des Agenten und seinen Zugriff auf die Infrastruktur im selben Trace-Baum. Ein Objekt zeigt, was der Agent angesehen hat, was er das Modell gefragt hat und wie lange jeder Teil gedauert hat.
Wie KI-Observability in der Praxis funktioniert
Der Tracing Service ist OpenTelemetry-nativ und erfordert keinen proprietären Agenten zur Installation. Eine Tracing-Pipeline lässt sich über die API erstellen; der Rückgabewert ist ein authentifizierter OTLP-Endpunkt – OTLP/HTTP oder OTLP/gRPC – plus ein Grafana-Endpunkt zur Auswertung der Ergebnisse. Gespeichert wird in Managed Grafana Tempo, mit 30 Tagen Aufbewahrung.
Eine Python-LLM-Anwendung zu instrumentieren, erfordert etwa zwanzig Zeilen Code:
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource
from opentelemetry.instrumentation.openai import OpenAIInstrumentor
from openai import OpenAI
import os
provider = TracerProvider(resource=Resource.create({"service.name": "ai-agent"}))
provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter(
endpoint="https://<tracing-host>/v1/traces",
headers={"apikey": os.environ["IONOS_TRACING_APIKEY"]},
)))
trace.set_tracer_provider(provider)
OpenAIInstrumentor().instrument() # every model call now emits a gen_ai span
client = OpenAI(base_url=MODELHUB_URL, api_key=os.environ["IONOS_MODELHUB_KEY"])
tracer = trace.get_tracer("ai-agent")
with tracer.start_as_current_span("agent-run"):Zwei Anmerkungen zu diesem Snippet. Die Bibliothek heißt OpenAIInstrumentor und die Spans heißen openai.chat – aber keine dieser Zeilen kommuniziert mit OpenAI. Der AI Model Hub stellt eine OpenAI-kompatible API bereit, und genau das ist der Punkt: Der Standard-Client und die Standard-Instrumentierung funktionieren unverändert zu einem Modell, das in Deutschland läuft.
Die wichtigste Lektion zu OpenTelemetry: Die Plattform speichert, was der Emitter sendet. Modellaufrufe erscheinen, weil die Instrumentierung den Client umschließt. Retrieval-Schritte, Tool-Aufrufe und Framework-interne Abläufe erscheinen nur, wenn entsprechende Spans emittiert werden – und die Framework-Abdeckung schwankt stark. Fehlt ein Schritt im Trace, liegt die Lücke in der Instrumentierung, nicht im Backend. Sie lässt sich jederzeit mit einem eigenen Span schließen, wie oben gezeigt.
Für alles jenseits eines einzelnen Dienstes trennt service.name die Komponenten innerhalb eines Traces. Pipelines sind die übergeordneten Trenneinheit. Die meisten Teams betreiben eine Pipeline pro Umgebung und Produktion getrennt von Staging. So kann ein einzelner Trace weiterhin alle Dienste dieser Umgebung umspannen.
Eine Schritt-für-Schritt-Untersuchung
Der folgende Durchlauf ist illustrativ und kein Kundenvorfall, hat aber die Form fast jeder Trace-geführten Untersuchung, die wir geführt haben.
Der Support leitet eine Beschwerde weiter: Der Assistent im Produkt „braucht seit heute Morgen ewig“. Keine Fehler, keine Alarme, nichts in den Logs außer erfolgreichen 200ern.
In Grafana wird die Tracing-Datenquelle gewählt und nach GenAI-Spans gefragt:
{ span.gen_ai.request.model != "" }Nach Dauer sortieren und den langsamsten Trace öffnen.
Die langsamsten Traces haben dieselbe Form: ein agent-run-Parent von etwa fünf Sekunden, darin ein Retrieval-Span und dann zwei Modellaufrufe, wo normalerweise einer steht. Der erste dauert 1,7 Sekunden, der zweite 2,9.
Der Retrieval-Span nennt die Ursache: retrieval.mode ist whole_document, 26 Dokumente, 11.466 Zeichen Kontext. Der Schritt übergibt ganze Dokumente in den Prompt statt nur den passenden Abschnitt. Eine Änderung von diesem Morgen hat die Chunk-Größe vergrößert. Das Modell war nie das Problem. Der Prompt war es.
Aus demselben Trace lässt sich zu den Logs dieser Anfrage in Loki und zu den Metriken des Dienstes in Mimir springen, für dasselbe Zeitfenster. Denn Traces, Logs und Metriken liegen in einem Grafana. Die Diagnose in Minuten, und die Prompts verlassen das Land nicht.
Wissen, was es kostet
Zwei Arten von Kosten zählen hier, und Traces geben zu beiden Auskunft.
KI-Kosten. Token-Zahlen liegen an jedem Modellaufruf-Span, sodass sich der Verbrauch einem Feature, einem Endpunkt oder einem Kunden zugeordnet werden kann – und der Prompt, der sich still verdreifacht hat, wird auffindbar. Aus einer Rechnung lässt sich das kaum rekonstruieren.
Observability-Kosten. Traces sind das volumenstärkste Telemetriesignal überhaupt. Deshalb rechnen wir rein nach Nutzung ab: pro aufgenommenem GB, pro gespeichertem GB während der Aufbewahrungsfrist. Keine Grundgebühr, keine Mindestabnahme, keine Lizenz pro Host.
Nichts wird nach berechnet. Wächst das Volumen schneller als gewünscht, ist Sampling der Hebel. Ein Bruchteil der Traces wird exportiert, während volle Detailtiefe für Fehler erhalten bleibt. Aktuelle Preise stehen in der IONOS CLOUD Preisliste.
Warum ein europäisches Backend keine Portabilität kostet
Der Standardeinwand gegen ein europäisches Backend ist Lock-in: Was, wenn ein Wechsel nötig wird?
OpenTelemetry beantwortet das. Instrumentierung ist Standard – SDKs, der Collector und OTLP. Weder gehört sie uns, noch ist sie auf uns zugeschnitten. Den Exporter auf ein anderes Backend zu richten, ist eine Konfigurationsänderung, kein Projekt zur Neuinstrumentierung. Genau darum baut man auf dem Standard, statt einen proprietären Agenten auszuliefern: Der Ausstieg ist günstig – und genau deshalb sollte das Bleiben eine Entscheidung sein und keine Folge.
Gleicher Standard, gleiches Grafana, gleiche Portabilität – und die Prompts bleiben hier.
Der erste GenAI-Trace in wenigen Minuten
- Tracing-Pipeline über die Tracing Service API erstellen; Ingestion-Key und Endpunkt sichern
- Abhängigkeiten installieren:
openai,opentelemetry-sdk,opentelemetry-exporter-otlpundopentelemetry-instrumentation-openai - Exporter und
OpenAIInstrumentor().instrument()in die Anwendung einfügen - Eine Anfrage ausführen, Grafana öffnen und
{ span.gen_ai.request.model != "" }abfragen
KI-Workloads sind der Ort, an dem Trace-Daten am interessantesten werden – aber nicht der einzige. Dieselbe Pipeline erfasst auch gewöhnliche Microservices, APIs und Automatisierungs-Workflows. Unser zweites Tutorial behandelt n8n-Workflow-Ausführungen ganz ohne Codeänderungen.
Drei Erkenntnisse zum Abschluss
Erstens zeigen Traces, was ein Agent tatsächlich getan hat – nicht, was angenommen wurde. Zweitens ist KI-Observability genauso eine Datenschutzentscheidung wie eine Werkzeugentscheidung, denn Prompts sind Kundeninhalte, sobald sie aufgezeichnet werden. Und drittens weil die Instrumentierung OpenTelemetry ist, kostet ein europäisches Backend nichts an Portabilität. Der Ausstieg bleibt günstig.
Der Tracing Service ist jetzt in IONOS CLOUD allgemein verfügbar. Erstellen Sie Pipeline, fügen Sie zwanzig Zeilen in die Anwendung ein und rufen Sie den ersten GenAI-Trace auf. Die Prompts bleiben genau dort, wo die Inferenz schon ist.
Weiterführende Links:
- Dokumentation des Tracing Service
- Tutorial: Traces eines KI-Agenten mit AI Model Hub im Tracing Service erfassen
- Tutorial: n8n-Workflow-Ausführungen mit dem Tracing Service erfassen
- IONOS CLOUD AI Model Hub – offene Modelle in EU-Rechenzentren betreiben
- IONOS CLOUD MCP Server – lesender KI-Zugriff auf das Cloud-Konto