Como solucionar problemas de dados ausentes no meu banco de dados do Prometheus?

Gradualmente, integrei o Prometheus nos meus fluxos de trabalho de monitoramento, a fim de reunir métricas detalhadas sobre a infraestrutura em execução.

Durante isso, notei que frequentemente encontro um problema peculiar: às vezes um exportador do qual Prometheus deve extrair dados fica sem resposta. Talvez por causa de uma configuração incorreta da rede - ela não esteja mais acessível - ou apenas porque o exportador caiu.

Qualquer que seja o motivo, acho que alguns dos dados que espero ver em Prometheus estão ausentes e não há nada na série por um determinado período de tempo. Às vezes, um exportador que falha (excede o tempo limite?) Também parece causar a falha de outros (o primeiro tempo limite levou o trabalho inteiro acima do tempo limite de nível superior - apenas especulando).

Tudo o que vejo é uma lacuna na série, como mostrado na visualização acima. Não há nada no log quando isso acontece. As auto-métricas de Prometheus também parecem bastante estéreis. Eu apenas tive que recorrer à tentativa de replicar manualmente o que Prometheus está fazendo e ver onde ele quebra. Isso é cansativo. Deve haver uma maneira melhor! Embora não precise de alertas em tempo real, quero pelo menos poder ver que um exportador falhou ao fornecer dados. Mesmo um sinalizador "ei, verifique seus dados" booleano seria um começo.

Como obtenho informações significativas sobre o Prometheus não obter dados de exportadores? Como entendo por que existem lacunas sem ter que executar uma simulação manual da coleta de dados do Prometheus? Quais são as práticas sensatas a esse respeito, talvez mesmo quando estendidas ao monitoramento da coleta de dados em geral, além do Prometheus?

Eu acho que você pode alertar uma métrica ratecom algo assim:

ALERT DropInMetricsFromExporter
  IF rate(<metric_name>[1m]) == 0
  FOR 3m
  ANNOTATIONS {
    summary = "Rate of metrics is 0 {{ $labels.<your_label> }}",
    description = "Rate of metric dropped, actually: {{ $value }}%",
}

A idéia principal é alertar sempre que a taxa de métrica estiver em 0 por 3 minutos, com o nome da métrica adequado e um rótulo informando de qual exportador ele deve fornecer as informações corretas.

A escolha da métrica certa a ser monitorada pelo exportador pode ser complexa, sem mais informações é difícil dar um conselho melhor a partir do vácuo.
Esta postagem no blog também pode ser uma inspiração para uma detecção mais genérica.

Existem algumas razões que podem ter causado a lacuna. Provavelmente, o exportador não está acessível e, nesse caso, as upséries temporais serão 0. Você pode alertar sobre isso desta maneira (obtido em https://prometheus.io/docs/alerting/rules/#templating ):

# Alert for any instance that is unreachable for >5 minutes.
ALERT InstanceDown
  IF up == 0
  FOR 5m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }

Na página de status, você também verá que está inativo, incluindo uma mensagem de erro. Infelizmente, não há como ver o erro passado, mas há um problema para acompanhar isso: https://github.com/prometheus/prometheus/issues/2820

O servidor do Prometheus também pode ser sobrecarregado, causando a interrupção da raspagem, o que também explicaria as lacunas. Nesse caso, você deverá ver Storage needs throttling. Scrapes and rule evaluations will be skipped.erros no log e aumentos nas prometheus_target_skipped_scrapes_totalmétricas. Você também deve alertar sobre isso, por exemplo:

ALERT PrometheusSkipsScrapes
  IF rate(prometheus_target_skipped_scrapes_total[2m]) > 0
  FOR 5m

Não tenho certeza se esse é o mesmo problema que você está vendo. Mas vimos essas lacunas aleatórias para aplicativos Java que não definiam especificamente as configurações do GC. Isso significa que estávamos vendo lacunas quando a coleta de dados foi interrompida porque a atividade da instância foi interrompida enquanto a JVM estava executando um GC completo. Se você estiver usando Java, isso pode acontecer. Nossa correção foi usar explicitamente o coletor de lixo G1 (Java 8+) com um limite especificado no comprimento da atividade do GC para evitar esses intervalos de tempo na coleta de dados.