This article details many compelling reasons why OpenTelemetry should be used in software.

Read "Why Telemetry?" for the history of telemetry from the 19th century to the present day in diverse areas including military, weather, healthcare, and spacecraft, finishing with software telemetry and how the OpenTelemetry Project came into existence.

Before discussing the whys, let's lay out what OpenTelemetry is.

What is OpenTelemetry?

OpenTelemetry (OTel) is the industry standard for software observability. It is a framework and toolkit for transmitting telemetry data in the form of distributed traces, metrics and logs, while tying them together.

For a deeper dive, see the OpenTelemetry documentation What is OpenTelemetry?. The OpenTelemetry documentation is excellent and very approachable.

The 3 Signals of OpenTelemetry

Signal	Best For
Traces	Understanding a single request end-to-end
Metrics	Detecting trends and alerting
Logs	Detailed diagnostic information

Profiles is a new 4th Signal, it is still in alpha and beyond the scope of this article.

OpenTelemetry Components

OpenTelemetry consists of:

• The comprehensive OpenTelemetry Specification
• A standard protocol - OTLP - "OpenTeLemetry Protocol" with two transport flavors, each supporting optional gzip compression:
  • OTLP/gRPC
  • OTLP/HTTP
• Semantic Conventions that define a standard naming scheme for telemetry data.
• Language SDKs for 16 languages.
• The OpenTelemetry Collector, a proxy that receives, processes, and exports telemetry data. It's stable, performant, extensible and very easy to use.
• A library ecosystem that implements instrumentation for common libraries and frameworks. For Dart and Flutter, Dartastic.io maintains Dartastic Labs which includes 50 open source otel_* packages available on pub.dev for common open source packages like logger, state management libraries and shelf; and 600 OTel instrumenters for common commercial packages.
• Tools and utilities like Kubernetes Helm Charts and FaaS helpers.

Want to Dive Right Into Open Source Code?

If you prefer to dive into open source OTel code, start with the Dart OTel Reference Demo. It has a set of apps for Flutter, Dart CLIs, Dart Functions, and Dart Containers, along with a local open source observability stack that demonstrates distributed traces, metrics, and logs, all running locally.

Dive Into Professional OpenTelemetry

Those who ship professional apps, or plan to, would be well-served by signing in to Dartastic.io and downloading the Dartastic OTel Reference Demo from the dashboard. It has additional demos of advanced native OTel that Dart can't do: identification of janky widgets, crash detection and symbolization, metrics for iOS & Android including battery and thermal state, Linux metrics, and dashboards for release health, user experience and more in Dartastic Observatory. Dartastic Cloud Observatory comes with a 7-day free trial.

Why Use OpenTelemetry?

There are many reasons to use OpenTelemetry. This article will discuss them with a focus on Dart and Flutter.

Let's start with some use cases pertinent to Dart server and Flutter apps.

Don't Fly Blind - Especially in Mobile

Telemetry is an essential component of any software system that supports users - clients and servers. Without being able to observe a running application:

• How do you know when your app is crashing?*
• How do you know if any of your widgets are janky?*
• How do you know which devices are working well and which are having problems?
• How do you determine what parts of your app get the most use? The least?
• How can you determine if your new release is producing new errors?
• How can you tell which user flows are smooth and which are creating friction?
• How can you tell why users abandon your app before subscribing?
• How do you know when a third-party service (e.g., AI, Stripe, Maps) is failing on user devices?
• How do you know if your app is using excessive CPU or RAM?*
• How do you know if your app is draining the user's battery?*

The answer is simple: without telemetry, you can't know. You are flying blind.

^* Supported with Dartastic Native OTel, not possible with open source dartastic_opentelemetry.

YAGNIA - "You're Gonna Need It Anyway"

YAGNI - "You aren't gonna need it" - is the tried-and-true admonition against building things before you need them. OpenTelemetry presents a compelling opposite:

YAGNIA - "You're gonna need it anyway."

Standards Make Software Better

You're not still using one of these, are you?

Or maybe you still have some of these?

Software or hardware, standards make life easier:

• Standards open up interoperability.
• Standards reduce waste.
• Standards reduce complexity.
• Standards reduce costs.

OpenTelemetry is the new observability standard. Like a USB-C cable, you're gonna need it anyway. The faster you adopt the standard, the lower the cost and the faster you open up interoperability with other systems.

If you use a proprietary observability SDK, then you have an unscheduled migration.

Your Timing Is Impeccable

OpenTelemetry reached Graduated maturity status in the Cloud Native Computing Foundation (CNCF) on May 11, 2026. Graduation is the CNCF’s highest maturity level and recognizes projects with a proven governance model, a healthy and diverse contributor community, strong security practices, and widespread production adoption.

OTel Is Everywhere

Language Support

Dart arrived late to the OTel party. Dart is the last of the 16 targeted languages to get an OTel SDK. The other 15 are: C++, C#/.NET, Erlang/Elixir, Go, Java, JavaScript, Julia, Kotlin, Lua, Perl, PHP, Python, Ruby, Rust and Swift.

Hyperscaler Support

The hyperscalers all support OpenTelemetry.

Google Cloud

From the announcement: "As part of our commitment to open standards, Google Cloud is deeply invested in making OpenTelemetry the universal client, data format, and set of standards for telemetry data."

OTLP is supported by Google Cloud Observability. "Sending trace data using OTLP via telemetry.googleapis.com is now the recommended best practice for both new and existing users — especially for those who expect to send high volumes of trace data."

AWS

AWS supports OpenTelemetry via the AWS Distro for OpenTelemetry (ADOT) at its foundation. See AWS Best Practices for Observability with OpenTelemetry and AWS Cloud Operations Blog post: "Adding metrics and traces to your application on Amazon EKS with AWS Distro for OpenTelemetry, AWS X-Ray and Amazon CloudWatch."

Azure

Azure supports OpenTelemetry via Azure Monitor across Azure Kubernetes Service, virtual machines, Virtual Machine Scale Sets and Azure Arc-enabled servers.

Observability Vendor Support

Most if not all observability vendors have resources working on the OpenTelemetry Specification. It's truly a universal effort.

Most new observability vendors are OTel-native, built specifically around OpenTelemetry: SigNoz, Uptrace, ClickHouse/ClickStack, and Dash0.

Many vendors are OTel-first and OTel-centric including: Honeycomb, Elastic, Grafana, Langfuse (LLM observability), Observe, Inc and OpenObserve.

Most legacy vendors have mixed support for OpenTelemetry. Many support their current customers with their own proprietary protocols and semantics while adding OTLP, usually through their proprietary SDKs, including Datadog, Dynatrace, IBM Instana, New Relic, Splunk and Sentry.

Which brings us to...

Avoiding Vendor Lock-in

Perhaps the strongest reason to adopt a standard is to preserve your freedom of choice. Once Apple was forced to adopt USB-C, you could buy your iPhone cable from any vendor, not just Apple or Apple's licensees. TCP/IP broke strangleholds in the home (CompuServe, Prodigy, AOL) and the office (IBM SNA, DECnet, IPX/SPX). HTML standards broke websites free from specific browsers (IE) and runtimes (Flash).

OpenTelemetry does the same thing for observability. Your application is instrumented once using a standard API. You can change your telemetry vendor by changing one standard configuration variable (OTEL_EXPORTER_OTLP_ENDPOINT).

You can port your application or Docker container to another cloud - Google Cloud, Azure Monitor, AWS CloudWatch - or take it in-house or hybrid and be assured that your observability will stay the same. No rewrite is necessary.

Instrument once, telemetry everywhere.

Become Open to Integration and Extend Distributed Tracing

No application is an island. Every mobile app has a backend. Even a small business may rely on separate systems for accounting, inventory, CRM, content management, and its core business operations. Larger enterprises can have hundreds of microservices spanning on-prem or multiple clouds. Apps may be built in silos. They may have their own proprietary telemetry. More typically, observability is consistent within an organization. Still, until recently, Flutter mobile apps and Dart backends had to use proprietary observability SDKs, if any existed at all. That is, until dartastic_opentelemetry.

The killer feature of OpenTelemetry is distributed tracing. The standard defines how a single user action can be tracked as a unified trace across all processes that were used to serve the request.

Here's an example from the Dart OTel Reference Demo.

Even in this simple contrived example we can follow the user's actions:

• The user clicks the "Get Weather" button on the Flutter app (weather-flutter is the tracer's service name).
• The click calls the fetchWeather method, which then makes an HTTP GET call.
• The weather-api tracer service reports a call to the /weather/:city endpoint on the server.
• The weather-api geocodes the city, first checking the cache-service to see if it was already geocoded.
• Since no geocode is found, the weather-api makes a POST to create a new weather entry.
• That in turn checks the cache-service for the weather for that geocode.
• The server then calls out to Open-Meteo to get the forecast, and returns it to the Flutter client.

The more you add OpenTelemetry to your apps and services, the deeper your distributed traces get. No more islands, no more observability silos.

Metrics - Detecting Problems Before Customers Do

Distributed traces tell you what happened to a specific request. Logs tell you why it happened. Metrics tell you when something is starting to go wrong.

With OpenTelemetry metrics, you can answer questions like:

• Is the error rate increasing?
• Did response times get slower after the last release?
• Which Flutter screens are becoming janky?
• Is battery usage increasing on Android 16?
• Which API endpoint consumes the most CPU?
• How many users are active right now?
• How many orders were processed today?
• Are subscription rates growing?
• Is memory usage increasing?

Unlike logs and traces, metrics let you watch your system’s health continuously. They are the heartbeat of your application.

Metrics are aggregated and inexpensive to collect. They can be retained for months or years, making them ideal for dashboards, alerting, capacity planning and release monitoring.

Metrics and Traces Work Better Together

Metrics tell you that a problem exists. Distributed traces tell you which requests experienced it.

Suppose your dashboard shows that p99 latency suddenly doubled at 2:17 PM. Without traces, you only know that something is wrong. With OpenTelemetry Traces, one click takes you from the latency chart directly to the slow traces, where you can see the exact database query, HTTP request, or third-party service responsible.

Metrics smell smoke. Traces point you to what’s burning.

Make Logs More Powerful

OpenTelemetry distributed traces make logs more powerful by giving them context. Note the "Log" icons for each step in the weather trace image in the distributed tracing section above. Clicking on one of the icons presents the logs for that step in the trace.

Logs with Trace context save countless hours vs. scouring raw log output.

Mobile Device Log Streaming

It's impossible to legitimately shell into a customer's mobile device. Many apps simply silence mobile logs in production, leaving a fleet of black boxes. Leave those logs on. With OpenTelemetry, mobile logs are routed to an OpenTelemetry collector on a server and are tied to the distributed trace for each interaction. By filtering by user.id and screen.name (semantic conventions — see the next section), for example, you can support a specific customer who reported trouble on a specific screen.

Furthermore, OpenTelemetry Resources are also tied to traces, metrics and logs. The user's device.id and app.build_id can be used for troubleshooting.

Strong Semantic Conventions

Plug-and-play portability is necessary but not sufficient. What your spans are called and what attributes they carry matters as much as where they're sent.

OpenTelemetry publishes a registry of semantic conventions — standard names for the attributes and metric units everyone should use. http.request.method is the attribute name for an HTTP request's method. db.system.name is the attribute name for a database product. It's host.name, not hostname, everywhere. Every system, every company, every year. Investments in learning OTel pay off in the short run and the long run.

When everyone uses the same keys, the value compounds:

• A dashboard that filters spans by http.response.status_code works on any service from any team.
• An alert rule that fires on error.type works for any error in any language.
• A trace search for user.id finds every span from a single user across your whole stack.

Without a convention, every team makes up its own keys. httpMethod, http_method, method, request.method, RequestMethod. Searching and filtering are a nightmare.

Dartastic was built after the semantic conventions stabilized, so we did one thing other OTel SDKs don't: dartastic_opentelemetry made the semantic conventions enforceable at the type level.

// In Dartastic, attribute keys are enums — typo-impossible.
span.setAttribute(HttpResource.httpRequestMethod, 'POST');
span.setAttribute(ServerResource.serverAddress, 'api.example.com');

Compare to the typical OTel SDK:

// Strings everywhere. One typo and your dashboard quietly breaks at 3am.
span.setAttribute('http.request.metohd', 'POST');  // 🐛 typo

Dart is the only OpenTelemetry language with an enum-based semantics API at the time of writing.

DevEx and DevOps in the Age of AI

A standard API across all languages, a standard transport, protocol and format, standard semantic conventions, Traces tied to Logs and Metrics — add it all up and it's easy to see how OpenTelemetry is a feast for AI.

When you point your AI at your OpenTelemetry Traces, Metrics and Logs, it diagnoses problems in a snap, with real data. No guessing, no hallucinating, no endless token spends on code inspection for one bug.

Here's Claude, after being reminded to follow the telemetry first when debugging.

Likewise, AI agents can diagnose issues, and even fix them, by inspecting structured OTel Traces, their associated Logs and Metrics.

The power of OpenTelemetry is also available on the developer's laptop. Your app might be sending OTel to an expensive backend in production, but with a config change, you can spin up a local Grafana-LGTM stack and use telemetry locally, even while offline. Combined with your favorite coding agent, you'll be more productive than ever. Get started by cloning the Dart OTel Reference Demo or logging in to Dartastic.io and downloading the Dartastic OTel Reference Demo.

Developers can build tests around OpenTelemetry. Perform an action and assert that a span with an Ok StatusCode was emitted.

Stability

The OpenTelemetry project has a formal stability specification. Once a signal reaches Stable (1.0), it comes with compatibility guarantees. That means:

• The API is not allowed to introduce breaking changes.
• The SDK follows the same compatibility rules.
• The OTLP wire protocol is stable and backwards compatible.
• Semantic conventions become versioned rather than silently changing.
• New capabilities are added without breaking existing instrumentation.

The philosophy is essentially: 1.0 means forever.

For that reason, pre-1.0 releases are usually production-worthy long before becoming stable.

Stability is often granted per signal within a release. For example, both Ruby and Swift have stable Traces but beta Metrics and Logs. That doesn't mean Metrics and Logs aren't ready for production, but it does mean that breaking changes are still allowed. Dartastic marks breaking changes with @Deprecated in a release before removal.

Looking for an Exit?

The end game for many companies is to get acquired. Using widely adopted standards reduces acquisition risk. During technical due diligence, the acquirer’s engineers will evaluate your architecture, dependencies, operational maturity, and technical debt. Every proprietary technology stack represents additional complexity, risk, and integration effort. By building on OpenTelemetry, your observability platform changes from a liability that raises questions to an asset that fits naturally into the acquirer’s existing ecosystem.

Looking for Better Work?

OpenTelemetry and observability are appearing in more and more job descriptions. Knowing observability, specifically OpenTelemetry, separates a candidate from the pack. Eventually, it will be table stakes for mid- and senior-level roles.

Why Dartastic.io?

dartastic_opentelemetry is the open source spec-compliant Dart implementation. It has a familiar API for Dart developers. Its semantic-convention enums catch the typo class of bugs at compile time. It's very high quality and well tested. Still, it's limited to what Dart can do.

Dartastic Native OTel passes all the tests of its open source sibling but does things Dart can't do:

• Identifies janky widgets.
• Reports native crashes.
• Reports metrics for all Dart and Flutter platforms.
• Detects Application Not Responding (ANR) conditions.
• Takes OTel processing off the main Dart isolate onto Rust threads.

Dartastic Pub is not just a community offering. With source code alongside OTel, Dartastic Symbolizer can automatically take OTel error spans with obfuscated error data and convert them into stack traces with Dart source code lines. It's more secure than other solutions since symbol files never leave the distribution — there's no separate symbol upload step to an observability vendor.

Dartastic Observatory is the only full-featured observability backend where Flutter is a first-class citizen. With simple pricing by box size, bills are predictable and without surprises.

Conclusion

Using OpenTelemetry is a no-brainer. It's a stable standard - You're Gonna Need It Anyway. It levels up Ops, DevOps, Development and Customer Service with new power and capabilities.

---

Read more: Why Telemetry? · Pricing · Documentation