Why does the collector need both a gRPC and an HTTP OTLP port?

OTLP defines both a gRPC and an HTTP/protobuf transport, and different SDKs and agents default to one or the other, so the standard OTLP receiver listens on both (4317 for gRPC, 4318 for HTTP by convention) to accept telemetry from either kind of client without extra configuration.

What do the batch and memory_limiter processors actually do?

batch groups incoming spans/metrics/logs into larger batches before exporting, dramatically cutting the number of outbound network calls; memory_limiter rejects or drops data once the collector's memory usage crosses a configured limit, preventing an overloaded collector from being OOM-killed. Nearly every production collector config enables both, with memory_limiter first in the processor chain.

Why is the pipeline the same for traces, metrics, and logs?

This tool wires all three signal pipelines (traces, metrics, logs) to the same receiver, processor chain, and exporter for a simple starting setup; a real deployment often exports different signals to different backends (e.g. traces to Tempo, metrics to Prometheus, logs to Loki) via separate exporters and pipelines, which you can split apart in the output after generating it.

Which exporter should I pick?

logging is for local debugging, printing received telemetry to the collector's own stdout. otlp forwards telemetry on to another OTLP-compatible backend (like Tempo, another collector, or a vendor endpoint). prometheus exposes an HTTP endpoint that Prometheus itself scrapes for metrics; use it only for the metrics signal in a real deployment.

OpenTelemetry Collector Config Generator - Build otel-collector-config.yaml

Overview

Introduction

An OpenTelemetry Collector config's four top-level sections (receivers, processors, exporters, service.pipelines) all have to reference each other by matching component names, and a typo in any one of them means the collector fails to start or silently drops telemetry.

This tool builds that config from a form: set your OTLP ports, toggle on the processors you want, pick an exporter and its endpoint, and the pipeline block is wired together automatically using the components you actually enabled.

What Is OpenTelemetry Collector Config Generator?

A visual builder for an OpenTelemetry Collector configuration YAML, covering an OTLP receiver (gRPC and HTTP), the batch and memory_limiter processors, one exporter (logging, OTLP, or Prometheus), and a service.pipelines block for traces, metrics, and logs.

It mirrors the collector's own four-section config structure, so the output is a complete, internally consistent config.yaml ready to pass to the otelcol binary with --config.

How OpenTelemetry Collector Config Generator Works

The receivers section always emits an otlp receiver with both grpc and http protocol endpoints on your chosen ports. The processors section emits memory_limiter and/or batch depending on which you've enabled, memory_limiter first since processor order matters (it should reject data before batch buffers it).

The exporters section emits exactly one exporter block matching your selection, with its endpoint field when the exporter type needs one. Finally, service.pipelines wires up a traces, metrics, and logs pipeline, each referencing the same otlp receiver, your enabled processors in the correct order, and your chosen exporter by name, so every reference in the pipeline points at a component that actually exists in the config.

When To Use OpenTelemetry Collector Config Generator

Use it when standing up a new OpenTelemetry Collector instance as the ingestion point in front of Tempo, Loki, or Prometheus, or as a local debugging collector that just logs incoming telemetry.

It's also useful for quickly sketching the receivers/processors/exporters/pipelines shape correctly before hand-editing it into a more elaborate multi-exporter, multi-pipeline config.

Often used alongside Prometheus Config Generator, Tempo Config Generator and Loki Config Generator.

Features

Advantages

Guarantees every pipeline reference (receiver, processor, exporter names) matches a component that's actually defined elsewhere in the same config, the most common source of a collector refusing to start.
Orders memory_limiter before batch automatically when both are enabled, matching the OpenTelemetry Collector's own recommended processor ordering.
Covers the three most common exporters (logging for debugging, OTLP for forwarding, Prometheus for scraping) with each one's required fields.

Limitations

Only models a single exporter shared across all three signal pipelines; splitting traces/metrics/logs to different backends requires manually adding more exporters and adjusting the pipelines block afterward.
Doesn't cover the many other available receivers (Jaeger, Zipkin, Prometheus scrape) or processors (resource, attributes, tail_sampling), only the OTLP receiver and the two most universally used processors.
Doesn't validate that memory_limit_mib is sized appropriately for your actual container/host memory, only that it's a positive integer.

Examples

A debugging collector logging everything it receives

Input

otlp: grpc 4317, http 4318; processors: memory_limiter (512 MiB) + batch; exporter: logging

Output

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch: {}

exporters:
  logging:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [logging]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [logging]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [logging]

All three pipelines reference the same otlp receiver, the same ordered processor list, and the logging exporter.

Best Practices & Notes

Best Practices

Always enable memory_limiter in front of batch in any collector that isn't purely for local debugging, an unbounded collector under load is one of the most common causes of collector OOM crashes.
Use the logging exporter only while developing or debugging a pipeline; swap to a real exporter (OTLP, Prometheus, or a vendor-specific one) before relying on the collector in production.
Split signals into separate exporters (traces to Tempo, metrics to Prometheus remote_write, logs to Loki) once you move past a single-backend proof of concept.

Developer Notes

The generator is a pure string-building function emitting fixed 2-space YAML with no YAML library dependency; ports are validated against a 1-65535 numeric range and memory_limit_mib against a positive-integer pattern. Processor names are collected into an ordered array (memory_limiter before batch) so the emitted pipelines' processors list always reflects both which processors are enabled and the collector's recommended ordering.

OpenTelemetry Collector Config Generator Use Cases

Standing up a debugging OpenTelemetry Collector that just logs incoming traces/metrics/logs to stdout
Bootstrapping a collector config that forwards telemetry on to Tempo/Loki/Prometheus via an OTLP or Prometheus exporter
Sketching a correctly wired receivers/processors/exporters/pipelines skeleton before hand-adding more advanced components

Common Mistakes

Putting batch before memory_limiter in a hand-written processors list, which lets memory pressure build up before the limiter has a chance to reject data.
Forgetting to update the OTLP exporter's endpoint from a placeholder value, causing the collector to fail every export attempt at startup.
Using the Prometheus exporter for traces or logs pipelines, when it's only meaningful for the metrics signal.

Tips

Use the Tempo Config Generator or Loki Config Generator to build the backend this collector's OTLP exporter should point at.
Start with the logging exporter to confirm telemetry is actually arriving before switching to a real backend exporter.

OpenTelemetry Collector Config Generator