A Atlassian reconstruiu a plataforma de métricas que atende cerca de 100 mil hosts em 14 regiões, trocando o gostatsd pelo OpenTelemetry sem desligar a interface StatsD usada pelas aplicações. O serviço operava com SLO de 99,95%, então a equipe precisou migrar sem interromper os alertas de produção existentes.
A estratégia, detalhada pelos engenheiros Iris Grace Endozo, Farzad Vazirnia e Albert Kerr em post no blog da CNCF, inverteu o custo da migração: em vez de pedir que milhares de serviços adotassem o SDK do OpenTelemetry, a equipe de plataforma manteve o endpoint StatsD sobre UDP e reconstruiu todo o pipeline por trás dele.
O resultado foi uma redução de cerca de 30% no custo de sidecars e uma queda de 96% no volume de dados armazenados, de 4,8 bilhões de pontos por minuto para cerca de 220 milhões.
Na avaliação do Mercado de TI, o caso é um modelo de engenharia de plataforma madura: resolver o problema onde ele é mais barato, na camada de infraestrutura, em vez de distribuir o custo para centenas de times de produto.
Por que a atlassian abandonou o gostatsd
O gostatsd funcionou de forma confiável por anos na empresa, mas seu desenho exclusivo para UDP não suporta traces nem logs. Ao mesmo tempo, cada vez mais serviços internos passaram a produzir dados nativos em OpenTelemetry.
# publicidade
Continuar com o gostatsd significaria reimplementar funcionalidades que a comunidade do Collector do OpenTelemetry já desenvolve. Em vez disso, a Atlassian criou distribuições próprias do Collector para quatro estágios: coleta, ingestão, agregação e encaminhamento. O modelo de pipeline do Collector, em que receivers aceitam dados, processors os modificam e exporters enviam aos destinos, permitiu trocar cada parte isoladamente.
“Mantivemos a interface e reconstruímos tudo por trás dela, o que transformou uma migração de toda a organização em uma migração da equipe de plataforma”, escreveram Endozo, Vazirnia e Kerr no post da CNCF.
O que mudou na coleta e na ingestão
Na camada de coleta, o sidecar do gostatsd foi substituído pela distribuição do Collector que o time de tracing já usava. As aplicações continuaram enviando pacotes StatsD para o mesmo endereço, enquanto um receiver OTLP passou a aceitar métricas nativas de serviços mais novos.
Unificar métricas no sidecar de tracing economizou, em média, 3,9% de CPU em cada um dos serviços Micros mais caros da empresa, e a estimativa é de corte de cerca de 30% no custo de sidecars na frota inteira. Para cargas serverless, onde sidecar não é viável, uma extensão Lambda do OpenTelemetry preserva a mesma interface.
A ingestão exigiu outra solução, porque agregação de métricas é stateful: todos os pontos de uma série temporal precisam chegar ao mesmo agregador. O antigo proxy nomad fazia hash por serviço e ambiente, concentrando os maiores serviços em poucas réplicas.
O novo sistema usa o exporter de balanceamento de carga do OpenTelemetry contrib, com hash por stream ID: séries individuais ficam juntas, mas um serviço grande se distribui pelo pool. A empresa relata CPU mais equilibrada, menos hot shards e melhor escalonamento fora de pico.
Agregação: o maior corte de volume
A agregação entregou o resultado mais expressivo: dos 4,8 bilhões de pontos recebidos por minuto, apenas cerca de 220 milhões são armazenados, redução de aproximadamente 96%. Como os componentes existentes não agregavam métricas delta da forma necessária, a Atlassian desenvolveu e abriu o código do seu próprio aggregation processor.
“Testes pequenos e benchmarks não foram suficientes; o profiling contínuo em produção foi o que de fato mostrou onde otimizar”, destacaram os autores.
O tier revisado consome cerca de metade da CPU para o mesmo tráfego. E o encaminhamento final trocou um serviço dedicado por uma distribuição stateless chamada metrics-gateway, com exporters para destinos como SignalFx e S3, com retry, filas e backpressure nativos do Collector. Adicionar novo destino virou mudança de configuração, não projeto de integração.
O que vem a seguir e como outras empresas fizeram
O gostatsd e o nomad ainda respondem por cerca de 38% dos pedidos de CPU nos clusters de métricas, com o nomad sozinho em torno de 13% dos recursos totais. Removê-los completará o pipeline OpenTelemetry de ponta a ponta. A próxima etapa planejada é migrar a instrumentação das aplicações, hoje em clientes StatsD, DogStatsD e de fornecedores, para os SDKs do OpenTelemetry.
O plano de migração seguiu prática operacional conservadora: começar por desenvolvimento e staging, escolher early adopters com ganho claro e avançar em ondas de 1%, 10%, 50% e 100%, mantendo fluxos operacionais familiares enquanto os dois sistemas conviviam.
A abordagem difere de casos recentes de outras empresas. O Airbnb usou emissão dupla a partir de uma biblioteca compartilhada e adotou o vmagent do VictoriaMetrics para agregação em streaming, chegando a mais de 100 milhões de amostras por segundo. A Skyscanner padronizou instrumentação e transporte em OpenTelemetry e migrou mais de 300 microsserviços atualizando uma biblioteca comum.
| Empresa | Estratégia | Escala citada |
|---|---|---|
| Atlassian | Manteve endpoint StatsD e reconstruiu o pipeline; processor de agregação open-source | 100 mil hosts, 14 regiões, 4,8 bilhões de pontos/minuto |
| Airbnb | Emissão dupla via biblioteca compartilhada; vmagent do VictoriaMetrics | Mais de 100 milhões de amostras/segundo |
| Skyscanner | Padronização em OpenTelemetry via biblioteca comum | Mais de 300 microsserviços migrados |
Arraste para o lado para ver toda a tabela.
Iwahori, líder de infraestrutura de monitoramento da GREE, classificou a abordagem da Atlassian como bem pensada em relatório de conferência traduzido. Ele destacou o roteamento por stream ID e o processor de agregação delta, mas questionou a escalabilidade de um tier de agregação stateful; segundo o relato, a resposta da Atlassian indicou que essa parte ainda depende de configuração manual.
Quem opera plataformas de observabilidade em ambientes Kubernetes, tema que aparece em vagas como a de DevOps engineer Kubernetes sênior listada no portal, tende a reconhecer o padrão: migrações de infraestrutura crítica raramente falham por tecnologia, e sim por custo de coordenação entre times. A mesma lógica de reescrever componentes centrais sem trocar a interface aparece no caso da Cloudflare, que redesenhou o cache DNS do 1.1.1.1 em Rust e liberou 100 TB de memória, e na aposta da Modal, que ignorou o Kubernetes para escalar 1 milhão de sandboxes.
O caso da Atlassian reforça uma tendência clara de DevOps: o OpenTelemetry Collector deixa de ser apenas receiver de telemetria e vira base de pipelines completos de métricas, com agregação stateful, roteamento por stream e fan-out declarativo. Para equipes brasileiras que mantêm stacks híbridas de StatsD, Prometheus e vendors, o caminho demonstrado é viável: preservar a interface, migrar o pipeline por estágios e medir em produção, não em benchmark.
Principais pontos
- A Atlassian migrou a plataforma de métricas de 100 mil hosts em 14 regiões do gostatsd para o OpenTelemetry, mantendo a interface StatsD, com SLO de 99,95% preservado.
- A consolidação de métricas no sidecar de tracing cortou cerca de 30% do custo de sidecars e 3,9% de CPU nos serviços mais caros.
- A agregação reduziu 96% do volume armazenado: de 4,8 bilhões de pontos por minuto para cerca de 220 milhões.
- A empresa abriu o código de seu aggregation processor e usa hash por stream ID para balancear o tier stateful.
- A remoção de gostatsd e nomad, que somam 38% dos pedidos de CPU nos clusters, completa o pipeline OpenTelemetry de ponta a ponta.
Perguntas frequentes
Por que a Atlassian não migrou as aplicações direto para o SDK do OpenTelemetry? Porque isso exigiria coordenar milhares de serviços. Manter o endpoint StatsD-over-UDP transformou uma migração organizacional em um projeto da equipe de plataforma, com a migração de instrumentação planejada como etapa posterior.
O aggregation processor da Atlassian é open-source? Sim. A empresa publicou o processor no GitHub na organização atlassian-labs, desenvolvido porque os componentes existentes do OpenTelemetry não agregavam métricas delta no formato necessário.
Como o tier de agregação stateful foi escalado? Com o exporter de balanceamento de carga do OpenTelemetry contrib, que faz hash por stream ID, mantendo séries temporais juntas e distribuindo serviços grandes pelo pool. Segundo relato da GREE, parte dessa escalabilidade ainda depende de configuração manual.
Qual foi o ganho no encaminhamento de métricas? O serviço dedicado foi substituído pelo metrics-gateway, uma distribuição stateless do Collector com retry, filas e backpressure. Adicionar destinos como SignalFx e S3 virou mudança de configuração, e não um projeto de integração separado.
Fonte: Infoq
