Surveillance de serveur avec Grafana : configurer les logs, les métriques et les alertes

Le serveur tourne, votre application est en ligne, et tout semble en ordre. Jusqu’au moment où un client vous appelle parce que le site est down depuis vingt minutes — et vous êtes le dernier à le savoir. Reconnaissable ? Alors il est temps de prendre au sérieux la supervision de serveur. Avec les bons outils, vous voyez les problèmes arriver avant qu’ils ne deviennent des incidents, et vous savez exactement ce qui se passe sur votre infrastructure.

Dans cet article, nous explorons une stack de supervision pratique avec Grafana comme cœur de vos dashboards et de votre alerting, complétée par la bonne agrégation de logs et des métriques en temps réel. Que vous gériez un seul VPS ou un cluster de dizaines de serveurs — les principes sont les mêmes.

Pourquoi la supervision de serveur n’est pas optionnelle

Beaucoup de développeurs et d’administrateurs système supervisent de manière réactive : ce n’est que quand quelque chose casse qu’ils se mettent à chercher. C’est compréhensible quand on est occupé, mais c’est aussi inutilement coûteux. Les temps d’arrêt coûtent de l’argent, de la réputation et des nerfs. Une bonne supervision de serveur repose sur trois piliers :

• Métriques : des données chiffrées sur le CPU, la mémoire, l’utilisation du disque, le réseau et les performances de l’application
• Logs : des événements textuels provenant de votre système, de votre application et de vos services
• Alertes : des notifications automatiques lorsque quelque chose sort des paramètres attendus

Sans métriques, vous ne savez pas si votre serveur est en bonne santé. Sans logs, vous ne savez pas pourquoi quelque chose a mal tourné. Sans alertes, vous ne savez pas quand cela a mal tourné. Les trois fonctionnent ensemble, et Grafana est la plateforme qui les fusionne en un ensemble cohérent.

La stack de supervision : Grafana, Prometheus et Loki

Grafana est en soi un outil de visualisation et une plateforme d’alerting — il a besoin d’une source de données. La combinaison la plus utilisée pour la supervision de serveur se présente comme suit :

• Prometheus — récupère les métriques de vos serveurs et applications et les stocke sous forme de séries temporelles
• Node Exporter — tourne sur chaque serveur et exporte les métriques système vers Prometheus
• Loki — système d’agrégation de logs de Grafana Labs, optimisé pour une utilisation avec Grafana
• Promtail — collecte les logs de votre système et les envoie vers Loki
• Grafana — visualise tout et envoie les alertes

Cette stack est entièrement open source, légère et bien documentée. Vous pouvez la faire tourner via Docker Compose, ce qui simplifie considérablement l’installation.

Installation rapide avec Docker Compose

Créez un fichier nommé docker-compose.yml avec la structure de base suivante :

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"
  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"
  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"
  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/log:/var/log
      - ./promtail-config.yml:/etc/promtail/config.yml
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=votremotdepasse

Démarrez la stack avec docker compose up -d et ouvrez Grafana sur le port 3000. Ajoutez Prometheus et Loki comme sources de données via Configuration → Data Sources, et vous êtes prêt à construire votre premier dashboard.

Visualiser les métriques dans Grafana

Une fois la stack en marche, place au travail intéressant : construire des dashboards. Grafana dispose d’une vaste bibliothèque de dashboards prêts à l’emploi sur grafana.com/grafana/dashboards. Pour Node Exporter, le dashboard ID 1860 est la référence — importez-le en un clic et vous obtenez immédiatement une vue sur l’utilisation du CPU, la charge moyenne, la mémoire, les I/O disque et le trafic réseau.

Si vous voulez ajouter vos propres panneaux, vous écrivez une requête PromQL. Quelques exemples pratiques :

• Utilisation du CPU en pourcentage : 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
• Mémoire disponible : node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
• Utilisation du disque : (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100

PromQL est puissant mais a une courbe d’apprentissage. Commencez simplement, utilisez l’autocomplétion dans l’éditeur de requêtes de Grafana, et construisez à partir de là.

Alternative : Netdata pour la supervision en temps réel

Vous voulez quelque chose qui fonctionne directement sans mettre en place toute la stack ? Alors Netdata est une excellente alternative. Netdata s’installe avec une seule commande :

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Vous obtenez immédiatement un dashboard riche avec des milliers de métriques, une détection automatique des anomalies et des alertes intégrées. Netdata est idéal pour des aperçus rapides ou comme complément à votre stack Grafana. Il peut aussi servir de source de données pour Grafana via l’intégration Netdata Cloud.

Collecter et rendre les logs consultables

Les métriques vous disent que quelque chose ne va pas. Les logs vous disent quoi et pourquoi. Une bonne configuration de supervision de serveur sans agrégation de logs, c’est comme une voiture sans rétroviseur : vous ne voyez que ce qui est devant vous.

Avec Loki et Promtail, vous collectez les logs de /var/log/syslog, vos logs d’accès Nginx ou Apache, les logs d’application et les services système. Promtail étiquette automatiquement les logs en fonction de leur emplacement source, afin que vous puissiez les filtrer dans Grafana par serveur, service ou niveau de log.

Dans Grafana, vous utilisez LogQL pour rechercher dans les logs. Exemples :

• Toutes les erreurs de Nginx : {job="nginx"} |= "error"
• Tentatives de connexion SSH : {job="syslog"} |= "Failed password"
• Logs des cinq dernières minutes avec une chaîne spécifique : {job="app"} |~ "timeout" [5m]

Reliez un panneau de logs à votre tableau de bord de métriques, afin de voir directement les logs d'application correspondants en cas de pic CPU. C'est là que la puissance de Grafana se révèle vraiment : la corrélation entre métriques et logs dans une seule interface.

Configurer des alertes : des notifications avant qu'il ne soit trop tard

La fonction la plus sous-estimée de la surveillance de serveurs est un système d'alertes bien configuré. Grafana dispose d'un moteur d'alertes intégré qui évalue les requêtes selon un calendrier et envoie des notifications en cas d'anomalies.

Configurez les alertes via Alerting → Alert Rules. Une règle typique ressemble à ceci :

• Condition : utilisation du CPU supérieure à 85 % pendant 5 minutes
• Période d'attente : 2 minutes (évite les fausses alertes lors de pics courts)
• Canal de notification : Slack, e-mail, PagerDuty ou webhook

Configurez les canaux de notification via Alerting → Contact Points. Grafana prend en charge des dizaines d'intégrations. Pour un environnement d'hébergement belge, Slack ou l'e-mail suffisent souvent ; les grandes équipes choisissent PagerDuty ou OpsGenie pour les rotations d'astreinte.

Seuils d'alerte pratiques pour les serveurs

Utilisez ces valeurs de seuil comme point de départ et adaptez-les à votre charge de travail :

• CPU : avertissement à >75 %, critique à >90 % pendant 5 minutes
• Mémoire : avertissement à >80 %, critique à >95 %
• Disque : avertissement à >75 %, critique à >90 %
• Charge moyenne : critique lorsque la charge soutenue dépasse 2× le nombre de cœurs CPU
• Service down : critique immédiat — utilisez un exportateur blackbox ou une vérification de disponibilité

Évitez la fatigue des alertes : si vous configurez trop d'alertes qui se déclenchent trop rapidement, vous finirez par les ignorer. Commencez de manière prudente et resserrez les seuils en fonction de vos données de référence après une semaine ou deux.

Conseils pratiques pour une configuration de surveillance solide

Pour terminer, voici quelques recommandations concrètes issues de la pratique :

• Surveillez la surveillance elle-même. Configurez une alerte si Prometheus ou Grafana n'est plus accessible. Un système de surveillance qui reste silencieux pendant une panne est inutile.
• Utilisez une politique de rétention pour les métriques. Prometheus stocke par défaut 15 jours de données. Envisagez une rétention plus longue avec Thanos ou Cortex pour l'analyse des tendances.
• Ne fermez pas vos tableaux de bord à l'équipe. Rendez Grafana accessible aux développeurs — la visibilité en production améliore la qualité des versions.
• Documentez vos alertes. Ajoutez un lien vers un runbook à chaque règle d'alerte. Ainsi, l'administrateur de garde saura exactement quoi faire à trois heures du matin.
• Testez vos alertes périodiquement. Une alerte qui ne se déclenche jamais peut être cassée. Simulez délibérément une situation qui devrait déclencher l'alerte.

Conclusion

La surveillance de serveurs avec Grafana, Prometheus, Loki et Node Exporter vous offre une observabilité complète de votre infrastructure : des métriques système en temps réel aux logs consultables et aux alertes proactives. La pile est open source, évolutive et bien intégrée.

Commencez petit : installez la pile sur un seul serveur, importez un tableau de bord existant et configurez trois alertes. Construisez à partir de là. L'investissement d'un après-midi de travail de configuration vous est rendu sous forme de nuits où vous dormez enfin — parce que vous savez que Grafana vous réveillera si nécessaire.

La clé n'est pas la pile parfaite, mais une pile fonctionnelle que vous utilisez et maintenez réellement.