Where OpenTelemetry fits on a long engagement.

Instrumentation is the expensive, long-lived part of observability; backends are the part organisations change. Instrumenting against a vendor SDK couples years of work to a commercial decision, and re-instrumenting an estate to change vendor is a project nobody wants to fund. OpenTelemetry decouples the two.

Auto-instrumentation gets a useful baseline quickly — HTTP, database and framework spans with no code changes — but it does not know your domain. The spans and attributes that answer business questions, like which tenant or which plan a slow request belonged to, have to be added deliberately.

What an assigned team does with OpenTelemetry.

The collector is where most of the operational work sits. Sampling, filtering, enrichment and routing all happen there, and it needs to be sized and monitored like any other production component rather than treated as plumbing.

Running it properly is standing platform work, assigned alongside the services it observes under devops managed services.

What we use OpenTelemetry for.

  • Instrumentation that outlives the vendor One standard, so changing backend is a configuration change rather than a re-instrumentation project.
  • A baseline without code changes Auto-instrumentation for framework and database spans, in place quickly.
  • Domain attributes that answer real questions Tenant and plan on spans, so "slow for whom" is answerable.

How OpenTelemetry capacity is assigned.

Instrumentation outlives both the people who wrote it and the vendors it reports to, which is why continuity on the platform discipline matters. That is what a dedicated development team is for.

Tell us what your roadmap needs OpenTelemetry for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

Loading the contact form… You can also email hello@azendo.co.

We reply within one working day. No obligation, and no newsletter.