Why OpenTelemetry Is the Future of Instrumentation
Cloud Native Computing Foundation and New Relic sponsored this post, in anticipation of the virtual KubeCon + CloudNativeCon North America 2020 – Virtual, November 17-20.
Today, companies are rapidly embracing open source in all aspects of software development; and the monitoring space is no different. Engineers have access to numerous tools to measure the performance of their stacks, and open source is at the heart of this tool explosion.
Apart from tools, standards are emerging and changing the way teams implement instrumentation. OpenTracing and OpenCensus were developed to standardize how teams capture traces and metrics. While both standards achieved their goals of making observability easy for many, a fundamental problem remained: they were two separate standards. For distributed tracing, it is particularly important to have one standard, because if even a single point in the causal chain is broken, the trace is no longer complete.
OpenTelemetry is an open source project and a unified standard for service instrumentation. Sponsored by the Cloud Native Computing Foundation (CNCF), it replaces OpenTracing and OpenCensus. The OpenTelemetry project consists of specifications, APIs and SDKs for various languages (like Java, Go and Python). It also defines a centralized collector and exporters, to send data to various backends. This standard is being backed by a number of leading monitoring companies, who all believe it’s the future of instrumentation.
Here are four reasons why OpenTelemetry is changing instrumentation:
1. Ubiquitous Instrumentation
As technologies evolve, it’s hard for one vendor to build integrations that provide the depth and breadth of instrumentation that is needed to get complete end-to-end visibility. Open source solutions have thriving communities around them, bound by a common drive to support and improve the solutions. This community-driven approach leads to the faster introduction of new concepts and capabilities; and this approach is often more effective than what proprietary solutions can offer. 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.
2. Interoperable
Modern environments are distributed and more complex, and effectively managing the performance in such environments poses a huge challenge. To understand the collective behavior of your services and applications, you need instrumentation for all of your frameworks and libraries, across all of your programming languages. Without standard instrumentation across all the services in your application, you’ll have blind spots or data silos that impact troubleshooting — which reduces your ability to quickly detect and resolve issues. OpenTelemetry bridges gaps in visibility by providing a standard form of instrumentation across all services, with complete interoperability.
3. Vendor Neutral
Most proprietary monitoring solutions require you to install the respective instrumentation agents to gather telemetry data. If you switch to a different vendor, your engineers have to spend more time and resources installing different proprietary agents or re-instrumenting code. You’re often locked into vendor configuration and roadmap priorities. OpenTelemetry provides a vendor-neutral path to instrumentation, so that you get full visibility into source code along with insight into how the community develops features and solves bugs. Having the flexibility to change your backend without having to change your instrumentation is essential.
4. Future Proof
As newer technologies emerge, they each have their pros and cons. The increased agility, scale and efficiency that most of these technologies bring comes at the cost of increased complexity in monitoring. This means that to monitor emerging technologies, you either have to do custom instrumentation or wait for proprietary vendors to build integrations. OpenTelemetry aims to solve this problem by building instrumentation into libraries and frameworks, so that when new technologies do emerge, you can easily monitor them without having to wait for vendors to add support.
Start Exploring OpenTelemetry Today
OpenTelemetry will become generally available in November, so now is the perfect time to start experimenting with it on your own applications and services. Experimenting on services you’re already familiar with will give you the confidence you need to future-proof your instrumentation. If you want to experiment, check out our fork of the Online Boutique cloud native microservices demo application, which has two services instrumented with the OpenTelemetry SDKs: FrontEnd (in Go) and AdService (in Java).
To learn more about Kubernetes and other cloud native technologies, consider coming to KubeCon + CloudNativeCon North America 2020, Nov. 17-20, virtually.
The Cloud Native Computing Foundation and Amazon Web Services are sponsors of The New Stack.
Feature image via Pixabay.