La supervision cloud n’est plus un tableau de bord avec des jaunes et des rouges qu’on regarde quand quelque chose plante. L’observabilité — savoir non seulement ce qui se passe, mais pourquoi — est devenue une exigence réglementaire (NIS2, DORA) et un avantage opérationnel majeur.
Pourtant, la plupart des DSI supervisent encore leur infrastructure avec une stack hétérogène : Nagios pour les services, Zabbix pour les serveurs, un ELK pour les logs, et des tableaux de bord maison que personne ne regarde. Le résultat : des alertes noyées dans le bruit, des temps de détection de 45 minutes, et des audits où on vous demande des métriques qui n’existent pas.
Ce guide vous montre comment déployer Grafana + Prometheus + Loki comme colonne vertébrale de l’observabilité, en conformité avec les exigences réglementaires, et sans recruter une équipe de SRE.
Observabilité vs supervision : la différence qui compte
Supervision traditionnelle
La supervision répond à la question : « Est-ce que ça fonctionne ? »
- Pings, checks de disponibilité, seuils de CPU/RAM
- Alertes quand un seuil est dépassé
- Réaction après l’incident
Problème : vous savez que quelque chose a planté, mais pas pourquoi. Et les fausses alertes noient les vraies.
Observabilité
L’observabilité répond à la question : « Pourquoi ça ne fonctionne pas ? »
- Métriques, logs et traces corrélés
- Compréhension causale des incidents
- Détection des anomalies avant l’incident
Bénéfice : vous comprenez le comportement de votre système avant qu’il ne casse. C’est ce que NIS2 et DORA exigent : pas seulement surveiller, mais comprendre et documenter.
Les trois piliers de l’observabilité
| Pilier | Outil | Ce qu’il capture |
|---|---|---|
| Métriques | Prometheus | CPU, RAM, disque, réseau, latence, débit |
| Logs | Loki | Événements applicatifs, erreurs, accès |
| Traces | Tempo | Parcours d’une requête à travers les services |
Les trois sont corrélés dans Grafana : cliquez sur un pic de latence dans un dashboard, et vous voyez les logs et traces associés.
La stack Grafana + Prometheus + Loki
Architecture
┌──────────────────────────────────────────────────────┐
│ GRAFANA │
│ (Dashboards, Alertes, Corrélations) │
└──────┬────────────────┬────────────────┬────────────┘
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌─────▼──────┐
│ PROMETHEUS │ │ LOKI │ │ TEMPO │
│ (Métriques)│ │ (Logs) │ │ (Traces) │
└──────┬──────┘ └──────┬──────┘ └─────┬──────┘
│ │ │
┌──────▼────────────────▼────────────────▼────────────┐
│ EXPORTERS │
│ node_exporter · app_metrics · Promtail · OpenTelemetry │
└─────────────────────────────────────────────────────┘Les composants en détail
Prometheus : collecte et stockage des métriques
- Scraping : collecte les métriques toutes les 15 secondes (par défaut)
- Stockage : base de données time-series haute performance (TSDB)
- Requêtes : langage PromQL pour explorer et corréler les métriques
- Alertes : Alertmanager pour le routage intelligent
Configuration typique :
- 15 secondes d’intervalle de scraping
- 30 jours de rétention (conforme aux exigences NIS2)
- 2 instances en HA pour la redondance
Loki : agrégation des logs
- Collecte : Promtail ou Docker Driver envoient les logs en temps réel
- Stockage : index minimal, compression efficace (5-10x moins de stockage qu’Elasticsearch)
- Requêtes : LogQL, compatible avec PromQL pour les corrélations
Pourquoi Loki et pas ELK :
- Consommation mémoire : 5 % de celui d’Elasticsearch
- Coût de stockage : 10x inférieur
- Intégration native avec Grafana et Prometheus
Grafana : visualisation et corrélation
- Dashboards : 50+ dashboards préconfigurés (infrastructure, applications, sécurité)
- Corrélation : liens entre métriques, logs et traces en un clic
- Alertes unifiées : règles d’alerte centralisées avec routage intelligent
- Annotations : marquage des déploiements et incidents sur les graphiques
Alertmanager : routage intelligent
- Groupement : alertes similaires regroupées pour éviter le bruit
- Routage : criticité → canal approprié (Slack, email, SMS, escalade)
- Silences : suppression planifiée des alertes pendant les maintiens
- Inhibition : si l’alerte critique A est active, inhiber les alertes mineures liées
Déploiement pratique : les 5 étapes
Étape 1 : Déployer Prometheus (Jour 1-2)
Installer Prometheus sur chaque cluster :
# prometheus.yml (extrait)
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
- job_name: 'opennebula'
static_configs:
- targets: ['opennebula-exporter:9191']Livrable : métriques de tous les nœuds visibles dans Prometheus.
Étape 2 : Déployer Loki + Promtail (Jour 2-3)
Configurer la collecte centralisée des logs :
# promtail.yml (extrait)
scrape_configs:
- job_name: system
static_configs:
- targets:
- localhost
labels:
job: syslog
__path__: /var/log/syslogLivrable : logs de tous les services consultables dans Grafana.
Étape 3 : Construire les dashboards (Jour 3-5)
Les dashboards essentiels pour un DSI :
| Dashboard | Ce qu’il montre | Alertes associées |
|---|---|---|
| Infrastructure | CPU, RAM, disque, réseau par nœud | Seuils CPU > 85 %, disque > 90 % |
| Applications | Latence, erreur 5xx, débit | Latence > 500ms, erreur > 1 % |
| Sécurité | Tentatives d’authentification, blocages WAF | Attaque brute force, IP suspecte |
| Conformité | Statut des sauvegardes, rotations de certificats | Sauvegarde manquée, certificat expiré |
| MCO | SLA, uptime, temps de réponse | SLA < 99,9 %, downtime > 5 min |
Livrable : 5 dashboards opérationnels, accessibles par les équipes.
Étape 4 : Configurer les alertes intelligentes (Jour 5-7)
Le problème classique de la supervision : trop d’alertes = on ne les lit plus. La solution : alerter sur les symptômes, pas sur les causes.
| Alerte intelligente | Au lieu de | Avantage |
|---|---|---|
| Latence P99 > 500ms pendant 5 min | CPU > 80 % | On identifie l’impact utilisateur |
| Disponibilité < 99,9 % sur 1h | Service down | On mesure le SLA, pas l’état instantané |
| Tentatives d’authentification anormales | Log d’erreur | On détecte les attaques, pas le bruit |
| Certificat expire dans 15 jours | Log de renouvellement | On anticipe, pas on réagit |
Livrable : 20 règles d’alerte configurées dans Alertmanager.
Étape 5 : Intégrer l’audit trail (Jour 7-10)
Pour la conformité NIS2 et DORA, chaque événement doit être tracé :
- Changements d’infrastructure : annotés sur les dashboards (liés aux commits Git Terraform)
- Alertes déclenchées : journalisées avec contexte complet
- Interventions : ticket généré automatiquement dans Plane ou Chatwoot
- Rapports : générés à partir des métriques réelles, pas de tableurs manuels
Livrable : rapport de conformité automatisé en 1 clic.
Observabilité et conformité réglementaire
NIS2 : signalisation des incidents
NIS2 exige que les incidents significatifs soient signalés dans les 24 heures (notification initiale) et dans les 72 heures (rapport complet). Avec Grafana + Prometheus :
- Détection automatique des incidents (règles d’alerte)
- Notification immédiate via Alertmanager (Slack, email, SMS)
- Rapport d’incident pré-rempli avec métriques et timeline
- Audit trail complet pour la documentation réglementaire
DORA : résilience opérationnelle
DORA exige des tests de résilience réguliers. Notre stack d’observabilité le permet :
- Chaos engineering : injection de pannes et observation de la récupération en temps réel
- SLA monitoring : dashboards qui mesurent la disponibilité réelle vs les SLA contractuels
- Rapports de résilience : générés automatiquement à partir des métriques de production
RGPD : sécurité des traitements
L’article 32 du RGPD exige des « mesures techniques appropriées ». L’observabilité en fait partie :
- Détection des accès non autorisés (anomalies d’authentification)
- Preuve du chiffrement des données en transit (mTLS metrics)
- Documentation des violations éventuelles (audit trail)
Dashboards essentiels : 5 configurations prêtes à l’emploi
Dashboard 1 : Vue exécutive DSI
Ce que le DSI veut voir au matin :
- Disponibilité globale : % d’uptime sur 30 jours (objectif : 99,95 %)
- MTTD : temps moyen de détection d’incident (objectif : < 5 min)
- MTTR : temps moyen de résolution (objectif : < 30 min)
- SLA compliance : respect des SLA contractuels
- Sécurité : nombre d’incidents bloqués, tentatives d’intrusion
Dashboard 2 : Infrastructure
Vue technique pour les équipes ops :
- CPU/RAM/disque par nœud et par service
- Réseau : débit, latence, erreurs
- Stockage : IOPS, latence, capacité
- OpenNebula : état des VM, autoscaling, snapshots
Dashboard 3 : Sécurité
Pour le RSSI et les audits :
- Tentatives d’authentification (succès/échec par IP)
- Blocages WAF (par type d’attaque)
- Rotation des certificats et expiration
- Accès Vault (secrets lus, échecs)
- Audit trail des changements d’infrastructure
Dashboard 4 : Conformité
Pour les rapports NIS2/DORA :
- Statut des sauvegardes (planifiées/exécutées/ratées)
- Certificats expirants dans les 30 jours
- SLA mesuré vs SLA contractuel
- Temps de réponse aux incidents vs exigences NIS2
Dashboard 5 : Coûts et optimisation
Pour le contrôle financier :
- Utilisation des ressources vs capacité allouée
- Coût par service (basé sur la consommation)
- Opportunités d’optimisation (VM surdimensionnées, volumes inutilisés)
- Tendance de consommation sur 90 jours
La stack complète Cloud Inspire
Notre stack d’observabilité est 100 % open source et déployée en 10 jours :
| Composant | Outil | Rôle |
|---|---|---|
| Métriques | Prometheus | Collecte et stockage TSDB |
| Logs | Loki | Agrégation centralisée |
| Traces | Tempo | Traçage distribué |
| Dashboards | Grafana | Visualisation et corrélation |
| Alertes | Alertmanager | Routage intelligent |
| Collecte | Promtail + Node Exporter | Agents de collecte |
| Sécurité | Traefik + Coraza WAF | Métriques de sécurité |
| Secrets | Vault | Audit des accès |
| Orchestration | OpenNebula | Métriques infrastructure |
Déploiement : la stack fait partie du Cloud Factory. Pas d’intégration sur mesure à durée indéterminée.
ROI de l’observabilité : les chiffres
| Métrique | Avant Grafana+Prometheus | Après | Amélioration |
|---|---|---|---|
| Temps de détection (MTTD) | 45 min | 2 min | -96 % |
| Temps de résolution (MTTR) | 4h | 30 min | -87 % |
| Fausses alertes/mois | 120+ | < 10 | -92 % |
| Temps de préparation audit | 2 semaines | 30 min | -98 % |
| Rapports de conformité | Manuels, Excel | Automatiques | -100 % manuel |
| Coût outils de supervision | 40 K€/an (licences) | 0 K€ (open source) | -100 % |
Les erreurs à éviter
Erreur 1 : Trop d’alertes
Le piège classique : alerter sur tout. Résultat — 200 alertes/jour, personne ne les lit.
Solution : alerter sur les symptômes utilisateur (latence, erreurs, SLA), pas sur les causes techniques (CPU, RAM). Et utiliser le groupement Alertmanager pour agréger les alertes similaires.
Erreur 2 : Des dashboards sans corrélation
Un dashboard CPU et un dashboard applicatif séparés ne servent à rien quand l’application ralentit.
Solution : lier les dashboards. Cliquer sur un pic de latence → voir les logs Loki associés → voir les traces Tempo. C’est la corrélation qui fait la valeur.
Erreur 3 : Ignorer les logs de sécurité
L’observabilité n’est pas que technique — c’est aussi une exigence de conformité.
Solution : intégrer les logs d’authentification, de WAF et de Vault dans Loki. Un dashboard sécurité avec les métriques de Coraza et les accès suspects.
Erreur 4 : Ne pas versionner les dashboards
Les dashboards modifiés à la main dérivent. Un jour ils fonctionnent, le lendemain quelqu’un a supprimé une requête.
Solution : GitOps. Les dashboards sont définis en code (JSON/YAML), versionnés dans Git, déployés par CI/CD. Exactement comme l’infrastructure.
Par où commencer
Semaine 1 : Visibilité immédiate
- Déployer Prometheus + Node Exporter sur tous les nœuds
- Installer Grafana avec 5 dashboards préconfigurés
- Configurer les alertes de base (disponibilité, disque, certificats)
Résultat : en 5 jours, vous voyez tout ce qui se passe sur votre infrastructure.
Semaine 2 : Logs et corrélation
- Déployer Loki + Promtail pour la collecte centralisée des logs
- Configurer la corrélation métriques ↔ logs dans Grafana
- Créer les rapports de conformité automatisés
Résultat : vous ne voyez plus seulement ce qui se passe, vous comprenez pourquoi.
Semaine 3 : Alertes intelligentes et audit trail
- Remplacer les alertes seuil par des alertes comportementales
- Intégrer Alertmanager avec vos canaux de notification
- Configurer l’audit trail pour NIS2/DORA
Résultat : vous détectez les incidents avant qu’ils n’impactent les utilisateurs, et vous avez la trace pour les réglementations.
Conclusion
L’observabilité est le fondement du MCO automatisé et de la conformité réglementaire. Sans visibilité, pas de résilience. Sans résilience, pas de conformité. Grafana + Prometheus + Loki offre une stack open source, éprouvée et conforme — avec un ROI mesurable dès le premier mois.
Pour les DSI qui supervisent encore avec des outils dispersés et des alertes noyées dans le bruit, le passage à Grafana + Prometheus n’est pas un investissement — c’est un gain immédiat en visibilité, en réactivité et en conformité.
Cloud Inspire déploie la stack d’observabilité complète en 10 jours, sur votre cloud privé OpenNebula. Si vous voulez voir ce qui se passe vraiment sur votre infrastructure, parlons-en.