OpenTelemetry Collector Config Generator

Config preset:

Start with the deployment role closest to the Collector you plan to run.

Signal pipelines:

Choose at least one signal. Prometheus export is limited to metrics.

Traces

Metrics

Logs

OTLP receiver protocols:

Enable only the transports your SDKs and upstream Collectors use.

Receiver bind address:

Use `localhost`, an IP address, or an environment expression such as `${env:MY_POD_IP}`.

Exporter target:

Uses current component ids: `otlp_grpc`, `otlp_http`, `prometheus`, or `debug`.

Exporter endpoint:

Exporter transport security:

The generated `tls.insecure` value applies only to OTLP gRPC export.

Memory guard:

Coordinate the hard limit with the container or host memory budget.

Memory limit:

Hard limit as a percentage of available memory.

Memory spike allowance:

A 20% starting point is common, but traffic and check interval determine the real need.

Memory limit:

Hard Collector memory limit in mebibytes.

MiB

Memory spike allowance:

Expected short-term increase between memory checks.

MiB

Memory check interval:

Shorter checks reduce the unobserved growth window.

Batch timeout:

Use a Go-style duration such as `200ms`, `1s`, or `5s`.

Batch send size:

Count of spans, metric points, or log records that triggers a send.

Maximum batch size:

Use 0 to leave the hard maximum unspecified.

Resource attributes:

Optional `key=value` rows. Leave blank to omit the resource processor.

Exporter auth header name:

Optional for OTLP exporters. Leave this and the value blank to omit headers.

Exporter auth header value:

Pair with the header name; avoid embedding a real token in saved or shared files.

Explicit sending queue:

Emits `sending_queue.enabled: true`; omitted settings continue to use the exporter's version-specific defaults.

Write explicit retry settings:

Emits `retry_on_failure.enabled: true`; queue overflow and backend retry behavior still need capacity review.

Health check extension:

Adds the health_check extension's operational endpoint on port 13133 using the receiver bind address.

Enable pprof extension:

Adds runtime profiling on port 1777; expose only on a trusted interface.

Enable zPages extension:

Adds live diagnostic views on port 55679; keep them off untrusted networks.

Collector log level:

Controls the Collector's own internal logs, not application telemetry.

Debug exporter verbosity:

Used only when the selected exporter target includes `debug`.

{{ values.config_text }}

The chart renderer is unavailable. The same findings remain available in Config audit.

Signal	Receiver	Processor order	Exporters	Rollout note	Copy
{{ row.signal }}	{{ row.receiver }}	{{ row.processors }}	{{ row.exporters }}	{{ row.note }}

Local rollout evidence

Review browser-checkable structure separately from target-environment validation.

{{ values.warning_count ? `${values.warning_count} review` : 'Ready' }}

{{ row.area }} {{ row.status }}

{{ row.check }}

{{ row.finding }}

Next: {{ row.action }}

Telemetry becomes useful only when traces, metrics, and logs can travel from an application to a backend without losing their identity or overwhelming the path between them. An OpenTelemetry Collector sits in that path as a vendor-neutral service that receives signal data, processes it in a declared order, and exports it onward.

A Collector configuration defines components and then activates them in service pipelines. Merely declaring a receiver or exporter does not make it run. Each signal pipeline must name its receivers, processors, and exporters, and processor order changes behavior because memory protection, enrichment, and batching happen sequentially.

OpenTelemetry Collector component roles
Component	Role	Planning question
Receiver	Accepts OTLP over gRPC, HTTP, or both.	Which clients must connect, and on which trusted interface?
Processor	Protects memory, enriches resource identity, or batches records.	What order limits pressure before data accumulates?
Exporter	Sends data to an OTLP backend, exposes Prometheus metrics, or prints debug output.	Which signals, endpoint shape, credentials, and transport security does the destination require?
Extension	Adds health or diagnostic endpoints outside the telemetry pipeline.	Can the endpoint remain on a trusted network?

Agent and gateway deployments make different trust choices. A same-host agent can often bind to localhost and forward to a gateway. A shared gateway may need a wildcard listener, but that increases exposure and calls for network policy, firewalling, receiver authentication, or TLS appropriate to the environment.

Capacity controls are not fixed recipes. The memory limiter needs a hard limit coordinated with the container or host and a spike allowance large enough for growth between checks. Batching trades fewer outgoing requests and better compression against memory use and delivery latency. Queue and retry settings also need backend outage and overflow planning rather than blind enablement.

Collector distributions do not all contain the same components or versions. Configuration validity therefore depends on the exact image or binary that will run it. A locally consistent YAML draft still needs distribution validation and a controlled smoke test before rollout.

Telemetry can contain service names, URLs, database statements, user attributes, tokens, and other sensitive data. Receiver exposure, exporter TLS, authentication headers, debug verbosity, and diagnostic endpoints are security decisions, not finishing details.

How to Use This Tool:

Start from the Collector's deployment role, then make the receiving and exporting paths agree.

Choose a Config preset close to the intended role, then enable only the traces, metrics, and logs the deployment will carry.
Select the OTLP receiver protocols and a Receiver bind address. Use localhost for same-host clients; widen the listener only when remote clients need it and the network boundary is understood.
Choose the Exporter target and enter the matching endpoint form. OTLP gRPC uses host and port without an HTTP scheme, OTLP HTTP starts with HTTP or HTTPS, and Prometheus export is available only for a metrics-only pipeline.
Set the memory guard and batch values. Keep the spike allowance below the hard limit and make the maximum batch size either 0 or at least the send trigger.
Review the Config audit, especially wildcard listeners, omitted memory protection, queue and retry assumptions, debug output, and diagnostics. Validate the generated YAML against the exact Collector distribution before starting a smoke test.

Interpreting Results:

The Collector YAML is a configuration draft. The Pipeline ledger confirms which signals share the OTLP receiver, ordered processors, and selected exporters. The Readiness profile counts local review findings, not runtime failures.

Ready means the chosen fields pass the generator's compatibility and format rules.
Review needed points to an operational decision such as an all-interface listener, omitted memory limiter, version-dependent queue defaults, exposed diagnostics, or detailed debug payloads.
Neither status proves that the target distribution contains every named component, that the backend accepts the signals, or that credentials and certificates work.

Technical Details:

An active signal path has the form receiver → ordered processors → exporter. The same receiver and processor instances may be referenced by several signal pipelines, but every enabled signal must be compatible with the exporter at the end of its path.

Mechanism Core:

Generated OpenTelemetry Collector pipeline mechanism
Stage	Generated behavior	Why the order matters
Receive	OTLP gRPC listens on port 4317 and OTLP HTTP on 4318 when selected.	The bind address controls which network interfaces accept telemetry.
Limit memory	`memory_limiter` is first when percentage or fixed protection is enabled.	Compatible receivers can apply backpressure before later processors retain more data.
Enrich	Optional shared resource attributes are applied with upsert behavior.	A shared value may overwrite an application's existing resource identity.
Batch	`batch` follows memory protection and enrichment.	Timeout and size triggers shape latency, request count, and memory use.
Export	OTLP, Prometheus, debug, or OTLP plus debug receives the selected signals.	Endpoint syntax, supported signals, TLS, headers, queues, and retries vary by exporter.

Memory Guard Formula Core:

The memory limiter begins refusing new data above a soft limit and forces garbage collection above the hard limit. For fixed MiB values, the spike allowance is the gap between them.

L_{soft} = L_{hard} - S

For percentage mode, available memory M scales both percentages before the same subtraction.

L_{soft} = M \times \frac{p - s}{100}

Here p is the hard-limit percentage and s is the spike percentage. The spike value must be strictly less than the hard-limit value in either mode. These are runtime thresholds, not display rounding.

Rule Core:

Compatibility and boundary rules for generated Collector configuration
Area	Rule
Signals	At least one of traces, metrics, or logs is required. Prometheus export requires metrics alone.
OTLP gRPC endpoint	Use host and port without an HTTP scheme. Its `tls.insecure` choice applies only to the gRPC exporter.
OTLP HTTP endpoint	Use an HTTP or HTTPS URL. The generated transport-security switch does not add an HTTP TLS block.
Batching	`send_batch_size` is a send trigger, not a hard cap. A positive `send_batch_max_size` is the cap and must be at least the trigger; 0 omits the cap.
Durations	Memory and batch intervals use Go-style duration strings such as `500ms`, `1s`, or `1m30s`.
Headers	An exporter header requires both a valid header name and a value, and is emitted only for an OTLP exporter.
Resource identity	Each line uses `key=value`; keys accept letters, digits, underscore, dot, and hyphen.

Health check, profiling, and live diagnostic extensions use the selected receiver bind address on ports 13133, 1777, and 55679 respectively. That makes a wildcard bind a security-relevant choice even when the telemetry receiver itself is expected to be public inside a cluster.

Privacy and Safety Notes:

The YAML is assembled in the browser. Do not paste a live bearer token into an authentication value; use an environment expression or secret-injection method supported by the deployment.
A wildcard receiver or diagnostic bind can expose telemetry and runtime information beyond the intended clients. Apply network and transport controls before rollout.
Detailed debug export can write telemetry payload contents into Collector logs. Use it only in an environment where those contents may safely appear.
The memory limiter reduces out-of-memory risk but can refuse data. If the preceding receiver cannot retry correctly, telemetry may be lost.

Worked Examples:

Same-host agent forwarding to a gateway

Choose the edge-agent preset, keep the receiver on localhost, enable the signals the applications send, and use an OTLP gRPC gateway target with verified TLS. The pipeline ledger should place memory protection before batching. Validate the file against the installed distribution, then send one known test signal and confirm that it reaches the gateway.

Metrics endpoint for Prometheus

Select Metrics only and choose the Prometheus exporter. A host-and-port target produces a metrics pipeline that Prometheus can scrape. Enabling traces or logs makes the configuration invalid because that exporter path is intentionally metrics-only. Keep the listener on a trusted interface and verify the scrape from the actual Prometheus network.

References:

Collector configuration, OpenTelemetry.
Memory Limiter Processor, OpenTelemetry Collector.
Batch Processor, OpenTelemetry Collector.
How to configure an OTLP receiver in the OpenTelemetry Collector, Simplified Guide.
How to secure OTLP traffic with TLS in the OpenTelemetry Collector, Simplified Guide.