Skip to content

PR: Logging, tracing, monitoring - DIARRA NIANZOU TAPE#44

Open
EmmanuelNianzou wants to merge 2 commits into
templep:mainfrom
EmmanuelNianzou:pr/diarra-nianzou-tape
Open

PR: Logging, tracing, monitoring - DIARRA NIANZOU TAPE#44
EmmanuelNianzou wants to merge 2 commits into
templep:mainfrom
EmmanuelNianzou:pr/diarra-nianzou-tape

Conversation

@EmmanuelNianzou
Copy link
Copy Markdown

@EmmanuelNianzou EmmanuelNianzou commented Apr 30, 2026 •
edited
Loading

PR du Projet Doodle — Logging, Tracing, Monitoring & Observabilité

Cours DevOps — ESIR 2 IOT, Université de Rennes 1
Dépôt original : https://github.com/selabs-ur1/doodle.git
Stack : Quarkus · MySQL · Prometheus · Loki · Promtail · Grafana · Jaeger · Docker Compose

Équipe :

  • DIARRA Fatouma Yasmine
  • NIANZOU Boa Emmanuel
  • TAPE Guy Stéphane

Table des matières

  1. Contexte et objectifs
  2. Choix technologiques et comparaison
  3. Prérequis
  4. Structure du projet
  5. Démarrage rapide
  6. Accès aux interfaces
  7. Simulation de trafic
  8. Comprendre le monitoring
  9. Les problèmes que nous avons rencontrés et solutions
  10. Arrêt et nettoyage
  11. Modifications apportées au dépôt original

1. Contexte et objectifs

Dans le cadre du cours de DevOps de la deuxième année ingénieure à l'ESIR (Université de Rennes 1), nous avons eu à prendre un projet existant, une application de sondage de type Doodle, et à y intégrer une chaîne d'observabilité complète. Le dépôt de base a été cloné depuis https://github.com/selabs-ur1/doodle.git.

L'application Doodle permet de créer des sondages pour planifier des événements collectifs. Elle est composée d'une API REST Quarkus (Java), d'un frontend Angular et d'une base de données MySQL. Notre travail a consisté à ajouter autour de cette application tout le nécessaire pour observer son comportement en production, à savoir :

  • Métriques : collecter et visualiser les indicateurs de performance (taux de requêtes, latence, mémoire JVM...)
  • Logs : centraliser les logs applicatifs en temps réel dans un système dédié
  • Traces distribuées : suivre le chemin complet de chaque requête HTTP à travers les composants
  • Dashboard unifié : visualiser tout ça en un seul endroit

L'ensemble du déploiement est orchestré avec Docker Compose : une seule commande suffit pour lancer les 10 services qui composent le projet.

2. Choix technologiques et comparaison

Plusieurs solutions existent pour implémenter l'observabilité. Voici pourquoi nous avons retenu celles-ci plutôt que les alternatives.

2.1 Métriques : Prometheus + Micrometer vs Datadog vs SkyWalking

Nous avons choisi Prometheus (avec le client Micrometer côté Quarkus) pour collecter les métriques.

Critère Prometheus + Micrometer Datadog SkyWalking
Coût Gratuit, open source Payant (SaaS) Gratuit, open source
Intégration Quarkus Native (quarkus-micrometer-registry-prometheus) Agent externe Agent bytecode
Complexité Faible Faible (mais dépendance cloud) Élevée
Indépendance Totale (auto-hébergé) Dépendance fournisseur Totale
Adapté à Docker Compose Oui Non (orienté cloud) Partiellement

Pourquoi pas Datadog ? Datadog est un excellent outil en entreprise, mais il est payant et requiert d'envoyer les données vers des serveurs externes. Dans notre cas, vu que c'est un projet scolaire, et il est hébergé localement, cela n'allait pas nous être util. De plus, il crée une dépendance forte à un fournisseur.

Pourquoi pas SkyWalking ? SkyWalking est très complet (APM, métriques, logs, traces) mais sa mise en place est nettement plus complexe. Il utilise un agent Java qui modifie le bytecode à la volée, ce qui peut créer des incompatibilités. Il est davantage adapté à des environnements Kubernetes avec de nombreux microservices.

2.2 Logs : Loki + Promtail vs ELK Stack vs Fluentd

Nous avons retenu Loki (stockage de logs) + Promtail (collecteur de logs Docker).

Critère Loki + Promtail ELK Stack Fluentd
Mémoire RAM requise ~200 Mo ~2–4 Go (Elasticsearch) ~300 Mo
Intégration Grafana Native Via plugin Via plugin
Complexité config Faible Élevée Moyenne
Indexation Par labels Full-text (Lucene) Configurable
Recherche full-text Non Oui Non

Pourquoi pas ELK (Elasticsearch + Logstash + Kibana) ? L'ELK Stack est la référence pour la recherche dans les logs (full-text), mais Elasticsearch est extrêmement gourmand en ressources — il consomme facilement 2 à 4 Go de RAM sur un poste de développement. Pour notre projet, la recherche par labels (application, niveau de log) est suffisante. Loki est conçu pour fonctionner léger.

Pourquoi pas Fluentd ? Fluentd est un bon outil mais sa configuration est plus complexe que Promtail, et son intégration avec Grafana nécessite un plugin supplémentaire. Promtail est développé par la même équipe que Loki, la compatibilité est donc garantie.

2.3 Traces : Jaeger vs Zipkin vs OpenTelemetry

Nous avons utilisé Jaeger via le protocole OpenTracing (supporté nativement par Quarkus).

Critère Jaeger Zipkin SkyWalking
Interface UI Riche (timeline, DAG) Simple Très complète
Intégration Quarkus Native (quarkus-smallrye-opentracing) Via lib externe Agent bytecode
Mode tout-en-un Oui (all-in-one) Oui Non
Facilité de démarrage Très facile Facile Complexe

Pourquoi pas Zipkin ? Zipkin est plus simple mais son interface est moins riche que Jaeger. Il ne supporte pas nativement le format Jaeger, ce qui aurait nécessité une conversion. Quarkus a un support intégré pour Jaeger via OpenTracing.

Une note sur OpenTracing vs OpenTelemetry : OpenTracing est le standard que nous utilisons ici car Quarkus 3.7.1 le supporte via quarkus-smallrye-opentracing. OpenTelemetry (OTel) est le successeur et fusionne les standards OpenTracing et OpenCensus. Pour un nouveau projet, OTel serait le choix idéal, mais la migration depuis OpenTracing demande des ajustements que nous n'avons pas eu à faire ici.

2.4 Visualisation : Grafana vs Kibana vs SkyWalking UI

Grafana est le tableau de bord central qui regroupe métriques (Prometheus), logs (Loki) et traces (Jaeger).

Critère Grafana Kibana SkyWalking UI
Multi-datasources Oui (Prometheus + Loki + Jaeger) Non (ELK uniquement) Non (SkyWalking uniquement)
Provisioning automatique Oui (fichiers JSON/YAML) Partiel Non
Communauté / dashboards prêts Très large Large Limitée
Coût Gratuit Gratuit (base) Gratuit

Pourquoi pas Kibana ? Kibana est lié à l'écosystème Elasticsearch. Il faudrait donc l'ELK Stack en plus, ce qui alourdit énormément le projet (voir section 2.2). Grafana peut se connecter à Prometheus ET Loki ET Jaeger simultanément en un seul outil.

2.5 Pourquoi pas Zuul ?

Zuul est une API Gateway développée par Netflix (intégrée à Spring Cloud). Son rôle est de router les requêtes entre plusieurs microservices, de gérer l'authentification et la limitation de débit. Dans notre architecture, nous n'avons qu'un seul service API (doodle-api), donc une API Gateway est inutile. Zuul ne fait pas de l'observabilité — c'est un composant d'infrastructure pour les architectures microservices complexes.

2.6 Pourquoi pas KuberHealthy ?

KuberHealthy est un framework de tests de santé spécifique à Kubernetes. Notre projet tourne sur Docker Compose, donc KuberHealthy est hors scope. En revanche, nous utilisons les health checks Docker (/q/health) et les health checks Quarkus (SmallRye Health) qui remplissent ce rôle dans notre contexte.

Résumé des choix

Besoin Notre choix Raison principale
Métriques Prometheus + Micrometer Intégration native Quarkus, gratuit
Logs Loki + Promtail Léger, intégré Grafana
Traces Jaeger + OpenTracing Support natif Quarkus, simple
Dashboard Grafana Multi-datasources, provisioning auto
Orchestration Docker Compose Simple, adapté dev/démo

3. Prérequis

Avant de commencer, s'assurer que les outils suivants sont installés :

Outil Version minimale Vérification
Docker Desktop 4.x docker --version
Docker Compose v2 (inclus dans Docker Desktop) docker compose version
Java + Maven (pour builder l'API) 17 java --version
Git 2.x git --version
curl — curl --version
bash — Git Bash sur Windows, terminal sur Linux/macOS

Sur Windows : On utilise Git Bash ou WSL2 pour exécuter les scripts .sh. Car PowerShell ne supporte pas la syntaxe bash.

Docker Desktop doit être lancé avant toute commande Docker. On Vérifie que l'icône Docker dans la barre des tâches est verte.

4. Structure du projet

doodlestudent/
├── api/                            Code source Quarkus (Java 17)
│   ├── src/main/resources/
│   │   └── application.yml         Config : métriques, logs JSON, tracing Jaeger
│   └── src/main/docker/
│       └── Dockerfile.jvm          Image Docker de l'API (JVM mode)
├── front/                          Frontend Angular (servi par Nginx)
├── monitoring/
│   ├── prometheus/
│   │   └── prometheus.yml          Config scrape : cible api:8080/q/metrics
│   ├── loki/
│   │   └── loki-config.yml         Stockage logs (filesystem, mode single-node)
│   ├── promtail/
│   │   └── promtail-config.yml     Collecte logs Docker → Loki
│   └── grafana/
│       ├── dashboards/
│       │   └── doodle-api.json     Dashboard JSON (7 panneaux, chargé automatiquement)
│       └── provisioning/
│           ├── datasources/
│           │   └── datasources.yml Prometheus + Loki + Jaeger (auto-configurés)
│           └── dashboards/
│               └── dashboards.yml  Chargement auto du dossier dashboards/
├── docker-compose.yml              Orchestration des 10 services
├── load-test.sh                    Script de simulation de trafic (50 cycles)
└── README.md                       Ce fichier

5. Démarrage rapide

Étape 1 — Cloner le dépôt

git clone https://github.com/selabs-ur1/doodle.git doodlestudent
cd doodlestudent

Si vous avez déjà le dépôt en local, il suffit de cd dans le dossier.

Étape 2 — Lancer Docker Desktop

Sur Windows, on ouvre Docker Desktop depuis le menu Démarrer et attendre que l'icône passe au vert dans la barre des tâches.

Étape 3 — Construire et démarrer tous les services

docker compose up --build -d

Docker va télécharge les images de base et compile l'API Java avec Maven. Les exécutions suivantes seront bien plus rapides grâce au cache Docker.

Étape 4 — Vérifier que tout est démarré

docker compose ps

Tous les services doivent afficher running (healthy pour la base de données), par exemple ce qu'on observait :

NAME                STATUS
doodle-api          running
doodle-db           running (healthy)
doodle-etherpad     running
doodle-front        running
doodle-grafana      running
doodle-jaeger       running
doodle-loki         running
doodle-mail         running
doodle-prometheus   running
doodle-promtail     running

Étape 5 — Vérifier que l'API répond

curl http://localhost:8080/q/health

Réponse attendue : {"status":"UP", ...}. Si l'API ne répond pas encore, attendre un instant puis réessayer.

6. Accès aux interfaces

Interface URL Identifiants
Frontend Doodle http://localhost:80 —
API REST http://localhost:8080/api/polls —
Swagger UI http://localhost:8080/q/swagger-ui —
Grafana http://localhost:3000 admin / doodle123
Prometheus http://localhost:9090 —
Jaeger http://localhost:16686 —
Loki (API) http://localhost:3100 —
Etherpad http://localhost:9001 —

Accéder au dashboard Grafana

  1. Ouvrir http://localhost:3000
  2. Se connecter avec admin / doodle123
  3. Dans le menu gauche, cliquez sur Dashboards puis sur "Doodle API"

Le dashboard contient 7 panneaux :

Panneau Métrique Description
Taux de requêtes HTTP http_server_requests_seconds_count req/s par endpoint et statut
Latence P95 http_server_requests_seconds_bucket Temps de réponse au 95e percentile
Erreurs HTTP 4xx/5xx http_server_requests_seconds_count Taux d'erreur par statut
JVM Heap Memory jvm_memory_used/max_bytes Mémoire Java consommée vs max
Threads JVM actifs jvm_threads_live_threads Nombre de threads en cours
Activité DB http_server_requests...{uri=~"/api/polls.*"} Trafic et latence vers les endpoints DB
Logs en temps réel Loki {service="doodle-api"} Flux de logs JSON de l'API

Explorer les traces dans Jaeger

  1. Ouvrir http://localhost:16686
  2. Dans le menu Service, sélectionner doodle-api
  3. Cliquer Find Traces
  4. Cliquer sur une trace pour voir le détail des spans

Explorer les métriques brutes dans Prometheus

  1. Ouvrir http://localhost:9090
  2. Dans la barre de recherche, taper http_server_requests_seconds_count
  3. Cliquer Execute puis passer en vue Graph

7. Simulation de trafic

Pour générer du trafic réaliste et voir les panneaux Grafana s'animer, un script de test de charge est fourni.

Lancer le test

chmod +x load-test.sh
./load-test.sh

Ce que fait le script

Le script effectue 50 cycles d'opérations qui simulent un usage normal de l'API :

Étape Requête But
1 GET /api/polls Lister les sondages (SELECT en DB)
2 POST /api/polls Créer un sondage (INSERT en DB)
3 GET /api/polls/{id} Lire le sondage créé
4 GET /q/health Vérifier la santé de l'API
5 GET /q/metrics Lire les métriques Prometheus
6 GET /api/polls/99999 Simuler une erreur 404

Une pause de 0.5 s entre chaque cycle.

Observer dans Grafana pendant le test

  • Le taux de requêtes monte immédiatement
  • La latence P95 apparaît après ~1 minute de collecte
  • Les erreurs 404 sont visibles dans le panneau Erreurs
  • L'activité DB montre le trafic sur /api/polls
  • Les logs défilent dans le panneau Loki

Grafana se rafraîchit toutes les 10 secondes. La fenêtre de temps est réglée sur les 30 dernières minutes par défaut.

8. Comprendre le monitoring

8.1 Métriques — Prometheus scrape l'API

[API Quarkus :8080]
      │
      │  expose /q/metrics (format Prometheus/OpenMetrics)
      │  via Micrometer (quarkus-micrometer-registry-prometheus)
      |
[Prometheus :9090] ── scrape toutes les 10s ──► stocke les séries temporelles
      │
      │  requêtes PromQL
      |
[Grafana :3000] ── affiche les graphes

Quarkus expose automatiquement les métriques JVM, HTTP et système via Micrometer. L'histogramme HTTP est activé (histogram: true) pour permettre le calcul du P95.

8.2 Logs — Promtail → Loki

[API Quarkus]
      │
      │  logs JSON structurés sur stdout
      │  (quarkus.log.console.json: true)
      |
[Docker Engine] : stocke les logs du container
      │
[Promtail] : lit via Docker socket (/var/run/docker.sock)
      │  parse le JSON (champs level, message, traceId...)
      │  applique le label service=doodle-api
      |
[Loki :3100] : stocke par labels (pas d'index full-text)
      │
      │  requêtes LogQL
      |
[Grafana :3000] : affiche les logs en temps réel

Promtail détecte automatiquement le container doodle-api grâce au label Docker logging=promtail défini dans docker-compose.yml.

8.3 Traces — Jaeger via OpenTracing

[API Quarkus]
      │
      │  génère des spans pour chaque requête HTTP
      │  via quarkus-smallrye-opentracing
      │  envoie vers Jaeger par HTTP (port 14268)
      |
[Jaeger :16686] ── stocke et visualise les traces

Chaque requête reçoit un traceId unique. Si une requête échoue ou est lente, Jaeger permet de voir exactement à quelle étape le problème s'est produit.

9. Les problèmes que nous avons rencontrés et solutions

Docker Desktop non démarré

Erreur : failed to connect to the docker API at npipe:////./pipe/dockerDesktopLinuxEngine

Solution : On n'avait pas lancer Docker Desktop. Il faut lancer Docker Desktop depuis le menu Démarrer Windows et attendre que l'icône passe au vert.

Panneau "Latence P95" — No Data

Cause : L'histogramme HTTP n'était pas activé dans le container.

Solution : Vérifier dans docker-compose.yml la présence de :

QUARKUS_MICROMETER_BINDER_HTTP_SERVER_HISTOGRAM: "true"

Puis reconstruire : docker compose up --build -d api

Panneau "Logs en temps réel" — No Data

Cause 1 — Sur Linux/macOS : Promtail ne peut pas accéder au socket Docker.

Vérification :

docker logs doodle-promtail

Cause 2 — Sur Windows avec Git Bash : Le chemin /var/run/docker.sock est converti par Git Bash en chemin Windows. Il faut Modifier le volume dans docker-compose.yml :

# Uniquement sur Windows + Git Bash
- //var/run/docker.sock:/var/run/docker.sock:ro

Vérifier que Loki reçoit les logs :

curl "http://localhost:3100/loki/api/v1/labels"

Si service apparaît dans la liste, les logs arrivent correctement.

L'API ne démarre pas

Cause : MySQL n'est pas encore prêt.

Solution : Attendre quelques secondes puis :

docker compose restart api

Grafana n'affiche pas le dashboard

Cause : Le provisioning n'a pas fonctionné au premier démarrage.

Solution :

docker compose restart grafana

Attendre quelques secondes, puis recharger http://localhost:3000.

Erreur "port already in use"

Cause : Un service local utilisait déjà un port par exemple, MySQL local sur 3306.

Solution : Arrêter le service local, ou changer le port hôte dans docker-compose.yml :

ports:
  - "3307:3306"  # port hôte modifié, port container inchangé

Services Docker et leurs rôles

Service Image Port Rôle
doodle-api Build local (Quarkus JVM) 8080 API REST principale
doodle-db mysql:8.0 3306 Base de données
doodle-front Build local (Angular + Nginx) 80 Interface utilisateur
doodle-etherpad etherpad/etherpad 9001 Édition collaborative
doodle-mail bytemark/smtp 2525 Serveur SMTP
doodle-prometheus prom/prometheus:v2.47.0 9090 Collecte métriques
doodle-loki grafana/loki:2.9.0 3100 Stockage logs
doodle-promtail grafana/promtail:2.9.0 — Collecte logs Docker
doodle-jaeger jaegertracing/all-in-one:1.49 16686, 14268 Traces distribuées
doodle-grafana grafana/grafana:10.1.0 3000 Dashboard de visualisation

10. Arrêt et nettoyage

Arrêter les services

docker compose down

Arrêter et supprimer toutes les données

docker compose down -v

-v supprime les volumes Docker : base de données, historique Prometheus, dashboards Grafana, logs Loki. À utiliser uniquement pour repartir de zéro.

Reconstruire l'API après modification du code source

docker compose up --build -d api

Voir les logs d'un service en temps réel

docker logs doodle-api -f        # Logs de l'API
docker logs doodle-prometheus -f  # Logs Prometheus
docker logs doodle-promtail -f   # Logs Promtail (debug collecte)
docker logs doodle-grafana -f    # Logs Grafana

Inspecter une métrique directement

# Toutes les métriques disponibles
curl -s http://localhost:8080/q/metrics | head -50

# Métriques HTTP uniquement
curl -s http://localhost:8080/q/metrics | grep http_server

# Métriques JVM
curl -s http://localhost:8080/q/metrics | grep jvm_memory

Modifications apportées au dépôt original

Le dépôt cloné depuis https://github.com/selabs-ur1/doodle.git contenait uniquement l'application Doodle (API Quarkus + frontend Angular), sans aucun outillage d'observabilité. Voici l'ensemble des fichiers que nous avons ajoutés ou modifiés pour mettre en place la chaîne Logging + Tracing + Monitoring.

1. api/src/main/resources/application.yml — Instrumentation de l'API

Fichier modifié (existait dans le dépôt original, nous l'avons enrichi).

Le fichier de configuration Quarkus d'origine se limitait aux paramètres de base (datasource, Hibernate, mailer). Nous avons ajouté trois blocs de configuration qui transforment l'API en application observable :

Métriques (Micrometer + Prometheus) :

quarkus:
  micrometer:
    export:
      prometheus:
        enabled: true
        path: /q/metrics
    binder:
      http-server:
        histogram: true          # indispensable pour le calcul du P95
        percentiles: "0.5,0.95,0.99"
      datasource:
        enabled: true

L'activation de l'histogramme HTTP (histogram: true) est le point clé : sans lui, la métrique http_server_requests_seconds_bucket n'existe pas et le panneau Latence P95 de Grafana affiche "No data".

Logs JSON structurés (pour Promtail/Loki) :

  log:
    console:
      json: true                 # format JSON au lieu de texte brut
      json.pretty-print: false   # une ligne par log, plus facile à parser

Quarkus écrit ses logs sur stdout. En activant le format JSON, chaque ligne de log devient un objet structuré que Promtail peut parser pour en extraire les champs level, message, traceId.

Tracing distribué (Jaeger via OpenTracing) :

  jaeger:
    service-name: doodle-api
    endpoint: http://localhost:14268/api/traces
    sampler-type: const
    sampler-param: "1"          # 100% des requêtes tracées

Chaque requête HTTP reçoit un identifiant de trace unique (traceId) visible dans Jaeger.

2. docker-compose.yml — Orchestration complète

Fichier ajouté (n'existait pas dans le dépôt original, nous l'avons créé entièrement).

Le dépôt cloné ne contenait aucun docker-compose.yml. Nous avons donc créé ce fichier de zéro en y intégrant à la fois les services applicatifs existants (api, front, db, etherpad, mail) et les cinq nouveaux services de monitoring.

Services ajoutés :

Service Image Rôle
prometheus prom/prometheus:v2.47.0 Collecte et stocke les métriques toutes les 10 s
loki grafana/loki:2.9.0 Stocke les logs indexés par labels
promtail grafana/promtail:2.9.0 Collecte les logs Docker et les envoie à Loki
jaeger jaegertracing/all-in-one:1.49 Reçoit et visualise les traces OpenTracing
grafana grafana/grafana:10.1.0 Dashboard unifié (métriques + logs + traces)

Modifications du service api :

Nous avons ajouté des variables d'environnement pour activer les métriques Agroal et l'histogramme HTTP, et deux labels Docker indispensables pour Promtail :

labels:
  logging: "promtail"    # Promtail ne collecte que les containers avec ce label
  app: "doodle-api"      # devient le label 'service' dans Loki

Sans ces labels, Promtail ignore le container doodle-api et le panneau Logs de Grafana reste vide.

3. monitoring/prometheus/prometheus.yml — Configuration du scrape

Fichier ajouté (n'existait pas dans le dépôt original).

Ce fichier configure Prometheus pour qu'il collecte les métriques de l'API toutes les 10 secondes en interrogeant l'endpoint /q/metrics exposé par Quarkus :

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'doodle-api'
    metrics_path: '/q/metrics'
    scrape_interval: 10s
    static_configs:
      - targets: ['api:8080']
        labels:
          service: 'doodle-api'

Le label job: doodle-api est automatiquement ajouté par Prometheus et sert de filtre dans toutes les requêtes PromQL du dashboard Grafana.

4. monitoring/loki/loki-config.yml — Stockage des logs

Fichier ajouté (n'existait pas dans le dépôt original).

Configuration de Loki en mode single-node avec stockage sur le système de fichiers. Ce mode est adapté à un environnement de développement/démonstration. Le schéma de stockage boltdb-shipper avec v11 est le standard pour Loki 2.9.

5. monitoring/promtail/promtail-config.yml — Collecte des logs Docker

Fichier ajouté (n'existait pas dans le dépôt original).

Promtail est configuré pour utiliser la découverte automatique des containers Docker via le socket Docker (/var/run/docker.sock). Il ne collecte que les containers ayant le label logging=promtail, ce qui évite de remonter les logs de tous les containers (prometheus, grafana, etc.) dans Loki :

scrape_configs:
  - job_name: docker
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        filters:
          - name: label
            values: ["logging=promtail"]   # filtre : uniquement doodle-api
    pipeline_stages:
      - docker: {}
      - json:
          expressions:
            level: level
            message: message
    relabel_configs:
      - source_labels: ['__meta_docker_container_label_app']
        target_label: 'service'            # service=doodle-api dans Loki

Problème rencontré sur Windows avec Git Bash : Le chemin /var/run/docker.sock est automatiquement converti par Git Bash en chemin Windows (C:\var\run\docker.sock), ce qui casse la connexion au daemon Docker. La solution est d'utiliser la notation //var/run/docker.sock (double slash) dans le volume Docker Compose, uniquement sous Windows.

6. monitoring/grafana/provisioning/datasources/datasources.yml — Sources de données Grafana

Fichier ajouté (n'existait pas dans le dépôt original).

Le provisioning Grafana permet de configurer les datasources automatiquement au démarrage, sans passer par l'interface graphique. Nous avons configuré les trois sources :

datasources:
  - name: Prometheus  # métriques (PromQL)
    uid: prometheus
    url: http://prometheus:9090
  - name: Loki        # logs (LogQL)
    uid: loki
    url: http://loki:3100
  - name: Jaeger      # traces
    uid: jaeger
    url: http://jaeger:16686

Les uid (prometheus, loki, jaeger) sont référencés directement dans le fichier JSON du dashboard, ce qui garantit que les panneaux se connectent à la bonne datasource sans configuration manuelle.

7. monitoring/grafana/dashboards/doodle-api.json — Dashboard Grafana

Fichier ajouté (n'existait pas dans le dépôt original).

Dashboard JSON défini en code, chargé automatiquement au démarrage de Grafana via le provisioning. Il contient 7 panneaux qui couvrent les quatre piliers de l'observabilité :

Panneau Type Requête
Taux de requêtes HTTP Time series rate(http_server_requests_seconds_count[1m])
Latence P95 Time series histogram_quantile(0.95, ...)
Erreurs 4xx/5xx Time series rate(...{status=~"4|5.."}[1m])
JVM Heap Memory Time series jvm_memory_used_bytes{area="heap"}
Threads JVM actifs Stat jvm_threads_live_threads
Activité DB (/api/polls) Time series rate(...{uri=~"/api/polls.*"}[1m])
Logs en temps réel Logs {service="doodle-api"} (LogQL)

Problème rencontré : En Quarkus 3.7.1 avec l'extension quarkus-micrometer-registry-prometheus, les métriques Agroal (pool de connexions) et Hibernate ne sont pas exposées dans l'endpoint /q/metrics contrairement à ce que la documentation laisse entendre. Ces métriques fonctionnent uniquement avec l'extension quarkus-smallrye-metrics (MicroProfile Metrics), incompatible avec Micrometer. Nous avons donc remplacé ce panneau par une surveillance indirecte de l'activité base de données via les métriques HTTP filtrées sur les endpoints /api/polls/*.

8. load-test.sh — Script de simulation de trafic

Fichier ajouté (n'existait pas dans le dépôt original).

Script bash de test de charge effectuant 50 cycles de requêtes réalistes sur l'API. Il permet de générer du trafic visible dans Grafana et de valider que l'ensemble de la chaîne d'observabilité fonctionne de bout en bout.

Résumé des modifications

Fichier Statut Impact
api/src/main/resources/application.yml Modifié Active métriques, logs JSON, tracing
docker-compose.yml Ajouté Créé de zéro : services applicatifs + 5 services d'observabilité
monitoring/prometheus/prometheus.yml Ajouté Scrape l'API toutes les 10 s
monitoring/loki/loki-config.yml Ajouté Stockage des logs
monitoring/promtail/promtail-config.yml Ajouté Collecte logs Docker → Loki
monitoring/grafana/provisioning/datasources/datasources.yml Ajouté Auto-config Prometheus + Loki + Jaeger
monitoring/grafana/provisioning/dashboards/dashboards.yml Ajouté Chargement auto du dashboard
monitoring/grafana/dashboards/doodle-api.json Ajouté Dashboard 7 panneaux
load-test.sh Ajouté Simulation de trafic (50 cycles)
README.md Ajouté Guide complet de mise en place

Auteurs

Projet réalisé dans le cadre du cours de DevOps — ESIR 2 IOT
Année universitaire 2025–2026

Nom Rôle
DIARRA Fatouma Yasmine Membre de l'équipe
NIANZOU Boa Emmanuel Membre de l'équipe
TAPE Guy Stéphane Membre de l'équipe

Dépôt original : https://github.com/selabs-ur1/doodle.git

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@EmmanuelNianzou