💃🏾 🚼 🧝🏼 Observabilidade do SRE: namespaces e estrutura métrica 🤹🏿 👨🏽 👅

Spyglass da Shorai-san

Os espaços para nome métricos estruturados são importantes para um acesso rápido às informações durante incidentes. Planeje com cuidado nomes e dimensões métricas para oferecer suporte a uma ampla variedade de consultas e extensões. Uma maneira eficaz de criar um modelo de métrica flexível é pensar neles como uma árvore.

Isso fornece várias vantagens: visualizar determinados subconjuntos de dados, definir uma métrica em termos de seus filhos e estabelecer relacionamentos entre métricas. Artigo traduzido da

equipe de soluções de nuvem do Mail.ru , que discute as propriedades dos espaços para nome da métrica, permitindo aumentar gradualmente os detalhes das consultas e mover para subconjuntos de dados, além de visualizar a métrica do ponto de vista das métricas em que ela consiste. Muitos desses conceitos são familiares para você, pois são implementados em soluções de monitoramento em nuvem nativas, como Prometheus e DogStatsD.

Namespaces de métricas e sua estrutura

Namespaces de métricas são os espaços conceituais em que as métricas residem. Eles geralmente são limitados a um banco de dados ou conta:

O espaço para nome da métrica também é a estrutura das métricas dentro do espaço para nome. O nome e a estrutura adequados abrem uma série de enormes vantagens.

O espaço para nome no diagrama acima não possui uma estrutura explícita. Cada métrica é separada e independente. As métricas não têm nada em comum, exceto o fato de existirem no mesmo espaço para nome. Nessa estrutura não relacionada, cada métrica será usada individualmente. Para ver a frequência das solicitações http de um serviço, a métrica do serviço deve ser acessada diretamente - service_N_http_requests_total.

Suponha que desejamos ver o número total de solicitações para todos os serviços. O que acontece no exemplo acima se criarmos um novo serviço?

Se o número total de solicitações for calculado somando as solicitações para service_1 e service_2, a adição do service_3 não altera o número total de solicitações. Para calcular o número total correto de solicitações, é necessário alterar a regra de contagem adicionando service_3_http_requests_total. Dê uma olhada no gráfico do número de solicitações abaixo:

Árvore de métricas

Uma alternativa para um espaço para nome sem estrutura é aceitar uma estrutura explícita usando o nome da métrica como espaço para nome. No diagrama abaixo, você vê essa estrutura como uma árvore:

No Prometheus e no Datadog, uma estrutura de métrica é criada usando tags e tags . As tags permitem criar uma árvore dinamicamente: sempre que um novo serviço é adicionado, ele se refere à métrica raiz.

No Prometheus, o número de solicitações por segundo para todos os serviços pode ser visualizado através da criação de uma solicitação, como na figura abaixo:

Com um espaço para nome estruturado, você pode calcular dinamicamente a soma de consultas em todo o nó. Nesse caso, o Prometheus calcula o número de solicitações por segundo para cada serviço como uma métrica separada.

Definindo Métricas de Herança

Ao usar a árvore de métricas, cada dimensão de métrica (denominada "serviço") contém uma frequência individual de solicitações para um serviço específico. Usando o namespace de métricas, é possível obter não apenas a frequência total de solicitações, mas também a frequência de solicitações para cada serviço:

Usando o espaço para nome, você pode selecionar e visualizar não apenas os dados da métrica geral, mas também os dados da parte da métrica geral, agrupados por algum atributo. Portanto, na figura acima, a frequência de solicitações para serviços individuais é visível, sua soma fornece a frequência de solicitações para o nó.

Limitando a amostra - subconjuntos de dados

Os espaços para nome também oferecem suporte ao estreitamento de consultas para recuperar subconjuntos específicos de dados. Por exemplo, vamos fazer a pergunta: “Qual é o atraso da p99 (99% das solicitações são mais rápidas que o atraso especificado) em todas as solicitações HTTP bem-sucedidas para servidores com implantação de canário?”.

A árvore acima modela o conceito de um espaço para nome e opcionalmente modela como as métricas são armazenadas no disco. O uso de um namespace de métrica bem definido permite estender as métricas para qualquer parâmetro.

A figura abaixo mostra um gráfico de p99 e p50 da árvore de métricas acima:

Se você fizer uma solicitação mais específica, poderá, por exemplo, responder à seguinte pergunta: “Qual é o atraso p99 em todas as solicitações HTTP bem-sucedidas para servidores com implantação de canário no contexto de cada servidor?”

Abaixo está uma visualização de uma métrica com uma seleção por machine_id:

Como a métrica possui uma estrutura bem definida, podemos selecionar os dados necessários na métrica de nível superior especificando os critérios de seleção necessários - no nosso caso, machine_id.

Regra de Probabilidades

Coeficientes são outra maneira de estruturar dados (correlações). Esse é um mecanismo muito poderoso e a base para calcular a disponibilidade e a taxa de erro dos SLOs (esses indicadores foram popularizados pelos especialistas do Google SRE).

Os coeficientes permitem que o usuário final associe explicitamente métricas, estabelecendo uma estrutura de métricas. Esses relacionamentos geralmente são expressos como uma porcentagem, ou seja, a acessibilidade pode ser calculada como a proporção de "solicitações bem-sucedidas / número total de solicitações" e a taxa de erro como "número de erros / número total de solicitações". Outro exemplo de coeficiente é a frequência com que um estado surge de vários estados.

Vamos ilustrar isso e supor que existe um aplicativo que executou a solicitação, e a solicitação pode levar a um dos dois estados: dados extraídos do cache (cache_hit: true) ou dados extraídos da fonte principal (cache_hit: false). Para ver a taxa de acertos do cache, os dados devem ser estruturados da seguinte maneira:

O gráfico abaixo mostra a frequência do cache de acertos e perdidos. Cada solicitação obtém ou não entra no cache. No total, ocorrem cerca de 160 solicitações por segundo:

O gráfico a seguir mostra a taxa de acertos do cache em relação ao número total de solicitações. O coeficiente de acerto é de 0,5 (50%):

Assim, você pode relacionar duas métricas. No Datadog e no Prometheus, esse relacionamento é expresso por uma operação aritmética simples.

Perguntas respondidas por dados

É importante pensar nas perguntas que os dados devem responder. No primeiro exemplo, a amostragem de dados não pode responder exatamente à pergunta: “Quantas consultas por segundo todas as instâncias processam?”, Mas a árvore do namespace ajudaria a obter a resposta.

Outro caso comum é o espaço para nome das métricas do cliente com o nome do serviço, e não com o nome da biblioteca do cliente. Adicionar o nome da biblioteca do cliente ao namespace responderá à pergunta: "O número total de solicitações de todos os clientes?".

Perguntas úteis gerais respondem aos quatro sinais de ouro do Google . Cada pergunta é feita de uma maneira geral e, em seguida, é especificada:

Quantas solicitações todos os clientes fazem no total?
Quantas solicitações cada cliente faz?
Quantas solicitações cada cliente faz para cada nó?
Qual é a porcentagem de solicitações de servidor bem-sucedidas para cada RPC?

A mesma estratégia se aplica a atrasos, taxas de erro e saturação de recursos.

Métricas etiquetadas genéricas

Aqui está o que eu li nas práticas recomendadas para otimização de consulta e armazenamento de dados para Datadog e Prometheus.

Para obter uma visão global que ofereça suporte ao detalhamento de segmentos específicos, comece com um namespace superior comum e adicione tags e rótulos (comece pelos comuns e adicione outros mais específicos). Ao fazer isso, considere a recomendação abaixo.

Cuidado com a cardinalidade

O Datadog e o Prometheus recomendam limitar o número de tags. Para citar o manual do Prometheus :

, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

Se você adicionar cotas de FS por usuário, alcançará rapidamente dezenas de milhões de séries temporais, de 10.000 usuários por 10.000 nós. Isso é demais para a implementação atual do Prometheus. Mesmo com números mais baixos, você não terá mais outros indicadores potencialmente mais úteis nesse monitoramento.

Comece sem tags e adicione mais tags ao longo do tempo, conforme necessário.

O monitoramento conveniente no nível do usuário geralmente é melhor alcançado por meio de rastreamento distribuído . O rastreamento distribuído possui seu próprio espaço de métricas e práticas recomendadas.

Conclusão

É importante entender quais perguntas podem ser respondidas estruturando as métricas. Uma estrutura incorreta leva a dificuldades na obtenção de respostas. Embora a estruturação do espaço métrico não seja complicada, ela requer planejamento prévio para aproveitar ao máximo os dados.

Quando surgem problemas, a capacidade de expandir manualmente a métrica para ver todos os estados é crítica e é importante que o espaço para nome não interfira nisso.

Boa sorte!

O que mais se pode ler :

Observabilidade do SRE: namespaces e estrutura métrica