OpenTelemetry Collector
A vendor-neutral telemetry middleman that receives, batches, filters, and routes logs, metrics, and traces to backends.
See it
What it is
The OpenTelemetry Collector is a vendor-neutral process that receives telemetry, processes it, and exports it somewhere else. Its pipelines are assembled from receivers, processors, and exporters: accept OTLP, batch and redact the data, then send traces to Tempo and metrics to Prometheus. It can run beside each app as an agent or as a shared gateway tier.
Reach for it when several services need the same batching, filtering, sampling, retry, enrichment, or routing policy. Apps can emit standard OTLP to one local target while backend credentials and vendor-specific configuration stay out of application code.
Gotcha: declaring a component in the YAML does nothing until it is referenced by a pipeline under service.pipelines, and processor order changes the result. The Collector also needs memory limits, queues, health checks, and monitoring like any other production service. Tail-based sampling adds another constraint: all spans for one trace must reach the same sampling decision point.
Ask AI for it
Create an OpenTelemetry Collector Contrib configuration with an OTLP receiver listening on gRPC 4317 and HTTP 4318. Build separate traces, metrics, and logs pipelines using memory_limiter first and batch last, add a resource processor that inserts deployment.environment.name when it is missing, and export with otlphttp endpoints supplied through environment variables. Enable the health_check extension, the Collector's own internal telemetry metrics, persistent sending queues backed by the file_storage extension, and retry_on_failure. Reference every declared component under service.pipelines, then include a docker-compose health check and a smoke test that sends one OTLP trace through the pipeline.