Atlassian troca motor de métricas em 100 mil hosts sem tocar no código

Atlassian migrou a plataforma interna de métricas para OpenTelemetry mantendo a interface StatsD intacta para os times de aplicação. O caso foi publicado em 1º de outubro. A plataforma recebe dados de cerca de 100 mil hosts em 14 regiões, sob um SLO de 99,95%.

A estratégia merece atenção. A empresa reconstruiu coleta, roteamento, agregação e encaminhamento por baixo, enquanto o contrato com as aplicações seguiu igual.

Portanto, nenhum time precisou reinstrumentar serviço antes da troca.

Por que o gostatsd deixou de atender

A empresa mantinha o gostatsd, implementação em código aberto↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → do StatsD, por boa parte da última década. Esse componente cuidava da coleta como processo auxiliar em cada host e também da agregação.

O limite apareceu na arquitetura. Baseada em UDP, ela deixava de suportar rastreamentos e logs.

Enquanto isso, boa parte da telemetria interna já migrava para OpenTelemetry. Esse projeto, aliás, se formou na CNCF em maio deste ano, com métricas, rastreamentos e logs como sinais centrais.

Atlassian dividiu o pipeline em quatro etapas

O novo desenho separa coleta, ingestão, agregação e encaminhamento. Cada etapa usa uma distribuição específica do OpenTelemetry Collector.

Assim, os times substituem componentes de forma independente.

A camada de coleta aceita dados em StatsD e em OTLP ao mesmo tempo. Consequentemente, aplicações antigas seguem enviando por UDP, enquanto instrumentação nova envia direto em OpenTelemetry.

A unificação trouxe ganho imediato. Ao juntar métricas e rastreamento no mesmo sidecar baseado em Collector, a empresa removeu o sidecar separado do gostatsd.

O resultado chegou a cerca de 3,9% menos CPU por serviço nos serviços Micros mais caros. Isso representou aproximadamente 30% de redução no custo de sidecar na frota.

O problema de roteamento que o stream ID resolveu

Aqui está a parte mais interessante do caso. Agregação de métrica é operação com estado, então pontos da mesma série temporal precisam chegar ao mesmo agregador.

A solução anterior usava um proxy interno chamado nomad. Ele distribuía tráfego por shard com hash de serviço e ambiente.

O desenho gerava desequilíbrio. Como o volume varia muito entre serviços, um shard responsável por um serviço grande recebia bem mais carga.

A troca veio pelo load balancing exporter do Collector. Em vez de rotear por serviço, ele usa um stream ID que identifica uma série temporal individual.

Dessa forma, séries diferentes do mesmo serviço se espalham entre vários shards. Ao mesmo tempo, cada série permanece em um shard consistente.

A empresa relatou distribuição mais uniforme de CPU entre shards. Além disso, a pool de agregação passou a reduzir mais em períodos de baixa atividade.

Os números de agregação impressionam

O volume dá a dimensão do desafio. O pipeline recebe cerca de 4,8 bilhões de pontos por minuto.

Depois da agregação, o armazenamento guarda em torno de 220 milhões. Ou seja, a redução chega a aproximadamente 96%.

Houve ainda um obstáculo técnico específico. Boa parte dos dados usa temporalidade delta, em que cada ponto representa a variação desde a medição anterior.

Os componentes upstream existentes agregavam esses deltas de forma diferente do necessário. Por isso, a equipe desenvolveu um processador próprio de agregação delta e publicou pelo Atlassian Labs.

A nova camada de agregação consome cerca de metade da CPU do sistema anterior sob o mesmo tráfego.

Encaminhamento, Lambda e o rollout gradual

A etapa de encaminhamento virou uma distribuição sem estado chamada metrics gateway. Ela envia telemetria para destinos como SignalFx e Amazon S3, usando recursos nativos de retry, fila e contrapressão.

Para cargas em AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → Lambda, onde sidecar convencional deixa de rodar, a empresa criou uma extensão própria. Ela mantém o mesmo endereço StatsD e as mesmas variáveis de ambiente da implementação anterior.

O rollout seguiu escada. Após testes em desenvolvimento, homologação e cargas menos críticas, a produção subiu de cerca de 1% para 10%, 50% e cobertura total.

Os dois sistemas rodaram lado a lado durante boa parte da migração. Logo, paridade operacional virou requisito ao longo do caminho.

Vale registrar uma lição sobre medição. Segundo a equipe, benchmarks sozinhos deixavam de revelar o custo real, e o perfilamento contínuo em produção apontou onde otimizar.

O que vem agora

Os componentes antigos ainda pesam. Agregadores gostatsd e o serviço nomad respondem por cerca de 38% das requisições de CPU nos clusters de métricas, sendo o nomad sozinho responsável por aproximadamente 13%.

O próximo passo move a instrumentação do lado da aplicação. A meta é sair de StatsD, DogStatsD e clientes internos rumo aos SDKs de OpenTelemetry.

Essa etapa vem depois da troca de infraestrutura. Assim, cada serviço migra no próprio ritmo.

Acompanhe nosso perfil no Instagram!