opentelemetry-collector
OpenTelemetry Collector is a vendor-agnostic Go service that receives, processes, and exports observability data (traces, metrics, logs) in multiple formats. It consolidates telemetry pipelines into a single deployable agent/collector, eliminating the need for multiple specialized agents.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | open-telemetry/opentelemetry-collector |
| Owner | open-telemetry |
| Primary language | Go |
| License | Apache-2.0 — OSI-approved |
| Stars | 7.2k |
| Forks | 2.1k |
| Open issues | 694 |
| Latest release | v0.156.0 (2026-07-07) |
| Last updated | 2026-07-08 |
| Source | https://github.com/open-telemetry/opentelemetry-collector |
What opentelemetry-collector is
Built in Go, the Collector implements OTLP v1.10.0 (Stable) and provides pluggable receivers, processors, and exporters for protocol translation. It operates as both an agent and server, with internal telemetry for self-monitoring and extensibility via custom components without core modifications.
Get the opentelemetry-collector source
Clone the repository and explore it locally.
git clone https://github.com/open-telemetry/opentelemetry-collector.gitcd opentelemetry-collector# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Configuration complexity: YAML-based setup with distinct receiver/processor/exporter pipelines; requires understanding of telemetry formats and backend APIs.
- Deployment flexibility: Supports agent (per-host), gateway (centralized), and mixed topologies; choose based on network architecture and data volume.
- Resource tuning: Memory limits, queue sizes, and batch settings must be tuned per environment; monitor internal telemetry to avoid dropped data.
- Go version tracking: Follows Go release policy; keep binaries updated as unsupported Go versions are dropped.
- Component stability: Some receivers/processors/exporters are beta or alpha; validate production-readiness of non-core components before deployment.
When to avoid it — and what to weigh
- Need simple, zero-configuration observability — Requires explicit configuration of receivers, processors, and exporters; not a drop-in replacement for lightweight APM agents.
- Operating on resource-constrained edge environments — Go binary and runtime footprint may exceed requirements for extremely lightweight deployments; consider language-specific agents for minimal overhead.
- Require proprietary vendor lock-in tooling — Vendor-agnostic design; if your workflow depends on closed-source integrations or specific vendor formats, evaluate compatibility first.
- Need application-level instrumentation only — Collector is infrastructure-tier; does not replace instrumentation libraries; you must instrument applications separately.
License & commercial use
Apache License 2.0 (Apache-2.0). Permissive OSI-approved license; permits commercial use, modification, and distribution with attribution and no warranty.
Apache-2.0 allows unrestricted commercial use, including building proprietary products on top. No license restrictions on deployment scope, users, or revenue. Standard OSS indemnification terms apply; review Apache-2.0 full text for corporate legal clarity.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Strong |
| License clarity | Clear |
| Deployment complexity | Moderate |
| DEV.co fit | Good |
| Assessment confidence | High |
Apache-2.0 licensed codebase, CII Best Practices badge, and OSS-Fuzz coverage indicate active security focus. No claims of built-in data encryption; relies on TLS configuration for in-transit protection and backend API key management. No code-level audit claimed. Deployed on untrusted networks should enforce mTLS and network policies. Cosign-signed container images available for integrity verification. Internal telemetry can expose operational data; configure scrape endpoints with access controls.
Alternatives to consider
Datadog Agent
Commercial, vendor-locked alternative; simpler default config for Datadog customers but less flexible for multi-backend scenarios.
Prometheus + Alertmanager + Jaeger
Best-of-breed OSS stack for metrics, alerting, and tracing; requires separate operational instances and higher complexity for log ingestion.
Fluent Bit / Logstash
Lighter-weight log collection agents; less integrated trace/metric support; suitable for log-only pipelines but misses unified telemetry consolidation.
Build on opentelemetry-collector with DEV.co software developers
Discuss deployment architecture, backend integrations, and operational tuning with our engineering team to validate fit for your telemetry scale and multi-backend requirements.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
opentelemetry-collector FAQ
Can the Collector replace my APM agent (e.g., New Relic APM, Datadog APM)?
What are the typical resource requirements (CPU/memory)?
Does the Collector support custom receivers or processors?
Is data guaranteed to be delivered to backends?
Custom software development services
Need help beyond evaluating opentelemetry-collector? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source observability integrations — and maintain them long-term.
Evaluate OpenTelemetry Collector for your observability stack
Discuss deployment architecture, backend integrations, and operational tuning with our engineering team to validate fit for your telemetry scale and multi-backend requirements.