04 — MONITORING, ALERTES & OBSERVABILITÉ

Objectif

À la fin de ce fichier :

Les 3 piliers de l'observabilité sont en place : métriques, logs, traces
Des dashboards montrent l'état de santé de chaque service en temps réel
Des alertes préviennent l'équipe avant que les utilisateurs ne s'en rendent compte
Un monitoring externe prouve la disponibilité au régulateur
Un runbook d'astreinte définit qui fait quoi quand ça casse

Pré-requis : fichier 03_gateway_cdn_securisation.md complété, infrastructure sécurisée.

PHASE 1 — GRAFANA CLOUD : MÉTRIQUES

Objectif

Collecter les métriques de performance de chaque service et de l'infrastructure (CPU, mémoire, latence, taux d'erreur, nombre de requêtes).

Instructions pour l'agent

1.1 Installer Grafana Agent dans le cluster

Grafana Agent est le collecteur léger qui envoie les métriques vers Grafana Cloud. Il remplace un Prometheus complet (pas besoin de stocker les métriques localement — Grafana Cloud s'en charge).

Installer via Helm dans le namespace nex-monitoring :

Chart : grafana/grafana-agent
Configuration : scrape les métriques Prometheus de tous les pods qui exposent un endpoint /metrics
Remote write : envoyer vers l'endpoint Prometheus de Grafana Cloud (URL + API key récupérés dans les pré-requis)
Scrape interval : 30 secondes

Métriques infrastructure à collecter :

kube-state-metrics : état des pods, deployments, nodes (installer le chart prometheus-community/kube-state-metrics)
Node exporter : CPU, mémoire, disque, réseau des nœuds (installer le chart prometheus-community/prometheus-node-exporter)
Ingress NGINX metrics : requêtes par seconde, latence, codes HTTP (déjà activé au fichier 01 phase 8.3)

Métriques applicatives :

NestJS n'expose pas de métriques Prometheus par défaut. L'équipe dev doit ajouter un package comme @willsoto/nestjs-prometheus ou prom-client dans chaque service pour exposer un endpoint /metrics.
Si l'équipe n'a pas encore intégré Prometheus dans les services, l'agent peut créer un ticket/issue pour ça. En attendant, les métriques infrastructure (CPU, mémoire, requêtes Ingress) suffisent pour commencer.

Recommandations :

Grafana Cloud Free inclut 10 000 séries métriques. Avec 11 services + les métriques infra, on est largement en dessous.
Ne pas scraper trop de métriques custom au début. Commencer par les métriques infra et les métriques Ingress (qui donnent déjà le taux d'erreur et la latence par service), puis ajouter les métriques applicatives progressivement.

Validation

bash

# Grafana Agent tourne
kubectl get pods -n nex-monitoring -l app.kubernetes.io/name=grafana-agent
# Attendu : Running

# Les métriques sont envoyées (vérifier dans Grafana Cloud → Explore → Prometheus)
# Requête : up{namespace="nex-staging"}
# Attendu : 11 séries (une par service) avec value=1

PHASE 2 — GRAFANA CLOUD : LOGS

Objectif

Centraliser les logs de tous les services dans un seul endroit, cherchable et filtrable.

Instructions pour l'agent

2.1 Installer Promtail

Promtail collecte les logs des pods et les envoie vers Grafana Loki (inclus dans Grafana Cloud).

Installer via Helm :

Chart : grafana/promtail
Namespace : nex-monitoring
Configuration : collecter les logs de tous les pods dans le namespace nex-staging
Push vers : endpoint Loki de Grafana Cloud
Labels : ajouter automatiquement namespace, pod, container, app (depuis les labels K8s) pour faciliter le filtrage

Format des logs :

Les services NestJS logguent en JSON par défaut. Promtail doit parser le JSON pour extraire les champs (level, message, timestamp, context).
Si les services ne logguent pas en JSON, l'équipe dev devrait les configurer pour le faire. Les logs texte brut sont difficiles à filtrer et analyser.

Recommandations :

Grafana Cloud Free inclut 50 Go de logs/mois. Pour 11 services en staging, c'est largement suffisant sauf si un service est très verbeux.
Configurer le log level sur debug en staging et info en production. Ça réduit le volume de logs en prod et le coût Grafana Cloud.
Ne pas logger de données sensibles (mots de passe, tokens, données personnelles clients). Vérifier avec l'équipe dev que les logs sont nettoyés.

Validation

bash

# Promtail tourne
kubectl get pods -n nex-monitoring -l app.kubernetes.io/name=promtail
# Attendu : un pod par nœud, tous Running

# Dans Grafana Cloud → Explore → Loki :
# Requête : {namespace="nex-staging", app="auth"}
# Attendu : les logs du service auth apparaissent

PHASE 3 — GRAFANA CLOUD : TRACES

Objectif

Suivre une requête de bout en bout à travers les microservices. Quand un utilisateur fait un transfert d'argent, la trace montre : Ingress → orchestrator → auth (vérification) → ledger-wallets (débit) → notifications (confirmation). Si ça ralentit, on voit exactement où.

Instructions pour l'agent

3.1 Installer Grafana Agent en mode traces

Le même Grafana Agent installé en phase 1 peut aussi collecter les traces. L'agent doit activer le mode OTLP (OpenTelemetry Protocol) dans la config du Grafana Agent :

Recevoir les traces sur le port 4317 (gRPC) et 4318 (HTTP)
Envoyer vers l'endpoint Tempo de Grafana Cloud

3.2 Instrumentation des services

Les services NestJS doivent envoyer des traces. L'équipe dev doit intégrer OpenTelemetry dans les services :

Package : @opentelemetry/auto-instrumentations-node (auto-instrumentation, pas besoin de modifier le code)
Configuration : exporter les traces vers le Grafana Agent (endpoint http://grafana-agent.nex-monitoring:4318)

Si l'équipe n'a pas encore intégré OpenTelemetry, créer un ticket. Les traces sont très utiles mais pas bloquantes pour le lancement. Les métriques et logs suffisent pour le monitoring initial.

Recommandation : l'auto-instrumentation OpenTelemetry est la méthode la plus rapide. Elle instrumente automatiquement HTTP, PostgreSQL, Redis, et les appels inter-services sans modifier le code applicatif. C'est un package NPM à ajouter et une variable d'environnement à configurer.

Validation

bash

# Dans Grafana Cloud → Explore → Tempo :
# Rechercher les traces du service orchestrator
# Attendu : des traces apparaissent avec les spans de chaque service appelé
# Si OpenTelemetry n'est pas encore intégré, les traces seront vides — c'est OK pour le lancement

PHASE 4 — SENTRY : ERREURS APPLICATIVES

Objectif

Capturer chaque erreur applicative avec son contexte complet (stack trace, user, device, breadcrumbs). Sentry est complémentaire de Grafana — Grafana montre les tendances, Sentry montre les bugs individuels.

Instructions pour l'agent

4.1 Configuration Sentry

Chaque microservice a son propre projet Sentry (créé dans les pré-requis). Le DSN de chaque projet est stocké dans Doppler.

L'équipe dev doit intégrer le SDK Sentry dans chaque service NestJS :

Package : @sentry/nestjs
Configuration : DSN depuis la variable d'environnement SENTRY_DSN, environment staging, release identifiée par le commit SHA

Si les devs n'ont pas encore intégré Sentry, l'agent doit créer un ticket avec les instructions d'intégration. C'est quelques lignes dans le main.ts de chaque service.

4.2 Configuration recommandée

Sample rate : 1.0 en staging (capturer 100% des erreurs), 0.5 en production (50% — pour limiter le volume)
Environment : staging ou production (selon l'env)
Release tracking : taguer chaque release avec le commit SHA pour pouvoir identifier quel deploy a introduit un bug
Source maps : uploader les source maps lors du build pour avoir des stack traces lisibles (le code est compilé par SWC)
PII : ne pas envoyer de données personnelles à Sentry (pas de noms, emails, numéros de téléphone dans les breadcrumbs)

4.3 Alertes Sentry

Configurer dans Sentry (Settings → Alerts) :

Alerte sur nouvelle erreur : quand une erreur jamais vue apparaît → notification Slack immédiate
Alerte sur régression : quand une erreur résolue réapparaît → notification Slack
Alerte sur volume : quand un service a plus de 50 erreurs en 1 heure → notification Slack + email (ça signifie un problème systémique, pas un bug isolé)

Validation

bash

# Vérifier que le DSN est configuré
kubectl exec -it deploy/auth -n nex-staging -- printenv SENTRY_DSN
# Attendu : https://xxxxx@sentry.io/xxxxx

# Provoquer une erreur volontaire (un endpoint qui throw)
# Vérifier dans le dashboard Sentry que l'erreur apparaît avec le contexte

PHASE 5 — UPTIMEROBOT : MONITORING EXTERNE

Objectif

Surveiller la disponibilité de l'API depuis l'extérieur, indépendamment de toute l'infrastructure. Si AWS, Cloudflare ET ton monitoring Grafana tombent en même temps, UptimeRobot (hébergé ailleurs) te prévient quand même. C'est aussi la preuve de disponibilité pour le régulateur.

Instructions pour l'agent

5.1 Moniteurs à créer

Configurer dans UptimeRobot (dashboard web ou API) :

Moniteur	URL	Intervalle	Alerte si	Status
NxPay Staging - Auth	`https://staging.paywithnex.com/auth/health`	5 min	Pas de réponse 200 contenant "ok"	✅ Créé
NxPay Staging - Configuration	`https://staging.paywithnex.com/configuration/health`	5 min	Pas de réponse 200 contenant "ok"	✅ Créé
NxPay Staging - Orchestrator (API)	`https://staging.paywithnex.com/api/health`	5 min	Pas de réponse 200 contenant "ok"	✅ Créé
CMMS Dashboard	`https://admin.paywithnex.com`	5 min	Pas de réponse 200 pendant 5 min	⏳ Quand déployé
Backoffice	`https://bo.paywithnex.com`	5 min	Pas de réponse 200 pendant 5 min	⏳ Quand déployé

Note : UptimeRobot Free = intervalle minimum 5 min. Le plan Pro ($7/mois) permet 1 min.

5.2 Alertes UptimeRobot

Notification email à l'équipe DevOps
Notification Slack dans un channel #alerts-infra
En production : ajouter une notification SMS au responsable d'astreinte

5.3 Status Page (optionnel mais recommandé)

UptimeRobot Pro permet de créer une status page publique (ex: status.paywithnex.com). C'est utile pour :

Les utilisateurs : ils voient si le service est en panne avant de contacter le support
Le régulateur : preuve de transparence sur la disponibilité
L'équipe : un lien unique pour vérifier l'état de tous les services

Validation

bash

# Vérifier dans UptimeRobot que tous les moniteurs sont verts
# Tester en coupant temporairement un service
kubectl scale deploy/auth -n nex-staging --replicas=0
# Attendu : UptimeRobot déclenche une alerte en < 3 minutes
# Remettre le service
kubectl scale deploy/auth -n nex-staging --replicas=2

PHASE 6 — DASHBOARDS GRAFANA

Objectif

Des dashboards visuels qui montrent l'état de santé du système en un coup d'œil.

Instructions pour l'agent

6.1 Dashboard "Vue d'ensemble Nex"

Un dashboard principal avec :

Ligne 1 — Indicateurs clés (stat panels) :

Nombre total de requêtes/min (depuis les métriques Ingress NGINX)
Taux d'erreur global (% de réponses 5xx)
Latence P95 (95e percentile du temps de réponse)
Nombre de pods healthy / total

Ligne 2 — Requêtes par service (graphe empilé) :

Requêtes/seconde pour chaque service public (auth, configuration, orchestrator)
Coloré par code HTTP (2xx en vert, 4xx en jaune, 5xx en rouge)

Ligne 3 — Ressources infrastructure (gauges) :

CPU utilisé / CPU total (tous les nœuds)
Mémoire utilisée / mémoire totale
Nombre de pods / quota max

Ligne 4 — Base de données (graphe) :

Connexions actives PostgreSQL
Latence des requêtes DB (si métriques dispo)
CPU RDS

6.2 Dashboard "Détail par service"

Un dashboard avec un dropdown pour sélectionner le service. Montre :

Requêtes/sec pour ce service
Latence (P50, P95, P99)
Taux d'erreur
CPU et mémoire du pod
Nombre de restarts (un restart fréquent indique un crash loop)
Logs récents (panel Loki intégré)

6.3 Dashboard "Business" (pour le régulateur)

Un dashboard de haut niveau, non technique :

Uptime du mois (%) — donnée UptimeRobot ou calculée depuis les métriques
Nombre de transactions du jour
Temps de réponse moyen
Incidents du mois (nombre et durée)

Recommandations :

Grafana Cloud offre des dashboards pré-faits pour Kubernetes, NGINX, PostgreSQL et Redis. Importer ces dashboards (via leur ID dans grafana.com/dashboards) comme base et les personnaliser.
Dashboards K8s standard à importer : ID 15760 (Kubernetes cluster), ID 14623 (NGINX Ingress), ID 9628 (PostgreSQL).
Ne pas créer 20 dashboards dès le début. Commencer avec la vue d'ensemble et le détail par service. Ajouter des dashboards spécialisés quand le besoin se fait sentir.

Validation

bash

# Vérifier dans Grafana Cloud que les dashboards sont créés et affichent des données
# Les graphes doivent montrer du trafic réel (même minime en staging)

PHASE 7 — RÈGLES D'ALERTE

Objectif

Être prévenu automatiquement quand quelque chose va mal, AVANT que les utilisateurs ne s'en rendent compte.

Instructions pour l'agent

Configurer les alertes dans Grafana Cloud (Alerting → Alert Rules) :

7.1 Alertes critiques (notification immédiate : Slack + email)

Alerte	Condition	Gravité
Service down	Un service a 0 pods Ready pendant > 2 min	Critique
Taux d'erreur élevé	Plus de 5% de réponses 5xx sur 5 minutes	Critique
Base de données down	Connexion PostgreSQL impossible pendant > 1 min	Critique
Redis down	Connexion Redis impossible pendant > 1 min	Critique
Nœud K8s down	Un nœud passe en status NotReady pendant > 5 min	Critique
Certificat TLS expirant	Certificat expire dans moins de 7 jours	Critique

7.2 Alertes warning (notification Slack uniquement)

Alerte	Condition	Gravité
CPU élevé	CPU d'un pod > 80% pendant > 10 min	Warning
Mémoire élevée	Mémoire d'un pod > 80% pendant > 10 min	Warning
Latence élevée	P95 latence > 2 secondes pendant > 5 min	Warning
Pod restart	Un pod a redémarré plus de 3 fois en 30 min	Warning
Disque nœud	Utilisation disque d'un nœud > 80%	Warning
RDS stockage	Stockage RDS > 80% de la capacité	Warning
Erreurs 4xx élevées	Plus de 20% de réponses 4xx sur 10 minutes	Warning

7.3 Alertes business (notification Slack channel #business)

Alerte	Condition	Note
Aucune transaction	Zéro transaction pendant 30 min en heures ouvrées	Peut indiquer un problème invisible
Échecs de transaction élevés	Plus de 10% de transactions échouées sur 1 heure	Problème potentiel sur ledger-wallets
KYC timeout	Vérification KYC prend plus de 5 minutes	Problème providers-gateway

Note : les alertes business nécessitent des métriques applicatives custom (compteur de transactions, durée KYC). Si ces métriques n'existent pas encore, créer les tickets pour l'équipe dev et les ajouter progressivement.

7.4 Contact Points

Configurer dans Grafana Cloud (Alerting → Contact Points) :

Slack #alerts-critical : alertes critiques
Slack #alerts-warning : alertes warning
Slack #alerts-business : alertes business
Email DevOps : alertes critiques (backup si Slack est down)

Recommandation : ne pas spammer le channel Slack avec trop d'alertes warning au début. Commencer avec les alertes critiques uniquement, puis affiner les seuils des warnings pour qu'ils soient pertinents (pas de fausse alerte = on les prend toujours au sérieux).

Validation

bash

# Tester une alerte en crashant volontairement un service
kubectl scale deploy/configuration -n nex-staging --replicas=0
# Attendu : alerte "Service down" dans Slack en < 3 min
kubectl scale deploy/configuration -n nex-staging --replicas=1
# Attendu : alerte "Resolved" dans Slack

PHASE 8 — RUNBOOK D'ASTREINTE

Objectif

Documenter les procédures de réaction pour chaque type d'incident. Quand ça casse à 3h du matin, la personne d'astreinte ouvre le runbook et suit les étapes.

Instructions pour l'agent

Créer le fichier docs/runbook-astreinte.md dans le repo infrastructure avec les procédures suivantes :

8.1 Structure du runbook

Pour chaque type d'incident :

Symptôme : ce que l'alerte dit
Impact : ce que ça signifie pour les utilisateurs
Diagnostic : les commandes à exécuter pour comprendre le problème
Résolution : les actions à prendre
Escalade : qui appeler si la résolution ne fonctionne pas

8.2 Incidents à documenter

Service down (pod crashé) :

Diagnostic : kubectl describe pod <pod> -n nex-staging + kubectl logs <pod> -n nex-staging --previous
Résolution : si OOMKilled → augmenter la mémoire limits. Si erreur applicative → rollback vers la version précédente avec kubectl rollout undo. Si problème de dépendance (DB down) → traiter la dépendance d'abord.

Base de données inaccessible :

Diagnostic : vérifier le status RDS dans la console AWS, vérifier le Security Group, tester la connexion depuis un pod
Résolution : si maintenance AWS → attendre. Si failover en cours → attendre (automatique, 60-120s). Si SG modifié par erreur → restaurer via Terraform.

Redis inaccessible :

Diagnostic : même approche que la DB
Impact spécifique : auth ne peut plus créer de sessions, les utilisateurs ne peuvent plus se connecter. service-catalog perd son cache (continue à fonctionner mais plus lentement).

Latence élevée :

Diagnostic : vérifier les dashboards Grafana pour identifier quel service est lent. Vérifier les connexions DB (trop de connexions ?). Vérifier les logs pour des requêtes SQL lentes.
Résolution : si un service est surchargé → vérifier le HPA, éventuellement scaler manuellement. Si la DB est lente → identifier la requête lente via pg_stat_statements.

Taux d'erreur élevé :

Diagnostic : filtrer les logs par erreur 5xx dans Grafana Loki, vérifier Sentry pour les erreurs récentes.
Résolution : si c'est un bug applicatif → rollback. Si c'est une dépendance externe (Auth0, Firebase) → vérifier leur status page.

Certificat TLS expirant :

Diagnostic : kubectl get certificates -n nex-staging
Résolution : cert-manager renouvelle automatiquement. Si le renouvellement échoue, vérifier les logs de cert-manager et le ClusterIssuer.

Nœud K8s down :

Diagnostic : kubectl get nodes, kubectl describe node <node>
Résolution : EKS remplace automatiquement les nœuds défaillants dans un node group managé. Vérifier que l'autoscaler compense. Si tous les nœuds sont down → problème AWS régional, consulter le status AWS.

8.3 Contacts d'escalade

Niveau	Qui	Quand	Comment
L1	DevOps d'astreinte	Première alerte	Slack + runbook
L2	Lead dev	Si L1 ne résout pas en 30 min	Appel téléphonique
L3	CTO / Direction	Si le service est down > 1h ou incident données	Appel téléphonique
AWS Support	AWS	Problème infrastructure AWS	Ticket support (Business support recommandé en prod)

Recommandations

Le runbook est un document vivant. Après chaque incident, ajouter une section "post-mortem" avec ce qui s'est passé, comment ça a été résolu, et comment éviter que ça se reproduise.
Garder les procédures simples et concrètes. Pas de texte théorique — des commandes à copier-coller.
En staging, il n'y a pas besoin d'astreinte 24/7. Le runbook est quand même utile pour la production en semaine 2.

PHASE 9 — BACKUPS & VÉRIFICATION

Objectif

S'assurer que les backups fonctionnent et qu'on peut réellement restaurer en cas de besoin. Un backup non testé n'est pas un backup.

Instructions pour l'agent

9.1 Backups automatiques RDS

Déjà configurés au fichier 01 (rétention 30 jours, fenêtre 03:00-04:00 UTC). Vérifier qu'ils s'exécutent :

bash

aws rds describe-db-snapshots --db-instance-identifier nex-staging-postgres \
  --query "DBSnapshots[-3:].{ID:DBSnapshotIdentifier,Date:SnapshotCreateTime,Status:Status}"

9.2 Script de backup manuel

L'agent doit créer scripts/backup-manual.sh qui :

Crée un snapshot RDS manuel avec un nom daté (nex-staging-manual-YYYY-MM-DD)
Attend que le snapshot soit complet
Copie le snapshot vers la région eu-west-3 (backup cross-région)
Confirme le succès

Ce script est utilisé avant chaque opération risquée (migration, changement de schéma, mise en production).

9.3 Test de restauration

L'agent doit créer scripts/test-restore.sh qui :

Restaure le dernier snapshot RDS dans une instance temporaire (nex-staging-restore-test)
Se connecte et vérifie que les données sont présentes
Détruit l'instance temporaire

Ce test doit être exécuté manuellement une fois maintenant pour valider la procédure, puis trimestriellement en production. Documenter la date du test et le résultat (le régulateur demandera).

Recommandation : la restauration RDS crée une nouvelle instance à partir du snapshot. L'instance restaurée n'aura pas le même endpoint — il faut mettre à jour Doppler si on bascule dessus. En cas de disaster recovery réel, le runbook doit documenter cette étape.

Validation

bash

# Dernier backup automatique existe et est récent (< 24h)
aws rds describe-db-snapshots --db-instance-identifier nex-staging-postgres \
  --query "DBSnapshots[-1].SnapshotCreateTime"
# Attendu : date d'aujourd'hui ou hier

# Test de restauration réussi (exécuter le script)
bash scripts/test-restore.sh
# Attendu : instance restaurée, données vérifiées, instance détruite

CHECKLIST GLOBALE — FIN DU FICHIER 04

Métriques (Grafana + Prometheus)

[ ] Grafana Agent installé et en Running
[ ] kube-state-metrics installé
[ ] Node exporter installé
[ ] Métriques Ingress NGINX collectées
[ ] Données visibles dans Grafana Cloud Explore

Logs (Grafana + Loki)

[ ] Promtail installé (un pod par nœud)
[ ] Logs des 11 services visibles dans Grafana Loki
[ ] Logs structurés en JSON (ou ticket créé pour l'équipe dev)
[ ] Pas de données sensibles dans les logs

Traces (Grafana + Tempo)

[ ] Grafana Agent en mode OTLP configuré
[ ] OpenTelemetry intégré dans les services (ou ticket créé)

Sentry

[ ] DSN configuré dans Doppler pour chaque service
[ ] SDK Sentry intégré (ou ticket créé)
[ ] Alertes Sentry configurées (nouvelle erreur, régression, volume)

UptimeRobot

[x] 3 moniteurs API créés (Auth, Configuration, Orchestrator) — UptimeRobot, 5 min, keyword "ok"
[ ] 2 moniteurs dashboards à créer quand déployés (CMMS, Backoffice)
[ ] Alertes Slack configurées (channel #alerts-infra)
[ ] Status page créée (optionnel)

Dashboards

[ ] Dashboard "Vue d'ensemble Nex" créé
[ ] Dashboard "Détail par service" créé
[ ] Dashboards pré-faits importés (K8s, NGINX, PostgreSQL)

Alertes

[ ] Alertes critiques configurées (service down, DB down, erreurs 5xx)
[ ] Alertes warning configurées (CPU, mémoire, latence, restarts)
[ ] Contact points Slack + email configurés
[ ] Test d'alerte réussi (scale down + alerte reçue + scale up + resolved)

Runbook & Backups

[ ] Runbook d'astreinte documenté (docs/runbook-astreinte.md)
[ ] Procédures pour les 7 types d'incidents principaux
[ ] Contacts d'escalade définis
[ ] Backups RDS automatiques vérifiés
[ ] Script de backup manuel créé et testé
[ ] Test de restauration exécuté et documenté (date + résultat)

Tous les points verts → l'environnement staging est complet, monitoré et opérationnel.

ET MAINTENANT ?

Semaine 2 — Production

Le staging est complet. La promotion en production consiste à :

Dupliquer l'infrastructure : terraform/environments/production/ avec les paramètres prod (Multi-AZ RDS, 2 NAT Gateways, plus de replicas, instances plus grandes).
Créer le cluster EKS production : nex-production avec les mêmes manifests K8s via l'overlay production/.
Configurer les DNS production : api.paywithnex.com dans Cloudflare.
Configurer Doppler production : nouveaux secrets avec des mots de passe différents.
Ajouter le stage deploy-production dans les pipelines GitLab CI : déploiement manuel (1 clic avec confirmation).
Renforcer la sécurité : WAF OWASP en mode block, Security Groups plus stricts, endpoint EKS privé.
Test de charge : simuler 10 000 transactions/jour avec k6 ou Artillery.
Pentest : test d'intrusion par un prestataire externe (requis par le régulateur).

Le fichier 05_deploy_mobile_stores.md (apps React Native) peut être exécuté en parallèle.

Prochaine étape : 05_deploy_mobile_stores.md — Build React Native, Fastlane, publication App Store & Play Store.

04 — MONITORING, ALERTES & OBSERVABILITÉ ​

Objectif ​

PHASE 1 — GRAFANA CLOUD : MÉTRIQUES ​

Objectif ​

Instructions pour l'agent ​

1.1 Installer Grafana Agent dans le cluster ​

Validation ​

PHASE 2 — GRAFANA CLOUD : LOGS ​

Objectif ​

Instructions pour l'agent ​

2.1 Installer Promtail ​

Validation ​

PHASE 3 — GRAFANA CLOUD : TRACES ​

Objectif ​

Instructions pour l'agent ​

3.1 Installer Grafana Agent en mode traces ​

3.2 Instrumentation des services ​

Validation ​

PHASE 4 — SENTRY : ERREURS APPLICATIVES ​

Objectif ​

Instructions pour l'agent ​

4.1 Configuration Sentry ​

4.2 Configuration recommandée ​

4.3 Alertes Sentry ​

Validation ​

PHASE 5 — UPTIMEROBOT : MONITORING EXTERNE ​

Objectif ​

Instructions pour l'agent ​

5.1 Moniteurs à créer ​

5.2 Alertes UptimeRobot ​

5.3 Status Page (optionnel mais recommandé) ​

Validation ​

PHASE 6 — DASHBOARDS GRAFANA ​

Objectif ​

Instructions pour l'agent ​

6.1 Dashboard "Vue d'ensemble Nex" ​

6.2 Dashboard "Détail par service" ​

6.3 Dashboard "Business" (pour le régulateur) ​

Validation ​

PHASE 7 — RÈGLES D'ALERTE ​

Objectif ​

Instructions pour l'agent ​

7.1 Alertes critiques (notification immédiate : Slack + email) ​

7.2 Alertes warning (notification Slack uniquement) ​

7.3 Alertes business (notification Slack channel #business) ​

7.4 Contact Points ​

Validation ​

PHASE 8 — RUNBOOK D'ASTREINTE ​

Objectif ​

Instructions pour l'agent ​

8.1 Structure du runbook ​

8.2 Incidents à documenter ​

8.3 Contacts d'escalade ​

Recommandations ​

PHASE 9 — BACKUPS & VÉRIFICATION ​

Objectif ​

Instructions pour l'agent ​

9.1 Backups automatiques RDS ​

9.2 Script de backup manuel ​

9.3 Test de restauration ​

Validation ​

CHECKLIST GLOBALE — FIN DU FICHIER 04 ​

Métriques (Grafana + Prometheus) ​

Logs (Grafana + Loki) ​

Traces (Grafana + Tempo) ​

Sentry ​

UptimeRobot ​

Dashboards ​

Alertes ​

Runbook & Backups ​

ET MAINTENANT ? ​

Semaine 2 — Production ​

04 — MONITORING, ALERTES & OBSERVABILITÉ

Objectif

PHASE 1 — GRAFANA CLOUD : MÉTRIQUES

Objectif

Instructions pour l'agent

1.1 Installer Grafana Agent dans le cluster

Validation

PHASE 2 — GRAFANA CLOUD : LOGS

Objectif

Instructions pour l'agent

2.1 Installer Promtail

Validation

PHASE 3 — GRAFANA CLOUD : TRACES

Objectif

Instructions pour l'agent

3.1 Installer Grafana Agent en mode traces

3.2 Instrumentation des services

Validation

PHASE 4 — SENTRY : ERREURS APPLICATIVES

Objectif

Instructions pour l'agent

4.1 Configuration Sentry

4.2 Configuration recommandée

4.3 Alertes Sentry

Validation

PHASE 5 — UPTIMEROBOT : MONITORING EXTERNE

Objectif

Instructions pour l'agent

5.1 Moniteurs à créer

5.2 Alertes UptimeRobot

5.3 Status Page (optionnel mais recommandé)

Validation

PHASE 6 — DASHBOARDS GRAFANA

Objectif

Instructions pour l'agent

6.1 Dashboard "Vue d'ensemble Nex"

6.2 Dashboard "Détail par service"

6.3 Dashboard "Business" (pour le régulateur)

Validation

PHASE 7 — RÈGLES D'ALERTE

Objectif

Instructions pour l'agent

7.1 Alertes critiques (notification immédiate : Slack + email)

7.2 Alertes warning (notification Slack uniquement)

7.3 Alertes business (notification Slack channel #business)

7.4 Contact Points

Validation

PHASE 8 — RUNBOOK D'ASTREINTE

Objectif

Instructions pour l'agent

8.1 Structure du runbook

8.2 Incidents à documenter

8.3 Contacts d'escalade

Recommandations

PHASE 9 — BACKUPS & VÉRIFICATION

Objectif

Instructions pour l'agent

9.1 Backups automatiques RDS

9.2 Script de backup manuel

9.3 Test de restauration

Validation

CHECKLIST GLOBALE — FIN DU FICHIER 04

Métriques (Grafana + Prometheus)

Logs (Grafana + Loki)

Traces (Grafana + Tempo)

Sentry

UptimeRobot

Dashboards

Alertes

Runbook & Backups

ET MAINTENANT ?

Semaine 2 — Production