In the previous subchapters we looked at AWS observability tools: CloudWatch (logs, metrics) and X-Ray (traces). They work very well, but there’s a catch: they are specific to AWS. What if you want a way to instrument your applications that doesn’t depend on a particular provider, so you’re not locked in? That’s what OpenTelemetry is for, the open observability standard that’s becoming the industry’s common language.

When you instrument your application (that is, add code so it emits logs, metrics, and traces) using provider-specific tools, your code becomes tied to that provider. This brings problems:

• If you want to switch observability tools (or use a better one), you have to rewrite the instrumentation.
• In multi-cloud or hybrid environments, each cloud would have its own way to instrument: a mess.
• You get locked in (vendor lock-in): switching is so costly that in practice you can’t.

Remember the concept of portability that we valued so much when talking about containers (Chapter 17) and multi-cloud Terraform (Chapter 10). The same applies to observability: ideally, you’d instrument once and be able to send that data wherever you want.

OpenTelemetry (often abbreviated OTel) is an open standard for generating and collecting observability data (logs, metrics, and traces) in a vendor-independent way. It’s a community project (from the CNCF, the same foundation that maintains Kubernetes) and has become the industry standard.

The central idea: you instrument your application just once using OpenTelemetry, and then you can send that data to any observability tool that understands the standard (CloudWatch, Grafana, Datadog, Jaeger... whatever).

Analogy: OpenTelemetry is like using a standard plug (like USB-C) instead of a different proprietary charger for each device. If all your devices use USB-C, you can plug them into any charger in the world. With proprietary chargers, each device ties you to its brand. OTel is the “USB-C of observability”: you instrument with a standard and plug in wherever you want.

Since you instrument with a standard, you’re not tied to any tool. Want to switch from CloudWatch to Grafana, or try another solution? You just change where you send the data, without rewriting your application’s instrumentation. Your investment in instrumenting the code is preserved.

You use the same way to instrument all your applications, regardless of language (OTel supports many: Python, Java, Go, JavaScript...) or where they run (AWS, another cloud, your own data center). A single standard for your whole ecosystem, which greatly simplifies things.

AWS supports OpenTelemetry and offers its own ready-to-use distribution: AWS Distro for OpenTelemetry (ADOT). It’s the version of OpenTelemetry that AWS provides, tested and supported by them, which lets you:

• Instrument your applications with the OpenTelemetry standard.
• Send that data to CloudWatch and X-Ray (to integrate with the AWS ecosystem).
• Or send it to other tools if you prefer (keeping your freedom).

This way you get the best of both worlds: the open standard (freedom, no lock-in) and easy integration with AWS when you want it.

Real-world example: a company instruments all its applications with OpenTelemetry (via ADOT). Today they send the data to CloudWatch because they’re on AWS. After a while, they decide to adopt a more advanced observability tool used company-wide. Since they instrumented with the standard, they just have to change the destination of the data: not a single line of their application instrumentation code changes. What would have been months of rewriting with proprietary tools, with OpenTelemetry is a configuration change. The company keeps the freedom to always choose the best tool.

• If you want to avoid lock-in and keep the freedom to change observability tools.
• If you work in multi-cloud or hybrid environments and want a uniform way to instrument.
• If your organization has already standardized on OpenTelemetry (more and more companies are doing this).

If you’re just starting out and only use AWS, CloudWatch and X-Ray directly are perfect. But knowing OpenTelemetry prepares you for larger environments and for the direction the industry is heading.

• Instrumenting with provider-specific tools couples your code to that provider and makes switching hard (vendor lock-in); you lose portability.
• OpenTelemetry (OTel) is an open standard for generating and collecting logs, metrics, and traces in a vendor-independent way. It’s the industry standard.
• You instrument just once with OTel and send the data to any tool that understands the standard. Like the USB-C of observability.
• Advantages: vendor independence (change the destination without rewriting) and consistency (one standard for all languages and environments).
• AWS offers ADOT (AWS Distro for OpenTelemetry): use the open standard and integrate with CloudWatch/X-Ray (or with other tools), the best of both worlds.
• It matters if you want to avoid lock-in, work multi-cloud, or your organization has standardized on OTel.

In the last subchapter of this chapter we’ll look at two very powerful managed services for visualizing and querying metrics: Managed Grafana and Managed Prometheus.