</Contexte>

BTS SIO SISR — 2ème année TP de supervision d'infrastructure avec Prometheus, Grafana et Docker. Durée estimée : 4 à 6 heures. Compétences : B1.3 Gestion des incidents, B2.2 Supervision.

Vous êtes administrateur système dans une entreprise qui utilise Nextcloud comme solution de stockage et collaboration. L'objectif est de mettre en place une solution de supervision pour surveiller l'état des serveurs en temps réel.

💡 La supervision permet de détecter les problèmes avant qu'ils n'impactent les utilisateurs, d'analyser les performances et de planifier les évolutions de l'infrastructure.

Stack technologique

🐳 Docker

Plateforme de conteneurisation. Chaque conteneur embarque l'application et toutes ses dépendances dans un environnement isolé.

🔥 Prometheus

Système de monitoring open source (SoundCloud). Collecte des métriques par méthode pull sur des endpoints HTTP et les stocke en TSDB (Time Series Database).

📈 Grafana

Plateforme de visualisation open source. Tableaux de bord interactifs depuis Prometheus, InfluxDB, MySQL, etc. Bibliothèque de dashboards communautaires.

📊 Node Exporter

Agent Prometheus collectant les métriques système Linux (CPU, RAM, disque, réseau). Expose les données sur :9100/metrics.

📊 cAdvisor

Container Advisor de Google. Analyse les performances des conteneurs Docker (CPU, mémoire, réseau, I/O) et expose les métriques sur :8080/metrics.

☁️ Nextcloud

Solution open source de stockage et partage de fichiers auto-hébergée. Joue le rôle d'application métier à superviser dans ce TP.


Architecture cible — 2 VM

VMOSRAM / CPUServicesPorts
srvnextcloudUbuntu 24.04 LTS4 Go / 2 vCPUNextcloud, MariaDB, Node Exporter, cAdvisor8081, 3306, 9100, 8080
srvmonitoringUbuntu 24.04 LTS4 Go / 2 vCPUPrometheus, Grafana, Node Exporter, cAdvisor9090, 3000, 9100, 8080
ServiceServeurPortRôle
Nextcloudsrvnextcloud8081Application cloud à superviser
MariaDBsrvnextcloud3306Base de données Nextcloud
Node ExporterLes deux9100Métriques système
cAdvisorLes deux8080Métriques des conteneurs
Prometheussrvmonitoring9090Collecte des métriques
Grafanasrvmonitoring3000Visualisation

</Installation>

1 — Création des deux VM

  • Type : Linux / Ubuntu 64-bit — RAM : 4096 Mo — CPU : 2 vCPU — Disque : 30 Go dynamique
  • Noms : srvnextcloud et srvmonitoring
  • Réseau : NAT — Cocher OpenSSH server lors de l'installation
⚠ Notez bien vos mots de passe et les adresses IP des deux serveurs !

2 — Configuration initiale (sur les deux serveurs)

# Obtenir l'IP
ip a
hostname -I

# Connexion SSH depuis Windows
ssh admin@192.168.1.100

# Mise à jour et outils
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget vim htop net-tools

IPs utilisées dans ce TP :

ServeurIP
srvnextcloud172.16.82.132
srvmonitoring172.16.82.133

3 — Installation Docker (sur les deux serveurs)

💡 Docker permet de déployer rapidement la stack de supervision de manière reproductible et isolée, sans conflits de dépendances.
# Étape 1 — Prérequis
sudo apt install -y ca-certificates curl gnupg

# Étape 2 — Clé GPG Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Étape 3 — Dépôt Docker
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" \
| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Étape 4 — Installation
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Accès sans sudo
sudo usermod -aG docker $USER
# ⚠ Déconnectez-vous et reconnectez-vous !

# Vérification
docker --version
docker compose version
docker run hello-world

4 — Déploiement Nextcloud (srvnextcloud uniquement)

sudo mkdir -p /srv/nextcloud
cd /srv/nextcloud
sudo nano /srv/nextcloud/docker-compose.yml
services:
  nextcloud-db:
    image: mariadb:10.11
    container_name: nextcloud-db
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: nextcloudpassword
    volumes:
      - nextcloud-db-data:/var/lib/mysql

  nextcloud:
    image: nextcloud:latest
    container_name: nextcloud
    restart: unless-stopped
    ports:
      - "8081:80"
    environment:
      MYSQL_HOST: nextcloud-db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: nextcloudpassword
    volumes:
      - nextcloud-data:/var/www/html
    depends_on:
      - nextcloud-db

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    restart: unless-stopped
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

volumes:
  nextcloud-db-data:
  nextcloud-data:
# Lancement
cd /srv/nextcloud
sudo docker compose up -d
docker compose ps

# Vérification exporters
curl http://localhost:9100/metrics | head -20
curl http://localhost:8080/metrics | head -20

❓ Analysez ce fichier docker-compose.yml. Combien de services sont définis ?

4 services : nextcloud-db (MariaDB 10.11 — stockage données), nextcloud (application cloud), node-exporter (métriques hôte), cAdvisor (métriques conteneurs).

❓ Exemples de métriques retournées par les exporters

Node Exporter : go_gc_duration_seconds{quantile="0"} 7.223e-05
cAdvisor : cadvisor_version_info{cadvisorVersion="v0.55.1",kernelVersion="6.8.0-94-generic",...} 1


5 — Déploiement Prometheus & Grafana (srvmonitoring uniquement)

sudo mkdir -p /srv/monitoring/prometheus
cd /srv/monitoring
sudo nano /srv/monitoring/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter_monitoring'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'node_exporter_nextcloud'
    static_configs:
      - targets: ['IP_SRVNEXTCLOUD:9100']   # ← remplacer

  - job_name: 'cadvisor_nextcloud'
    static_configs:
      - targets: ['IP_SRVNEXTCLOUD:8080']   # ← remplacer

  - job_name: 'cadvisor_monitoring'
    static_configs:
      - targets: ['cadvisor:8080']

❓ Que signifie scrape_interval: 15s ?

Prometheus se connecte toutes les 15 secondes aux cibles définies dans les targets pour récupérer leurs métriques. C'est une sorte de heartbeat vérifiant la disponibilité et collectant les données.

sudo nano /srv/monitoring/docker-compose.yml
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=15d'

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=GrafanaAdmin123!
    volumes:
      - grafana-storage:/var/lib/grafana

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    restart: unless-stopped
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

volumes:
  prometheus-data:
  grafana-storage:
cd /srv/monitoring
sudo docker compose up -d
docker compose ps

❓ Combien de conteneurs sont en cours d'exécution sur srvmonitoring ?

4 conteneurs : cadvisor, grafana, node-exporter, prometheus.

</Supervision>

Configuration Grafana

  • Accéder à Prometheus : http://IP_SRVMONITORING:9090 → Status > Targets (tous les endpoints doivent être UP)
  • Accéder à Grafana : http://IP_SRVMONITORING:3000 — Login : admin / GrafanaAdmin123!
  • Ajouter la source : Configuration > Data Sources > Prometheus > URL : http://prometheus:9090 > Save & Test
💡 Dans Docker, les conteneurs d'un même réseau communiquent via leur nom de service. Grafana accède à Prometheus par prometheus:9090, pas par localhost.

Import des tableaux de bord

DashboardID Grafana.comUsage
Node Exporter Full1860Métriques système des deux serveurs
Docker / cAdvisor13946Métriques des conteneurs

❓ Node Exporter — Pouvez-vous voir les deux serveurs ?

Oui. En changeant le job (node_exporter_nextcloud / node_exporter_monitoring), on accède aux métriques de chaque serveur. Le dashboard monitoring affiche aussi les noms des images conteneurisées.

❓ cAdvisor — Quels conteneurs de srvnextcloud sont visibles ?

4 conteneurs visibles avec leurs ressources : nextcloud, nextcloud-db, node-exporter, cadvisor.


Tests de charge

# Sur srvnextcloud — charge CPU (2 min)
sudo apt install -y stress
stress --cpu 2 --timeout 120

# Charge mémoire (60 sec)
stress --vm 1 --vm-bytes 1G --timeout 60

❓ Comportement des conteneurs pendant l'activité Nextcloud ?

Seul le conteneur nextcloud enregistre de l'activité réseau/disque accrue. nextcloud-db reste stable car il gère uniquement les utilisateurs, droits et métadonnées.


Requêtes PromQL

RequêteDescription
upÉtat des cibles (1=UP, 0=DOWN)
node_memory_MemTotal_bytesMémoire totale du système
node_cpu_seconds_totalTemps CPU cumulé par mode
container_memory_usage_bytesUtilisation mémoire des conteneurs
(1-(node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes))*100% RAM utilisée
100-(avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100)% CPU moyen sur 5 min

❓ Pourcentage mémoire utilisée sur chaque serveur

srvmonitoring : 22.39% — srvnextcloud : 27.20%

❓ Panel personnalisé — Quelle requête PromQL avez-vous utilisée ?

Comparaison CPU par instance : 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

</Alertes>

Prometheus évalue les règles d'alertes à intervalles réguliers. Si une condition est vraie pendant la durée for, l'alerte passe en état FIRING.


Règles CPU

sudo mkdir -p /srv/monitoring/prometheus/rules
sudo nano /srv/monitoring/prometheus/rules/cpu_alerts.yml
groups:
  - name: cpu_alerts
    rules:
      - alert: CpuSaturated
        expr: (1 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])))) > 0.8
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "CPU saturé sur {{ $labels.instance }}"
          description: "L'utilisation CPU dépasse 80% depuis plus de 3 minutes."

      - alert: CpuHigh
        expr: (1 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])))) > 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU élevé sur {{ $labels.instance }}"
          description: "L'utilisation CPU dépasse 50% depuis plus de 5 minutes."

❓ Différence entre les deux alertes CPU ? Que signifie for ?

CpuSaturated : critique — CPU > 80% pendant 3 min.
CpuHigh : warning — CPU > 50% pendant 5 min.
Le paramètre for définit la durée minimale pendant laquelle la condition doit être vraie avant de déclencher l'alerte (évite les faux positifs sur des pics courts).


Règles mémoire

sudo nano /srv/monitoring/prometheus/rules/memory_alerts.yml
groups:
  - name: memory_alerts
    rules:
      - alert: MemorySaturated
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.85
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Mémoire saturée sur {{ $labels.instance }}"
          description: "L'utilisation mémoire dépasse 85% depuis plus de 3 minutes."

      - alert: MemoryHigh
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.70
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Mémoire élevée sur {{ $labels.instance }}"
          description: "L'utilisation mémoire dépasse 70% depuis plus de 5 minutes."

Mise à jour de prometheus.yml pour charger les règles

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "rules/*.yml"    # ← ajouter cette section

scrape_configs:
  # ... (inchangé)
# Rechargement de Prometheus
cd /srv/monitoring
sudo docker compose restart prometheus

# Vérifier les règles dans l'interface
# http://IP_SRVMONITORING:9090 → Status > Rules
💡 Pour tester une alerte CPU immédiatement, générez une charge avec stress --cpu 2 --timeout 300 sur srvnextcloud et attendez 3 minutes.

</Conclusion>

Résultats et livrables

  • 2 VM Ubuntu 24.04 déployées et interconnectées via NAT.
  • Stack Nextcloud + MariaDB + Node Exporter + cAdvisor sur srvnextcloud.
  • Stack Prometheus + Grafana + Node Exporter + cAdvisor sur srvmonitoring.
  • Dashboards Grafana importés (ID 1860 et 13946), métriques des deux serveurs visibles.
  • Règles d'alertes CPU et mémoire configurées avec seuils WARNING et CRITICAL.

Questions de synthèse

❓ Avantages d'un serveur de monitoring séparé du serveur applicatif ?

Le serveur de monitoring est dédié à la vérification et centralise les alertes. Si un serveur applicatif tombe, le monitoring le détecte et envoie une alerte, sans être lui-même affecté par la panne.

❓ Node Exporter vs cAdvisor — quand utiliser lequel ?

cAdvisor — superviser un parc de conteneurs Docker (métriques par conteneur).
Node Exporter — superviser le parc de serveurs physiques ou VM (bare-metal).

❓ Pourquoi superviser une infrastructure ?

Pour suivre l'évolution des ressources, détecter les erreurs/pannes (critiques ou non) avant qu'elles n'impactent les utilisateurs, et planifier les évolutions de capacité.

❓ Améliorations possibles ?

Connecter l'infrastructure à un Windows Server pour monitorer un SI d'entreprise. Vérifier la connectivité externe via un scrape sur un endpoint public (ex: google.com). Intégrer Alertmanager pour les notifications email/Slack.


Ressources

— Fin du document —