Alta disponibilidade (HA) do Prometheus

Se você estiver usando nossa integração de gravação remota do Prometheus em uma configuração de alta disponibilidade (HA), será necessário garantir que seus servidores Prometheus não estejam enviando várias cópias da mesma métrica para New Relic. Este documento descreve como você pode configurar sua integração de gravação remota para que New Relic não mantenha métricas duplicadas.

Referência rápida

O New Relic desduplica as réplicas de HA usando três valores. É necessário definir todos os três em cada réplica em um cluster de alta disponibilidade:

Como funciona: a New Relic organiza as réplicas em clusters de HA com base na conta, no rótulo prometheus e no parâmetro prometheus_server. Em cada cluster, a New Relic designa uma réplica como líder e armazena apenas os dados desse líder. O líder é identificado pelo rótulo prometheus_replica.

Configurar a Desduplicação

Operador Prometeu

O Prometheus Operator versão 0.19.0 ou superior adiciona os rótulos externos prometheus e prometheus_replica automaticamente, quer se utilize o operador diretamente ou por meio do helm chart:

• prometheus é definido como <prometheus deployment namespace>/<prometheus deployment name>. Por exemplo, uma implantação chamada prometheus-cluster1 no namespace monitoring produz monitoring/prometheus-cluster1.
• prometheus_replica é definido para o nome do pod de cada réplica, no formato replica-<replica number> (por exemplo, replica-1).

É necessário definir prometheus_server manualmente na configuração remoteWrite no recurso Prometheus, usando o mesmo valor para cada réplica. Por exemplo, este recurso executa um par de HA de duas réplicas com um único bloco remoteWrite, de modo que prometheus_server permaneça consistente em ambas as réplicas:

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: monitoring-cluster
  namespace: monitoring
spec:
  replicas: 2
  remoteWrite:
    - url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=prod-monitoring
      authorization:
        credentials:
          name: nr-license-key
          key: licenseKey

O operador então define prometheus como monitoring/monitoring-cluster e prometheus_replica como o nome do pod de cada réplica automaticamente — é necessário fornecer apenas prometheus_server. Caso utilize o helm chart kube-prometheus-stack, defina o mesmo bloco remoteWrite em prometheus.prometheusSpec.

Prometeu autônomo

Adicione os rótulos externos ao arquivo de configuração de cada réplica e use uma URL remote_write idêntica — incluindo o parâmetro prometheus_server — em todas as réplicas.

Replica 1 (prometheus.yml)

global:
  external_labels:
    prometheus: monitoring-cluster
    prometheus_replica: replica-1

remote_write:
  - url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=prod-monitoring
    authorization:
      credentials: YOUR_LICENSE_KEY

Replica 2 (prometheus.yml)

global:
  external_labels:
    prometheus: monitoring-cluster
    prometheus_replica: replica-2

remote_write:
  - url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=prod-monitoring
    authorization:
      credentials: YOUR_LICENSE_KEY

Apenas prometheus_replica difere entre as duas réplicas; prometheus e prometheus_server são idênticos.

Limitações

É necessário manter prometheus_server idêntico entre as réplicas. Como o New Relic usa prometheus_server para agrupar réplicas, atribuir valores diferentes às réplicas — por exemplo, por host ou por pod — coloca cada uma em seu próprio grupo de HA. Cada réplica se torna o único membro de seu grupo, é sempre eleita líder e retém todos os seus dados. O resultado são dados duplicados no New Relic sem nenhum erro ou aviso, já que cada réplica aparece como um líder íntegro e independente. Para distinguir réplicas individuais, deve-se usar o rótulo prometheus_replica em vez disso.

Uma conta pode ter até 1.500 clusters Prometheus HA únicos, contados por combinação única de conta, rótulo prometheus e parâmetro prometheus_server. Exceder esse limite faz com que os dados de clusters de HA adicionais sejam descartados, e a New Relic gera PrometheusHAClusterLimit eventos NrIntegrationError. Manter prometheus_server consistente entre as réplicas também evita que um único grupo de HA consuma vários slots nesse limite.

Resolução de problemas

Prometheus Operator não define prometheus_server — esse valor vem inteiramente da configuração de remoteWrite no recurso Prometheus. Quando todas as réplicas compartilham um único bloco remoteWrite (o caso normal), isso é consistente por padrão. Caso sejam injetadas sobrescritas de remoteWrite por réplica, é necessário garantir que prometheus_server seja igual em todas elas.

Se ainda forem observadas cópias duplicadas de dados de réplica, é necessário garantir que não haja replicaExternalLabelName ou prometheusExternalLabelName na especificação Prometheus ou na configuração do chart, pois essas substituições alteram o nome do rótulo.

Para uma desduplicação mais consistente, o Prometheus scrape_interval deve ser mantido em 60 segundos ou menos. O New Relic identifica a réplica ativa em cada cluster de HA a partir dos dados recebidos mais recentemente, e a gravação remota de Prometheus encaminha novas amostras cerca de uma vez por coleta. Se um cluster enviar dados com menos frequência do que isso, o New Relic pode não reconhecer consistentemente o mesmo líder e pode reter dados duplicados ou intercalados de mais de uma réplica, sem que nenhum erro seja apresentado.