Como gerenciar métricas de alta cardinalidade no Prometheus e Kubernetes
Nos últimos meses, um tema comum e recorrente nas nossas conversas com os usuários tem sido a gestão de custos de observabilidade, que está aumentando a uma taxa mais rápida do que o impacto causado pelos aplicativos e infraestrutura que estão sendo monitorados. À medida que as empresas se voltam para arquiteturas nativas da nuvem e a popularidade do Prometheus continua crescendo, não é surpreendente que a cardinalidade das métricas (uma combinação cartesiana de métricas e rótulos) também cresça. No entanto, a taxa de crescimento pegou algumas empresas de surpresa e se tornou uma prioridade quando se trata de construir e manter sistemas e práticas de observabilidade.
Se isso soa familiar e você está atualmente tentando descobrir como controlar o crescimento das métricas, assista ao nosso webinário “Como controlar o crescimento das métricas no Prometheus e no Kubernetes com o Grafana Cloud” para aprender dicas e truques acionáveis que você pode começar a implementar hoje.
Mas por que as métricas estão crescendo a uma taxa sem precedentes?
Ambientes nativos da nuvem e arquiteturas baseadas em microsserviços combinadas com a autonomia e flexibilidade do desenvolvedor criam uma trilogia perfeita para um aumento exponencial nos dados de séries temporais. Com o aumento dos níveis de abstração nas infraestruturas nativas da nuvem, como o Kubernetes, surgem mais séries temporais. O que antes era um único servidor bare metal executando um aplicativo, agora foi substituído por muitos pods executando muitos microsserviços diferentes espalhados por diversos nós. Cada uma dessas camadas abstratas precisa de um rótulo para que possa ser identificada de forma exclusiva, e cada um desses componentes gera suas próprias métricas, criando seu conjunto exclusivo de séries temporais.
Além disso, a natureza efêmera das cargas de trabalho no Kubernetes também acaba criando mais séries temporais. Considere a métrica kube_pod_status_phase (uma das métricas padrão do kube), que gera uma nova série temporal cada vez que um pod muda de estado, digamos de “pendente” para “em andamento” para “falhou” ou “bem-sucedido”. Dependendo da taxa de eventos de cluster, especialmente com muitas tarefas de curto prazo, o rastreamento do status de um único pod seria capaz de gerar muitas métricas.
A facilidade de instrumentação e autonomia criada por meio de uma arquitetura de microsserviços às vezes também pode resultar em um aumento na cardinalidade. Com um rico conjunto de exportadores de código aberto, bem como bibliotecas de clientes para mais de 15 linguagens de programação, nunca foi tão fácil instrumentar seu aplicativo para expor as métricas do Prometheus. Com cada equipe capacitada para adicionar métricas à sua aplicação, a governança se torna mais desafiadora. Às vezes, métricas relevantes em um ambiente de desenvolvimento podem entrar em um ambiente de produção e causar um pico nas séries temporais. Com tantas equipes instrumentando suas aplicações, detectar e evitar esses vazamentos torna-se um desafio para uma equipe de observabilidade centralizada.
É apenas o monitoramento nativo da nuvem que resulta em um aumento na cardinalidade das métricas?
Embora a alta cardinalidade seja definitivamente mais comum em ambientes nativos da nuvem, ela também é comum quando a infraestrutura legada, que não seja Prometheus (hardware ou software), é migrada com os exportadores para um formato compatível com Prometheus. Esses exportadores podem gerar um número de métricas extremamente grande, contribuindo para a alta cardinalidade. Por exemplo, o exportador Prometheus Node, que fornece métricas de hardware e sistema operacional, emite, por padrão, cerca de 500 séries temporais Prometheus. O exportador mySQL publica cerca de 1.000 séries temporais e nem todas são valiosas.
Não importa o ambiente, um dos erros mais comuns que vemos é o uso de rótulos abaixo do ideal em bancos de dados de métricas. Como a cardinalidade é um produto cartesiano de dois conjuntos (métricas e rótulos), a forma como os rótulos são definidos ajuda muito a manter a cardinalidade sob controle. Se rótulos gerados aleatoriamente e sem limite superior de valores exclusivos forem usados (por exemplo, se {session_id} for gerado a cada nova conexão), o número de séries temporais poderá aumentar quando o tráfego no sistema aumentar. O mesmo pode ser dito para {user_id} ou {device_id}.
A alta cardinalidade é um sintoma do meio ambiente, mas por que isso é importante?
Um aumento na cardinalidade significa que agora você precisa de mais infraestrutura e computação para armazenar e processar essas séries temporais. Isso, por sua vez, tem um impacto direto sobre o quanto você gasta na sua plataforma de observabilidade. Recentemente, isso tem sido uma prioridade para operadores e equipes de observabilidade centralizadas.
Também afeta o desempenho da sua própria plataforma de observabilidade. À medida que seu banco de dados cresce, o mesmo acontece com o número de séries temporais acessadas em qualquer consulta, o que pode desacelerar muito seu sistema ao consultar ou visualizar seus dados. Painéis com carregamento lento ou consultas que demoram para retornar dados prolongam o MTTR ao solucionar problemas de interrupções.
Observação: a vantagem de usar uma plataforma de observabilidade nativa da nuvem, como a Grafana Cloud, que é alimentada pelo banco de dados de séries temporais mais escalável, o Grafana Mimir, é que você não enfrentará esses problemas de desempenho à medida que a sua contagem de séries temporais aumenta.
Então, como posso controlar o crescimento das métricas?
Como o crescimento das métricas é inevitável e tem consequências no seu resultado, isso levanta a dúvida de como controlar e otimizar métricas e custos crescentes. Como é o caso do monitoramento e da observabilidade, as respostas começam com a visibilidade e os insights corretos sobre os dados.
A seguir estão as três etapas principais para controlar a cardinalidade e os custos das métricas:
1. Obtenha visibilidade das métricas de alta cardinalidade e de métricas valiosas
O primeiro passo para qualquer otimização é ganhar visibilidade sobre quais métricas e rótulos estão contribuindo para a cardinalidade e identificar quais métricas são valiosas. Métricas que são usadas em painéis, alertas e regras de gravação são obviamente necessárias; no entanto, outras só podem ser usadas em consultas para essa finalidade ao solucionar problemas ou quando não são consultadas.
O diagrama abaixo mostra métricas divididas em quatro quadrantes com base na cardinalidade e no valor. Você deve começar ao identificar as métricas no quadrante 3, que possuem um alto custo, mas não estão sendo usadas. Para as métricas no quadrante 4, reavaliar a granularidade e a arquitetura de rótulos pode produzir ótimos retornos para métricas e rótulos que fornecem valor, mas têm alta cardinalidade.
Identificar métricas e rótulos de alta cardinalidade
Os planos Grafana Cloud Pro e Advanced incluem um conjunto de painéis de gestão de cardinalidade para ajudar a identificar métricas e rótulos de alta cardinalidade e orientar seus esforços de otimização.
Para mais informações sobre como monitorar facilmente a cardinalidade com os painéis da Grafana, confira:
- Como gerenciar a cardinalidade com painéis prontos para usar no Grafana Cloud
- Analisar o uso de métricas com painéis de gestão de cardinalidade
Se você usa o Grafana Cloud e deseja saber mais sobre como otimizar suas métricas, entre em contato conosco.
Descobrir métricas não utilizadas
O Mimirtool é uma ferramenta de código aberto que pode ser usada para identificar métricas no Mimir, Prometheus ou em bancos de dados compatíveis com Prometheus que não são usados em painéis, alertas ou regras de gravação. O Mimirtool é executado com uma linha de comando e gera um arquivo JSON com as métricas não utilizadas.
Métricas que não são totalmente usadas podem ser descartadas com segurança, se não forem necessárias em consultas para essa finalidade ou projetos futuros.
Saiba mais sobre como usar o Mimirtool para identificar métricas não utilizadas nos seguintes documentos:
- Como encontrar rapidamente métricas não utilizadas e obter mais valor com o Grafana Cloud
- Analisar e reduzir o uso de métricas com o Grafana Mimirtool
2. Entenda quais equipes são responsáveis pelo crescimento das métricas
Em seguida, você precisa entender quais equipes e ambientes estão contribuindo mais para a cardinalidade na sua organização.
O Grafana Cloud Advanced inclui Insights de Uso para ajudar a identificar as fontes de cardinalidade no seu ambiente. Acompanhe o número de séries temporais que têm um determinado rótulo ou conjunto de rótulos aplicados ao longo do tempo para poder entender como diferentes equipes, ambientes ou aplicativos estão contribuindo para sua contagem geral de séries. Ao fornecer esses dados como uma série temporal, você pode facilmente identificar como uma mudança em um ponto específico no tempo levou a um aumento nos seus custos com observabilidade.
Para mais informações sobre como utilizar grupos de uso para monitorar a alocação de métricas, confira esta publicação do blog:
3. Comece a otimizar suas métricas
Nesta seção, abordaremos como você pode começar a otimizar métricas, após ter visibilidade das métricas e rótulos, resultando em uma alta cardinalidade, e como você pode conseguir identificar métricas de baixo e alto valor.
Inspecione a frequência dos dados
Ao prever os requisitos de capacidade para métricas, é importante considerar seus próprios requisitos de frequência de dados. O scrape_interval padrão do Prometheus leva 15 segundos, ou 4 pontos de dados por minuto (DPM). Mas, se essa frequência não for necessária, a configuração padrão pode resultar em mais dados armazenados do que o previsto.
Para inspecionar seu scrape_interval atual, use a consulta abaixo para encontrar o número de amostras alcançadas no último minuto, dividido por destino:
count_over_time(scrape_samples_scraped[1m])
Em seguida, você pode inspecionar essas métricas e aumentar o scrape_interval para métricas menos importantes a fim de reduzir custos. Muitas vezes, métricas menos importantes podem ser definidas para um scrape_interval de 60 segundos, o que pode reduzir os custos em até 75%.
Para mais informações sobre como ajustar os scrape_intervals, consulte nossa documentação:
Inspecionar histogramas
Os histogramas permitem que você entenda a distribuição de uma certa quantidade. A precisão dessa distribuição é determinada pelo número de buckets que você tem nesse histograma. No Prometheus, cada bucket é rastreado como uma série temporal que tem um valor específico do rótulo le (menor ou igual a).
Usando o painel de gestão de cardinalidade do Grafana, no Grafana Cloud, podemos ver os valores para o rótulo le e como isso contribui para a cardinalidade em geral. Escolha buckets que são mais relevantes para o seu ambiente. Por exemplo, se o SLO para um serviço for um tempo de resposta de 50 ms, talvez você não precise fazer distinção entre solicitações que levam 5 ms e 10 ms.
Você pode descartar com segurança a série de métricas para buckets que não são necessários. Isso não resultará em perda de dados, pois os buckets são cumulativos. Por exemplo, se você descartar o bucket “menor ou igual a 10”, esses valores serão simplesmente incluídos no bucket “menor ou igual a 25”. Se esse nível de dimensionalidade não for necessário, você pode descartar com segurança o valor 10 para o rótulo le.
A seguir está um exemplo de uma configuração de re-rotulagem:
# descarte todas as séries de métricas que terminam com _bucket e onde le = "10"
- source_labels: [__name__, le]
separator: _
regex: ".+_bucket_10"
action: "drop"
Para mais informações sobre como reduzir o uso de métricas do Prometheus e a configuração de novos rótulos, confira nossa documentação:
Reduzir rótulos
Não é tão simples descartar rótulos de métricas que não estão sendo usados. Descartar um rótulo pode resultar em séries duplicadas, que serão descartadas pelo Prometheus. Veja os exemplos abaixo. No primeiro exemplo, você pode descartar com segurança o rótulo ip, pois as séries restantes são únicas. No entanto, no segundo exemplo, você pode ver como descartar o rótulo ip criará séries temporais duplicadas, que o Prometheus descartará. Neste exemplo, o Prometheus receberá valores de 1, 3 e 7 para my_metric_total com o mesmo registro de hora e descartará 2 dos pontos de dados.
# Você pode descartar o rótulo ip e as séries restantes ainda são únicas
my_metric_total{env=“dev”, ip=“1.1.1.1"} 12
my_metric_total{env=“tst”, ip=“1.1.1.1"} 14
my_metric_total{env=“prd”, ip=“1.1.1.1"} 18
# Valores restantes após descartar o rótulo ip
my_metric_total{env=“dev”} 12
my_metric_total{env=“tst”} 14
my_metric_total{env=“prd”} 18
# Você não pode descartar o rótulo ip e as séries restantes não são únicas
my_metric_total{env=“dev”, ip=“1.1.1.1"} 1
my_metric_total{env=“dev”, ip=“3.3.3.3"} 3
my_metric_total{env=“dev”, ip=“5.5.5.5"} 7
# Valores restantes após descartar o rótulo ip não são únicos
my_metric_total{env=“dev”} 1
my_metric_total{env=“dev”} 3
my_metric_total{env=“dev”} 7Você pode descartar rótulos com segurança, se isso não resultar em séries duplicadas.
Em ambientes onde você tem controle do aplicativo, você pode reconfigurar os agentes usados para a coleção de métricas para descartar rótulos que não são usados.
Se você não tiver controle do aplicativo e os rótulos descartados resultarem em séries duplicadas, a aplicação de uma função (ou seja, soma, média, mín, máx) por meio das regras de gravação do Prometheus pode permitir que você mantenha os dados agregados, enquanto descarta séries individuais. No exemplo abaixo, usamos a função soma para armazenar a métrica agregada, permitindo que descartemos as séries temporais individuais.
# soma por env
my_metric_total{env="dev", ip="1.1.1.1"} 1
my_metric_total{env="dev", ip="3.3.3.3"} 3
my_metric_total{env="dev", ip="5.5.5.5"} 7
# Regra de gravação
sum by(env) (my_metric_total{})
my_metric_total{env="dev"} 11Saiba mais sobre como reduzir as regras de gravação do Prometheus e re-rotular a configuração nos seguintes recursos:
- Regras de gravação do Prometheus
- Reduzir o uso de métricas do Prometheus com a rerrotulagem
- Como funciona a rerrotulagem no Prometheus
Saiba mais sobre como gerenciar métricas no Prometheus e no Kubernetes com o Grafana Cloud
Para começar a entender a cardinalidade no seu ambiente, ao atribuir custos a equipes e ambientes e otimizar seus custos de métricas, inscreva-se no Grafana Cloud. Isso inclui um teste grátis de 14 dias do Grafana Cloud Pro, para que você possa testar os painéis de gestão de cardinalidade, grupos de uso e outras tecnologias no seu ambiente.
Para mais informações sobre como controlar os custos de métricas nos ambientes Prometheus e Kubernetes, confira nosso webinário “Como controlar o crescimento das métricas no Prometheus e Kubernetes com o Grafana Cloud” sob demanda.
Se você usa o Grafana Cloud e deseja saber mais sobre como podemos ajudar você em sua jornada de otimização de métricas, entre em contato conosco.