OpenTelemetry Collector Config Generator

Signal	Pipeline	Receivers	Processor order	Exporters	Rollout note	Copy
{{ row.signal }}	{{ row.pipeline }}	{{ row.receivers }}	{{ row.processors }}	{{ row.exporters }}	{{ row.note }}

Severity	Check	Finding	Action	Copy
{{ row.severity }}	{{ row.check }}	{{ row.finding }}	{{ row.action }}

Telemetry pipelines are easy to draw and harder to run safely once real traffic arrives. The OpenTelemetry Collector sits between instrumented services and observability backends, so its configuration decides what traces, metrics, and logs can enter, which processors protect or enrich them, and where each signal leaves the process. A local agent, a shared gateway, and a debug-only Collector can use similar YAML shapes while needing very different bind addresses, credentials, and memory margins.

Most Collector files use a compact vocabulary. Receivers accept telemetry, processors change or guard it, exporters send or expose it, extensions add operational endpoints, and service pipelines activate the components for each signal. Defining a component does not make it run; the service pipeline must reference it. That distinction is a common source of configs that look complete but never move data.

Transport affects endpoint shape. OTLP/gRPC and OTLP/HTTP both carry OpenTelemetry data, but their endpoint conventions and default ports differ.
Deployment role affects exposure. An agent on the same host usually binds narrowly, while a gateway may listen on a network address and needs stronger surrounding controls.
Backpressure affects loss risk. Memory limiting, batching, queues, and retries influence what happens when traffic spikes or a backend slows down.
Component availability is distribution-specific. Core, contrib, vendor, and custom Collector builds do not always ship the same receivers, processors, exporters, or extensions.

OpenTelemetry Collector receivers feeding processors, exporters, and signal pipelines

Collector setup often fails at boundaries rather than inside YAML indentation. A gRPC exporter written like an HTTP URL, a Prometheus exporter paired with traces, a diagnostic endpoint exposed on a shared interface, or a missing service pipeline can all pass a casual read. These mistakes matter because telemetry often includes service names, attributes, request paths, and sometimes payload-adjacent details that should not be exposed through logs or untrusted networks.

A valid-looking Collector file is still a starting point. The exact Collector binary or container image must support the selected components, the backend must accept the exporter settings, and the target network must make listener and diagnostic endpoints safe. The configuration can reduce rollout risk, but it cannot replace distribution-specific validation and a small traffic test.

How to Use This Tool:

Start with the preset closest to the rollout, then make the receiver, signal, exporter, memory, and diagnostic choices match the Collector that will actually run.

Choose a Config preset. The presets cover an edge agent forwarding to an OTLP gateway, a gateway using OTLP HTTP, a local debug Collector, and a logs-only gateway.
Select Signal pipelines. At least one of Traces, Metrics, or Logs must stay enabled before the summary can report a ready config.
Set OTLP receiver protocols and Receiver bind address. Use localhost for same-host clients, and use 0.0.0.0 only when the Collector is meant to accept network traffic.
Pick the Exporter target and, when shown, the Exporter endpoint. OTLP gRPC uses a host and port, OTLP HTTP uses an HTTP or HTTPS base URL, Prometheus mode is metrics-only, and debug output is for inspection.
Open Advanced for the Memory guard, batch timing and sizes, resource attributes, optional exporter auth header, diagnostic extensions, Collector log level, and debug exporter verbosity.
Read Config Audit before copying. Fix blocking items such as no signal selected, invalid duration text, a gRPC endpoint written with an HTTP scheme, a batch maximum below the send size, or a half-entered auth header.
Use Pipeline Ledger to confirm each signal uses the expected receiver, processor order, and exporter list, then copy or download Collector YAML.

Run the copied YAML through the exact Collector distribution that will run in production, then send a small test trace, metric, or log before moving shared traffic.

Interpreting Results:

Collector YAML is the file to validate and run. Pipeline Ledger is the readable map of selected signals, receivers, processor order, and exporters. Config Audit is the fastest place to catch settings that are structurally wrong or risky for rollout.

A ready summary means the inputs pass the visible structural checks. It does not prove that the backend accepts the exporter credentials, that the Collector distribution includes every component, or that a listener is safe on the target network.

Trust the YAML only after otelcol validate --config collector.yaml succeeds against the target Collector image or binary.
Give extra review to 0.0.0.0, disabled memory limiting, detailed debug verbosity, missing remote buffering, and diagnostic extensions on shared networks.
Check the first processor in the ledger. Production pipelines should usually put memory_limiter before enrichment and batching.
Do not treat an empty error list as a credential test. The audit does not contact exporter endpoints or verify bearer tokens.

Technical Details:

Collector configuration has two stages: component declaration and service activation. Receiver, processor, exporter, and extension sections define available parts. The service section decides which of those parts are enabled, which signals have pipelines, and the order in which each pipeline processes data.

Pipeline order is operational, not cosmetic. A memory limiter early in the chain can refuse data and create backpressure before enrichment and batching add more work. A batch processor later in the chain groups spans, metric points, or log records before export. Resource attributes should be stable because they are upserted onto every selected signal that passes through the shared processor.

OTLP has two common transports. OTLP/gRPC commonly listens on port 4317 and Collector gRPC exporter examples often use a host and port. OTLP/HTTP commonly listens on port 4318 and uses HTTP or HTTPS URL semantics. Mixing those endpoint shapes is one of the easiest ways to create YAML that looks plausible but fails validation or sends telemetry to the wrong path.

Rule Core:

OpenTelemetry Collector configuration rules used by the generator
Config Area	Collector Rule	Operational Consequence
Receivers	An OTLP receiver can expose gRPC on `bind:4317`, HTTP on `bind:4318`, or both.	Client SDKs must send to a listener that is actually present and reachable.
Processors	`memory_limiter` should run before enrichment and `batch` when memory protection is used.	Memory pressure should be handled before enrichment and batching increase downstream work.
Exporters	OTLP exporters push data, Prometheus exposes metrics for scraping, and debug output prints telemetry for inspection.	The selected exporter decides whether telemetry is pushed onward, exposed for Prometheus, or printed for inspection.
Extensions	`health_check`, `pprof`, and `zpages` must be both configured and enabled in service extensions.	Diagnostic extensions help operations, but exposed diagnostic endpoints need network controls.
Service pipelines	Each traces, metrics, or logs pipeline names its receivers, ordered processors, and exporters.	A signal without a service pipeline has no active path through the Collector.

Memory and Batch Core:

The memory limiter uses a hard limit and a spike allowance. When memory crosses the soft limit, the Collector can refuse incoming telemetry so receivers apply backpressure or retry. If the spike allowance is too small for bursty traffic, the Collector may cross the hard limit between checks; if it is too large, refusal starts late.

soft limit = hard limit - spike limit

spike limit < memory limit

Memory limiter and batch processor boundary rules
Setting	Meaning	Boundary
`check_interval`	How often memory usage is measured.	Short intervals such as `1s` are safer for variable traffic than long gaps.
`limit_percentage` or `limit_mib`	The hard memory target, either relative to the host limit or fixed in MiB.	Percentage mode must stay below `100`; fixed mode should leave headroom for non-heap memory.
`spike_limit_percentage` or `spike_limit_mib`	The expected short-term increase between memory checks.	The spike value must be less than the memory limit.
`timeout`	How long the batch processor waits before sending a partial batch.	Valid OpenTelemetry durations include values such as `200ms`, `1s`, and `5s`.
`send_batch_size`	The record count that triggers a batch send.	It is a trigger, not a hard maximum.
`send_batch_max_size`	The optional upper bound that splits larger batches.	`0` means no upper bound; otherwise it must be at least `send_batch_size`.

Validation Boundaries:

Validation boundaries for OpenTelemetry Collector YAML generation
Check	Boundary	Result Meaning
Signal coverage	At least one signal must be enabled.	The service section needs at least one telemetry pipeline.
Endpoint syntax	OTLP gRPC mode blocks URL schemes; OTLP HTTP mode requires an HTTP or HTTPS base URL.	Transport syntax must match the exporter type.
Prometheus exporter	Prometheus exporter mode supports metrics pipelines only.	Traces and logs need OTLP or debug exporters instead.
Batch sizing	`send_batch_max_size` is omitted at `0`; otherwise it must be at least `send_batch_size`.	The maximum is an upper bound, not the trigger that starts a send.
Resource attributes	Each non-comment line must use `key=value` with safe key characters.	Bad attribute rows are blocked before ambiguous enrichment appears in YAML.
Auth header	A header requires both a valid token-style name and a value.	Half-entered credentials should not be copied into rollout config.

Collector validation is still required because schema support, component names, and extension availability come from the running distribution. A config that is structurally consistent can still fail if the image lacks a selected component, if a backend rejects credentials, or if network policy blocks the chosen listener or exporter target.

Privacy and Safety Notes:

The generator works in the browser and does not contact exporter endpoints. Treat the YAML as sensitive when it includes authorization headers, tenant names, internal hostnames, resource attributes, or diagnostic endpoints.

Use environment references such as ${env:OTEL_EXPORTER_OTLP_TOKEN} instead of pasting literal tokens into saved YAML.
Review 0.0.0.0, pprof, and zpages before sharing a network-facing Collector config.
Use basic debug verbosity for routine smoke tests; detailed payload output can expose telemetry contents in logs.
Keep backend credentials, network policy, and Collector distribution checks outside the generated audit, because those checks require the target environment.

Worked Examples:

An edge agent forwarding traces, metrics, and logs to otel-gateway.example.com:4317 can use the Edge agent to OTLP gateway preset with Verified TLS, percentage memory mode at 80%, and resource attributes such as deployment.environment=prod. Pipeline Ledger should show three pipelines with memory_limiter -> resource/common -> batch, and Config Audit should mark YAML readiness as ready before the file is copied.

A shared gateway that receives network traffic and exports to an HTTPS OTLP endpoint on otlp.vendor.example.com can use OTLP HTTP with Receiver bind address set to 0.0.0.0 and an Authorization header value that references an environment variable. Config Audit should still flag receiver exposure for review, because a ready YAML state does not prove that the listener is protected by service mesh, firewall, Kubernetes policy, or authentication.

A metrics-only Prometheus setup needs Metrics enabled and Traces and Logs disabled. If traces or logs remain selected, Config Audit reports that the Prometheus exporter supports metrics pipelines only; if Max batch size is lower than Batch send size, the audit blocks the YAML until the batch boundary is corrected.

FAQ:

Why does OTLP gRPC reject an HTTP URL here?

The gRPC exporter path expects a host and port such as otel-gateway.example.com:4317. Choose OTLP HTTP when the backend provides an HTTP or HTTPS base URL.

Can the Prometheus exporter handle traces or logs?

No. Prometheus exporter mode is treated as metrics-only, so Config Audit blocks selected traces or logs until you disable those signals or choose an OTLP or debug exporter.

Should memory limiting be enabled for production?

Usually yes. The audit warns when the memory guard is off because busy receivers and batches can increase heap pressure before the backend slows down or fails.

Why does the batch maximum need to be at least the send size?

Batch send size is the trigger for sending, while Max batch size is the optional upper bound. A maximum below the trigger is contradictory, so the audit treats it as a blocking input issue.

Should I paste a real bearer token into the auth header?

Use an environment reference instead of a literal secret when possible. The YAML is copied or downloaded from the browser, and saved config files are often shared in tickets, repositories, or deployment manifests.

Does the generated YAML validate the backend credentials?

No. The audit checks structure, endpoint syntax, and missing values. It does not contact the exporter endpoint, verify credentials, or prove that the selected Collector distribution includes every component.

Glossary:

Receiver: A Collector component that accepts telemetry from clients or other agents.
Processor: A component that changes, batches, filters, enriches, or guards telemetry before export.
Exporter: A component that sends telemetry to a backend, exposes it for scraping, or prints it for inspection.
Pipeline: The service path that connects receivers, processors, and exporters for one signal type.
OTLP: The OpenTelemetry Protocol used by clients and Collectors to send traces, metrics, and logs.
Memory limiter: A processor that refuses data under memory pressure so backpressure can happen earlier.
Batch processor: A processor that groups telemetry by count or timeout before sending it to the next component.
Resource attributes: Stable metadata such as environment or namespace that can be attached to all selected signals.
Debug exporter: An exporter used for inspection by printing telemetry rather than sending it to an observability backend.

References:

Collector configuration, OpenTelemetry.
OTLP specification, OpenTelemetry.
OpenTelemetry Protocol Exporter, OpenTelemetry.
Memory limiter processor, OpenTelemetry Collector.
Batch processor, OpenTelemetry Collector.
Debug exporter replacement note, OpenTelemetry Collector, October 3, 2024.
Security, OpenTelemetry.