Viele erwarten, dass LLM-Observability mit der richtigen Instrumentierung beginnt und der Rest sich von selbst ergibt. Der wichtigste Kontrollpunkt liegt aber zwischen Anwendung und Backend: im OpenTelemetry Collector. Man kann Redaktion, Normalisierung und Sampling in jeder Anwendung einzeln nachbauen. Dann verteilt man dieselbe Politik über viele Codebasen und muss jede Änderung mehrfach prüfen. Der Collector für LLM-Observability ist deshalb kein Zusatzbaustein, sondern die Stelle, durch die jede Spur läuft, bevor sie Honeycomb erreicht.
Die Ausgangslage ist unhandlich. Modellaufrufe, Tool-Nutzung, Retrieval-Schritte und Token-Zahlen erzeugen Spans, deren Attribute ganze Prompts und Completionen tragen. Diese Daten sind voluminös, enthalten oft personenbezogene Inhalte und kommen je nach Instrumentierung unter unterschiedlichen Attributnamen an. Eine Collector-Konfiguration für LLM-Observability muss daher drei Aufgaben zugleich lösen: vereinheitlichen, schützen und dosieren. Der folgende Entwurf beschreibt diese Reihenfolge, vom OTLP-Empfang bis zum Export nach Honeycomb.
Was der Collector zwischen Anwendung und Backend leistet
Der Collector ist ein herstellerneutraler Dienst, der Telemetrie empfängt, verarbeitet und weitergibt. Receiver nehmen Daten in einem Protokoll an, meist OTLP. Prozessoren bearbeiten sie in einer festgelegten Reihenfolge: Sie benennen Attribute um, redigieren Werte, filtern Spans oder samplen Traces. Exporter liefern das Ergebnis an ein oder mehrere Backends. Extensions ergänzen Betriebsfunktionen wie Health-Checks, und der Service-Abschnitt verbindet alles zu Pipelines. Für LLM-Observability ist der Fluss kurz: Das SDK der Anwendung sendet Spans per OTLP an den Collector, die Prozessorkette formt und schützt die Daten, der Exporter übergibt sie an Honeycomb.
Der wichtigste Grund für diese Zwischenstufe ist Datenschutz. Prompts, Completionen, Retrieval-Chunks und Tool-Argumente enthalten regelmäßig Nutzerdaten, Zugangsdaten und internen Kontext. Der Collector redigiert oder verwirft diese Inhalte innerhalb der Netzwerkgrenze, bevor etwas an einen Dritten geht. Die Regel liegt in einer prüfbaren Konfiguration statt verstreut im Anwendungscode. Der zweite Grund ist Volumen: Nachrichten-Payloads sind deutlich größer als gewöhnliche Span-Attribute, und Agenten-Workflows fächern sich in viele Spans pro Anfrage auf. Filtern und intelligentes Sampling halten die Kosten planbar, ohne den interessanten Traffic zu verlieren. Der dritte Grund ist Konsistenz. Ältere Schemata aus OpenInference, OpenLLMetry und Eigenbau-Wrappern treten neben nativen GenAI-Konventionen; der Collector führt all das auf eine querybare Form zusammen.
OTLP-Empfang und die Reihenfolge der Prozessoren
Der OTLP-Receiver nimmt Traces über gRPC auf Port 4317 und über HTTP auf Port 4318 an. Viele OpenTelemetry-SDKs nutzen standardmäßig einen dieser Endpunkte. Dann reicht oft eine Umgebungsvariable, etwa OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318. Die Bindung an 0.0.0.0 macht den Receiver aus anderen Containern und Pods erreichbar. Für ein Gateway-Muster ist das gewünscht. Läuft der Collector als Sidecar oder auf demselben Host wie die Anwendung, ist localhost die sicherere Bindung. Der Port ist dann nicht nach außen sichtbar. In Kubernetes sollte der Receiver über einen Service exponiert werden, auf den alle Workloads zeigen.
Die Reihenfolge der Prozessoren zählt. memory_limiter gehört an den Anfang, damit der Collector sich selbst schützt, bevor er Arbeit verrichtet. gen_ai_normalizer läuft vor allen Stufen, die auf gen_ai.-Attribute matchen. So sieht jede spätere Regel kanonische Namen. Die Redaktion folgt aus demselben Grund nach der Normalisierung und zielt auf einen Satz von Namen statt auf einen pro Framework. Der transform-Prozessor kann jedem Resource-Attribut etwa deployment.environment.name hinzufügen. Dann lässt sich Token-Verbrauch nach Umgebung oder Team auswerten. Ein separater Batch-Prozessor fehlt bewusst, weil Batching und Retry heute über die sending_queue des Exporters laufen. Geheimnisse gehören in Umgebungsvariablen und nicht in die Konfigurationsdatei.
Normalisierung: GenAI-Telemetrie auf eine querybare Form bringen
Wenn Dienste die offiziellen GenAI-Instrumentierungen nutzen, kommen ihre Spans bereits in den Konventionen an. Dann bleibt vor allem Anreicherung. Die offizielle OpenTelemetry-GenAI-Instrumentierung deckt inzwischen direkte Client-Bibliotheken wie anthropic, openai und google-genai sowie Agenten-Frameworks wie langchain, openai-agents und smolagents im Repository opentelemetry-python-genai ab. Ältere Schemata sind dennoch verbreitet, und selbst native Emitter driften zwischen Versionen der semantischen Konventionen. Hier setzt die Normalisierung von GenAI-Telemetrie an: Der gen_ai_normalizer schreibt Attribute älterer Schemata auf die Konventionen um. Eingebaute Tabellen gibt es für OpenInference und OpenLLMetry, eigene Tabellen für Eigenbauten.
Der Normalizer beherrscht Typumwandlung, sodass aus stringbasierten Token-Zahlen Integer werden. Mit remove_originals: true verschwinden die alten Namen nach dem Mapping. Manche Formen lassen sich mit einer Mapping-Tabelle nicht ausdrücken, etwa die Ableitung von gen_ai.operation.name aus Span-Namensmustern. Dafür lässt sich der transform-Prozessor ergänzen. Zusätzlich stempelt der Normalizer die Schema-URL, gegen die er arbeitet; der Schema-Prozessor kann damit Telemetrie zwischen Konventionsversionen übersetzen. Das ist wichtig, weil Attributnamen wandern: Aus gen_ai.usage.prompt_tokens wurde in der Vergangenheit gen_ai.usage.input_tokens. Eine Pipeline sollte solche Migrationen absorbieren, statt sie in jedem Dienst nachzuziehen.
Datenschutz: Prompts und Tool-Argumente vor dem Export redigieren
Diese Stufe sollte vor dem ersten Produktivbetrieb sitzen. Prompts und Completionen sind Nutzerinhalte, Tool-Argumente können Zugangsdaten tragen, und Retrieval-Chunks zitieren interne Dokumente. Der Collector ist der letzte Punkt, an dem sich diese Daten kontrollieren lassen, bevor sie das eigene Netz verlassen. Deshalb gehört die Politik hierher und nicht in Anwendungscode, der Dienst für Dienst geprüft werden müsste. Unter dem Stichwort LLM Observability Datenschutz OpenTelemetry ist die zentrale Frage nicht, ob redigiert wird, sondern welche Inhalte überhaupt exportiert werden dürfen. Diese Entscheidung sollte früh und eher streng fallen. Eine Redaktion lässt sich später leichter lockern als exportierte Daten zurückholen.
Der redaction-Prozessor bietet drei komplementäre Hebel. blocked_values maskiert passende Teilstrings, wo immer sie auftauchen. Eine Kartennummer oder eine Vielflieger-Referenz verschwindet dann innerhalb von gen_ai.input.messages, während der Rest des Gesprächs lesbar bleibt. Dieselben Muster fangen API-Schlüssel in anderen Attributen. blocked_key_patterns maskiert die Werte ganzer Attributschlüssel und ist damit die strengste Variante. hash_function, einschließlich hmac-sha256, ersetzt Treffer durch einen stabilen Hash. Das ist für Nutzerkennungen nützlich, wenn Aktivität korrelierbar bleiben soll, ohne den Rohwert zu exportieren.
Wie weit die Datenredaktion geht, ist eine Abwägung mit Folgen für die spätere Analyse. Bleiben Nachrichteninhalte mit gezielter Wertmaskierung erhalten, funktionieren Gesprächsdebugging und die Nachrichtenansicht der Agent Timeline weiter. Bekannte sensible Muster verlassen dann das Netz nicht. Werden gen_ai.input.messages und gen_ai.output.messages vollständig maskiert, ist der Schutz größer, aber gesprächsorientierte Workflows verlieren die Inhalte, die sie untersuchen wollen. Muss ein Attribut laut Politik das Environment grundsätzlich verlassen dürfen, sollte es mit delete_key im transform-Prozessor gelöscht statt nur maskiert werden. In jedem Fall geschieht der Eingriff innerhalb der Netzwerkgrenze und vor dem Export.
Volumen, Sampling und der Export nach Honeycomb
memory_limiter schützt den Collector vor Payload-Spitzen. Die sending_queue des Exporters übernimmt Batching, Retry und Backdruck, damit kurze Netzwerkfehler keine Daten verlieren. Der filter-Prozessor entfernt Traffic ohne analytischen Wert, im Beispiel Health-Checks. Dieselbe OTTL-Syntax kann Null-Token-Spans oder verbose Zwischenschritte verwerfen, die niemand abfragt. Für das Sampling von LLM-Spans gilt: GenAI-Traffic zunächst nicht samplen. Ein Gespräch verliert seinen Wert, wenn Turns fehlen. Vollständigkeit ist für diese Daten wichtiger als eine niedrige Volumenkurve. Filtering und das Kürzen geschwätziger Attribute liefern den größten Teil der Volumenkontrolle, ohne Gespräche zu zerreißen. Für umliegende Nicht-LLM-Dienste kann adaptive_tail_sampling in eigenen Pipelines arbeiten.
Der Export nach Honeycomb läuft über den otlp_http-Exporter gegen https://api.honeycomb.io, für EU-Teams gegen https://api.eu1.honeycomb.io. Der API-Schlüssel steht im Header x-honeycomb-team und wird aus einer Umgebungsvariablen gelesen, nicht in die Datei geschrieben. TLS ist für diesen Endpunkt standardmäßig aktiv, sodass keine zusätzliche Transportkonfiguration nötig ist. Die sending_queue-Einstellungen regeln Batching, Wiederholung und Backdruck an der Exportgrenze. Endpunkt und Header sollten regelmäßig gegen die aktuelle Honeycomb-OTLP-Dokumentation geprüft werden. Sie ändern sich am ehesten.
Validierung und Betrieb: woran sich die Pipeline prüfen lässt
Validierung heißt hier, zu bestätigen, dass die Konfiguration das beabsichtigte Verhalten zeigt, nicht nur, dass irgendwelche Daten ankommen. Eine Abfrage gruppiert nach gen_ai.request.model sollte alle Dienste unter kanonischen Modellnamen zeigen, unabhängig von der verwendeten Instrumentierung. Ein COUNT gruppiert nach gen_ai.operation.name sollte Werte wie chat und execute_tool liefern und keine frameworkspezifischen Span-Arten. Für die Redaktion sucht man nach einem Muster, das die Politik blockiert, etwa einem API-Schlüssel-Präfix oder einer Test-Kartennummer, die bewusst durch die Pipeline geschickt wurde. Null Treffer bedeuten, dass die Regel hält. Eine Stichprobe im Gen-AI-Tab eines Spans zeigt, ob die maskierte Stelle erscheint und der Rest der Nachricht lesbar bleibt.
Beim Troubleshooting hilft die Reihenfolge der Pipeline mehr als jedes einzelne Log. Fehlen Daten vollständig, sind Receiver-Endpunkt, Service-Bindung und API-Schlüssel die ersten Prüfpunkte. Fehlen nur bestimmte Spans, liegt es oft an einem filter-Ausdruck oder an einer Redaktionsregel, die zu breit greift. Erscheinen Modellnamen uneinheitlich, wurde der Normalizer zu spät oder gar nicht eingebunden. Bleiben Exporte trotz stabiler Anwendung sporadisch aus, lohnt ein Blick auf sending_queue und memory_limiter. Der Collector ersetzt keine gute Instrumentierung, aber er macht LLM-Telemetrie beherrschbar. Er ist die Stelle, an der Datenschutz, Normalisierung und Kostenkontrolle einmal definiert und für alle Dienste durchgesetzt werden.
Quelle: honeycomb.io
