ConfigGenerator

OpenTelemetry Config Generator

Generate production-ready otel-collector-config.yaml with receivers, processors, exporters, extensions, and pipelines for vendor-neutral telemetry collection.

Output:A ready-to-use configuration file for OpenTelemetry Config with best practices applied.

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]
Not generated yet

What is this tool?

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 to Use This Tool

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 Notes

  • 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.

How We Keep Your Configs Safe & Valid

Built-in Error Checking

Every file is checked against official rules. We catch missing fields and bad syntax. YAML indentation errors are flagged right away. Kubernetes, Terraform, and Docker specs are all covered. API versions and labels are verified too. You get valid output every time you generate.

100% Private & Local

All tools run in your browser only. Your API keys never leave your machine. We do not use any tracking scripts. No data is sent to any server. Passwords and secrets stay on your device. Crypto operations use the Web Crypto API. Your privacy is fully protected at all times.

Secure Settings by Default

Configs use safe defaults out of the box. Containers run as non-root users. Root filesystems are set to read-only. Dangerous Linux capabilities are dropped. Network policies limit pod-to-pod traffic. TLS 1.3 is enabled for web servers. Security headers are added where needed.

Ready for CI/CD & Git

Output files are ready for your Git repo. Use them with ArgoCD, Flux, or GitHub Actions. Files use clear formatting and comments. Code review is easy for your team. Indentation and key order are consistent. Test in staging before going to production. Every file is clean and well-structured.

Infrastructure as Code

Store configs in Git alongside your code. Terraform modules include typed variables. Backend configs support remote state locking. Outputs work across multiple modules. Ansible playbooks use clear task steps. Chef and Puppet configs are also supported. Every file works with version control tools.

Monitoring & Tracing

Set up Prometheus with auto-discovery rules. Create Grafana dashboards with template variables. Add alerting rules with severity labels. Use OpenTelemetry for trace collection. Forward logs to Loki or Elasticsearch. Connect to Jaeger or Tempo for tracing. Monitor metrics, logs, and traces together.

Container & Docker Safety

Dockerfiles use multi-stage builds for small images. Base images are pinned to exact versions. Dev files are excluded from final images. Health checks are added for orchestrator use. Containers switch to non-root users. Docker Compose uses named volumes and networks. Resource limits are set in deploy configs.

Multiple Output Formats

Export as YAML, JSON, HCL, or TOML. Kubernetes uses YAML with proper separators. Terraform uses HCL with correct escaping. JSON output has consistent indentation. Copy to clipboard with one click. Preview output with syntax highlighting. Line numbers help you review quickly.

Related Tools

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.