ConfigGenerator

OpenTelemetry Config Generator

Build production-ready otel-collector-config.yaml with Receivers, Processors, Exporters, Extensions, and Pipelines.

OpenTelemetry Collector

Receivers

Processors

Exporters

Extensions

Pipelines

traces

metrics

logs

otel-collector-config.yaml
1# OpenTelemetry Collector Configuration
2# Generated by ConfigGenerator.com
3

4receivers:
5otlp:
6  otlp:
7    protocols:
8      grpc:
9        endpoint: 0.0.0.0:4317
10      http:
11        endpoint: 0.0.0.0:4318
12

13processors:
14memory_limiter:
15  memory_limiter:
16    check_interval: 1s
17    limit_mib: 512
18    spike_limit_mib: 128
19batch:
20  batch:
21    send_batch_size: 1024
22    timeout: 200ms
23    send_batch_max_size: 2048
24

25exporters:
26prometheus:
27  prometheus:
28    endpoint: 0.0.0.0:8889
29    namespace: otel
30

31extensions:
32health_check:
33  endpoint: 0.0.0.0:13133
34pprof:
35  endpoint: 0.0.0.0:1777
36zpages:
37  endpoint: 0.0.0.0:55679
38

39service:
40  extensions: [health_check, pprof, zpages]
41  pipelines:
42    traces:
43      receivers: [otlp]
44      processors: [memory_limiter, batch]
45      exporters: [prometheus]
46    metrics:
47      receivers: [otlp]
48      processors: [memory_limiter, batch]
49      exporters: [prometheus]
Syntax
Security
Best Practices

Overview

The OpenTelemetry Config Generator helps you build production-ready otel-collector-config.yaml files for the OpenTelemetry Collector. OpenTelemetry (OTel) is the CNCF standard for instrumenting, generating, collecting, and exporting telemetry data including traces, metrics, and logs in a vendor-neutral way.

The OTel Collector is the cornerstone of the OpenTelemetry ecosystem. It receives telemetry in multiple formats, processes it through a pipeline of processors, and exports it to one or more backends. This generator produces syntactically correct YAML configurations with all four core components fully configured: Receivers, Processors, Exporters, and Extensions.

How It Works

1. Define Receivers: Receivers ingest telemetry data into the Collector. Common receivers include otlp (gRPC and HTTP), jaeger, zipkin, prometheus (scrape), kafka, hostmetrics (CPU, memory, disk, network), docker_stats, and k8s_cluster for Kubernetes metrics.

2. Add Processors: Processors transform, filter, and enrich telemetry in-flight. Use batch for efficient batching, memory_limiter to prevent OOM, filter to drop unwanted signals, attributes to modify resource or span attributes, resource to set resource-level attributes, probabilistic_sampler for head-based sampling, and transform for OTTL-based transformations.

3. Configure Exporters: Exporters send processed telemetry to backends. Supported exporters include prometheus, jaeger, zipkin, otlp, loki, elasticsearch, opensearch, AWS CloudWatch, Azure Monitor, Google Cloud Logging, and debug for development.

4. Enable Extensions: Extensions provide health checks (health_check), profiling (pprof), and observability (zpages) for monitoring the Collector itself.

5. Wire Pipelines: Connect receivers, processors, and exporters into signal-specific pipelines (traces, metrics, logs). Each pipeline defines which receivers feed into which processors and exporters for that particular telemetry signal.

Best Practices

  • Always include a memory_limiter processor to prevent out-of-memory crashes under high load.
  • Use batch processor to group telemetry before exporting, reducing network overhead and backend load.
  • Configure health_check extension for Kubernetes liveness and readiness probes.
  • Use separate pipelines for traces, metrics, and logs to apply signal-specific processors.
  • Enable zpages extension during development to inspect pipeline performance in real-time.
  • Set explicit TLS configuration on all exporters for production deployments.
  • Use probabilistic_sampler to control trace volume in high-traffic environments.
  • Include pprof extension for production profiling and debugging performance issues.

Common Mistakes

  • Running without memory_limiter processor, risking OOM kills under traffic spikes.
  • Not configuring health_check extension, preventing Kubernetes probes from working.
  • Using debug exporter in production, leaking sensitive telemetry to stdout.
  • Forgetting to add receivers to pipelines, resulting in no data flow through the Collector.
  • Mixing incompatible receiver formats without proper decoding processors.

Security Recommendations

  • Enable TLS on all gRPC and HTTP endpoints to encrypt telemetry in transit.
  • Use authentication headers or mTLS between the Collector and backend exporters.
  • Avoid the debug exporter in production environments to prevent data leakage.
  • Apply RBAC in Kubernetes to restrict which namespaces the Collector can observe.
  • Use environment variables for sensitive values like API keys and tokens.
  • Restrict Collector network exposure — receivers should only listen on necessary interfaces.

Production Tips

  • Deploy the OTel Collector as a sidecar in Kubernetes for per-pod instrumentation.
  • Use the agent/collector split pattern: lightweight agents forward to a centralized collector fleet.
  • Monitor the Collector itself via the health_check and pprof extensions.
  • Scale the Collector horizontally behind a load balancer for high-availability setups.
  • Tune batch send_batch_size and timeout based on your backend's ingestion capacity.
  • Use the transform processor with OTTL for advanced telemetry manipulation without code changes.
  • Export traces to Jaeger or Tempo and metrics to Prometheus for a complete CNCF observability stack.

Frequently Asked Questions

What is OpenTelemetry and why should I use it?
OpenTelemetry is the CNCF standard for observability instrumentation. It provides vendor-neutral APIs, SDKs, and tools for collecting traces, metrics, and logs. Using OTel avoids vendor lock-in and provides a unified instrumentation approach across all telemetry signals.
What is the OpenTelemetry Collector?
The OTel Collector is a vendor-agnostic proxy that receives, processes, and exports telemetry. It supports multiple receiver formats, has a pluggable processor pipeline, and can export to any backend. The Collector can run as an agent on each node or as a standalone deployment.
What is the difference between OTLP, Jaeger, and Zipkin receivers?
OTLP is the native OpenTelemetry protocol over gRPC and HTTP. Jaeger and Zipkin receivers accept their respective proprietary formats, allowing gradual migration from existing instrumentation to OpenTelemetry without rewriting application code.
How does the memory_limiter processor work?
The memory_limiter periodically checks the Collector's memory usage. When memory exceeds the configured limit_mib, it signals receivers to apply backpressure. The spike_limit_mib provides a buffer to handle transient spikes without triggering throttling.
Can I use the OTel Collector with Prometheus?
Yes. The prometheus receiver scrapes Prometheus endpoints and converts metrics to OTLP format. The prometheus exporter exposes OTel metrics as a Prometheus-compatible endpoint. This allows seamless integration with existing Prometheus-based monitoring.
What is OTTL (OpenTelemetry Transformation Language)?
OTTL is a domain-specific language used in the transform processor for manipulating telemetry. It supports setting, updating, and deleting attributes, filtering conditions, and complex transformations on traces, metrics, and logs using a safe, side-effect-free syntax.
How do I deploy the OTel Collector in Kubernetes?
Use the OpenTelemetry Operator for Kubernetes to manage Collector deployments. It supports sidecar injection, auto-instrumentation, and CRD-based configuration. Alternatively, deploy as a DaemonSet for agent mode or Deployment for gateway mode with a Helm chart.

Related Generators

Prometheus Config Generator

Generate prometheus.yml with scrape targets, alerting rules, and recording rules.

Grafana Dashboard Generator

Build Grafana dashboard JSON for visualizing OTel telemetry data.

Kubernetes YAML Generator

Generate Kubernetes manifests for deploying the OTel Collector.