OpenTelemetry Collector Configuration for LLM Observability

OpenTelemetry Collector can serve as a centralized control layer between LLM applications and Honeycomb, receiving OTLP traces and applying consistent normalization, enrichment, redaction, filtering, and export policies before telemetry leaves an organization’s network. It is particularly useful for LLM observability because prompts, completions, retrieval content, tool arguments, and token metrics are large, potentially sensitive, and often emitted under inconsistent schemas by different instrumentation libraries. A recommended pipeline uses the contrib Collector distribution with OTLP receivers, a memory limiter, optional GenAI schema normalization, resource transforms, redaction rules, filters, and an OTLP HTTP exporter with queued retries to Honeycomb. The guidance emphasizes running normalization before rules that depend on canonical `gen_ai.*` attributes, redacting sensitive values or removing prohibited fields before export, avoiding sampling GenAI conversation traffic when completeness is important, and filtering low-value spans instead. Validation should confirm canonical attributes, effective redaction, usable token metrics, correct trace relationships, and Agent Timeline rendering, while production operations should monitor Collector queueing, dropped spans, memory pressure, evolving semantic conventions, and new content-bearing attributes introduced by SDK updates.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.