Supervision des serveurs : Grafana, journaux et alertes — maîtrise de votre infrastructure

Votre serveur tourne, votre application fonctionne — et puis c'est le silence. Jusqu'au moment où un client vous appelle parce que le site est hors ligne depuis vingt minutes. Ça vous parle ? La supervision de serveur est la différence entre réagir aux problèmes et les prévenir. Dans cet article, vous apprendrez comment mettre en place une stack de supervision solide avec Grafana, comment gérer efficacement les logs et comment configurer des alertes vraiment utiles — sans que votre boîte mail ne soit submergée de faux positifs.

Nous nous concentrons sur l'implémentation pratique. Pas de théorie pour la galerie, mais des étapes concrètes que vous pouvez appliquer dès aujourd'hui sur votre VPS, votre serveur dédié ou votre infrastructure sur site.

Pourquoi la supervision de serveur n'est pas une option, mais une nécessité

Un serveur sans supervision, c'est comme conduire sans tableau de bord. Vous roulez peut-être bien, mais vous ne voyez que le réservoir est vide quand le moteur s'arrête. La supervision de serveur vous donne une visibilité sur l'utilisation du CPU, la mémoire, l'espace disque, le trafic réseau et le comportement des applications — en temps réel et de manière historique.

Les problèmes les plus courants que la supervision met en lumière :

• Les fuites de mémoire qui étouffent lentement mais sûrement votre serveur
• Les disques qui se remplissent à cause de logs ou de sauvegardes qui ne vont nulle part
• Les pics de CPU dus à des processus incontrôlés ou à une augmentation soudaine du trafic
• Les services en échec qui se redémarrent tout seuls sans que vous le remarquiez
• Les problèmes réseau comme la perte de paquets ou la latence qui ralentissent les applications

Avec une bonne supervision de serveur, vous traitez ces problèmes avant que les utilisateurs n'en souffrent. C'est la promesse — et elle est tout à fait réalisable avec la bonne stack d'outils.

La stack de supervision : Prometheus, Grafana et les exporters

Le standard de facto pour la supervision open-source de serveurs combine Prometheus comme collecteur de métriques avec Grafana comme couche de visualisation. Prometheus récupère les métriques de vos serveurs et applications via ce qu'on appelle des exporters. Grafana transforme ces données brutes en tableaux de bord compréhensibles et gère vos règles d'alerte.

Étape 1 : Installer Prometheus et Node Exporter

Le node_exporter est votre premier point de contact pour les métriques système. Installez-le sur chaque serveur que vous souhaitez superviser :

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.1/node_exporter-1.8.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.8.1.linux-amd64.tar.gz
sudo mv node_exporter-1.8.1.linux-amd64/node_exporter /usr/local/bin/
sudo useradd -rs /bin/false node_exporter

Créez ensuite un service systemd pour que l'exporter démarre automatiquement :

[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

Après systemctl enable --now node_exporter, vos métriques système sont disponibles sur le port 9100. Prometheus les récupère selon l'intervalle que vous configurez — par défaut toutes les 15 secondes.

Étape 2 : Installer Grafana et le connecter

Vous installez Grafana le plus simplement via le dépôt apt officiel :

sudo apt-get install -y apt-transport-https software-properties-common
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update && sudo apt-get install grafana
sudo systemctl enable --now grafana-server

Grafana tourne maintenant sur le port 3000. Connectez-vous avec admin/admin et modifiez immédiatement le mot de passe. Ajoutez Prometheus comme source de données via Configuration → Data Sources → Add data source, remplissez l'URL de votre instance Prometheus et cliquez sur Save & Test.

Pour un ensemble de départ complet de tableaux de bord, importez l'ID de tableau de bord 1860 — le tableau de bord complet Node Exporter. Cela vous donne d'un coup une vue d'ensemble du CPU, de la RAM, des I/O disque, du réseau et plus encore, entièrement mis en forme et prêt à l'emploi.

Centraliser les logs : du chaos à la clarté

Les métriques vous disent ce qui se passe ; les logs vous disent pourquoi. Une bonne stratégie de supervision de serveur inclut toujours les deux. Le problème avec les logs, c'est qu'ils sont dispersés : /var/log/syslog, les logs d'application, les logs Nginx, les logs des conteneurs Docker — tous à des endroits différents et dans des formats différents.

La solution, c'est l'agrégation de logs. La stack la plus utilisée pour cela dans l'écosystème Grafana est Loki en combinaison avec Promtail comme expéditeur de logs.

Mettre en place Loki et Promtail

Loki stocke vos logs dans un format optimisé que vous pouvez interroger directement depuis Grafana. Promtail lit vos fichiers de logs et les envoie à Loki. Une configuration Promtail minimale pour les logs Nginx ressemble à ceci :

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets: [localhost]
        labels:
          job: nginx
          __path__: /var/log/nginx/*.log

Une fois actif, ajoutez Loki comme deuxième source de données dans Grafana. Ensuite, dans l'écran Explore, vous pouvez directement exécuter des requêtes sur vos logs avec LogQL — le langage de requête de Loki qui ressemble fortement à PromQL.

Une requête pratique pour trouver toutes les erreurs 500 de Nginx :

{job="nginx"} |= "HTTP/1.1\" 5"

Combinez cela avec une métrique Prometheus qui suit le nombre de requêtes et vous avez dans un seul dashboard à la fois l'image quantitative (combien d'erreurs) et l'image qualitative (quelles requêtes échouent et pourquoi).

Configurer des alertes que votre équipe prend vraiment au sérieux

La supervision de serveurs n'est efficace que si vous êtes également averti à temps. Grafana dispose d'un moteur d'alerting intégré qui vous permet de définir des règles sur la base à la fois des métriques Prometheus et des logs Loki. Le grand danger de l'alerting est la fatigue d'alerte : trop de notifications qui signifient trop peu, ce qui fait que les gens les ignorent structurellement — et alors vous ratez la notification qui compte vraiment.

Règles de base pour des alertes efficaces

• Alertez sur les symptômes, pas sur les causes. « Le site web ne répond pas » est plus pertinent que « le CPU est à 95 % ». Les pics de CPU peuvent être légitimes ; un site injoignable est toujours un problème.
• Utilisez des seuils avec une marge. Définissez une alerte sur une utilisation de la mémoire au-dessus de 85 % pendant au moins 5 minutes, pas lors d'un pic court de 90 %.
• Distinguez les niveaux de sévérité. Utilisez warning pour les situations qui demandent de l'attention et critical pour les situations qui exigent une action immédiate. Envoyez-les via des canaux différents — Slack pour les warnings, PagerDuty ou SMS pour les critical.
• Testez vos alertes activement. Une alerte que vous n'avez jamais vue se déclencher ne fonctionne probablement pas.

Créer une règle d'alerte Grafana pratique

Dans Grafana, allez dans Alerting → Alert Rules → New alert rule. Choisissez votre source de données Prometheus et entrez comme requête :

(node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15

Cela déclenche une alerte lorsque moins de 15 % d'espace disque est disponible sur la partition racine. Définissez l'intervalle d'évaluation sur 1m et la période en attente sur 5m — cela évite qu'une anomalie courte déclenche immédiatement une alarme. Associez un point de contact à la règle, configurez votre webhook Slack ou votre adresse e-mail, et votre première alerte sérieuse est en ligne.

Outils complémentaires : Netdata et Glances pour une vision en temps réel

En plus de la pile Prometheus/Grafana, deux outils méritent d'être mentionnés pour des cas d'utilisation spécifiques.

Netdata offre une supervision de serveurs en temps réel avec un poids d'installation étonnamment faible. Avec une seule commande, vous avez un dashboard complet :

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

Netdata est idéal pour un diagnostic rapide et des environnements plus petits. L'inconvénient est que les données historiques sont limitées par défaut — pour les tendances à long terme, Prometheus/Grafana reste le meilleur choix.

Glances est un outil en ligne de commande qui vous donne un aperçu direct de toutes les ressources système dans un seul écran. Si vous le lancez avec glances -w, il fonctionne comme serveur web et vous pouvez également y accéder via le navigateur. Idéal pour la situation où vous voulez vérifier quelque chose rapidement sans ouvrir un dashboard complet.

Conclusion : la supervision de serveurs comme fondement, pas comme accessoire

Une supervision de serveurs efficace se construit par couches. Grafana et Prometheus forment le fondement pour les métriques et les alertes. Loki et Promtail vous donnent une prise sur vos logs. Des outils comme Netdata et Glances comblent les lacunes pour le diagnostic en temps réel et les vérifications rapides.

Les points clés à retenir :

• Commencez avec Node Exporter + Prometheus + Grafana — ce trio couvre 80 % de vos besoins en supervision
• Ajoutez Loki dès que vous voulez corréler les logs avec les métriques
• Configurez des alertes sur les symptômes, pas sur les métriques de ressources brutes
• Utilisez des niveaux de sévérité et envoyez-les via les canaux appropriés
• Testez vos alertes régulièrement — une alerte silencieuse est une alerte inutile

La supervision de serveurs n'est pas un projet ponctuel mais un système vivant. Ajoutez de nouveaux exporters lorsque vous déployez de nouveaux services, affinez vos seuils d'alerte sur la base de modèles réels et examinez vos dashboards périodiquement. Ainsi, vous construisez une infrastructure qui ne vous surprend pas — mais qui vous informe.