Remote Write

3. Remote Write #

Envoi des données vers Grafana Cloud ou une instance locale.

Envoyer vers Mimir, Prometheus ou Grafana Cloud #

prometheus.remote_write envoie les métriques vers tout backend compatible. Il écrit d'abord dans un journal sur disque (WAL), puis expédie depuis ce journal : une panne du backend ne fait donc pas perdre les données immédiatement.

prometheus.remote_write "mimir" {
  external_labels = { region = "eu-west" }

  endpoint {
    url = "https://mimir.example.com/api/v1/push"

    basic_auth {
      username = sys.env("MIMIR_USER")
      password = sys.env("MIMIR_PASSWORD")
    }

    queue_config {
      capacity             = 10000
      max_shards           = 10
      max_samples_per_send = 2000
    }

    write_relabel_config {
      source_labels = ["__name__"]
      regex         = "up|node_.*"
      action        = "keep"
    }
  }

  wal {
    truncate_frequency = "2h"
    max_keepalive_time = "8h"
  }
}

Les réglages utiles #

En cas de panne : les données sont conservées environ 8 heures par défaut, et le disque grossit pendant ce temps. Prévoyez l'espace pour --storage.path.

Filtrer par destination #

write_relabel_config filtre pour un seul backend. Nous l'avons mesuré en envoyant les mêmes données vers deux destinations : celle qui ne gardait que up et alloy_build_info a reçu 8 échantillons, l'autre 1765. C'est le moyen le plus simple de réduire une facture de stockage.

Superviser l'envoi #

# Échantillons qui n'arrivent pas à partir (à alerter)
rate(prometheus_remote_storage_samples_failed_total[5m]) > 0

# File d'attente vers le backend
prometheus_remote_storage_samples_pending

# Cibles collectées
prometheus_scrape_targets_gauge

Bonne pratique : mettez les mots de passe dans l'environnement ou un fichier (voir Gestion des secrets), et rendez --storage.path persistant : sans cela, le WAL disparaît au redémarrage du conteneur.