1. Introduction
Superviser l'hôte local
Le besoin
Pourquoi collecter en local ?
Bien que Grafana Alloy excelle dans le routage de télémétrie distante, sa première utilité est souvent de superviser la machine sur laquelle il est installé. Alloy embarque nativement des intégrations (similaires à node_exporter ou promtail) pour collecter l'utilisation CPU/RAM, l'espace disque, et lire les fichiers de logs systèmes (comme /var/log/syslog) ou ses propres logs de fonctionnement.
2. L'approche par l'interface Web (UI)
Simple mais fortement déconseillée en production
Le piège de la facilité
Add Connection -> Linux
Dans Grafana (et particulièrement Grafana Cloud), vous disposez d'un menu Connections > Add new connection qui propose de configurer un serveur Linux en quelques clics. L'interface génère alors une longue commande Bash à copier-coller sur votre serveur, qui installe Alloy et télécharge une configuration River générée automatiquement.
Pourquoi l'éviter ?
Les limites de l'assistant
Bien que cette méthode soit idéale pour un test rapide (PoC), elle présente des risques majeurs en entreprise :
- Absence de versionning (GitOps) : La configuration échappe à votre contrôle de version (Git). Si quelqu'un modifie la configuration depuis l'UI, vous créez une dérive (configuration drift).
- Opacité : Le script installe et configure des composants implicitement. En cas d'erreur de parsing ou de droits, le dépannage est complexe.
- Incompatibilité avec l'automatisation : En production, le déploiement doit être industrialisé via Ansible, Terraform, ou Helm, ce que l'assistant graphique rend obsolète.
3. L'approche "Configuration as Code" (River)
La méthode recommandée
Collecter les métriques système (CPU, RAM...)
Utilisation de prometheus.exporter.unix
Alloy intègre un équivalent de node_exporter. Pour collecter les métriques locales et les envoyer vers Mimir ou Prometheus, ajoutez ce bloc :
// 1. Activation de l'exportateur système
prometheus.exporter.unix "local_system" {
enable_collectors = ["cpu", "meminfo", "diskstats", "netdev"]
}
// 2. Scraping des métriques exposées en local
prometheus.scrape "scrape_system" {
targets = prometheus.exporter.unix.local_system.targets
forward_to = [prometheus.remote_write.mimir.receiver]
scrape_interval = "15s"
}
// 3. Point de destination
prometheus.remote_write "mimir" {
endpoint {
url = "http://mon-mimir:9009/api/v1/push"
}
}Collecter les logs du système
Fichiers locaux vers Loki
Pour collecter les logs classiques d'un système Linux (auth.log, syslog) :
local.file_match "system_logs" {
path_targets = [
{"__path__" = "/var/log/syslog"},
{"__path__" = "/var/log/auth.log"}
]
}
loki.source.file "read_logs" {
targets = local.file_match.system_logs.targets
forward_to = [loki.write.loki_endpoint.receiver]
}
loki.write "loki_endpoint" {
endpoint {
url = "http://mon-loki:3100/loki/api/v1/push"
}
}Note : Assurez-vous que l'utilisateur système alloy a les droits de lecture sur /var/log (ex: via le groupe adm).
Auto-supervision : Les logs d'Alloy
Surveiller le collecteur lui-même
Si Alloy est lancé en tant que service systemd, la méthode la plus robuste pour récupérer ses propres logs et détecter s'il a des problèmes est de lire journald :
loki.source.journal "alloy_journal" {
format_as_json = true
max_age = "12h"
forward_to = [loki.write.loki_endpoint.receiver]
relabel_rules = discovery.relabel.journal_filter.rules
}
discovery.relabel "journal_filter" {
// Ne garder que les logs du service systemd "alloy"
rule {
source_labels = ["__journal__systemd_unit"]
regex = "alloy\\.service"
action = "keep"
}
// Renommer le label pour Loki
rule {
source_labels = ["__journal__systemd_unit"]
target_label = "unit"
}
}4. Conclusion
Les bénéfices du code
La maîtrise totale
Ce qu'il faut retenir
En écrivant vous-même vos fichiers .river plutôt qu'en utilisant l'interface génératrice de Grafana, vous comprenez exactement quel composant fait quoi. Cela vous permet :
- D'isoler facilement un problème si la consommation CPU d'Alloy explose.
- De versionner votre configuration sur Git.
- De la déployer dynamiquement avec des outils comme Ansible en remplaçant les endpoints (Mimir/Loki) par des variables propres à chaque environnement.