Seja você um DevOps, SRE ou apenas um indivíduo orientado a dados, provavelmente é viciado em painéis e métricas. Analisamos nossas métricas para ver como nosso sistema está se saindo, seja na infraestrutura, no aplicativo ou no nível de negócios. Confiamos em nossas métricas para nos mostrar o status de nosso sistema e onde ele se comporta mal. Mas nossas métricas nos mostram o que realmente aconteceu? Você ficaria surpreso com a frequência com que não é o caso.

Neste post, examinarei a matemática e a mecânica por trás das métricas, alguns equívocos comuns, o que é necessário para ter métricas precisas e se existe tal coisa.

Métricas essenciais

Métricas são essencialmente acúmulos de eventos brutos. Durante esse processo de acúmulo, os eventos são convertidos em pontos de dados numéricos. Um exemplo simples são os erros ocorridos no sistema, com uma métrica simples para contabilizar os erros. As métricas também podem envolver diversas variáveis, como contagem de solicitações com tempo de resposta superior a 1 segundo. Quando medidos ao longo do tempo, esses pontos de dados formam uma série temporal .

As métricas podem ser de vários tipos, como contadores, medidores e histogramas. Os contadores são usados para a contagem cumulativa de eventos, como vimos nos exemplos acima. Os medidores geralmente representam o valor mais recente da medição. E há tipos mais elaborados, como Histogramas , que podem amostrar a distribuição de valores métricos, contando eventos em “baldes” ou “caixas” configuráveis. Por exemplo, talvez você queira entender a porcentagem de uso de memória segmentada por pods em seu cluster em determinados pontos no tempo.

A mecânica das métricas

Em um mundo ideal, ingeriríamos e armazenaríamos todos os eventos brutos e, em seguida, calcularíamos as métricas no tempo de consulta. Isso nos permitiria dividir os eventos da maneira que precisarmos e fazer quaisquer perguntas ad hoc que desejarmos.

No mundo real, no entanto, manter todos os eventos brutos por longos períodos de tempo pode ser proibitivamente caro devido aos grandes volumes de dados. Para superar isso, os eventos são frequentemente agrupados em métricas no pipeline de coleta, descartando os eventos brutos ou retendo-os apenas por curtos períodos. Muitas vezes, isso é uma questão de configuração simples em seu agente coletor de métricas.

Além de reduzir custos, a agregação na coleta pode melhorar o desempenho de análises em tempo real com transmissão de métricas mais altas e taxas de ingestão com maior frequência, evitando agregações e cálculos pesados no tempo de consulta.

A matemática das métricas em poucas palavras

Esse processo de enrolamento envolve alguma matemática. Podemos querer calcular a média ou mediana dos tempos de resposta, ou talvez um percentil, ou uma agregação em uma janela de tempo. Também podemos agrupar vários eventos em uma métrica composta. Por exemplo, posso querer calcular o 95º percentil (comumente conhecido como P95) de todos os pods de um serviço específico em meu cluster.

Mesmo que você não goste de matemática, não pode evitá-la com métricas. Você precisa entender as diferentes funções de agregação e a relação entre a pergunta que deseja fazer e a métrica e o agregado de que precisa para respondê-la. Vejamos a função Average como exemplo, já que muitos tendem a começar por aí. As médias, por definição, suavizam as coisas e serão menos adequadas para eliminar comportamentos anômalos e discrepantes. Ao investigar problemas de latência, por exemplo, será inútil olhar para os valores médios das métricas e seria melhor olhar para os percentis.

Determine suas perguntas, projete suas métricas de acordo

De certa forma, você pode pensar nessas métricas como uma compactação com perdas, durante a qual perdemos dados e contexto dos eventos brutos. Se não mantivermos os eventos brutos, precisamos determinar antecipadamente o que é importante para nós. Por exemplo, se eu calcular apenas o valor médio sobre os dados, não poderei perguntar sobre o P95 (95º percentil) posteriormente sobre os dados pré-agregados.

Você precisa determinar quais perguntas deseja responder, o que é importante para você e projetar suas métricas e agregações de acordo. Um erro comum é que as pessoas evitam essa fase de design e apenas usam as métricas predefinidas e os valores padrão fornecidos imediatamente com o coletor de métricas de sua escolha. Embora você possa pensar que esses padrões representam algum padrão do setor, eles geralmente são legados e, na maioria dos casos, não estão em sintonia com suas necessidades específicas.

O problema de medição

Assim como na física, o problema de medição ocorre quando medimos uma propriedade (aparentemente) contínua em intervalos discretos, geralmente chamados de intervalo de amostragem , que determina a taxa de amostragem. Isso cria uma representação distorcida, onde a métrica pode não refletir a propriedade originalmente medida. Por exemplo, se medirmos a utilização da CPU a cada 60 segundos, qualquer outlier da CPU que ocorra entre esses pontos de amostragem será invisível para nós.

Além disso, para desenhar uma linha consecutiva, as ferramentas de visualização geralmente fazem a média de pontos de dados consecutivos, o que dá a aparência enganosa de uma linha suave. Em algumas ocasiões, pode ocorrer o oposto, onde você pode obter artefatos em suas métricas que não são reais, como picos em suas métricas que realmente não existem. Isso pode acontecer ao executar agregações dentro do back-end de armazenamento, devido ao qual o cálculo está sendo feito.

Tempo médio para detecção

O período de amostragem também influencia a rapidez com que uma mudança no sistema será visível nas métricas. A maioria dos algoritmos requer cinco pontos de dados para detectar uma tendência. Se o intervalo de amostragem for de 60 segundos, a matemática simples determina que levará cinco minutos (ou seja, 60 segundos X 5 pontos de dados) antes de vermos que algo está errado. Você poderia esperar 5 minutos para saber que seu sistema travou? O uso de intervalos de amostragem mais curtos (ou seja, taxas de amostragem mais altas) reduzirá esse período e nos permitirá detectar e reagir mais rapidamente. Obviamente, taxas de amostragem mais altas geram sobrecarga na CPU e no armazenamento, portanto, precisamos encontrar a configuração que atinja o equilíbrio certo para nossas necessidades.

Resolução variável e redução de escala

Uma prática comum é salvar métricas em diferentes resoluções em uma abordagem em camadas, para reduzir custos. Por exemplo, você pode querer salvar a métrica a cada 10 segundos no primeiro dia, mas depois a cada 5 minutos na próxima semana e talvez a cada 1 hora no mês ou mais à frente. Essa prática pressupõe que precisamos da granularidade mais fina para o período quase em tempo real, o que pode ser necessário se houver um problema no sistema, enquanto as investigações em períodos mais longos exigem tendências em escala maior.

As diferentes granularidades podem ser alcançadas diminuindo a escala das métricas, ou seja, calculando a métrica menos granular a partir da granularidade mais alta. Embora isso pareça perfeitamente razoável, a matemática pode interferir aqui, pois algumas funções de agregação não são compatíveis com determinados cálculos e, portanto, não podem ser agregadas posteriormente. Por exemplo, os percentis não são aditivos e não podem ser somados. Portanto, seguindo o exemplo acima, se você tiver um percentil P99 amostrado com resolução de 10 segundos, não poderá aumentá-los para uma resolução de 5 minutos. É importante estar ciente da compatibilidade das funções de agregação e, ao usar funções não compatíveis, como percentis, tomar decisões de design sobre quais resoluções exigimos e calcular essas séries temporais antecipadamente.

A resolução variável não se limita apenas ao fator tempo. Outro exemplo é salvar dados por pod e, em seguida, desejar “agrupar por” nós ou clusters. A mesma restrição se aplica aqui, o que significa que, se esperamos estar interessados em dividir uma métrica baseada em percentil por nó, por região, por namespace ou em todo o cluster, precisamos pré-agregar adequadamente.

Outra abordagem é abrir mão da precisão das medições para obter compatibilidade na computação, usando histogramas. Você pode obter histogramas de alguns servidores e resumi-los, ou histogramas de várias janelas de tempo e resumi-los e, em seguida, reduzi-los. O problema é que, neste caso, os percentis serão estimados em vez de precisos. Também é importante observar que os histogramas consomem mais tempo em armazenamento e rendimento, pois cada amostra não é apenas um único número, mas algumas amostras (uma por balde).

Resumo

Métricas são uma maneira poderosa de monitorar nossos aplicativos. Mas eles não são necessariamente representativos do estado atual do sistema. Isso requer uma compreensão da matemática e da natureza das métricas, bem como um design cuidadoso, para garantir que nossas métricas sejam realmente úteis para responder às perguntas de que precisamos. Ter acesso aos dados brutos, além das métricas, é sempre bom, pois essa é a fonte da verdade.

Quer aprender mais? Confira o episódio OpenObservability Talks: Todas as métricas estão erradas, algumas são úteis no Spotify , Apple Podcasts ou outros aplicativos de podcast .

Este artigo foi originalmente aqui .