Now more than ever, customers expect relevant and personalized digital experiences, no matter where they are, and on the device of their choosing. That’s why technology leaders around the world tell us that there’s no greater priority than full-stack observability to drive digital transformation. The reasons are clear: Digital technologies represent radically new ways of delivering value to customers, disrupting competitive landscapes, and changing the underlying economics of markets.
Rapid innovation prompts the need for better solutions
Technological change is nothing new, but this round of change is happening at a rate faster than ever before. To deliver on these digital transformations, new approaches have emerged to enable faster innovation, such as Cloud technologies, containers, and orchestration engines like Kubernetes, microservices, serverless, and DevOps with CI/CD automation, SRE, and on-call developers to name a few.
Technology complexity reaches new heights
A consequence of these rapid changes is increased technical complexity, which is why making sense of such highly dynamic and distributed systems presents new challenges. This was the bedrock for the recent emergence of Observability and where OpenTelemetry comes in to help.
OpenTelemetry will manage that complexity and diversity
OpenTelemetry is a vendor-neutral standard way to collect telemetry data for applications, their supporting infrastructures, and services. It’s now promoted to a Cloud Native Computing Foundation incubating project since its inception in May 2019 with the merger of OpenCensus and OpenTracing projects. Most of the standard has reached 1.0 stage. Spans and traces are the most advanced for now, automated instrumentation, and additional languages are in active development, and logs are planned for a later date.
OpenTelemetry is an important milestone, making it easier for providers and users alike to collect data from a broader set of systems and get a more complete picture of how applications behave and why. Today’s challenge shouldn’t be about getting telemetry data –whether that’s metrics, events, logs, or traces (also known as M.E.L.T.) — but to relating how the infrastructure (whether compute, storage or network) and supporting services (as service meshes) influence the application’s health, and ultimately, the user experiences delivered and the impact they have on business.
That’s what AppDynamics has been focusing on for years: understanding where problems come from, why they happen and relating how technical problems impact user experiences and business outcomes to set the right priorities of actions. As a consequence, we welcome OpenTelemetry as a data ingestion standard which will make it even easier to get visibility into a broader set of systems and enrich our traditional AI and ML capabilities to help make sense of that vast array of data.
How does OpenTelemetry work (in a nutshell)?
OpenTelemetry covers many components, including the following:
- APIs are used to instrument your code to generate traces, i.e. the components parts that make calls and exchange information with other parts. This can be performed via code change or auto-instrumentation agents (which is less mature for now). Most libraries are expected to come with OpenTelemetry capabilities out of the box in the not-too-distant future.
- SDKs to collect such data and pass it to the processing and export stages.
- In-process exporters, running with the application, can translate the telemetry data into custom formats and send directly or through a collector to back-ends, whether Open Source as Jaeger or Zipkin, or from commercial providers. The in-process exporter approach is language-specific and is the main approach used so far since it was the first one to be mature.
- The out-of-process collector is used for data filtering, aggregation, batching, and communication with various telemetry backends. This communication is performed either via vendor-specific exporters or standard OpenTelemetry OTLP exporters.
We’re working on making AppDynamics’ backend OTLP compliant and support both:
- Our recommended out-of-process collector standard so our customers can use the bundled OpenTelemetry OTLP exporters to minimize the risk of relying on multiple specific in-process exporters which might get out of sync with the rapidly evolving OpenTelemetry standard and to support all existing and upcoming languages at once.
- In-process standard OTLP exporters if you don’t have the possibility to deploy a dedicated collector.
This is obviously an oversimplified introduction; see the OpenTelemetry documentation for more details.
OpenTelemetry will accelerate innovation through standardization
By alleviating the burden of collecting data from diverse technologies, OpenTelemetry will allow observability and monitoring solution providers to focus more of their efforts on capabilities to relate the data across domains (i.e., understand how a compute element interacts with the storage and network ones), understand the impact on the application health, and ultimately, the delivered user experiences and business outcomes.
This blog may contain product roadmap information of AppDynamics LLC (“AppDynamics”). AppDynamics reserves the right to change any product roadmap information at any time, for any reason, and without notice. This information is intended to outline AppDynamics’ general product direction, it is not a guarantee of future product features, and it should not be relied on in making a purchasing decision. The development, release, and timing of any features or functionality described for AppDynamics’ products remain at AppDynamics’ sole discretion. AppDynamics reserves the right to change any planned features at any time before making them generally available as well as never making them generally available.
Erwan Paccard has been Director, Product Marketing at AppDynamics since 2017. He knows the APM and observability market well with over 10 years in the space across various companies. Over the span of his 24 years career in the tech industry as product manager and product marketer, he has worked for companies like Dynatrace and IBM, developing and architecting a range of their products.