OpenTelemetry Collector configs are easy to grow and hard to reason about.
A config can be valid and still have production risks:
exporters:
otlphttp:
endpoint: http://backend.example.com
headers:
X-API-KEY: "hardcoded-secret"
or:
service:
pipelines:
traces:
processors: [batch, memory_limiter]
These are the kinds of things oteldoctor is designed to catch.
What it does
oteldoctor checks:
- undefined receivers/processors/exporters
- missing
memory_limiter
- wrong processor order
- missing retry/queue config
- hardcoded secrets
- plain HTTP exporters
- debug exporters in production
- high-cardinality attributes
- missing sampling/filtering hints
- semantic convention issues
- Kubernetes readiness gaps
Commands
oteldoctor analyze ./deploy --profile production
oteldoctor analyze ./deploy --format json
oteldoctor analyze ./deploy --format sarif > oteldoctor.sarif
oteldoctor graph collector.yaml --format mermaid
oteldoctor explain OTEL-SEC-202
oteldoctor fix collector.yaml --dry-run
Install
go install github.com/firfircelik/oteldoctor/cmd/oteldoctor@v0.1.0
Why it exists
This is not a replacement for Collector validation.
It is more like a production-readiness layer for Collector configs.
The goal is to catch reliability, security, cost, semantic, and Kubernetes deployment risks earlier — ideally in CI, before the config is deployed.
GitHub: https://github.com/firfircelik/oteldoctor
If you work with OpenTelemetry Collector, I’d really appreciate feedback, issue reports, and real-world config edge cases.
