A Atlassian reconstruiu sua plataforma de métricas em torno do OpenTelemetry Collector sem exigir inicialmente que as equipes de serviços mudassem a forma de enviar métricas. Em vez de remover o pipeline antigo e depois reconfigurar milhares de serviços, a empresa manteve a interface StatsD via UDP e substituiu gradualmente as camadas de agregação, processamento e roteamento por trás dela.
A plataforma anterior dependia, durante a maior parte da última década, do gostatsd, uma aplicação StatsD de código aberto desenvolvida pela Atlassian, que funcionava como agente secundário nos hosts e como camada de agregação na outra extremidade. A plataforma lidava com métricas provenientes de cerca de 100 mil hosts distribuídos por 14 regiões, de acordo com uma meta de nível de serviço de 99,95% e baixa latência.
Alterar o mecanismo mantendo o contrato estável
As equipes da Atlassian concluíram que reconfigurar cada serviço para usar o OpenTelemetry SDK antes de mudar a infraestrutura seria um processo de vários anos, com risco de perda dos dados dos quais os alertas dependem. Por isso, a interface da plataforma foi separada de seus componentes internos: os serviços continuaram se comunicando com o mesmo endereço e no formato StatsD, enquanto as camadas internas foram substituídas por distribuições personalizadas do OpenTelemetry Collector.
O projeto adotou quatro etapas independentes: coleta, recepção, agregação e roteamento. A camada de coleta também foi preparada para receber StatsD e OTLP simultaneamente. Assim, foi possível iniciar a migração sem obrigar as equipes a trocar as bibliotecas de cliente, abrindo ao mesmo tempo caminho para métricas criadas originalmente com OpenTelemetry.
O que mudou na prática?
Na etapa de coleta, o agente secundário gostatsd foi substituído por uma distribuição do OpenTelemetry Collector que já era usada pela equipe de tracing, mantendo os aplicativos com seu comportamento anterior. Isso permitiu combinar métricas e tracing em um único agente secundário, em vez de executar dois agentes em cada host.
A Atlassian afirma que essa integração reduziu o consumo de CPU em uma média de aproximadamente 3,9% por serviço entre os serviços Micros de maior custo, o que equivale a uma redução de cerca de 30% no custo dos agentes secundários em toda a frota. Também foi adicionado um receptor OTLP para que a camada de coleta pudesse receber métricas do OpenTelemetry e encaminhá-las diretamente.
Na etapa de recepção, o principal problema estava relacionado ao estado das séries temporais. Cada ponto de dados pertencente à mesma série precisava ser enviado a um único agregador. O sistema antigo, por meio de um agente interno chamado nomad, usava uma partição baseada no par serviço e ambiente. No entanto, a variação no tamanho dos serviços fazia surgir agregadores sobrecarregados e outros com pouca utilização.
A Atlassian resolveu isso usando o componente loadbalancingexporter do repositório do OpenTelemetry, com particionamento baseado no streamID, ou seja, a identidade da série temporal individual. Esse método permitiu distribuir os dados de serviços grandes entre o conjunto de agregadores, mantendo uma série individual no mesmo agregador. Como resultado, a distribuição de CPU entre os agregadores ficou mais equilibrada, a capacidade de escalabilidade automática melhorou e os alertas de carga elevada diminuíram.
Redução de dados e custos na camada de agregação
A camada de agregação lida com cerca de 4,8 bilhões de pontos de dados por minuto, mas armazena apenas aproximadamente 220 milhões, uma redução de cerca de 96%. Como a maioria das métricas usa delta temporality, e os componentes anteriores não agregavam essas diferenças da forma esperada pelos usuários, a Atlassian desenvolveu um processador específico para agregar deltas de métricas e o publicou como código aberto sob o escopo atlassian-labs.
Após a migração, a camada de agregação passou a precisar de aproximadamente metade da CPU anterior. A fonte relaciona essa melhoria a vários fatores, incluindo a eliminação da análise do formato gostatsd, uma distribuição de carga melhor e o aproveitamento de melhorias da comunidade do OpenTelemetry.
Na etapa final, um roteador interno personalizado foi substituído por uma distribuição stateless do Collector que a empresa chamou de metrics-gateway. Essa distribuição usa exporters upstream para permitir o envio a vários destinos, como SignalFx e S3, com recursos de novas tentativas, filas e controle de contrapressão. De acordo com o projeto divulgado, adicionar um novo destino passa a ser uma alteração de configuração, em vez de um projeto de integração independente.
Lições da migração gradual
- Comece pelas equipes certas: a Atlassian escolheu ambientes de desenvolvimento e teste e serviços que enfrentavam mais problemas, para obter feedback inicial dentro de um escopo menos sensível.
- Monitore a produção continuamente: o profiling sob cargas de produção revelou o comportamento e o custo dos componentes de uma forma que testes pequenos ou benchmarks sintéticos não conseguiram oferecer.
- Mantenha a simetria operacional: como a migração pode durar meses ou anos, com os dois sistemas operando em paralelo, a empresa recomendou manter, tanto quanto possível, as mesmas ferramentas e os mesmos procedimentos operacionais.
- Amplie o escopo em etapas: o processo de implantação seguiu percentuais graduais, começando em 1%, depois 10% e 50%, até chegar a 100%, testando problemas nos serviços menos sensíveis antes dos caminhos críticos.
Por que essa abordagem é importante?
A experiência mostra que adotar um novo padrão na infraestrutura não exige necessariamente mudar as interfaces de todos os consumidores ao mesmo tempo. Manter o contrato externo transformou a migração de um projeto organizacional envolvendo todas as equipes em um projeto conduzido pela plataforma de infraestrutura, abrindo gradualmente espaço para OTLP e para os componentes do OpenTelemetry.
A Atlassian indica que gostatsd e nomad juntos representavam cerca de 38% das solicitações de CPU nos clusters de métricas, enquanto o nomad sozinho representava aproximadamente 13% dos recursos totais. Portanto, o impacto da transição não se limita à unificação das ferramentas; ele também está relacionado à remoção de componentes personalizados caros e à redução do número de partes que precisam de manutenção interna.
Isso, contudo, não significa que a migração tenha sido concluída no nível da instrumentação dos serviços. O próximo passo mencionado pela empresa é migrar as próprias ferramentas de instrumentação para o OpenTelemetry SDK e abandonar gradualmente os clientes Datadog e DogStatsD e as bibliotecas StatsD internas que ainda são utilizadas. Os resultados de desempenho e os números apresentados aqui também continuam sendo uma descrição da experiência da Atlassian em seu ambiente, e não uma garantia de que os mesmos valores se repetirão em toda arquitetura de monitoramento.