Grafana Alloy : L'importance de l'auto-supervision (Self-Monitoring)

Publié le : 24/10/2024 à 10:00

1. Introduction : Pourquoi superviser le superviseur ?

Votre collecteur de télémétrie est une brique critique de votre infrastructure d'observabilité. S'il tombe en panne ou se dégrade silencieusement, vous perdez toute visibilité sur vos applications. L'auto-supervision consiste à traiter Grafana Alloy comme n'importe quelle autre application critique : en surveillant sa santé, ses performances et ses erreurs.

Les risques d'un collecteur non surveillé

• Perte de données silencieuse : Un composant mal configuré peut cesser d'envoyer des données sans générer d'erreur visible.
• Consommation excessive de ressources : Un pipeline de logs inefficace peut entraîner une surconsommation de CPU ou de RAM, impactant les autres applications sur le même hôte.
• Erreurs de configuration : Des erreurs de syntaxe dans un fichier .river peuvent empêcher le rechargement de la configuration.

Le self-monitoring permet de détecter ces problèmes de manière proactive.

2. Collecter les métriques d'Alloy

Alloy expose ses propres métriques de santé et de performance au format Prometheus, ainsi que celles de l'hôte.

Métriques de l'hôte (CPU, RAM, Disque)

Le composant prometheus.exporter.unix (similaire à node_exporter) est idéal pour collecter les métriques de base du système sur lequel Alloy est installé.

// Expose les métriques du système (CPU, mémoire, disque, réseau)
prometheus.exporter.unix "local_system" {}

// Scrape les métriques exposées par l'exportateur ci-dessus
prometheus.scrape "scrape_system" {
  targets    = prometheus.exporter.unix.local_system.targets
  forward_to = [prometheus.remote_write.mimir.receiver]
}

prometheus.remote_write "mimir" {
  // ... votre configuration d'endpoint Mimir/Prometheus
}

Métriques internes d'Alloy

Alloy expose ses propres métriques internes de santé et de performance.

ATTENTION : Ne pas utiliser l'UI (ex : {"__address__" = "localhost:12345", "job" = "alloy"}) pour collecter les métriques car cette dernière peut être désactivée. Il faut plutôt utiliser prometheus.exporter.self pour collecter les métriques.

Utilisez le composant prometheus.exporter.self et ajoutez-le à vos cibles de scraping.

// Expose les métriques internes d'Alloy
prometheus.exporter.self "alloy_internal" {}

prometheus.scrape "scrape_alloy_and_system" {
  targets = concat(
    prometheus.exporter.unix.local_system.targets,
    prometheus.exporter.self.alloy_internal.targets
  )
  forward_to = [prometheus.remote_write.mimir.receiver]
}

// Métriques clés à surveiller :
// - alloy_component_health : Santé de chaque composant (0=unhealthy, 1=healthy)
// - process_cpu_seconds_total : Temps CPU consommé par Alloy
// - process_resident_memory_bytes : Mémoire RAM utilisée par Alloy

3. Collecter les logs d'Alloy

Capturer les logs produits par Alloy est essentiel pour diagnostiquer les erreurs de configuration ou les problèmes d'exécution.

Méthode recommandée : via journald

Si Alloy est exécuté en tant que service systemd, la meilleure méthode est de lire directement le journal système.

// Découvre et filtre les logs du service 'alloy.service'
discovery.relabel "journal_filter" {
  rule {
    source_labels = ["__journal__systemd_unit"]
    regex         = "alloy\\.service"
    action        = "keep"
  }
}

// Lit les logs depuis journald
loki.source.journal "read_alloy_logs" {
  forward_to = [loki.write.loki_endpoint.receiver]
  relabel_rules = discovery.relabel.journal_filter.rules
}

loki.write "loki_endpoint" {
  // ... votre configuration d'endpoint Loki
}

Alternative : via un fichier local

Si vous redirigez la sortie standard d'Alloy vers un fichier (ex: /var/log/alloy.log), vous pouvez utiliser loki.source.file.

local.file_match "alloy_log_file" {
  path_targets = [{"__path__" = "/var/log/alloy.log"}]
}

loki.source.file "read_from_file" {
  targets    = local.file_match.alloy_log_file.targets
  forward_to = [loki.write.loki_endpoint.receiver]
}

N'oubliez pas de configurer une rotation de logs pour éviter de saturer le disque.

4. Collecter les Traces et Profils (Profiling)

Pour un débogage avancé des performances, Alloy peut exposer des profils de performance via son interface web.

Activer le profiling avec pprof

Les endpoints de profiling (pprof) sont disponibles sur l'interface web d'Alloy.

ATTENTION : Tout comme pour les métriques, se fier à l'UI locale (ex : {"__address__" = "localhost:12345"}) pour le profiling peut être risqué si elle est désactivée en production. Assurez-vous qu'elle soit active si vous utilisez pyroscope.scrape.

pyroscope.scrape "alloy_profiling" {
  targets = [
    {"__address__" = "localhost:12345", "job" = "alloy"}
  ]
  forward_to = [pyroscope.write.pyroscope_endpoint.receiver]
}

pyroscope.write "pyroscope_endpoint" {
  endpoint {
    url = "http://pyroscope:4040/api/v1/push"
  }
}

// Profils collectés : 
// - alloy_process_cpu : Profil d'utilisation CPU
// - alloy_process_mem : Profil d'allocation mémoire (heap)

La collecte de traces internes d'Alloy est un cas d'usage très avancé, généralement réservé au développement du produit lui-même. Pour la plupart des utilisateurs, les métriques et les profils sont suffisants pour le self-monitoring.

5. Conclusion : Une boucle de confiance

En configurant Grafana Alloy pour qu'il se supervise lui-même, vous créez une boucle de confiance. Vous pouvez non seulement valider que votre collecteur fonctionne correctement, mais aussi optimiser ses performances et être alerté immédiatement en cas de problème. C'est une étape fondamentale pour construire une plateforme d'observabilité robuste et fiable.