“Everything Looks Fine on Our Side”: Why We Need OpenTelemetry

When an application slows down, technical teams usually start by checking their own systems. The application team looks at logs, the database team reviews queries, and the infrastructure team checks CPU and memory usage.

The results come back: servers look healthy, there is no obvious database issue, and the services are running.

Meanwhile, the customer is still waiting on the payment screen.

More people join the call. Screens get shared. Someone asks, “What time did it happen?” for the third time. Someone else suggests bringing in the network team.

If you have been in that meeting, you already know the problem OpenTelemetry is trying to address.

What Is OpenTelemetry?

OpenTelemetry, or OTel, is an open-source framework and toolkit for generating, collecting, and exporting telemetry data such as traces, metrics, and logs. This data helps teams understand how their applications behave.

It is vendor-neutral. It provides a common foundation so that the telemetry your application produces can be used with different compatible observability platforms.

OpenTelemetry itself is not a dashboard or an APM product. You still need an observability backend to store, visualize, and analyze the data. (opentelemetry.io)

We Can See Every Component. Can We Follow the Whole Transaction?

A customer clicking a single button can trigger a surprising amount of work. The application checks the cart, calculates discounts, queries inventory, contacts a payment provider, and saves the order.

These steps may run in different applications. Some are in the cloud, others are on premises. Different teams may own them.

Each application has its own records. Following the same transaction across all of them is not always straightforward. When those records live in different tools, part of the investigation becomes a manual exercise in matching timestamps and transaction IDs.

OpenTelemetry supports correlating traces, logs, and metrics through shared context. With the necessary instrumentation and context propagation in place, teams can investigate the steps of a single request across multiple services. (opentelemetry.io)

Finding the customer’s payment request and seeing which call took too long is a better starting point than comparing ten screenshots on a conference call.

Traces, Logs, Metrics… Weren’t We Already Collecting Those?

We were. OpenTelemetry did not invent them.

Metrics help us spot changes in the system. Have response times increased? Is the error rate rising? Has memory usage changed?

Logs provide details about what happened at a particular moment. This is where we find error messages and events recorded by the application.

Traces show the steps a request went through and how much time each step took. They are particularly useful for investigating delays when a transaction spans several services. (opentelemetry.io)

When these signals are correlated, you can move from a rising error rate to an affected request, then to the failed call within that request and its associated logs.

Putting three charts on the same screen does not establish that connection. The underlying data needs to let you connect the observations to the same transaction.

Google, Microsoft, and AWS Are Involved Too

OpenTelemetry is supported beyond the open-source community. Major cloud providers include it in their products and official instrumentation guidance.

Google Cloud recommends OpenTelemetry for instrumenting applications for Cloud Trace. Its documentation describes sending data to Google Cloud through the OpenTelemetry Protocol, or OTLP, either directly or through a Collector. (docs.cloud.google.com)

Microsoft offers OpenTelemetry-based distributions for Azure Monitor and Application Insights. It recommends an OpenTelemetry-based approach for new Application Insights projects, citing vendor neutrality and consistent APIs across languages among its reasons for investing in the project. (learn.microsoft.com)

AWS offers AWS Distro for OpenTelemetry, or ADOT. Metrics and traces collected through ADOT can be sent to AWS X-Ray, CloudWatch, and other supported monitoring solutions. (docs.aws.amazon.com)

Support from all three matters. Applications can adopt a common approach to producing telemetry, while the choice of where to analyze that data remains a separate decision.

Second Only to Kubernetes—By Which Measure?

You may have heard OpenTelemetry described as having “the largest community after Kubernetes.” It is worth being specific about the measure.

According to CNCF’s May 2026 announcement, OpenTelemetry ranks second only to Kubernetes in project velocity. Since the project began, more than 12,000 contributors from over 2,800 companies have participated. The same announcement confirmed that OpenTelemetry had reached CNCF’s Graduated maturity level. (cncf.io)

Participation at this scale makes sense. We may use different technologies, but we keep asking similar questions: Why did the application slow down? Where did the error start? Which transactions were affected?

Having teams and tool vendors work on a common foundation can reduce the need to build separate telemetry collection approaches for each product.

Why Should Changing a Monitoring Tool Become an Application Project?

You may be happy with your current observability platform. A few years from now, your requirements or budget might change. You might want to try another one.

If application instrumentation is tightly coupled to a single product, that decision can lead to new agents, SDK changes, and another round of application testing.

OpenTelemetry helps separate telemetry generation from the platform used to analyze it. Sending data to another compatible backend can reduce the need to instrument the entire application estate again. (opentelemetry.io)

Dashboards, alerts, and platform-specific queries may still require migration work. But keeping the application’s instrumentation investment is a meaningful advantage.

We Installed It. Are We Done?

Not yet.

Automatic instrumentation can provide a quick starting point for supported technologies. Coverage depends on the language, libraries, and runtime environment. Application-specific business steps may require additional instrumentation. (opentelemetry.io)

Seeing that a database call took three seconds is one thing. Understanding which business rule caused an order to wait is another. To answer the second question, the application needs to emit the relevant information.

Starting with one critical transaction can make adoption more manageable. Take order creation, for example. Follow the request through the services, identify gaps in visibility, and correlate the relevant error logs. Then expand the coverage.

Your first goal does not have to be hundreds of dashboards for the entire system. When a real issue occurs, can you find where that transaction got stuck? Start there.

You may still need a meeting when the next performance issue happens. But this time, everyone saying “Everything looks fine on our side” can open the same trace and investigate it together.

At least you will have somewhere to look before calling the network team.