That’s why it’s so critical for teams to have visibility into the performance and health of their applications. By funneling streams of telemetry data into an observability platform, teams can gauge whether their applications are performing as intended and address issues as they arise.
However, as we all know, it can be difficult to gain this level of visibility. That’s because it’s complex to collect disparate streams of telemetry data across various systems and transmit them to your observability platform. The distributed nature of cloud-native applications and microservices only adds to this issue.
The shortcoming of vendor-specific observability agents
Organizations have attempted to solve this challenge with distributed tracing, which tracks a request’s journey, paired with logs and metrics to monitor the systems supporting the application. To capture traces, logs, and metrics, however, teams are forced to deploy and manage proprietary, vendor-specific agents from each observability platform — each agent equipped with their own data collection standards and schema.
So, for example, if I’m using Splunk for monitoring logs, SignalFX for metrics and Lightstep for tracing, I’d have to deploy three different agents that don’t talk to one another. Understanding how my application is performing requires me to work across these tools in a disjointed manner.
By using proprietary tools, your app data is also subject to vendor lock-in: if each provider has their own standard, how can you move your data off of one platform and onto another without a ton of manual work? Ultimately, standards should be shared across vendors — both in terms of the structure and the schema of data, as well as the way it’s collected.
Open standards, like OpenCensus and OpenTracing, have been developed to combat this issue. These standards, however, are difficult to scale and hard to maintain as your application needs evolved. That’s why the groups behind these standards merged their efforts and released OpenTelemetry (or “OTel”) as part of the Cloud Native Computing Foundation (CNCF).
What is OpenTelemetry?
OpenTelemetry is a set of APIs, SDKs, tooling, and integrations, offering an open specification across observability vendors. Instead of forcing you to deploy and manage different proprietary agents to capture traces, logs, and metrics, OpenTelemetry aims to consolidate these data streams into a single system. This consistency removes significant friction from the process of capturing and transmitting telemetry data and drives value across observability platforms. By standardizing what telemetry data looks like, OpenTelemetry makes it easier to analyze application performance and mitigate errors. At the same time, it drives data mobility and gives you the freedom to choose the observability platform that is right for your application and use case.
The trajectory of OpenTelemetry moving forward
The OpenTelemetry specification is rapidly evolving and maturing. Earlier this month, OTel contributor, Ted Young announced the promotion of OpenTelemetry to v1.0.01. With this release, the specification can guarantee stability for the tracing components involved. This means that teams can receive updates, new features, and security patches without having to rewrite tracing instrumentation or scripts.
The level of choice offered by OpenTelemetry is also increasing. Initially, OTel supported traces, followed by metrics. In February, observIQ announced that their now open source log agent, Stanza, would be comprised within OpenTelemetry2. This addition gives teams vendor-neutral support for their logs as well, reducing the need for specialized vendors to handle different types of telemetry data. Instead, teams can select an observability platform based on how it fits their application and use case once logging and metrics are stabilized.
OpenTelemetry is gaining significant traction in the developer community and following a trajectory not unlike Kubernetes — CNCF’s most popular initiative to date. This growth reflects the need for an open standard that mitigates vendor lock-in and drives consistency across platforms.
One indicator of OpenTelemetry’s growth and popularity is the attention it is getting from software and cloud vendors. Nine vendors support OTel natively in their commercial products and six currently offer distributions: AWS, Elastic, Lightstep, New Relic, Splunk, and Sumo Logic3. This point is worth highlighting because it emphasizes that vendors see value in moving away from their own proprietary agents and adopting a common standard.
How EdgeDelta is supporting OTel users
At the core of OpenTelemetry is the notion that technology and telemetry should be open and standardized in order to maximize value for its users. Edge Delta shares this vision, which is why we offer a vendor-agnostic solution.
Our observability pipeline natively integrates with all commonly used observability platforms and offers pre-built processors that are optimized for OpenTelemetry — both from a data collection standpoint, as well as data format and schema. These allow you to process the telemetry data coming off the source prior to being centralized for monitoring on your given platform, while automatically extracting and tagging the useful information based on the open standards and schemas.
By routing your data through Edge Delta, you can increase the speed at which you respond to application issues, lower your storage and compute costs, and unlock advanced capabilities by automatically capturing optimized data points. These benefits deliver a seamless experience as you embrace OTel, enabling you to get the most value out of your telemetry data.
If you are interested in learning more about what Edge Delta is doing to embrace the future of OpenTelemetry, don’t hesitate to shoot me a message at firstname.lastname@example.org, on LinkedIn, or get started with a free trial today!