 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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:
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.
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.
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.
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.
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.
