Guest post by Austin Parker, Principal Developer Advocate at LightStep

If the best platforms are more than matchmakers, then the best open source projects are more than utilities. It wouldn’t be incorrect or inconceivable to suggest that the success of cloud native has more to do with the ability of vendors and other third parties to create interesting distributions out of the building blocks provided by CNCF projects such as Kubernetes, Prometheus, Jaeger, and more. 

OpenTelemetry is well suited to become an integral part of this pattern. If you’re not familiar with it, OpenTelemetry provides a single set of APIs, SDKs, and tooling for the collection of telemetry data from cloud-native software – telemetry such as metrics, traces, and logs. By providing open source and consistent formats and protocols for this data it allows for end users, other open source developers, and vendors to build extensions, wrappers, and distributions that conveniently package its functionality to ease adoption and ensure that best practices are being followed.

Broadly, there are two major areas where the community can package and extend OpenTelemetry – the SDK itself, and the OpenTelemetry collector. We’ve already seen dozens of community contributions to the collector itself, allowing interoperability with a variety of observability and monitoring tools. As the OpenTelemetry project moves towards general availability later this fall, however, we’re now seeing distributions of the SDK that promise easier and more consistent setup and usage of OpenTelemetry, built on best practices.

One example of the latter are the OpenTelemetry Launchers, an open source configuration layer and wrapper, now available for Java, Golang, Node.JS, and Python. These launchers allow you to integrate OpenTelemetry into your service with as little as one line of code by providing sensible defaults, consistent configuration via environment variable or configuration file, 100% interoperability with upstream OpenTelemetry, and simple validation of configuration options to aid installation.

As OpenTelemetry grows and matures, I anticipate that we’ll see more distributions crop up as observability and monitoring tools build consensus on OpenTelemetry as the best way to create and collect telemetry data from their cloud native software. The days of proprietary agents and incompatible protocols are passing by as practitioners adopt high quality open source instrumentation for their observability needs. The OpenTelemetry project is committed to highlighting these contributions and ensuring that end users are able to find the integrations they need through our registry, and we’re always eager to bring more people to the table to build out support for OpenTelemetry into libraries and other cloud-native products.

If you’d like to learn more about OpenTelemetry or join our community, you can find out more at our website or GitHub. If you’d like to read more about the launchers, or about how to quickly get started with OpenTelemetry, check out this documentation.