OpenTelemetry is a healthy open source community, and contributors are free to propose new work streams or work on any part of the project that they desire. However, there’s also value in the project focusing community members of specific bodies of work and releases, as this allows us to form a more cohesive set of capabilities (unified semantics, single implementations for each language, etc.) and to ship the project in a more impactful way (new signal types release across multiple languages at once, etc.).
This roadmap is not law, and it is not meant to be used to force people to work on specific projects – this is an open source project and we (community members, the governance committee, etc.) are not anyone’s boss. Rather, it exists to provide direction to new contributors, to the public and end users who want to know what’s coming next, and to attempt to channel the bulk of our concentration and development efforts into the areas where they are most needed.
OpenTelemetry was started in 2019 with the promise of making it easy and consistent for developers to capture distributed traces and metrics from their applications and infrastructure using SDKs, the Collector, and OTLP. Since then, we’ve delivered:
All of the following work streams are major areas of investment for OpenTelemetry: all of them have large groups of people already focused on them. Their priorities primarily reflect the ordering of when we expect them to be released.
These priorities are most useful when comparing them against each other. For example, P0 entries are more critical than P1 entries, which are in turn more critical than P2s. We do have some basic definitions of each priority level, however:
The project’s top priority will always be ensuring that the capabilities and robustness of our existing artifacts (the Collector, SDKs, language agents, etc.) remain excellent. This work takes place in each language SIG and in the Collector SIG, and includes continual improvement to these components, making them even easier to use, providing and integrating more instrumentation libraries, working with the suppliers of telemetry sources to use the OpenTelemetry APIs natively, and more.
OpenTelemetry established a logging SIG in mid-2020, with two goals:
Much progress has been made on the first item, particularly through the donation of the Stanza logging agent into the OpenTelemetry Collector, and by the investments that the project has made in defining and stabilizing a data model and OTLP format for logs. However much still remains before we can declare our logging work generally available:
OpenTelemetry’s consistent semantic conventions across all data types are a major source of the project’s value, as they allow end-users and observability systems to both correlate related signals and set expectations about the metadata that should be present on telemetry captured from specific sources or types of interactions. For example, OpenTelemetry’s semantics describe the expected metadata for traces, metrics, and logs captured as part of an HTTP 4xx response.
However we still need to define the semantic conventions for more scenarios, so that instrumentation authors can release stable instrumentation libraries and so that end-users and observability systems can make firmer dependencies on OpenTelemetry’s metadata.
We want OpenTelemetry to provide true end-to-end visibility to service owners, including E2E latency (including client app and internet latency) and the chain of backend service events and infrastructure-side performance stats that take place from a single user interaction. This requires OpenTelemetry to start supporting webpage JS, mobile applications, and desktop applications. OpenTelemetry JS has technically supported capturing spans from web browsers since its first releases, however this behavior was mostly unspecified, and there was no equivalent functionality for other types of client applications like those on Android, iOS, or Windows.
In late 2021, the Client Instrumentation SIG (often called the RUM SIG) was established, which seeks to specify client instrumentation behavior so that there is consistency in the data captured from and in the developer-facing telemetry interfaces in different types of client applications. This SIG is currently completing its first round of spec work, which will need to be implemented by the JS, Swift, Java, and other SIGs once it is complete.
Distributed profiling has been a long-standing topic of discussion within OpenTelemetry, and contributors to other profiling projects have advocated for it to be added to OpenTelemetry as an additional signal type. In May of 2022, this work commenced within OpenTelemetry’s profiling SIG.
Sampled heap and CPU profiles will allow OpenTelemetry to extend end-users' visibility to the performance of their actual code. While other profiling solutions allow this kind of inspection today, few are able to properly correlate profiles with application and infrastructure resource metadata, and even fewer are able to correlate profiling telemetry with distributed traces or other signals. Adding this to OpenTelemetry will allow analysis solutions and end-users to find instances of poor performance between services and then immediately chase these down to their root cause within code.
OpenTelemetry launched a community demo SIG in May 2022, which will provide sample applications that demonstrate OpenTelemetry’s capabilities to prospective end users, and also allow the community to better perform automated testing of OpenTelemetry components. The project’s first release occurred in October 2022, and we will be further investing in the demo throughout 2023 and beyond.
Since OpenTelemetry’s initiation, end-users and vendors have expressed a desire to (a) understand what SDKs, language agents, and Collectors are deployed within their environment (along with their status), and to (b) be able to make changes to the configuration of these artifacts or possibly even update agent binaries.
Specification work is already underway to address both of these needs, and the agent management SIG has already produced a specification for OpAMP, the protocol that will drive these interactions. Over time, the SIGs that develop various OpenTelemetry artifacts will need to implement OpAMP to enable these scenarios.
These topics have been discussed in the past, but have either been deliberately prioritized beneath the project’s major ongoing priorities, or have yet to have a large group of contributors form up behind them.
Was this page helpful?
Thank you. Your feedback is appreciated!
Please let us know how we can improve this page. Your feedback is appreciated!