Monitoring - Système de Supervision TAAF

Acte 1 Débutant → Intermédiaire Prometheus · Grafana · Loki

Acte 1 — Mise en lumière

Port-aux-Français, base perdue dans l’océan Indien. Un service tombe — et personne ne le sait avant qu’un chercheur ne trouve porte close. La DSI des TAAF pilote à l’aveugle.

Votre première mission : lui rendre la vue. Vous construisez la visibilité de l’infrastructure — métriques, dashboards, logs centralisés, alertes — sans laquelle aucune détection n’est possible.

→ Le parcours complet : fil rouge en 3 actes.

Vous arrivez de l’Acte 0

L’infrastructure est déjà déployée et le scénario peuplé (Acte 0 — Mise en place). L’Acte 1 pose la couche de visibilité par-dessus — c’est le point de départ de tout le reste.

Vue d’ensemble

Le parcours Monitoring vous apprend à mettre en place une solution complète de supervision et d’observabilité pour les bases polaires TAAF. Vous allez déployer et configurer une stack de monitoring moderne avec Prometheus, Grafana et Loki.

🇫🇷 Cadre réglementaire

Ce module répond à l’axe « supervision » de la feuille de route de sécurité numérique de l’État : doter l’infrastructure d’une capacité de collecte, de centralisation et d’analyse des traces. Voir le Cadre réglementaire.

Architecture de la Solution

Stack de Monitoring

La solution de supervision s’appuie sur les technologies suivantes :

• PostgreSQL (bases multiples) : Stockage des données opérationnelles
• Prometheus : Collecte et stockage des métriques
• Alertmanager : Gestion et routage des alertes
• Grafana : Visualisation et dashboards
• Loki : Agrégation et analyse des logs
• Alloy : Agent de collecte unifié (Grafana Agent)
• cAdvisor : Collecte des métriques des conteneurs Docker
• Caddy : Serveur web et proxy inverse avec SSL automatique
• Exporters : postgres_exporter, node_exporter

Architecture Simplifiée

graph LR
 subgraph "Stack Monitoring (Observabilité)"
 PG[(PostgreSQL
Bases TAAF)] -->|métriques|PROM[Prometheus]
 NC[NextCloud] -->|logs|ALLOY[Grafana Alloy]
 PG -->|logs|ALLOY

 ALLOY --> LOKI[Loki]
 PROM --> GRAF[Grafana]
 LOKI --> GRAF

 PROM --> AM[Alertmanager]
 AM -->|notifications|DISC[Discord/Slack]
 end

 classDef monitoring fill:#99ff99,stroke:#333,stroke-width:2px
 classDef infra fill:#ffcc99,stroke:#333,stroke-width:2px
 classDef alert fill:#cc99ff,stroke:#333,stroke-width:2px

 class PROM,ALLOY,LOKI,GRAF monitoring
 class PG,NC infra
 class AM,DISC alert

Métriques Surveillées

• Disponibilité : Statut UP/DOWN des bases
• Performance : Temps de réponse, throughput
• Ressources : CPU, RAM, stockage
• Connexions : Nombre de sessions actives
• Erreurs : Logs d’erreurs et exceptions

Alertes Configurées

Via Alertmanager (TP4) :

• Base de données inaccessible
• Performances dégradées
• Espace disque critique
• Erreurs critiques dans les logs
• Notifications Discord/Slack/Email

Base de Données Surveillée

Le système gère une seule instance PostgreSQL (postgres-af) exposant une unique base de données base_af. Toutes les données opérationnelles des bases polaires y sont regroupées sous forme de tables :

Tables de la base base_af

• personnel_base : Gestion du personnel, rotations et congés
• conditions_meteo : Relevés météorologiques et alertes
• equipements_critiques : Inventaire et maintenance du matériel
• communications_satellite : Logs des communications satellite
• stocks_approvisionnement : Inventaires critiques

Une table sensible existe aussi — vous ne la supervisez pas ici

Une table genetic_samples (échantillons génétiques classifiés, KER-2024-002, CLASSIFIED) vit aussi dans base_af. À l’Acte 1, on ne la supervise pas — volontairement : la pédagogie Voir → Détecter → Prouver consiste à observer le métier normal ici, puis à transformer la supervision en sentinelle à l’Acte 2. C’est là que genetic_samples deviendra le cœur de l’enquête (détection du vol), puis à l’Acte 3 la pièce maîtresse du forensic. Gardez-la en tête : elle existe, elle est planquée volontairement, elle reviendra.

Scripts SQL d’initialisation

Les scripts suivants doivent être exécutés dans l’ordre depuis le repository kds-formation/sql sur la base base_af :

Schémas (création des tables) :

1. personnel_base.sql
2. conditions_meteo.sql
3. equipements_critiques.sql
4. communications_satellite.sql
5. stocks_approvisionnement.sql

Données (insertion) : 6. data-personel.sql 7. data-meteo.sql 8. data-materiel.sql 9. data-com-satellite.sql 10. data-stocks.sql

Ordre des TPs

IMPORTANT : Les TPs doivent être réalisés dans l’ordre strict suivant :

1. TP1 - Métriques Grafana

   • Créer dashboard de supervision des conteneurs Docker
   • Livrable : 1 dashboard métriques système

2. TP2 - Dashboards Données

   • Ajouter dashboards données métier TAAF
   • Livrable : 2 dashboards supplémentaires (Communications + RH)

3. TP3 - Intégration Loki

   • Intégrer la dimension logs
   • Livrable : Dashboards hybrides logs+métriques

4. TP4 - Alerting

   • Configuration alertes multi-sources
   • Livrable : Alertmanager + webhooks Discord/Google Chat

5. TP Bonus (Optionnel)

   • Monitoring production électrique La Réunion

Consultez l’ordre détaillé des TPs pour plus d’informations.

Prérequis

Système requis

• Docker Desktop ou Docker Engine
• Docker Compose
• 8 GB RAM minimum (16 GB recommandé)
• 20 GB d’espace disque libre

Architecture de déploiement (all-in-one)

Tout l’Acte 1 tourne sur une seule VM, monitoring (TAAF-MONITORING-001, IP_VM2). Le dépôt monitoring déploie en un docker compose le SI observé ET l’observabilité :

• SI observé : PostgreSQL postgres-af (base base_af, port 5432), NextCloud (8081)
• Observabilité : Grafana (3000), Prometheus (9090), Loki (3100), Alloy, Alertmanager (9093), cAdvisor, exporters

Tous ces services partagent le réseau Docker interne de la VM : entre eux, ils se joignent par leur nom de service Docker (postgres-af, prometheus, loki…), jamais par IP ni localhost.

Accès depuis votre poste

Depuis votre navigateur, vous joignez la VM par son IP (relevée avec hostname -I sur la VM) :

ping IP_VM2
curl http://IP_VM2:3000   # Grafana
curl http://IP_VM2:9090   # Prometheus

La connectivité inter-VM par IP ne devient cruciale qu’à l’Acte 2 (la VM SOC joint Loki de cette VM monitoring).

Démarrage Rapide

Installation

# Cloner le projet
git clone https://gitlab.com/kds-formation/monitoring
cd monitoring

# Démarrer tous les services
docker compose up -d

# Vérifier le statut
docker compose ps

Accès aux interfaces

Accès selon votre environnement

Les URLs d’accès dépendent de votre position réseau.

Depuis votre poste de travail (navigateur) :

• Grafana : http://IP_VM2:3000
  • User : admin
  • Password : AdminTAAF2024!
• Prometheus : http://IP_VM2:9090

Connexion à la base PostgreSQL (client SQL, depuis votre poste) :

• PostgreSQL Alfred Faure : IP_VM2:5432 (user: taaf_admin, password: TaafPostgres2024!, base : base_af)
  • Tables disponibles dans base_af : personnel_base, conditions_meteo, equipements_critiques, communications_satellite, stocks_approvisionnement

Dans les configurations Grafana (datasources) — tout en nom de service Docker :

• Prometheus : http://prometheus:9090
• PostgreSQL Alfred Faure : postgres-af:5432
• Loki : http://loki:3100

Datasources Grafana — nom de service Docker, jamais localhost

Grafana et ses sources (postgres-af, prometheus, loki, alertmanager) tournent dans le même docker compose sur la VM monitoring. Les datasources se câblent donc sur le nom de service Docker :

• PostgreSQL : postgres-af:5432
• Prometheus : http://prometheus:9090
• Loki : http://loki:3100
• Alertmanager : http://alertmanager:9093

IMPORTANT : n’utilisez jamais localhost/127.0.0.1 (dans un conteneur, localhost désigne le conteneur lui-même), ni l’IP de la VM, pour une datasource.

Ports utilisés

• 3000 : Interface Grafana
• 9090 : Interface Prometheus
• 3100 : Service Loki
• 5432 : PostgreSQL Alfred Faure (toutes les bases)
• 8080 : cAdvisor (métriques conteneurs)
• 8081 : NextCloud (UI)
• 9093 : Alertmanager
• 9187 : postgres_exporter
• 9100 : node_exporter

Vérification cAdvisor

cAdvisor est automatiquement déployé avec Docker Compose et collecte les métriques de tous les conteneurs Docker.

# Vérifier que cAdvisor fonctionne
docker ps | grep cadvisor

# Accéder à l'interface web cAdvisor
curl http://localhost:8080/containers/

# Vérifier les métriques Prometheus
curl http://localhost:8080/metrics

# Tester depuis Prometheus
# Ouvrir http://localhost:9090 → Explorer → Rechercher "container_"

Métriques cAdvisor disponibles :

• container_cpu_usage_seconds_total : Utilisation CPU par conteneur
• container_memory_usage_bytes : Utilisation mémoire
• container_network_receive_bytes_total : Octets réseau reçus
• container_network_transmit_bytes_total : Octets réseau envoyés
• container_fs_usage_bytes : Utilisation disque

Ces métriques sont utilisées dans le TP1 pour créer le dashboard de supervision des conteneurs.

Commandes Utiles

# Démarrer les services
docker compose up -d

# Voir les logs d'un service spécifique
docker compose logs -f grafana
docker compose logs -f prometheus

# Voir les logs de tous les services
docker compose logs -f

# Arrêter les services
docker compose down

# Nettoyer (attention: supprime les données)
docker compose down -v

# Redémarrer un service spécifique
docker compose restart grafana

# Accéder à la base base_af
docker exec -it postgres-af psql -U taaf_admin -d base_af

# Lister les tables de base_af
docker exec -it postgres-af psql -U taaf_admin -d base_af -c "\dt"

# Interroger une table
docker exec -it postgres-af psql -U taaf_admin -d base_af -c "SELECT COUNT(*) FROM communications_satellite;"
docker exec -it postgres-af psql -U taaf_admin -d base_af -c "SELECT COUNT(*) FROM personnel_base;"

Dépannage

Problèmes courants

Services qui ne démarrent pas :

# Vérifier les ports utilisés
netstat -tulpn | grep -E ':(3000|9090|5432)'

# Voir les logs d'erreur
docker compose logs grafana
docker compose logs prometheus

Données manquantes :

# Réinitialiser les données PostgreSQL
docker compose down -v
docker compose up -d

Performance lente :

• Vérifier la RAM disponible (minimum 8 GB)
• Augmenter les limites Docker si nécessaire

Évaluation et Rendu

Format obligatoire

Plateforme : Moodle de l’Université de la Réunion Format : nom-prénom-promo.PDF (exemple: dupont-marie-m2info.PDF)

PÉNALITÉ : -5 points pour non-respect du nommage

Critères de qualité du rapport

Lisibilité et compréhensibilité = 15% de la note finale

• Police : 11pt minimum (12pt recommandé)
• Structure : Titres clairs, sections organisées
• Images : Captures d’écran nettes et contrastées
• Code : Formatage correct des requêtes SQL/PromQL
• Orthographe : Relecture obligatoire

Un rapport illisible sera sanctionné même si le contenu technique est correct.

Ressources

Repository GitLab

• monitoring - Code source et configuration

Documentation technique

• Présentation du projet
• Guide PostgreSQL
• Documentation Caddy
• Guide Dashboards

Documentation externe

• Prometheus Documentation
• Grafana Documentation
• Loki Documentation

Prochaines Étapes

1. Consulter l’ordre des TPs
2. Lire la présentation du projet
3. Commencer par le TP1 - Métriques Grafana