OpenTelemetry is a great way to combine different types of telemetry from across your application and to do so in a way that protects your organization from future vendor changes. But maybe you think your team can do better? Why not set your team out to build a new abstraction for extracting telemetry that is customized to your application and the needs of your organization? After all, your platform team will need to invest in some abstraction, why not invest in one that precisely fits your needs?
The APIs, wire formats, and other standards set by OpenTelemetryOpenTelemetry have been carefully considered and designed by a panel of industry experts. Even if your team could do incrementally better, you should really ask if it’s worth their time to be doing so.
By virtue of its permissive licenses, OpenTelemetry is compatible with other open source projects. It’s likely that your application already includes many open source components (either in the form of frameworks that are compiled into proprietary services or as standalone services). If your organization defines its own APIs and formats for telemetry, these open source components will not be compatible. In fact, those components might already be compatible with OpenTelemetrycompatible with OpenTelemetry; if they are not, that is an opportunity for your team to contribute back to the open source projects that you are using.
There’s no “I” in “team”
Your platform team will absolutely need to invest their time in building a paved road for teams to follow. But instead of investing in how telemetry is gathered from the application, have them instead focus on how observability is integrated into other tools. For example, have them consider how your source code repositorysource code repository or continuous integration and continuous delivery (CI/CD)continuous integration and continuous delivery (CI/CD) could leverage telemetry to support or automate decision making and other processes.
How’s your system today?
Understanding the performance of the application as a whole is absolutely necessary – that’s how your users see it. And understanding performance effectively means combining different types of telemetry (metrics, logs, and traces) to derive insights as quickly as possible. At the same time, as your organization continues to adopt DevOps practices that give more autonomy to individual teams, setting standards will become more and more important to avoiding miscommunication and redundant work.
OpenTelemetry: One for all and all for one
OpenTelemetry provides a cost-effective and scalable way for your platform and infrastructure teams to support the rest of the organization while still enforcing those standards. By using an expert-built abstraction layer that’s compatible with other open source components, your platform team will be able instead to focus on customizations with a higher return-on-investment for your organization, your application, and – ultimately – your users.
Check out our Engineering Leader’s Guide to OpenTelemetryEngineering Leader’s Guide to OpenTelemetry to learn more about how OpenTelemetry and how it can help your team.
Interested in joining our team? See our open positions herehere.
Explore more articles
OpenTelemetry Collector in Kubernetes: Get started with autoscalingMoh Osman | Jan 6, 2023
Learn how to leverage a Horizontal Pod Autoscaler alongside the OpenTelemetry Collector in Kubernetes. This will enable a cluster to handle varying telemetry workloads as the collector pool aligns to demand.Learn moreLearn more
Observability-Landscape-as-Code in PracticeAdriana Villela, Ana Margarita Medina | Oct 25, 2022
Learn how to put Observability-Landscape-as-Code in this hands-on tutorial. In it, you'll use Terraform to create a Kubernetes cluster, configure and deploy the OTel Demo App to send Traces and Metrics to Lightstep, and create dashboards in Lightstep.Learn moreLearn more