TP 3 - Loki Integration : Intégration Logs & Métriques TAAF

Objectifs

📡 Poste SOC · La Réunion — vous supervisez Port-aux-Français (Kerguelen), à ~3 300 km. Liaison SATCOM nominale.

🎯 Objectif métier — corréler logs et métriques au même endroit pour remonter d’un symptôme à sa cause en minutes.

🔴 Au fil de l’enquête

Le jour J à 10:22Z, l’attaquant effacera son .bash_history pour couvrir ses traces. La manœuvre ne fonctionne que si les logs restent sur la machine. Centraliser dans Loki, c’est mettre les preuves hors de portée de celui qui veut les détruire — et clore l’Acte 1 en rendant l’infra non seulement visible, mais mémorable.

Ce TP vous apprend à :

1. Intégrer Loki dans une stack de monitoring existante
2. Corréler logs et métriques pour une analyse complète
3. Créer des dashboards hybrides (Prometheus + Loki)
4. Configurer des alertes mixtes basées sur logs et métriques
5. Analyser des incidents avec une approche multi-sources

Stack Monitoring vs Stack SIEM

Important : Dans l’architecture TAAF, il y a deux stacks indépendantes :

• Stack Monitoring (ce TP) : Logs applicatifs → Grafana Alloy → Loki → Grafana

  • Pour l’observabilité des applications (Nextcloud, PostgreSQL)

• Stack SIEM : Événements de sécurité → Falco → Wazuh (syslog)

  • Pour la détection d’intrusion et sécurité

Ce TP se concentre sur la stack Monitoring (logs applicatifs).

---

Architecture du TP3

graph TB
 subgraph "Applications"
 NC[Nextcloud]
 PG[PostgreSQL]
 end

 subgraph "Collecte"
 PROM[Prometheus
Métriques]
 ALLOY[Grafana Alloy
Logs]
 end

 subgraph "Stockage"
 LOKI[Loki
Logs]
 end

 subgraph "Visualisation"
 GRAF[Grafana]
 D1[Dashboard
Métriques]
 D2[Dashboard
Logs]
 D3[Dashboard
Hybride]
 end

 NC -->|métriques|PROM
 PG -->|métriques|PROM
 NC -->|logs|ALLOY
 PG -->|logs|ALLOY

 ALLOY --> LOKI
 PROM --> GRAF
 LOKI --> GRAF

 GRAF --> D1
 GRAF --> D2
 GRAF --> D3

 U[Vous] -->|créez dashboards hybrides|GRAF

 classDef app fill:#ffcc99,stroke:#333,stroke-width:2px
 classDef collect fill:#99ccff,stroke:#333,stroke-width:2px
 classDef store fill:#e6ccff,stroke:#333,stroke-width:2px
 classDef viz fill:#99ff99,stroke:#333,stroke-width:2px
 classDef user fill:#99ccff,stroke:#333,stroke-width:2px

 class NC,PG app
 class PROM,ALLOY collect
 class LOKI store
 class GRAF,D1,D2,D3 viz
 class U user

Dans ce TP, vous allez :

1. Utiliser Grafana Alloy pour collecter les logs applicatifs
2. Stocker les logs dans Loki
3. Interroger les logs avec LogQL
4. Corréler les logs (Loki) avec les métriques (Prometheus) dans Grafana

---

Étape 0 : Configuration de la Source de Données Loki dans Grafana

Configuration obligatoire

Avant de commencer le TP, vous devez configurer Loki comme source de données dans Grafana pour pouvoir interroger les logs avec LogQL.

0.1 Ajouter la Source de Données Loki

1. Connectez-vous à Grafana : http://IP_VM2:3000

   • User : admin
   • Password : AdminTAAF2024!

2. Dans le menu de gauche, allez dans Configuration → Data Sources

3. Cliquez sur Add data source

4. Recherchez et sélectionnez Loki

0.2 Configuration de la Connexion

Loki et Grafana sont dans le même docker compose (VM monitoring) :

Paramètre	Valeur	Description
Name	Loki TAAF	Nom de la source de données
URL	http://loki:3100	Nom du service Docker

Datasource = nom de service Docker

• Loki tourne dans le même réseau Docker que Grafana (VM monitoring)
• Utilisez le nom du service Docker : http://loki:3100
• N’utilisez PAS localhost ni l’IP de la VM dans la configuration datasource

0.3 Tester la Connexion

1. Cliquez sur Save & Test

2. Vérifiez le message de succès :

   • ✅ “Data source connected and labels found”
   • ✅ “Data source connected, but no labels received” (acceptable si Loki est vide)

3. Si vous obtenez une erreur :

   • Vérifiez que Loki est démarré : docker ps | grep loki
   • Testez la connectivité : curl http://localhost:3100/ready

0.4 Checkpoint de Validation

Validation Étape 0

Avant de continuer, vérifiez :

• Datasource Loki configurée dans Grafana
• Test de connexion réussi
• Loki accessible depuis le conteneur Grafana

---

Étape 1: Configuration de l’intégration

Prérequis

Convention d’accès — localhost, IP_VM2 ou nom de service ?

L’adresse change selon d’où vous lancez la commande :

• curl / CLI en SSH sur la VM → localhost est correct (vous êtes sur la machine).
• Navigateur depuis votre poste (« Ouvrez http://localhost:3000 ») → utilisez http://IP_VM2:3000.
• Datasource Grafana (Prometheus, Loki) → nom de service Docker (http://prometheus:9090, http://loki:3100), jamais localhost ni l’IP.

OBLIGATOIRE - TPs précédents :

• TP 1 - Grafana Metric terminé : Dashboard supervision conteneurs
• TP 2 - Grafana Data terminé : Dashboards données métier TAAF
• Stack de supervision complète démarrée

Déploiement Nextcloud

Ce TP utilise Nextcloud comme source de logs applicatifs à collecter. Si vous n’avez pas encore déployé Nextcloud, consultez la page Ressources Nextcloud pour les instructions complètes de déploiement et de configuration.

Configuration Loki :

• Dossier loki/ avec les configurations présent
• Accès admin à Grafana (http://localhost:3000)

Vérification de l’intégration

# 1. Vérifier que Loki est intégré dans la stack principale
cd Supervision/
docker-compose ps | grep loki

# 2. Tester la connectivité Loki
curl http://localhost:3100/ready

# 3. Vérifier Grafana Alloy
curl http://localhost:12345/metrics

Configuration Grafana

1. Accéder à Grafana : http://localhost:3000
2. Vérifier les datasources :
   • Configuration → Data Sources
   • Vérifier présence de “Loki” et “Prometheus”
3. Tester les connexions :
   • Cliquer sur chaque datasource
   • “Save & Test” pour vérifier la connectivité

Vérification de la configuration Docker

Configuration déjà prête

Les volumes Docker et la collecte de logs sont pré-configurés dans le docker-compose.yml fourni.

Vous n’avez qu’à vérifier que tout fonctionne correctement :

# Vérifier que le conteneur Alloy fonctionne
docker ps | grep alloy

# Vérifier que les logs sont collectés
docker logs grafana-alloy --tail 20

# Vous devriez voir des lignes comme :
# "component started" {...}
# "running" {...}

Si ces commandes échouent, consultez l’enseignant pour vérifier la configuration Docker.

Comprendre la Configuration Grafana Alloy

Rôle d’Alloy dans la pipeline de logs :

Grafana Alloy est l’agent de collecte qui :

• Lit les logs depuis les fichiers sources
• Applique des labels pour identifier l’origine des logs
• Peut collecter à la fois des logs (vers Loki) et des métriques (vers Prometheus)
• Transmet les données enrichies vers les systèmes de stockage

Architecture de remontée des logs :

[Applications] → Logs → [Grafana Alloy] → [Loki] → [Grafana]
                         ↑ Enrichissement
                         (labels: job, base, criticality...)

Configuration pré-configurée

Le fichier config/alloy/alloy.alloy est déjà fourni et configuré dans votre repository.

Votre mission : Comprendre sa structure pour l’utiliser efficacement dans vos requêtes LogQL.

Analyser le fichier config/alloy/alloy.alloy

Ouvrez le fichier config/alloy/alloy.alloy pour comprendre les 3 étapes principales de la pipeline simplifiée :

Configuration Minimaliste - Principe KISS

La configuration Alloy du TP TAAF suit le principe KISS (Keep It Simple, Stupid) :

• Pas de parsing complexe : Les logs sont envoyés bruts à Loki
• Extraction dynamique : Le parsing se fait dans Grafana avec LogQL (opérateurs | pattern, | regexp)
• Focus pédagogique : Comprendre la pipeline de base avant d’ajouter de la complexité

Avantages :

• Configuration simple à comprendre et déboguer (108 lignes au lieu de 450+)
• Flexibilité maximale : changez vos patterns de parsing dans Grafana sans redémarrer Alloy
• Moins de points de défaillance : pas de regex complexes à maintenir

Étape 1 : Découverte des fichiers (local.file_match)

Définit quels fichiers de logs surveiller avec leurs labels de base :

local.file_match "postgres_logs" {
  path_targets = [
    {
      "__path__" = "/var/log/postgresql/*.log",
      "job"      = "postgresql-logs",
      "base"     = "Alfred-Faure",
      "service"  = "database",
    },
  ]
}

Explication :

• __path__ : Pattern glob pour trouver les fichiers de logs
• job, base, service : Labels statiques qui seront ajoutés à tous les logs de cette source
• Ces labels permettent de filtrer et grouper les logs dans Grafana

Labels disponibles

La configuration simplifiée utilise uniquement 4 labels :

• job : Identifiant de la source de logs (ex: “postgresql-logs”, “nextcloud-af”)
• base : Base TAAF (ex: “Alfred-Faure”)
• service : Type de service (ex: “database”, “apache”)
• log_type : Type de log (ex: “access”, “error”) - uniquement pour Nextcloud

Important : Les labels comme level, status, ip, alert_priority ne sont pas créés automatiquement. Vous devez les extraire dynamiquement avec LogQL (voir section LogQL ci-dessous).

Tableau de référence des labels disponibles

Voici tous les labels créés automatiquement par la configuration Alloy :

Source de logs	Label job	Label base	Label service	Label log_type
PostgreSQL	postgresql-logs	Alfred-Faure	database	(non utilisé)
Nextcloud Access	nextcloud-af	(non utilisé)	apache	access
Nextcloud Error	nextcloud-af	(non utilisé)	apache	error

Exemples de requêtes avec ces labels :

# Tous les logs PostgreSQL
{job="postgresql-logs"}

# Tous les logs Nextcloud (access + error)
{job="nextcloud-af"}

# Uniquement logs Apache Access
{job="nextcloud-af", log_type="access"}

# Uniquement logs Apache Error
{job="nextcloud-af", log_type="error"}

# Tous les logs du service "apache"
{service="apache"}

# Tous les logs de la base Alfred-Faure
{base="Alfred-Faure"}

Labels NON disponibles

Les labels suivants n’existent PAS dans la configuration simplifiée :

• ❌ level (niveau de log ERROR/WARN/INFO)
• ❌ status (code HTTP 200/404/500)
• ❌ ip (adresse IP source)
• ❌ container_name (nom du conteneur)
• ❌ alert_priority, mission_impact, etc.

Pour utiliser ces informations, vous devez les extraire dynamiquement avec LogQL :

# Extraire le niveau de log avec pattern
{job="postgresql-logs"} | pattern `<timestamp> <timezone> [<pid>] <level>: <message>`

# Extraire le status HTTP avec regexp
{job="nextcloud-af", log_type="access"} | regexp `(?P<status>\d+)`

Étape 2 : Lecture des logs (loki.source.file)

Lit le contenu des fichiers et transmet directement à Loki :

loki.source.file "postgres_logs" {
  targets    = local.file_match.postgres_logs.targets
  forward_to = [loki.write.loki_endpoint.receiver]
}

Points clés :

• targets récupère les fichiers découverts à l’étape 1
• forward_to transmet directement à loki.write (pas d’étape de parsing intermédiaire)
• Les logs sont envoyés bruts à Loki avec uniquement les labels statiques

Étape 3 : Envoi vers Loki (loki.write)

Transmet les logs vers Loki :

loki.write "loki_endpoint" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Points clés :

• URL du service Loki (utiliser le nom du service Docker, pas loki-taaf)
• Configuration simple pour environnement local stable

Exemple complet : Pipeline Nextcloud

Voici comment Alloy collecte les logs Nextcloud (Apache Access + Error) :

// Logs Apache Access
local.file_match "nextcloud_access" {
  path_targets = [
    {
      "__path__" = "/var/log/apache2/access.log",
      "job"      = "nextcloud-af",
      "service"  = "apache",
      "log_type" = "access",
    },
  ]
}

loki.source.file "nextcloud_access" {
  targets    = local.file_match.nextcloud_access.targets
  forward_to = [loki.write.loki_endpoint.receiver]
}

// Logs Apache Error
local.file_match "nextcloud_error" {
  path_targets = [
    {
      "__path__" = "/var/log/apache2/error.log",
      "job"      = "nextcloud-af",
      "service"  = "apache",
      "log_type" = "error",
    },
  ]
}

loki.source.file "nextcloud_error" {
  targets    = local.file_match.nextcloud_error.targets
  forward_to = [loki.write.loki_endpoint.receiver]
}

Labels créés automatiquement :

• Nextcloud Access : job="nextcloud-af", service="apache", log_type="access"
• Nextcloud Error : job="nextcloud-af", service="apache", log_type="error"

Extraction de champs avec LogQL (Parsing dynamique)

Puisque les logs sont envoyés bruts, vous extrayez les informations dans Grafana avec LogQL :

Logs PostgreSQL - Extraction du niveau d’erreur

# Afficher tous les logs PostgreSQL
{job="postgresql-logs"}

# Extraire le champ "level" avec pattern
{job="postgresql-logs"} | pattern `<timestamp> <timezone> [<pid>] <level>: <message>`

# Filtrer uniquement les ERROR
{job="postgresql-logs"} | pattern `<timestamp> <timezone> [<pid>] <level>: <message>` | level = "ERROR"

# Compter les erreurs par minute
sum(count_over_time({job="postgresql-logs"} |= "ERROR" [1m]))

Logs Apache Access - Extraction méthode HTTP et status

# Tous les logs Apache Access
{job="nextcloud-af", log_type="access"}

# Extraire IP, méthode, path, status avec regexp
{job="nextcloud-af", log_type="access"}
  | regexp `(?P<ip>\S+) \S+ \S+ \[(?P<timestamp>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) (?P<protocol>\S+)" (?P<status>\d+)`

# Filtrer les erreurs serveur (5xx)
{job="nextcloud-af", log_type="access"}
  | regexp `(?P<status>\d+)`
  | status =~ "5.."

# Top 10 des IP par nombre de requêtes
topk(10, sum by (ip) (count_over_time(
  {job="nextcloud-af", log_type="access"}
  | regexp `(?P<ip>\S+)` [1h]
)))

Logs Apache Error - Recherche textuelle

# Tous les logs d'erreur Apache
{job="nextcloud-af", log_type="error"}

# Rechercher "PHP" dans les erreurs
{job="nextcloud-af", log_type="error"} |= "PHP"

# Rechercher "500" ou "Fatal"
{job="nextcloud-af", log_type="error"} |~ "500|Fatal"

# Compter les erreurs PHP par minute
sum(count_over_time({job="nextcloud-af", log_type="error"} |= "PHP" [1m]))

Référence LogQL

Opérateurs de filtrage :

• |= : Contient la chaîne (case-sensitive)
• != : Ne contient pas la chaîne
• |~ : Correspond au regex
• !~ : Ne correspond pas au regex

Opérateurs de parsing :

• | pattern : Parsing simple avec variables <nom>
• | regexp : Parsing regex avec groupes nommés (?P<nom>...)
• | json : Parsing automatique de JSON
• | logfmt : Parsing automatique de format logfmt

Agrégations temporelles :

• count_over_time({...}[1m]) : Compte les lignes sur 1 minute
• rate({...}[1m]) : Taux par seconde sur 1 minute
• sum by (label) : Somme groupée par label

Pas de modification nécessaire

Le fichier config/alloy/alloy.alloy est déjà optimisé pour l’apprentissage.

Vous n’avez pas besoin de le modifier pour ce TP. Concentrez-vous sur :

1. Comprendre les labels statiques disponibles (job, base, service, log_type)
2. Maîtriser LogQL pour extraire des champs dynamiquement
3. Créer des requêtes efficaces sans surcharger Loki

Configuration de Loki avec Ruler

Rôle du Loki Ruler :

Le Loki ruler permet de créer des alertes basées sur les logs en évaluant périodiquement des requêtes LogQL. Ces alertes sont ensuite envoyées vers Alertmanager, exactement comme les alertes Prometheus.

Architecture d’alerting hybride :

[Prometheus] → [Règles PromQL] → [Alertmanager] → [Webhooks]
[Loki] → [Règles LogQL via Ruler] → [Alertmanager] → [Webhooks]

Configuration du fichier loki.yml :

Le fichier config/loki/loki.yml contient la configuration complète de Loki, incluant le ruler :

# Extrait de loki.yml - Section Ruler
ruler:
  storage:
    type: local
    local:
      directory: /loki/rules
  rule_path: /loki/rules
  alertmanager_url: http://alertmanager:9093
  ring:
    kvstore:
      store: inmemory
  enable_api: true
  enable_sharding: false

Paramètres clés :

• directory: /loki/rules : Répertoire contenant les fichiers de règles d’alerte LogQL
• alertmanager_url : URL d’Alertmanager (utiliser le nom du service Docker, pas alertmanager-taaf)
• enable_api: true : Active l’API pour gérer les règles
• enable_sharding: false : Désactive le sharding (requis pour le mode monolithique)

Alertes basées sur les logs

La configuration d’alertes basées sur les logs Loki (Loki Ruler) sera abordée dans le TP4 - Alerting.

Pour le moment, concentrez-vous sur la collecte, l’exploration et la visualisation des logs.

---

Étape 2: Exploration des données

Exploration Prometheus (Métriques)

# Accéder à Explore → Prometheus
# Tester ces requêtes :

# 1. Utilisation CPU des conteneurs
rate(container_cpu_usage_seconds_total[5m])

# 2. Connexions PostgreSQL
pg_stat_database_numbackends

# 3. Métriques réseau
rate(container_network_receive_bytes_total[5m])

# 4. Statut des services
up

Exploration Loki (Logs)

# Accéder à Explore → Loki
# Tester ces requêtes LogQL :

# 1. Tous les logs disponibles
{job=~".+"}

# 2. Logs PostgreSQL uniquement
{job="postgresql-logs"}

# 3. Logs Nextcloud Apache
{job="nextcloud-af"}

# 4. Logs avec recherche textuelle (erreurs)
{job=~".+"} |= "ERROR"

# 5. Taux de logs contenant "error" par minute
sum(rate({job=~".+"} |= "error" [1m]))

# 6. Logs d'erreur PostgreSQL (extraction dynamique)
{job="postgresql-logs"} | pattern `<timestamp> <timezone> [<pid>] <level>: <message>` | level = "ERROR"

# 7. Logs Apache avec status 5xx (extraction dynamique)
{job="nextcloud-af", log_type="access"} | regexp `(?P<status>\d+)` | status =~ "5.."

---

Étape 3: Corrélation logs et métriques

Scénario 1: Analyse d’un pic de CPU

Objectif : Comprendre pourquoi un conteneur consomme beaucoup de CPU

1. Identifier le pic dans Prometheus :

rate(container_cpu_usage_seconds_total{name=~"postgres.+"}[5m])

2. Corréler avec les logs dans Loki :

{job="postgresql-logs"} |= "ERROR"

3. Timeline de corrélation :
   • Synchroniser les time ranges
   • Rechercher des logs d’erreur au moment du pic CPU

Scénario 2: Analyse d’une panne de service

Objectif : Analyser une interruption de service complète

1. Détecter la panne (Prometheus) :

up{job="postgres-exporter"}

2. Comprendre la cause (Loki) :

{job="postgresql-logs"} |= "FATAL"

3. Corréler l’impact (Prometheus) :

increase(pg_stat_database_deadlocks[1h])

---

Étape 4: Création d’un dashboard hybride

Dashboard “TAAF - Analyse d’Incident”

Panels à créer :

1. Panel Métriques - Statut des services

# Query: up
# Visualization: Stat
# Title: "Services Status"

2. Panel Logs - Erreurs récentes

# Query: {job=~".+"} |= "ERROR"
# Visualization: Logs
# Title: "Recent Errors"

3. Panel Hybride - Corrélation CPU/Logs

# Query A (Prometheus): rate(container_cpu_usage_seconds_total[5m])
# Query B (Loki): sum(rate({job=~".+"}[1m]))
# Visualization: Time series
# Title: "CPU vs Log Volume"

4. Panel Alertes - État des alertes

# Query: ALERTS{alertstate="firing"}
# Visualization: Table
# Title: "Active Alerts"

Configuration du dashboard

1. Créer un nouveau dashboard
2. Ajouter les variables :
   • $container : label_values(container_name) (pour métriques Prometheus/cAdvisor)
   • $job : label_values(job) (pour logs Loki)
   • $timerange : 5m,15m,1h,6h,24h
3. Configurer les time ranges synchronisés
4. Ajouter des annotations pour les alertes

---

Étape 5: Configuration des alertes

Alerte 1: Service down (Prometheus)

# Dans alert_rules.yml
- alert: TAAFServiceDown
  expr: up == 0
  for: 1m
  labels:
    severity: critical
    mission: taaf
  annotations:
    summary: "Service {{ $labels.job }} down"
    description: "Service {{ $labels.instance }} hors ligne depuis plus d'1 minute"

Alerte 2: High CPU (Prometheus)

- alert: TAAFHighCPU
  expr: rate(container_cpu_usage_seconds_total[5m]) > 0.8
  for: 2m
  labels:
    severity: warning
    mission: taaf
  annotations:
    summary: "High CPU on {{ $labels.name }}"
    description: "CPU élevé ({{ $value | humanizePercentage }}) depuis 2 minutes"

Alerte 3: Taux d’erreurs élevé dans les logs (Loki)

Pour créer des alertes basées sur les logs, vous avez deux approches :

Approche 1 : Loki Ruler (Recommandé pour production)

Le Loki ruler permet de créer des alertes directement dans Loki, qui sont ensuite envoyées vers Alertmanager.

Créer le fichier de règles :

# Créer le répertoire s'il n'existe pas
mkdir -p config/loki/rules

# Créer le fichier de règles
nano config/loki/rules/taaf_log_alerts.yml

config/loki/rules/taaf_log_alerts.yml

groups:
  - name: taaf_application_logs
    interval: 1m
    rules:
      - alert: TAAFHighErrorRate
        expr: |
          sum(rate({job=~".+"} |= "ERROR" [5m])) > 0.5
        for: 2m
        labels:
          severity: warning
          mission: taaf
        annotations:
          summary: "Taux d'erreurs élevé détecté dans les logs"
          description: "Plus de 0.5 erreurs/sec détectées ({{ $value }} erreurs/sec)"

Recharger les règles Loki :

# Redémarrer Loki pour charger les nouvelles règles
docker compose restart loki

# Vérifier que les règles sont chargées
curl http://localhost:3100/loki/api/v1/rules

# Vérifier les alertes actives
curl http://localhost:3100/loki/api/v1/alerts

Avantages de cette approche :

• Alertes gérées nativement par Loki
• Pas de dépendance à Grafana
• Envoi direct vers Alertmanager (même système que Prometheus)
• Meilleure performance pour l’évaluation des règles

Approche 2 : Grafana Alerting (Alternative)

Vous pouvez aussi créer des alertes via l’interface Grafana :

1. Dans Grafana : Alerting → Alert rules → New alert rule

2. Configurer la query Loki :

sum(rate({job=~".+"} |= "ERROR" [5m]))

3. Définir la condition :

WHEN query(A, 5m, now) > 0.5

4. Configuration :
   • Alert rule name : TAAF High Error Rate
   • Folder : TAAF Monitoring
   • Evaluation interval : 1m
   • Pending period : 2m
   • Summary : “Taux d’erreurs élevé détecté dans les logs”

Avantages de cette approche :

• Interface graphique pour la configuration
• Prévisualisation des alertes
• Utile pour le prototypage

Note sur les alertes hybrides (avancé)

Les alertes “hybrides” combinant métriques Prometheus ET logs Loki nécessitent Grafana Alerting avec plusieurs queries :

Query A (Prometheus): rate(container_cpu_usage_seconds_total{name=~"postgres.+"}[5m])
Query B (Loki): sum(rate({job="postgresql-logs"} |= "ERROR" [5m]))
Condition: WHEN (A > 0.8) AND (B > 0.1)

Cette approche permet de corréler logs et métriques dans une seule alerte.

Recommandation : Pour les environnements de production, privilégiez le Loki ruler pour les alertes logs simples, et Grafana Alerting uniquement pour les alertes hybrides nécessitant la corrélation Prometheus + Loki.

---

Exercices pratiques

Exercice 1: Investigation d’incident (Guidé)

Contexte : La base Port-aux-Français ne répond plus

Tâches :

1. Identifier le problème via Prometheus
2. Analyser les logs avec Loki
3. Corréler la timeline des événements
4. Proposer une solution

Métriques à vérifier :

up{instance=~".+paf.+"}
pg_up{instance=~".+paf.+"}
rate(container_cpu_usage_seconds_total{name=~".+paf.+"}[5m])

Logs à analyser :

# Tous les logs disponibles (recherche textuelle "paf")
{job=~".+"} |= "paf"

# Logs PostgreSQL avec recherche "paf"
{job="postgresql-logs"} |= "paf"

# Logs avec recherche "Port-aux-Francais"
{job=~".+"} |= "Port-aux-Francais"

Exercice 2: Dashboard personnalisé (Intermédiaire)

Objectif : Créer un dashboard pour votre base TAAF assignée

Requirements :

• 2 panels Prometheus (métriques)
• 2 panels Loki (logs)
• 1 panel hybride (corrélation)
• Variables de templating
• Seuils d’alerte visuels

Exercice 3: Alerte prédictive (Avancé)

Objectif : Créer une alerte qui prédit un problème

Scénario : Détecter une dégradation progressive

• Augmentation graduelle des erreurs dans les logs
• Diminution progressive des performances (métriques)
• Déclencher avant la panne complète

---

Analyse d’un cas réel

Incident simulé: “Panne de communication satellite”

Timeline de l’incident :

1. 10
   - Premiers signes dans les métriques

increase(container_network_transmit_errors_total[5m])

2. 10
   - Apparition d’erreurs dans les logs

{job=~".+"} |= "satellite" |= "connection"

3. 10
   - Panne complète

up{job="satellite-comm"} == 0

4. 10
   - Activation du backup

{job=~".+"} |= "backup" |= "activated"

Mission étudiante :

1. Reconstruire cette timeline avec Grafana
2. Identifier les indicateurs précurseurs
3. Proposer des alertes préventives

---

Métriques de performance

KPIs à monitorer

Métriques Prometheus :

# Latence moyenne des requêtes
histogram_quantile(0.95, prometheus_http_request_duration_seconds_bucket)

# Throughput Loki
rate(loki_request_duration_seconds_count[5m])

# Utilisation mémoire
process_resident_memory_bytes

Métriques Loki :

# Volume de logs par seconde
sum(rate({job=~".+"}[1m]))

# Distribution des niveaux de log (extraction dynamique)
sum by (level) (count_over_time({job="postgresql-logs"} | pattern `<timestamp> <timezone> [<pid>] <level>: <message>` [5m]))

# Taux de logs contenant "ERROR"
sum(rate({job=~".+"} |= "ERROR" [1h]))

# Top 10 des services par volume de logs
topk(10, sum by (service) (rate({job=~".+"}[1h])))

---

Outils et commandes utiles

Debug et tests

# Test requête Prometheus
curl -G 'http://localhost:9090/api/v1/query' \
  --data-urlencode 'query=up'

# Test requête Loki
curl -G 'http://localhost:3100/loki/api/v1/query' \
  --data-urlencode 'query={job="postgresql-logs"}' \
  --data-urlencode 'limit=10'

# Export dashboard
curl -s "http://admin:AdminTAAF2024!@localhost:3000/api/dashboards/uid/DASHBOARD_UID" | \
  jq '.dashboard' > my-dashboard.json

# Reload Prometheus config
curl -X POST http://localhost:9090/-/reload

Simulation d’événements

# Générer des logs d'erreur (exemple - nécessite un fichier log accessible)
for i in {1..20}; do
  echo "$(date '+%Y-%m-%d %H:%M:%S') ERROR Base_Test Simulation_erreur_$i" | \
  docker exec -i grafana-alloy sh -c 'cat >> /var/log/test-errors.log'
  sleep 1
done

# Stress test CPU (déclenche alertes)
docker run --rm --name cpu-stress progrium/stress \
  --cpu 4 --timeout 300s

# Arrêter un service (test alertes)
docker stop postgres-af

---

Questions de Validation

Les 10 questions suivantes valident votre compréhension et votre réalisation (difficulté croissante) :

Question 1 - Configuration de base (Facile)

“Listez les 3 sources de données configurées dans votre Grafana unifié.”

Réponse attendue : Liste des datasources (ex: Prometheus, Loki, autres) + captures d’écran de la configuration.

Question 2 - Requête LogQL simple (Facile)

“Combien de logs d’erreur (level=‘ERROR’) sont présents dans Loki pour la dernière heure ?”

Réponse attendue : Requête LogQL utilisée + résultat numérique + capture d’écran Explore.

Question 3 - Corrélation simple (Facile)

“À quel timestamp précis avez-vous observé une erreur critique dans les logs ET un pic CPU dans les métriques ?”

Réponse attendue : Timeline synchronisée + timestamp + capture des deux panels + corrélation identifiée.

Question 4 - Requête Prometheus (Moyen)

“Quelle est l’utilisation mémoire moyenne du conteneur postgres-af sur les 30 dernières minutes ?”

Réponse attendue : Requête PromQL avec agrégation temporelle + valeur en MB + graphique correspondant.

Question 5 - Analyse de patterns (Moyen)

“Identifiez le pattern horaire des logs d’erreur : à quelle heure observe-t-on le plus d’erreurs ?”

Réponse attendue : Requête LogQL avec extraction d’heure + histogramme + heure de pic + explication possible.

Question 6 - Dashboard hybride (Moyen)

“Créez un panel qui affiche simultanement le taux d’erreur logs (LogQL) et l’utilisation CPU (PromQL) du même service.”

Réponse attendue : Configuration panel à double axe + deux requêtes différentes + capture fonctionnelle + analyse de corrélation.

Question 7 - Configuration d’alerte (Moyen)

“Configurez une alerte Prometheus qui se déclenche quand l’utilisation CPU d’un conteneur dépasse 80% pendant 2 minutes.”

Réponse attendue : Règle d’alerte YAML complète dans alert_rules.yml + test de déclenchement via simulation + capture d’écran de l’alerte dans Grafana.

Question 8 - Investigation d’incident (Difficile)

“Analysez un incident où un service devient lent : corrélations entre métriques de performance et logs d’application.”

Réponse attendue : Scénario d’incident reconstitué + timeline complète + requêtes utilisées + analyse root cause + métriques corrélées.

Question 9 - Debug et simulation (Moyen)

“Simulez une panne de service (docker stop) et montrez comment vous l’identifiez via Prometheus ET analysez la cause via les logs Loki.”

Réponse attendue :

• Commande de simulation utilisée
• Requête PromQL montrant le service down
• Requête LogQL montrant les derniers logs avant la panne
• Timeline reconstituée avec captures d’écran
• Analyse de la corrélation entre les deux sources

Question 10 - Synthèse et cas d’usage TAAF (Difficile)

“Expliquez comment l’approche hybride (logs + métriques) améliore le monitoring des bases polaires TAAF par rapport à un monitoring traditionnel (métriques uniquement). Proposez 3 cas d’usage concrets spécifiques au contexte polaire.”

Réponse attendue :

• Analyse comparative : monitoring traditionnel vs hybride
• Avantages de la corrélation logs/métriques pour les bases isolées
• 3 cas d’usage TAAF détaillés avec :
  • Scénario problème
  • Métriques à surveiller
  • Logs à analyser
  • Alertes associées
• Adaptation au contexte polaire (connectivité limitée, isolation, conditions extrêmes)

---

Livrables

Rapport d’intégration

# Rapport TP Loki-Intégration TAAF

## 1. Configuration réalisée
- [ ] Services Loki/Grafana Alloy intégrés
- [ ] Datasources configurées dans Grafana
- [ ] Dashboards hybrides créés
- [ ] Alertes mixtes configurées

## 2. Dashboards créés
- Screenshot du dashboard principal
- Liste des panels créés
- Configuration des variables

## 3. Alertes hybrides
- Règles d'alerte créées
- Tests effectués
- Captures d'alertes déclenchées

## 4. Analyse d'incident
- Description du scénario traité
- Timeline reconstituée
- Corrélations identifiées
- Recommandations

## 5. Apprentissages
- Points forts de l'approche hybride
- Difficultés rencontrées
- Amélioration par rapport au monitoring seul

Fichiers techniques

• custom-alert-rules.yml - Vos règles d’alerte
• hybrid-dashboard.json - Export du dashboard créé
• integration-tests.sh - Scripts de test
• incident-timeline.md - Analyse d’incident

---

Pour aller plus loin

Intégrations avancées

• Tracing avec Tempo - Ajout de la dimension traces
• Service Mesh - Monitoring avec Istio
• Machine Learning - Détection d’anomalies avec Prometheus
• Chaos Engineering - Tests de résilience automatisés

Cas d’usage TAAF avancés

• Prédiction météo - Corrélation logs/métriques météo
• Optimisation énergie - Analyse consommation/logs
• Maintenance prédictive - Alertes sur dégradation équipements

---

Consignes de rendu OBLIGATOIRES

Plateforme de rendu : Moodle de l’Université de la Réunion

Nommage STRICT : nom-prénom-promo.PDF
Exemple : martin-lucas-but3.PDF

ATTENTION : Tout fichier ne respectant pas ce format de nommage entraînera une pénalité de -5 points sur la note finale.

---