Procédures de Monitoring et Alerting

1.1 Contexte

Le monitoring et l'alerting constituent des piliers essentiels de l'exploitation de la plateforme REWAPP. Dans un écosystème où la détection automatique des transactions bancaires et la génération de QR codes en temps réel sont au cœur de la proposition de valeur, une surveillance proactive est indispensable pour garantir la qualité de service.

Ce document définit les procédures complètes de monitoring et d'alerting pour l'ensemble de l'infrastructure REWAPP, incluant les quatre composantes principales :

• Application Mobile (iOS/Android)
• Site Vitrine (Angular)
• Dashboard Admin (Angular)
• Dashboard Partenaire (Angular + Ionic PWA)

1.2 Portée du Document

Ce document couvre :

• La définition des métriques surveillées (infrastructure, application, business, sécurité)
• La configuration des seuils d'alerte et niveaux de sévérité
• Les canaux de notification et la matrice d'escalade
• Les dashboards de visualisation par audience
• Les procédures de réponse aux incidents (runbooks)
• La maintenance et l'évolution du système de monitoring

2.1 Objectifs Principaux

2.2 Principes Directeurs

3.1 Architecture du Monitoring

L'infrastructure de monitoring REWAPP s'appuie sur une architecture multi-couches combinant CapRover et des outils open-source (Prometheus, Grafana, Loki).

3.2 Flux de Données

Le flux de collecte et d'alerte suit le chemin suivant :

1. 1

   Collecte

   Les métriques sont collectées par Prometheus (infra et app)

2. 2

   Agrégation

   Les données sont agrégées et stockées avec rétention configurable

3. 3

   Visualisation

   Grafana affiche les dashboards en temps réel

4. 4

   Analyse

   Les seuils sont évalués en continu par Grafana Alerts

5. 5

   Notification

   Les alertes sont routées vers PagerDuty puis distribuées aux équipes

3.3 Configuration des Outils

3.3.1 Prometheus + Grafana

Namespace         : REWAPP/Production, REWAPP/Staging
Résolution        : 1 minute (standard), 10 secondes (haute résolution critiques)
Rétention logs    : 90 jours (production), 30 jours (staging)
Dashboard refresh : 1 minute

3.3.2 Prometheus

Scrape interval : 15 secondes
Retention       : 15 jours (données brutes), 2 ans (données agrégées via Thanos)
Port exposition : 9090 (interne uniquement)

3.3.3 Grafana

Version         : 10.x
Authentification: SSO via intégration OAuth
Rôles           : Viewer (support), Editor (dev), Admin (ops)
Alertes         : Activées via Grafana Alerts + PagerDuty

3.3.4 Sentry

DSN             : Configuré par environnement (secrets manager)
Sample rate     : 100% erreurs, 10% transactions (performance)
Release tracking: Activé (corrélation avec déploiements)
PII             : Désactivé (conformité RGPD)

4.1 Métriques Infrastructure

4.1.1 Compute (Docker Containers)

4.1.2 Base de Données (RDS PostgreSQL)

4.1.3 Cache (ElastiCache Redis)

4.1.4 Load Balancer (ALB)

4.2 Métriques Application

4.2.1 API Backend (NestJS)

4.2.2 Services Métier

4.2.3 QR Code (Règle Métier Critique)

4.3 Métriques Business

4.4 Métriques Sécurité

5.1 Niveaux de Sévérité

5.2 Seuils d'Alerte par Métrique

5.2.1 Infrastructure

5.2.2 Application

5.3 Canaux de Notification

5.3.2 Canaux Slack

• #rewapp-alerts-critical : Alertes P1-P2 (équipe ops + management)
• #rewapp-alerts-warning : Alertes P3-P4 (équipe technique)
• #rewapp-security : Alertes sécurité uniquement
• #rewapp-business : Alertes KPIs business

5.3.3 Groupes de Distribution Email

• ops-critical@rewapp.fr : Alertes P1 (équipe ops + CTO)
• tech-alerts@rewapp.fr : Alertes P2-P3 (équipe technique)
• security-alerts@rewapp.fr : Alertes sécurité
• business-alerts@rewapp.fr : Alertes business (COO + équipe produit)

5.4 Matrice d'Escalade

5.4.2 Planning d'Astreinte

Rotation : Hebdomadaire (lundi 9h00 → lundi suivant 9h00)
Équipe   : 4 ingénieurs en rotation
Backup   : Un backup désigné par semaine
Outils   : PagerDuty, accès VPN, laptop de garde

Horaires :
• Heures ouvrées (9h-18h)  : Équipe technique complète disponible
• Soir (18h-22h)           : Ingénieur de garde (réponse P1 < 15 min)
• Nuit (22h-9h)            : Ingénieur de garde (réponse P1 < 30 min)
• Week-end                 : Ingénieur de garde (réponse P1 < 30 min)

6.1 Dashboard Opérationnel (Ops)

6.2 Dashboard Technique (Dev)

6.3 Dashboard Business

6.4 Dashboard Sécurité

7.1 Procédure Générale

7.1.1 Workflow de Réponse

1. 1

   Acknowledge

   Confirmer la prise en charge de l'alerte dans PagerDuty (< 5 min pour P1)

2. 2

   Assess

   Évaluer l'impact et confirmer la sévérité

3. 3

   Communicate

   Informer les parties prenantes via Slack

4. 4

   Investigate

   Identifier la cause racine via logs et dashboards

5. 5

   Mitigate

   Appliquer une correction temporaire si nécessaire

6. 6

   Resolve

   Appliquer la correction définitive

7. 7

   Document

   Créer un Post-Mortem pour les incidents P1-P2

7.1.2 Template de Communication

🚨 INCIDENT P[X] - [Titre court]

Impact    : [Description de l'impact utilisateur]
Début     : [Timestamp]
Statut    : Investigating / Identified / Monitoring / Resolved
Ingénieur : @[nom]

Dernière mise à jour : [Timestamp] - [Description action]

7.2 Runbooks par Type d'Incident

7.2.1 Runbook : API Latency Élevée

Étapes de diagnostic :

1. Vérifier le dashboard Grafana "API Performance"
   → Identifier les endpoints les plus lents

2. Vérifier la charge infrastructure
   → CPU/RAM des containers ECS
   → Connexions et latence RDS
   → Hit ratio Redis

3. Vérifier les logs CloudWatch
   → Filtrer sur slow queries (> 1s)
   → Rechercher erreurs timeout

4. Vérifier les déploiements récents
   → Corrélation avec un déploiement ?

Actions de remédiation :

[Si CPU élevé]
→ Déclencher scale-out ECS manuellement
→ aws ecs update-service --cluster rewapp-prod --service api --desired-count [N+2]

[Si DB saturée]
→ Vérifier les slow queries :
  SELECT * FROM pg_stat_activity WHERE state = 'active';
→ Tuer les queries bloquantes :
  SELECT pg_terminate_backend([pid]);

[Si Redis saturé]
→ Vérifier les clés volumineuses : redis-cli --bigkeys
→ Flush cache non critique : redis-cli FLUSHDB

[Si déploiement récent]
→ Rollback : ./scripts/rollback.sh [previous-version]

7.2.2 Runbook : Error Rate Élevé

Étapes de diagnostic :

1. Vérifier Sentry pour les nouvelles erreurs
   → Identifier le type d'erreur dominant
   → Vérifier la stack trace

2. Vérifier le dashboard "Error Distribution"
   → Quel service est impacté ?
   → Quelle route API ?

3. Vérifier les logs du service concerné
   → aws logs filter-log-events --log-group-name /rewapp/prod/[service]

4. Vérifier les dépendances externes
   → Status page Budget Insight, SendGrid, FCM

Actions de remédiation :

[Si erreur code récent]
→ Rollback immédiat vers version stable

[Si dépendance externe down]
→ Activer le circuit breaker si pas automatique
→ Communiquer aux utilisateurs si impact visible

[Si saturation ressources]
→ Voir runbook "API Latency Élevée"

7.2.3 Runbook : Database Connection Exhaustion

# 1. Vérifier le nombre de connexions actives
SELECT count(*) FROM pg_stat_activity;

# 2. Identifier les connexions idle
SELECT * FROM pg_stat_activity WHERE state = 'idle';

# 3. Vérifier PgBouncer
pgbouncer-cli show pools

# REMÉDIATION :

# 1. Tuer les connexions idle anciennes (> 5 min)
SELECT pg_terminate_backend(pid) FROM pg_stat_activity
WHERE state = 'idle' AND query_start < now() - interval '5 minutes';

# 2. Augmenter temporairement max_connections si nécessaire
# → Modification via Parameter Group RDS (nécessite reboot)

# 3. Scale-out les services pour répartir la charge

7.2.4 Runbook : QR Code System Failure

# DIAGNOSTIC :

# 1. Vérifier le service Points Service
aws logs filter-log-events --log-group-name /rewapp/prod/points-service

# 2. Vérifier Redis (stockage QR temporaire)
# → Connexion OK ? Mémoire disponible ?
# → TTL des clés QR respecté ?

# 3. Vérifier les métriques QR
# → qr_generation_latency, qr_validation_latency
# → qr_blocked_points_timeout (points non libérés)

# REMÉDIATION :

[Si Redis down]
→ Failover vers replica : aws elasticache failover-replica
→ Communiquer indisponibilité temporaire du paiement QR

[Si latence génération > 500ms]
→ Scale-out Points Service
→ Vérifier charge Redis

[Si replay attempts détectés]
→ ALERTE SÉCURITÉ : Potentielle fraude
→ Bloquer l'utilisateur concerné
→ Investigation forensique

[Si points bloqués non libérés]
→ Script de libération manuelle :
→ ./scripts/release-blocked-points.sh --force

7.2.5 Runbook : Security Incident

Étapes immédiates :

1. Ne pas paniquer - Suivre la procédure

2. Bloquer la source de l'attaque
   → IP : aws waf update-ip-set --ip-set-id [id] --addresses [IP]/32
   → Utilisateur : ./scripts/disable-user.sh [userId]

3. Préserver les preuves
   → Exporter les logs pertinents
   → Screenshot des dashboards

4. Escalader
   → Informer immédiatement : CTO, DPO, équipe sécurité

Communication :

• Interne uniquement dans un premier temps (canal privé)
• Évaluer l'obligation de notification CNIL (72h si données personnelles)
• Communication utilisateurs si nécessaire

Post-incident :

• Post-mortem obligatoire sous 48h
• Mise à jour des règles WAF si nécessaire
• Revue des accès et permissions

8.1 Maintenance Régulière

8.2 Évolutions Prévues

8.2.1 Court Terme (Q1 2026)

• Intégration Datadog pour APM avancé
• Alertes prédictives basées sur machine learning
• Dashboard mobile pour équipe de garde

8.2.2 Moyen Terme (2026)

• Automatisation des remédiations (self-healing)
• Chaos Engineering (tests de résilience automatisés)
• Observabilité end-to-end incluant partenaires bancaires

8.3 Indicateurs de Qualité du Monitoring

9.1 Récapitulatif

Le système de monitoring et alerting de REWAPP a été conçu pour garantir :

9.2 Points Clés à Retenir

• Stack CloudWatch + Prometheus + Grafana pour une observabilité complète
• 4 niveaux de sévérité (P1-P4) avec temps de réponse définis
• Escalade automatique via PagerDuty avec rotation d'astreinte 24/7
• Runbooks documentés pour les incidents les plus fréquents
• Maintenance régulière pour éviter l'alert fatigue et maintenir la pertinence

9.3 Documents Connexes

• 10.1 Plan de Déploiement
• 10.2 Documentation Technique Ops
• 10.4 Plan de Sauvegarde et Disaster Recovery
• 10.5 CI/CD Pipeline
• 13.2 Définition des KPIs Techniques
• 4.1 Architecture Technique Globale