OpenTelemetry Collector

Last reviewed Sep 13, 2026 · 843 words

Install the OpenTelemetry Collector on its own and you will see nothing, because it stores nothing and displays nothing. It receives traces, metrics, and logs on ports 4317 (gRPC) and 4318 (HTTP), runs them through processors, and exports them somewhere else. That somewhere else is the part you still have to run: Prometheus or VictoriaMetrics for metrics, Loki for logs, Tempo or Jaeger for traces, Grafana on top. So the question is never "should I run the Collector" but "do I have enough sources that a single ingestion point in front of those backends pays for itself". For a homelab with 3 containers, no. For anything with application traces, yes, and the config below is the one I would start from.

Receivers, processors, exporters, and the one rule about order

A pipeline is three lists. Receivers accept data: otlp for anything instrumented with an OpenTelemetry SDK, prometheus to scrape existing exporters, hostmetrics for CPU, memory, disk, and network of the box it runs on, filelog to tail log files. Processors transform it: batch groups records to reduce exporter calls, memory_limiter drops data rather than letting the process balloon, attributes and resource add or strip fields. Exporters send it on. The order rule that catches people is that memory_limiter must be the first processor in every pipeline and batch should be last; the docs say so, and a Collector that runs out of memory at 3 a.m. is usually one where someone put them the other way round.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      filesystem:
      network:

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 400
  batch:

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true
  otlphttp/loki:
    endpoint: http://loki:3100/otlp

service:
  pipelines:
    metrics:
      receivers: [otlp, hostmetrics]
      processors: [memory_limiter, batch]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/loki]

Prometheus then scrapes :8889, Tempo and Loki receive over OTLP natively, and every application only ever needs to know one address. The debug exporter, added to any pipeline, prints what is flowing to stdout and is the first thing to reach for when a backend shows nothing.

Core, contrib, or build your own

This is the trap in the first hour. The otel/opentelemetry-collector image is the core distribution and contains only the OTLP receiver and a handful of exporters; hostmetrics, filelog, the prometheus exporter, and almost everything useful live in otel/opentelemetry-collector-contrib, which is roughly 10 times the binary size. Run contrib unless you have a reason not to. The reason not to, once a setup is stable, is the OpenTelemetry Collector Builder (ocb), which compiles a binary containing exactly the 6 components you use; that is the production answer and overkill for a homelab. The project sits at 7,492 stars for the core repo alone, Apache-2.0, in Go, and the contrib repo is where most of the activity is.

Memory is small until you tail logs

The 128 MB minimum is real for a Collector doing OTLP passthrough with batching. It stops being real the moment you add filelog on a chatty directory or a prometheus receiver scraping 20 targets, because the Collector buffers everything in memory before export. Set memory_limiter to roughly 80% of the container's limit and set the container limit explicitly, then watch the Collector's own metrics on :8888 for otelcol_processor_dropped_*; drops there mean the backend is slower than the sources, and the fix is a bigger batch timeout or a faster backend, not a bigger limit.

When Alloy or Vector is the easier tool

If your whole backend is the Grafana stack, Grafana Alloy is a Collector distribution with a friendlier config language, built-in Loki and Prometheus components, and Grafana's opinions baked in; it is easier for that one case and worse the moment you export anywhere else. If you only care about logs, Vector has better transforms and a lighter footprint. If you want the backend and the pipeline in one box, SigNoz bundles a Collector with its own storage and UI. The plain Collector wins when you have more than one backend, when you expect to swap a backend, or when you are instrumenting your own code and want the tracing pipeline to be vendor-neutral from the first day.

What I'd do

Run the contrib image as one container beside the monitoring stack, start from the config above, add the debug exporter until every pipeline shows data in Grafana, then remove it. Point every application's OTEL_EXPORTER_OTLP_ENDPOINT at the Collector and never at a backend directly. Revisit in 6 months: if the config is still 60 lines, leave it; if it has grown to 400, that is the signal to build a custom distribution with ocb and pin the components you actually use. The monitoring category covers the backends this feeds.