OpenTelemetry Collector
inari.otel-collector
A Docker Compose file for OpenTelemetry Collector alone, generated from the catalog and checked by the safety inspector. No account needed.
Vendor-neutral pipeline for traces, metrics and logs, receiving telemetry in several protocols, processing it through batching, filtering and attribute rules, and exporting to one or more backends.
The Collector is configured as a set of pipelines, each wiring receivers to processors to exporters, so where telemetry arrives from, what happens to it and where it goes are separate concerns declared in one file. Placing it between applications and backends means instrumentation targets a single endpoint and changing backend becomes a configuration edit rather than a redeployment of every service. Processors handle batching, memory limiting, sampling, attribute redaction and resource enrichment before anything leaves the deployment. The contrib distribution adds a large set of third-party receivers and exporters beyond the core components.
You know it worked when
- The collector starts without configuration validation errors.
- Its internal metrics endpoint reports spans received and exported.
- An instrumented application's traces are accepted over OTLP.
- Those traces arrive at the configured backend.
- A processor rule visibly alters attributes between receipt and export.
Known sharp edges
- A pipeline is only active if its components are listed under the service section; a receiver that is defined but not referenced there is silently unused.
- Without a memory limiter processor, a burst of telemetry grows the collector until it is killed, taking the whole pipeline down with it.
- Recent defaults bind the OTLP receiver to localhost, so a containerised collector accepts nothing from other containers until the endpoint is set explicitly.
- Exported telemetry carries whatever attributes instrumentation attached, which frequently includes request fragments and user identifiers.