---
title: "OpenTelemetry | Skills We Assign For | Azendo"
description: "OpenTelemetry for vendor-neutral instrumentation — one standard, portable backends, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/opentelemetry/"
---

[Skills](https://azendo.co/skills/) Observability 

# OpenTelemetry.

OpenTelemetry is a vendor-neutral standard and toolkit for generating traces, metrics and logs. Applications instrument once against the standard and export to whichever backend the organisation uses, without changing application code to switch.

## 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](https://azendo.co/services/cloud-and-devops/).

## 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](https://azendo.co/services/dedicated-development-team/) is for.

## Roles we assign OpenTelemetry for

* [Site Reliability Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/site-reliability-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in observability

* [SLO and error budget design — skill we assign for](https://azendo.co/skills/slo-and-error-budget-design/)
* [Prometheus — skill we assign for](https://azendo.co/skills/prometheus/)
* [CloudWatch — skill we assign for](https://azendo.co/skills/cloudwatch/)
* [PagerDuty — skill we assign for](https://azendo.co/skills/pagerduty/)
* [Observability — skill we assign for](https://azendo.co/skills/observability/)
* [Sentry — skill we assign for](https://azendo.co/skills/sentry/)
* [Logging — skill we assign for](https://azendo.co/skills/logging/)
* [audit logging — skill we assign for](https://azendo.co/skills/audit-logging/)

## 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.

[All skills we assign for](https://azendo.co/skills/)