What is OpenTelemetry?
OpenTelemetry is an open source project and unified standard for service instrumentation, or a way of measuring performance. It provides a single application programming interface (API), libraries, integrations, and a software development kit (SDK) for programming languages including Java, Go, and Python. DevOps teams that use the standardized API don’t need to worry about code changes when switching between SDKs. This saves time, reduces effort, and streamlines performance enhancement and troubleshooting activities.
Sponsored by the Cloud Native Computing Foundation (CNCF), OpenTelemetry replaced OpenTracing and OpenCensus. The goal is to standardize how you collect and send telemetry data to a backend platform. It defines a centralized collector service that you can use for collecting telemetry data from your applications and services. And it also includes exporters to send that data to the observability platform that you choose.
OpenTelemetry covers all three aspects of monitoring software: implementing the recording instrumentation, capturing data, and exporting the information for analysis. It’s also vendor neutral. Development teams don’t need to manually create monitoring solutions if they want a vendor neutral solution. With OpenTelemetry, you aren’t forced to use the solution provider's instrumentation libraries to meet client specifications.
The most valuable OpenTelemetry use cases
Teams find OpenTelemetry the most valuable for three priority use cases:
- You have data cross multiple platforms
- You need vendor neutrality
- You want to optimize valuable team hours
In this blog post, you get an overview of what OpenTelemetry is and why this open standard is the future of instrumentation. Let's start with a video:
Get started now
- Review the OpenTelemetry quick start guide.
- Check out our OpenTelemetry examples.
Why OpenTelemetry is the future of instrumentation
As described in the video, there are four reasons why OpenTelemetry is changing instrumentation:
- You have access to a broad and deep set of instrumentation, because it is built and supported by a large open source community. More than 300 companies contributed to the OpenTelemetry project in the past year, with more than 100,000 contributions. And the OpenTelemetry community had more than 2,000 contributors over the past year. As an open standard, OpenTelemetry encourages broad collaboration and promotes better coverage, flexibility, and ubiquity as engineers from all over the world contribute to the instrumentation.
- The standard instrumentation means that different tools and services operate together, so you get visibility for your entire system. OpenTelemetry is interoperable, which means that various systems can use this standard form of instrumentation across all services to exchange information. Without a standard instrumentation across all services of your application, you have blind spots or data silos that affect troubleshooting and reduce your ability to quickly detect and resolve issues. OpenTelemetry bridges gaps in visibility.
- You have flexibility to change your backend observability tools. Most proprietary monitoring solutions require you to install specific instrumentation agents to gather telemetry data. If you switch to a different tool, you have to spend more time and resources installing different proprietary agents or re-instrumenting your code. With OpenTelemetry, your path is independent from the various proprietary tools. You can change your backend observability tool without having to change your instrumentation. You have full visibility into the OpenTelemetry source code and insight into how the community develops features and fixes bugs.
- You can monitor emerging technologies easily. When new technologies are built, OpenTelemetry instrumentation becomes a part of libraries and frameworks that your applications are already using. This means you don't need to wait for individual monitoring tools to support the latest technologies.
The necessity to make orchestrated systems like Kubernetes more understandable and application performance monitoring (APM) more transparent are two of the several development threads that gave rise to the discipline of observability. The goal of observability is to offer rich context and incredibly granular insights into how systems behave.
Why you need OpenTelemetry for your observability
Two main software development threads that gave rise to the discipline of observability are the need to make orchestrated systems like Kubernetes more understandable and the need to make application performance monitoring (APM) more transparent. The goal of observability is to offer rich context and incredibly granular insights into how systems behave.
For observability, you need:
- to create systems and applications that collect relevant data like metrics, traces, and logs
- to be able to easily or automatically export this information to a platform outside of the program you are analyzing
- the analysis to provide visualizations and insights into the system as a whole, including how the end user experience is affected by changes in the development of the application
Observability provides holistic monitoring of systems and platforms for developers and stakeholders to determine how they are functioning. But observability is hard to measure and analyze without help. Tools like OpenTelemetry streamline performance monitoring across vendors and languages and help devs watch observability metrics and report on them. To determine if OpenTelemetry is right for your product, developers should ask:
- What programming language, platform, and frameworks are we using?
- What types of data are we looking to analyze?
- What analytical tools will we be pushing the data to for analysis?
OpenTelemetry needs to combine with observability to function at its best. When parts of OpenTelemetry’s Collector (the receivers, processors, and exporters) take in, compile, and distribute meaningful data and information in a format that can be analyzed properly for performance and troubleshooting purposes, developers are able to access full observability and monitoring in one tool.
New Relic and OpenTelemetry
New Relic has been one of the major contributors to OpenTelemetry since its inception. In 2020, we announced our full commitment to open source instrumentation including open sourcing our agents and standardizing our observability offerings on OpenTelemetry. With our native OpenTelemetry protocol (OTLP) support and curated user experiences, you can use this new standard of instrumentation to understand, troubleshoot, and optimize your systems.
Start exploring OpenTelemetry today
Now is the perfect time to start experimenting with OpenTelemetry tracing on your own applications and services. If you want to try it, check out our OpenTelemetry examples.
- Sign up for New Relic for free and start sending your OpenTelemetry data today.
- Check out Part 2 in the series: Core components of OpenTelemetry.
- Ready to apply your knowledge and instrument a basic application in your preferred programming language? Go to the OpenTelemetry Masterclass.
- For more hands-on work learning about OpenTelemetry, check out OpenTelemetry: an open source data collection standard, a 90-minute self-paced course with New Relic University.
This blog post is the first part in the Understand OpenTelemetry series. You got an overview of OpenTelemetry and an understanding of why this open standard is the future of instrumentation. In the next parts, Alan West, one of the maintainers of the OpenTelemetry project, and contributor Jack Berg will walk through the core components of OpenTelemetry, the data sources, how to instrument an application with OpenTelemetry, how to see the data in New Relic, and more.
Part 2 explores the core components of the OpenTelemetry project, and Part 3 focuses on the primary OpenTelemetry data sources. Part 4 walks through examples of instrumenting a Java application with OpenTelemetry, and Part 5 shows how to send the OpenTelemetry data to your backend platform.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.