A operação de serviços de produção exige saber o que acontece dentro deles, mas adicionar métricas não é gratuito. Em uma apresentação publicada pela InfoQ, Brian Martin, cofundador da IOP Systems, explica que a diferença entre uma implementação e outra pode transformar a atualização de um contador de uma operação que custa cerca de 5 nanossegundos em uma operação que supera 1 microssegundo. Com histogramas, a diferença pode passar de cerca de 7 nanossegundos para dezenas de microssegundos quando há disputa entre as threads.
A ideia central da apresentação não é escolher uma determinada biblioteca Rust, mas tratar a medição como parte do projeto de desempenho. Uma métrica colocada em um caminho chamado milhões de vezes amplifica qualquer pequeno custo, enquanto a ausência de medição torna mais difícil diagnosticar lentidão, incidentes de produção e oportunidades de otimização.
Comece entendendo o tipo de dado e o custo de sua atualização
Martin distingue três tipos principais de métricas: o contador, que normalmente não diminui, como o número de solicitações; a métrica instantânea, que representa um valor atual, como a profundidade da fila; e o histograma, que descreve a distribuição dos valores, como os tempos de resposta. Essa distinção é importante porque cada tipo exige operações diferentes, e os histogramas fornecem informações que um único contador total não oferece.
Nos casos mais simples, um atomic fetch_add é adequado para contadores inteiros. Já os loops de comparação e troca, ou CAS, normalmente precisam tentar novamente quando várias threads disputam o mesmo local. Grande parte do custo vem da sincronização das linhas de memória cache entre os núcleos. A apresentação traz medições em uma máquina AWS Graviton com 32 unidades virtuais de processamento: o limite teórico de processamento chegou a cerca de 119 milhões de solicitações por segundo com uma atualização atômica de baixo custo, contra cerca de 23 milhões quando se utilizou uma implementação de custo mais alto com Prometheus.
Reduza a disputa com o particionamento por processador
Quando todas as threads compartilham um único contador, a linha de memória cache é continuamente transferida entre os núcleos. Em vez disso, Martin propõe criar um contador independente para cada processador, de modo que as operações de escrita sejam quase não concorrentes, e depois somar os valores durante a leitura. Essa abordagem aumenta um pouco o custo da leitura, mas protege o caminho de escrita crítico, que se repete a cada solicitação.
É preciso prestar atenção ao fenômeno de false sharing. Ter contadores logicamente independentes não basta se eles forem colocados em uma única linha de memória cache; a linha tem 64 bytes, o que significa que oito contadores de 64 bits podem ficar lado a lado. Por isso, a apresentação recomenda agrupar e preencher os contadores para que ocupem linhas de memória separadas. De acordo com os números apresentados, o desempenho teórico pode passar de cerca de 119 milhões de solicitações por segundo com o contador atômico para cerca de 6,4 bilhões de solicitações por segundo com o particionamento adequado.
Projete os histogramas para o caminho de atualização
O custo de um histograma começa pela determinação do recipiente ao qual o valor pertence. A busca linear dentro de uma lista de recipientes é a opção mais simples e mais lenta, enquanto a busca binária reduz o número de comparações, mas ainda depende da quantidade de recipientes. A alternativa mais rápida é a indexação direta, que calcula o número do recipiente a partir do valor em vez de procurá-lo.
Essa indexação envolve compromissos. A divisão em intervalos lineares é rápida, mas pode produzir um erro relativo grande em valores pequenos. A indexação logarítmica preserva melhor o erro relativo, mas o próprio cálculo do logaritmo é caro. Martin apresenta o uso de intervalos externos baseados em Log2, com sub-recipientes que ajustam a precisão, como no HDR Histogram e no H2Histogram. Em um teste não atômico, a determinação do recipiente e a atualização levaram cerca de 2,65 nanossegundos no HDR Histogram e cerca de 2,15 nanossegundos no H2Histogram.
Quando a consistência aproximada é aceitável?
O custo do histograma não é determinado apenas pelo método de indexação. Algumas aplicações realizam várias operações atômicas a cada operação, usam CAS para somar os valores ou impõem um bloqueio para obter um instantâneo consistente. A apresentação observa que algumas implementações chegaram a mais de dois microssegundos, e até a dezenas de microssegundos com 32 núcleos, enquanto a implementação baseada em indexação direta e uma única atualização atômica ficou mais próxima do custo de um contador.
A alternativa é a consistência aproximada: alguns recipientes podem mudar durante a leitura do histograma, mas a diferença entre duas leituras consecutivas continua sendo útil quando as métricas já são aproximadas por natureza. Essa não é uma regra geral; sistemas que precisam de um instantâneo perfeitamente consistente podem preferir a sincronização, apesar do custo.
Leitura editorial da certi.news
Na prática, o que muda é que a decisão de adicionar métricas deve incluir a arquitetura da atualização, e não apenas os nomes das métricas. O contador atômico, o particionamento por processador e a indexação direta podem tornar a medição utilizável dentro de caminhos sensíveis, enquanto histogramas sincronizados ou dinamicamente expansíveis podem impor um custo elevado sob pressão. A apresentação não oferece uma receita única válida para todas as bibliotecas ou serviços; ela mostra que flexibilidade, possibilidade de usar a biblioteca em outros projetos, consistência e desempenho são objetivos parcialmente conflitantes. Portanto, é necessário testar a implementação real sob os níveis de disputa e o volume de processamento pretendidos, em vez de depender do nome da biblioteca ou do resultado em um estado sem concorrência.
Martin também apresenta o uso de eBPF por meio do projeto Rezolus para obter métricas precisas do kernel do Linux, incluindo o agendador, os caminhos de chamadas do sistema e a pilha TCP, sem modificar o código do kernel. A questão em aberto continua sendo quanta precisão e consistência são necessárias em cada caso e se o custo da leitura ou da agregação das partes continuará aceitável à medida que o sistema for ampliado.