Observabilité d'Alloy

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
}

Explication des blocs :

• prometheus.exporter.unix : Collecte et expose les métriques du système d'exploitation hôte (CPU, mémoire, etc.).
• prometheus.scrape : Récupère à intervalles réguliers les métriques exposées par l'exportateur.
• prometheus.remote_write : Définit la destination pour envoyer les métriques collectées vers une base de données compatible Prometheus (comme Mimir).

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

Explication des blocs :

• prometheus.exporter.self : Expose les métriques de santé et de performance internes du processus Alloy lui-même.
• prometheus.scrape : Utilise la fonction concat() pour regrouper les cibles système et internes dans un seul job de scraping simplifié.

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
}

Explication des blocs :

• discovery.relabel : Définit une règle pour conserver uniquement les logs provenant de l'unité systemd alloy.service.
• loki.source.journal : Se connecte au journal systemd de la machine locale pour en lire le contenu en continu.
• loki.write : Indique l'URL et les paramètres de destination pour expédier les logs vers 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]
}

Explication des blocs :

• local.file_match : Cible le ou les fichiers de logs locaux à l'aide d'un chemin spécifique ou d'un masque.
• loki.source.file : Suit les modifications de ces fichiers (tail) pour en extraire et transférer les nouvelles lignes en temps réel.

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)

Explication des blocs :

• pyroscope.scrape : Se connecte à l'endpoint de profilage standard (pprof) exposé par Alloy sur le port 12345 pour récupérer les profils de performance (CPU, mémoire).
• pyroscope.write : Route et écrit ces profils vers un backend compatible comme Grafana Pyroscope.

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.