---
title: The roadmap to v1 for the OpenTelemetry Collector
linkTitle: Collector Roadmap
date: 2024-05-06
author: '[Alex Boten](https://github.com/codeboten) (Honeycomb)'
# prettier-ignore
cSpell:ignore: Antipatterns Boten Broadbridge Helmuth Hrabovcak Ishan Jaglowski OTTL Pantuza pushback Shishi Vijay
---

The [OpenTelemetry Collector](/docs/collector/) is a very popular component in
OpenTelemetry that has been under heavy development for quite some time. It is a
binary that allows many formats of telemetry to be sent to it, transformed, and
emitted to a destination. Much has been said about the Collector over the past
few years in various blog posts and talks. Here's a small list of talks about
the Collector if you haven't had the chance to learn about it:

- [Connected Observability Pipelines in the OpenTelemetry Collector - Dan Jaglowski](https://www.youtube.com/watch?v=uPpZ23iu6kI)
- [OpenTelemetry Collector Antipatterns - Adriana Villela](/blog/2024/otel-collector-anti-patterns/)
- [Telemetry Showdown: Fluent Bit Vs. OpenTelemetry Collector - Henrik Rexed](https://www.youtube.com/watch?v=ykq1F_3PmJw)
- [OpenTelemetry Collector Deployment Patterns - Juraci Kröhling](https://www.youtube.com/watch?v=WhRrwSHDBFs)
- [OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Just Got Better - Tyler Helmuth & Evan Bradley](https://www.youtube.com/watch?v=uVs0oUV72CE)
- [Manage OpenTelemetry Collectors at scale with Ansible - Ishan Jain](/blog/2024/scaling-collectors/)

The Collector has been a core component for organizations looking to adopt
OpenTelemetry as part of their strategy to improve the telemetry emitted by
their systems. Organizations around the world have already adopted it and
successfully process large amounts of data through pipelines as documented by
these various talks:

- [Adopting OpenTelemetry Collector @ eBay - Swapping Engines Mid Flight - Vijay Samuel](https://www.youtube.com/watch?v=tZJd6W-CIcU)
- [Ingesting 6.5 Tb of Telemetry Data Daily Through OpenTelemetry Protocol and Collectors - Gustavo Pantuza](https://www.youtube.com/watch?v=aDysORX1zIs)
- [Today, Not Tomorrow: Scalable Strategies for Migrating to OpenTelemetry - Jason Anderson & Kevin Broadbridge](https://www.youtube.com/watch?v=iPGd9_aYu-A)
- [How and Why You Should Adopt and Expose OSS Interfaces Like OTel & Prometheus - Daniel Hrabovcak & Shishi Chen](https://www.youtube.com/watch?v=D71fK2MFreI)
- [Why, How to, and Issues: Tail-Based Sampling in the OpenTelemetry Collector - Reese Lee](https://www.youtube.com/watch?v=l4PeclHKl7I)

A few months ago, there was an
[ask from the community](https://github.com/open-telemetry/community/issues/1971)
to declare the OpenTelemetry Collector stable.

![Can haz Collector v1?](can-haz-collector.png)

Now you might be asking yourself "Why would anyone want the Collector to be
declared stable? You just told me it's already used in production!" It's true,
the Collector and its configuration have been fairly stable for core components
for some time. However, being "unofficially stable" is not good enough for a
wide variety of organizations who wish to adopt the Collector:

- An official v1 will signal that the OpenTelemetry community is ready to
  provide long term support and not introduce backwards incompatible changes
  without bumping the major version.
- Organizations with policies not to use pre-release software will be able to
  start adopting the Collector.
- Stability in the Collector helps the community move OpenTelemetry to become a
  CNCF Graduated project.

The request to stabilize was met with pushback from maintainers since calling
anything 1.0 has a way of setting expectations indefinitely. This led to a
series of discussions and meetings that brought together the maintainers of the
Collector to decide on what a 1.0 really means for the Collector.

And after a lot of back and forth, we decided on a limited scope of what we
wanted to focus on:

1. A distribution of the Collector that only includes an OTLP receiver and an
   OTLP exporter.
2. Individual Go modules that the Collector components rely upon must also be
   marked as stable as per the project's
   [versioning guidelines](https://github.com/open-telemetry/opentelemetry-collector/blob/f0c7a8b5077040e9946020ed3496fe8d262009fd/VERSIONING.md?from_branch=main#general-go-api-considerations).

Aside from this, there were a few areas the contributors wanted to improve based
on user feedback:

- The telemetry generated by the Collector about itself:
  - Traces, metrics, and logs must be available via OTLP.
  - The configuration for the telemetry must follow the configuration schema.
- The scalability of the Collector:
  - Handling for queueing, back pressure, and errors must be improved.
  - Clear benchmarks and performance expectations for end users.
- Overall documentation befitting of a stable piece of critical infrastructure.

The
[roadmap](https://github.com/open-telemetry/opentelemetry-collector/blob/af92ca87d82026e700c29eea922f23e3a8aff2dc/docs/ga-roadmap.md?from_branch=main)
was published in the Collector's repository and milestones were created to track
the work underway. To ensure the effort can be successful, the scope of the
deliverable was limited to provide:

- a clear and achievable goal
- the focus needed to not get distracted
- a signal to new contributors of where the project is focusing

There is much to do as you can see on the
[project board](https://github.com/orgs/open-telemetry/projects/83), but there
is a lot of excitement around this effort. If you're keen on helping, reach out
either by commenting on any of the open issues in GitHub, or attending the
Collector SIG call that happens weekly on Wednesdays. For a quick overview of
the 1.0 progress you can checkout the tracking
[issue](https://github.com/open-telemetry/opentelemetry-collector/issues/9375).
