May 10, 2026

Why OpenTelemetry? Plug-and-play observability with strong semantics

OTel works with every observability backend out of the box, and Dartastic uses typed enums for semantic conventions so you stop typoing keys at 3am. Here's why both matter.

Why OpenTelemetry?

If you have to pick one thing about OpenTelemetry to internalize, pick this:

Instrument once. Send your data wherever you want.

That's the entire pitch. Every observability vendor before OTel had its own SDK, its own agent, its own tagging conventions. Switching vendors meant rewriting your instrumentation. OpenTelemetry kills that lock-in, and that's why your CI is full of opentelemetry-* packages now.

But there are two specific things that make OTel particularly worth adopting on Dart and Flutter, and they're worth spelling out separately.

1. Plug-and-play across every backend

OpenTelemetry defines a wire format — OTLP — that every observability backend either speaks natively or accepts via a one-process collector. That includes:

  • Open-source self-hosted: Jaeger, Prometheus, OpenSearch, and the broader OSS observability ecosystem
  • Cloud-native: Google Cloud Operations (Cloud Trace / Cloud Logging / Cloud Monitoring), AWS X-Ray, Azure Monitor
  • Vendors: Honeycomb, Datadog, New Relic, Splunk, Dynatrace, Lightstep, Sentry — every major one

You instrument your Dart server or Flutter app once with OTel APIs. You point an environment variable at whichever of those you want today. You change your mind in six months and point the same variable at a different one. Your code doesn't change.

That last sentence is the unlock. The cost of switching observability vendors used to be measured in engineer-quarters of re-instrumentation. With OTel it's measured in deployments.

For a Dart shop using Dartastic, this is concrete: a Flutter app's traces flow into your in-house OSS stack today, into Honeycomb tomorrow, into your enterprise customer's Datadog the day after — without a Flutter code change. The same is true on the server side.

2. Strong semantic conventions

Plug-and-play is necessary but not sufficient. The thing nobody tells you is that 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 key for HTTP method. db.system.name is the key for the database product. service.name is the key for, well, the service name.

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.

The catch: until OTel published this registry, every team made up its own keys. httpMethod, http_method, method, request.method, RequestMethod — all the same data, all incompatible. Three years into a rapidly-growing service, switching to the standard names is a non-trivial migration.

Dartastic was built after the registry stabilized, so we did one thing other OTel SDKs don't: we 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. It's the smallest possible quality-of-life win and we believe it'll save you a real bug.

3. (Bonus) it works with what you already have

If your team has a Prometheus-based stack, OTel slots in. If they have Datadog, OTel slots in. If they have a homegrown OpenSearch setup, OTel slots in. There is no "you must move off your current stack" prerequisite.

That's also true on the data side. OTel collectors can re-emit data to multiple backends in parallel — useful for migrations, A/B comparisons, or having a self-hosted free-tier backend alongside a paid vendor for higher-fidelity drilldown. Dartastic's open-source SDK and Pro libraries both speak OTLP; routing is the collector's problem.

Where Dartastic fits

dartastic_opentelemetry is the spec-compliant Dart implementation. It works with every backend above. Its semantic-convention enums catch the typo class of bugs at compile time. It's the funnel for everything else we do at Dartastic.io — and it's Apache 2.0, no asterisks.

Read more: Why Telemetry? · Pricing · Documentation

All posts opentelemetryplug-and-playsemantic-conventions