OpenTelemetry graduado na CNCF e o que isso significa

Q: O que significa um projeto ser graduated na CNCF?

É o nível máximo de maturidade da Cloud Native Computing Foundation. Para alcançá-lo, o projeto precisa comprovar governança aberta, adoção em produção em larga escala e passar por auditoria de segurança independente. Kubernetes, Prometheus e Envoy também são projetos graduados. O selo indica que a fundação considera o projeto confiável para ambientes críticos.

Q: O OpenTelemetry substitui meu APM como Datadog, New Relic ou Dynatrace?

Não diretamente. O OpenTelemetry padroniza a instrumentação e o transporte da telemetria, não o armazenamento e a visualização. Você continua precisando de um backend para guardar e analisar os dados. A diferença é que, instrumentando com o padrão aberto, você escolhe e troca o backend sem reinstrumentar a aplicação. A maioria dos APMs citados já consome OTLP.

Q: Todos os quatro sinais já estão estáveis?

Não. Traces, metrics e logs têm especificação estável e são considerados production ready, embora a maturidade dos SDKs varie por linguagem. O quarto sinal, profiles, ainda está em desenvolvimento na especificação. A graduação é do projeto como um todo, não de cada sinal isoladamente.

Em 21 de maio de 2026, durante o Observability Summit em Minneapolis, a Cloud Native Computing Foundation anunciou que o OpenTelemetry alcançou o status de projeto graduated. É o nível mais alto da CNCF, o mesmo do Kubernetes, Prometheus e Envoy, e sinaliza que o projeto atingiu a maturidade técnica e de governança exigida para os ambientes mais críticos. A jornada levou sete anos, desde a fusão de OpenTracing e OpenCensus em 2019, passando pela incubação em 2021, até a graduação em 2026.

Este artigo abre a masterclass de OpenTelemetry explicando o que a graduação significa na prática. Não é apenas um selo de comunidade. A graduação remove a principal objeção que sobrava contra a padronização da observabilidade: a percepção de imaturidade. Para arquitetos, SREs e times de plataforma, a decisão entre um APM proprietário e o padrão aberto ganhou um novo dado de peso. Vamos detalhar os critérios atendidos, o estado dos quatro sinais e o impacto direto nas suas decisões de stack.

Insights

A CNCF anunciou em 21 de maio de 2026 a graduação do OpenTelemetry, o nível máximo de maturidade da fundação, consolidando o padrão como referência de facto para observabilidade.
A graduação não foi automática. O projeto passou por auditoria de segurança independente, revisão dos componentes do Collector e revisão formal de governança.
O OpenTelemetry é o segundo projeto de maior velocidade entre mais de 240 da CNCF, atrás apenas do Kubernetes, com mais de 12.000 contribuidores de mais de 2.800 empresas.
Três dos quatro sinais estão estáveis na especificação. Traces, metrics e logs são production ready, enquanto profiles, o sinal de continuous profiling, ainda está em desenvolvimento.
Para quem decide arquitetura, a graduação muda o cálculo de risco. Adotar o padrão aberto deixou de ser aposta e passou a ser a escolha conservadora.

O anúncio

A CNCF formalizou a graduação do OpenTelemetry em 21 de maio de 2026, durante o Observability Summit, em Minneapolis. A decisão de graduação partiu do Technical Oversight Committee (TOC) da fundação, o órgão responsável por aprovar a promoção de projetos. A frase escolhida pela CNCF resume a intenção: “solidifying status as the de facto observability standard”.

O termo graduated tem peso específico na CNCF. A fundação organiza seus projetos em três níveis de maturidade, e a graduação é o topo dessa escala. Não é uma medalha simbólica. É um atestado, baseado em critérios auditáveis, de que o projeto pode sustentar cargas de produção em larga escala com governança sólida.

Chris Aniszczyk, CTO da CNCF, foi direto na avaliação: “OpenTelemetry’s graduation solidifies it as the essential, unified observability standard”. Do lado do projeto, Ted Young, um dos cocriadores e hoje na Grafana, descreveu o momento como o início de uma nova fase, em que a padronização destrava técnicas de observabilidade antes inviáveis.

Os três níveis de maturidade da CNCF

Para entender o que a graduação representa, é preciso conhecer a escala. A CNCF classifica projetos em três estágios progressivos.

flowchart LR
    A[Sandbox] --> B[Incubating]
    B --> C[Graduated]
    A -.- A1[Projetos experimentais<br/>e em estágio inicial]
    B -.- B1[Adoção crescente<br/>e processos maduros]
    C -.- C1[Pronto para produção<br/>em larga escala]

O sandbox recebe projetos experimentais. O incubating exige adoção comprovada e processos definidos. O graduated impõe a barra mais alta: governança aberta, comunidade diversa e, crucialmente, evidência independente de segurança. Chegar ao topo significa que a fundação assume publicamente que o projeto é uma fundação confiável para construir.

A jornada de sete anos até a graduação

O OpenTelemetry nasceu da fusão de dois projetos concorrentes, OpenTracing e OpenCensus, que resolviam o mesmo problema de formas incompatíveis. A unificação eliminou a fragmentação e criou um padrão único de instrumentação.

timeline
    title Jornada do OpenTelemetry na CNCF
    2019 : Fusao de OpenTracing e OpenCensus
         : Aceito na CNCF em 7 de maio
    2021 : Promovido a incubating em 26 de agosto
    2023 : Especificacao de traces declarada estavel
    2026 : Graduado na CNCF
         : Anuncio oficial em 21 de maio

Foram sete anos entre a criação e a graduação. Esse intervalo não é fraqueza, é o oposto. A observabilidade lida com o sistema nervoso da operação, e padrões nessa área precisam de estabilidade comprovada antes de receberem o selo máximo.

Os critérios que o projeto precisou atender

A graduação na CNCF exige requisitos formais que vão além de popularidade. No caso do OpenTelemetry, três pilares sustentaram a decisão.

O primeiro foi a auditoria de segurança independente. Uma empresa terceira analisou o código dos componentes centrais, com atenção especial ao OpenTelemetry Collector, o ponto por onde transita toda a telemetria. Auditoria externa é exigência de graduação justamente porque o Collector costuma ter acesso privilegiado a dados sensíveis.

O segundo foi a revisão de governança. A fundação avaliou se o projeto tem processo de decisão aberto, mantenedores de múltiplas empresas e mecanismos saudáveis de resolução de conflitos. Aqui os números falam por si: mais de 12.000 contribuidores de mais de 2.800 empresas, com centenas de mantenedores distribuídos por Special Interest Groups específicos de cada linguagem.

O terceiro foi a production readiness comprovada por adoção em escala. Organizações como Alibaba, Anthropic, Bloomberg, Capital One, eBay, FICO Software e Heroku já operam o OpenTelemetry em produção. A API JavaScript ultrapassou 1,36 bilhão de downloads em doze meses e a de Python passou de 1,3 bilhão, ambas batendo recordes mensais em abril de 2026.

O estado dos quatro sinais

Um equívoco comum é tratar a graduação como sinônimo de “tudo estável”. A graduação é do projeto, não de cada componente individualmente. Os sinais do OpenTelemetry estão em estágios diferentes, e conhecer essa distinção evita decisões erradas.

Sinal	Status na especificação	Observação
Traces	Stable (API, SDK e protocolo)	Coberto por long term support
Metrics	Stable (API e protocolo); SDK mixed	Maturidade do SDK varia por linguagem
Logs	Stable (Bridge API, SDK e protocolo)	Implementações por linguagem ainda evoluem
Baggage	Stable (API e SDK)	Mecanismo de propagação de metadados
Profiles	Development (protocolo)	O sinal mais novo, continuous profiling

Traces é o sinal mais maduro, completamente estável e com suporte de longo prazo. Metrics e logs têm especificação estável, mas a estabilidade dos SDKs varia entre linguagens. Já profiles, o quarto sinal, ainda está em desenvolvimento. A graduação confirma que o tripé de traces, metrics e logs é uma base sólida para padronizar agora, enquanto profiles segue amadurecendo para se juntar a eles sob o mesmo protocolo.

Por que isso muda decisões de arquitetura

Antes da graduação, a objeção mais frequente contra padronizar em OpenTelemetry era a percepção de imaturidade. “É um projeto incubado, ainda vai mudar muito.” Esse argumento perdeu sustentação. A graduação inverte o ônus da prova: agora cabe ao fornecedor proprietário justificar por que não falar OTLP.

O cálculo de lock-in também muda. Com instrumentação baseada em OpenTelemetry, a aplicação emite telemetria em formato OTLP, o protocolo nativo do padrão. Trocar de backend, de Datadog para Grafana, de New Relic para Honeycomb, ou rodar vários em paralelo, passa a ser uma mudança de configuração no Collector, não uma reinstrumentação de todo o código.

flowchart LR
    App[Aplicacao instrumentada<br/>com OpenTelemetry] -->|OTLP| Col[OpenTelemetry Collector]
    Col --> B1[Jaeger / Tempo]
    Col --> B2[Prometheus]
    Col --> B3[APM proprietario]
    Col --> B4[Azure Monitor]

A instrumentação fica acoplada ao padrão aberto, e não ao fornecedor. Esse desacoplamento é o ativo estratégico mais valioso que a graduação valida.

Como os sinais estáveis já se traduzem em código

A melhor forma de entender o que “estável” significa é ver os sinais funcionando. O exemplo a seguir, em .NET, instrumenta um serviço com traces e metrics e exporta tudo via OTLP, usando as APIs nativas System.Diagnostics.ActivitySource e System.Diagnostics.Metrics.Meter.

using System.Diagnostics;
using System.Diagnostics.Metrics;
using OpenTelemetry;
using OpenTelemetry.Metrics;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

var resource = ResourceBuilder.CreateDefault().AddService("checkout-service");

// Pipeline de traces exportando via OTLP para o Collector (localhost:4317)
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .SetResourceBuilder(resource)
    .AddSource("Checkout")
    .AddOtlpExporter()
    .Build();

// Pipeline de metrics exportando via OTLP
using var meterProvider = Sdk.CreateMeterProviderBuilder()
    .SetResourceBuilder(resource)
    .AddMeter("Checkout")
    .AddOtlpExporter()
    .Build();

var activitySource = new ActivitySource("Checkout");
var meter = new Meter("Checkout");
var pedidosProcessados = meter.CreateCounter<long>("pedidos.processados");

using (var activity = activitySource.StartActivity("ProcessarPedido"))
{
    activity?.SetTag("pedido.id", 1234);
    pedidosProcessados.Add(1, new KeyValuePair<string, object?>("status", "ok"));
    Console.WriteLine("Pedido processado e telemetria exportada via OTLP.");
}

using System.Diagnostics;

using System.Diagnostics.Metrics;

using OpenTelemetry;

using OpenTelemetry.Metrics;

using OpenTelemetry.Resources;

using OpenTelemetry.Trace;

var resource = ResourceBuilder.CreateDefault().AddService("checkout-service");

// Pipeline de traces exportando via OTLP para o Collector (localhost:4317)

using var tracerProvider = Sdk.CreateTracerProviderBuilder()

.SetResourceBuilder(resource)

.AddSource("Checkout")

.AddOtlpExporter()

.Build();

// Pipeline de metrics exportando via OTLP

using var meterProvider = Sdk.CreateMeterProviderBuilder()

.SetResourceBuilder(resource)

.AddMeter("Checkout")

.AddOtlpExporter()

.Build();

var activitySource = new ActivitySource("Checkout");

var meter = new Meter("Checkout");

var pedidosProcessados = meter.CreateCounter<long>("pedidos.processados");

using (var activity = activitySource.StartActivity("ProcessarPedido"))

{

activity?.SetTag("pedido.id", 1234);

pedidosProcessados.Add(1, new KeyValuePair<string, object?>("status", "ok"));

Console.WriteLine("Pedido processado e telemetria exportada via OTLP.");

}

O mesmo serviço, em Python, com as APIs estáveis de traces e metrics:

from opentelemetry import trace, metrics
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter

resource = Resource.create({"service.name": "checkout-service"})

# Pipeline de traces via OTLP
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4317"))
)

# Pipeline de metrics via OTLP
reader = PeriodicExportingMetricReader(
    OTLPMetricExporter(endpoint="http://localhost:4317")
)
metrics.set_meter_provider(MeterProvider(resource=resource, metric_readers=[reader]))

tracer = trace.get_tracer("checkout")
meter = metrics.get_meter("checkout")
pedidos_processados = meter.create_counter("pedidos.processados")

with tracer.start_as_current_span("processar_pedido") as span:
    span.set_attribute("pedido.id", 1234)
    pedidos_processados.add(1, {"status": "ok"})
    print("Pedido processado e telemetria exportada via OTLP.")

from opentelemetry import trace, metrics

from opentelemetry.sdk.resources import Resource

from opentelemetry.sdk.trace import TracerProvider

from opentelemetry.sdk.trace.export import BatchSpanProcessor

from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

from opentelemetry.sdk.metrics import MeterProvider

from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader

from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter

resource = Resource.create({"service.name": "checkout-service"})

# Pipeline de traces via OTLP

trace.set_tracer_provider(TracerProvider(resource=resource))

trace.get_tracer_provider().add_span_processor(

BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4317"))

)

# Pipeline de metrics via OTLP

reader = PeriodicExportingMetricReader(

OTLPMetricExporter(endpoint="http://localhost:4317")

)

metrics.set_meter_provider(MeterProvider(resource=resource, metric_readers=[reader]))

tracer = trace.get_tracer("checkout")

meter = metrics.get_meter("checkout")

pedidos_processados = meter.create_counter("pedidos.processados")

with tracer.start_as_current_span("processar_pedido") as span:

span.set_attribute("pedido.id", 1234)

pedidos_processados.add(1, {"status": "ok"})

print("Pedido processado e telemetria exportada via OTLP.")

Os dois exemplos enviam dados no mesmo formato OTLP para o mesmo endpoint. Essa é a essência do padrão: linguagens diferentes, protocolo idêntico. Repare que nenhum dos códigos cita um fornecedor específico. O destino é definido fora da aplicação, no Collector.

Sinais para os ecossistemas .NET, Python e Java

Para o ecossistema .NET, a notícia reforça um caminho que a Microsoft já trilhava. As APIs Activity e System.Diagnostics.Metrics foram desenhadas para serem compatíveis com OpenTelemetry, e o Azure Monitor consome OTLP nativamente. Instrumentar com o padrão aberto não é mais um desvio do ecossistema oficial, é o caminho recomendado.

No mundo Python, com mais de 1,3 bilhão de downloads da API em doze meses, a maturidade da instrumentação para frameworks como FastAPI, Flask e Django está consolidada. Para times que constroem aplicações de IA, isso se conecta às convenções semânticas de GenAI, tema que esta masterclass aborda mais adiante.

Em Java, o agent de instrumentação automática continua sendo um dos pontos mais fortes do projeto, permitindo capturar telemetria de aplicações existentes sem alterar uma linha de código. A graduação dá aos times Java o respaldo formal para padronizar em produção.

Próximos passos da comunidade

Com a graduação consolidada, o foco da comunidade se desloca para amadurecer o sinal de profiles e expandir as convenções semânticas, especialmente as de GenAI e mensageria. A meta declarada é tornar o OpenTelemetry o padrão único para os quatro pilares da observabilidade sob um só protocolo, OTLP, e uma só camada de convenções semânticas.

Para você, leitor, o recado é prático. A graduação não exige migração imediata, mas elimina a desculpa para adiar a padronização. Nos próximos artigos desta masterclass, vamos descer ao detalhe: a arquitetura do Collector, as estratégias de sampling, o tracing distribuído em produção e a instrumentação por linguagem.

FAQ – Perguntas Frequentes

1. O que significa um projeto ser graduated na CNCF?

É o nível máximo de maturidade da Cloud Native Computing Foundation. Para alcançá-lo, o projeto precisa comprovar governança aberta, adoção em produção em larga escala e passar por auditoria de segurança independente. Kubernetes, Prometheus e Envoy também são projetos graduados. O selo indica que a fundação considera o projeto confiável para ambientes críticos.

2. O OpenTelemetry substitui meu APM como Datadog, New Relic ou Dynatrace?

Não diretamente. O OpenTelemetry padroniza a instrumentação e o transporte da telemetria, não o armazenamento e a visualização. Você continua precisando de um backend para guardar e analisar os dados. A diferença é que, instrumentando com o padrão aberto, você escolhe e troca o backend sem reinstrumentar a aplicação. A maioria dos APMs citados já consome OTLP.

3. Todos os quatro sinais já estão estáveis?

Não. Traces, metrics e logs têm especificação estável e são considerados production ready, embora a maturidade dos SDKs varie por linguagem. O quarto sinal, profiles, ainda está em desenvolvimento na especificação. A graduação é do projeto como um todo, não de cada sinal isoladamente.

4. Preciso migrar para OpenTelemetry agora que o projeto graduou?

A graduação não impõe prazo nem obriga migração. O que ela faz é remover a principal objeção técnica contra a adoção, a percepção de imaturidade. Para projetos novos, padronizar em OpenTelemetry desde o início é a recomendação mais segura. Para sistemas existentes, a migração pode ser gradual, sinal por sinal.

5. A graduação muda o protocolo OTLP ou quebra compatibilidade?

Não. A graduação reconhece a estabilidade que já existia, não introduz mudanças que quebrem compatibilidade. O OTLP e as APIs estáveis seguem com compromisso de compatibilidade retroativa. Esse compromisso de estabilidade é justamente um dos critérios que sustentaram a decisão da CNCF.

Compartilhe:

Tiago Tartari

Eu ajudo e capacito pessoas e organizações a transformar problemas complexos em soluções práticas usando a tecnologia para atingir resultados extraordinários.

Qual é o desafio
que você tem hoje?