TP Final : Monitors et SLO en Terraform avec correction

Ce que vous allez apprendre dans ce TP

• Configurer le fournisseur Terraform
• Écrire monitors et SLO
• Tester le déclenchement

Introduction #

Ce que vous allez apprendre dans cette section

• Configurer le fournisseur Terraform
• Écrire monitors et SLO
• Tester le déclenchement

Contexte. Les monitors créés à la main se multiplient sans relecture ni historique. Vous passez à une gestion as code.

Prérequis : TP 4 terminé, Terraform, clé d'application Datadog  ·  Durée estimée : 50 min

Une configuration Datadog relue et versionnée.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Configurer le fournisseur

   Pourquoi ? Les clés passent par l'environnement, jamais dans le code.

   Créez une clé d'application, exportez les variables et initialisez le projet.
   Voir la correction

   export DD_API_KEY=<cle_api> DD_APP_KEY=<cle_application>
   cat > main.tf <<'EOF'
   terraform {
     required_providers { datadog = { source = "DataDog/datadog" } }
   }
   provider "datadog" { api_url = "https://api.datadoghq.eu/" }
   EOF
   terraform init

2. 2. Monitor de latence APM

   Pourquoi ? Un monitor par service, sur une métrique de trace.

   Ajoutez un monitor sur la latence p95 de paiement-api.
   Voir la correction

   resource "datadog_monitor" "latence" {
     name    = "[lab] Latence p95 de paiement-api"
     type    = "query alert"
     query   = "percentile(last_5m):p95:trace.flask.request{service:paiement-api,env:lab} > 0.4"
     message = "{{#is_alert}}p95 à {{value}} s{{/is_alert}} @webhook-lab"
     monitor_thresholds { critical = 0.4 }
     tags = ["env:lab", "service:paiement-api", "managed-by:terraform"]
   }

   À savoir : Le nom de la métrique dépend de l'intégration (trace.flask.request pour Flask) : vérifiez-le dans le Metrics Explorer.

3. 3. Monitor de logs et SLO

   Pourquoi ? Les logs d'erreur et un objectif de disponibilité complètent le dispositif.

   Ajoutez un monitor de logs (plus de 20 erreurs en 5 min) et un SLO métrique à 95 % sur 7 jours.
   Voir la correction

   resource "datadog_monitor" "erreurs_logs" {
     name    = "[lab] Erreurs de paiement"
     type    = "log alert"
     query   = "logs(\"service:paiement-api status:error\").index(\"*\").rollup(\"count\").last(\"5m\") > 20"
     message = "{{value}} erreurs en 5 min @webhook-lab"
     monitor_thresholds { critical = 20 }
     tags = ["env:lab", "managed-by:terraform"]
   }
   
   resource "datadog_service_level_objective" "disponibilite" {
     name = "[lab] Disponibilité de paiement-api"
     type = "metric"
     query {
       numerator   = "sum:trace.flask.request.hits{service:paiement-api,env:lab}.as_count() - sum:trace.flask.request.errors{service:paiement-api,env:lab}.as_count()"
       denominator = "sum:trace.flask.request.hits{service:paiement-api,env:lab}.as_count()"
     }
     thresholds {
       timeframe = "7d"
       target    = 95
     }
     tags = ["env:lab", "managed-by:terraform"]
   }

4. 4. Appliquer

   Pourquoi ? Le plan montre exactement ce qui sera créé : c'est ce qu'on relit en pull request.

   Lancez terraform plan puis terraform apply, et retrouvez les objets dans l'interface.
   Voir la correction

   terraform plan && terraform apply -auto-approve

5. 5. Déclencher

   Pourquoi ? Valider la chaîne avant d'en dépendre.

   Générez 500 requêtes sur l'API et observez l'état des monitors et du SLO.
   Voir la correction

   for i in $(seq 500); do curl -s localhost:5000/payer >/dev/null; done

   Le monitor de logs passe en alerte (environ 50 erreurs) ; le SLO affiche environ 90 % pour une cible de 95 % : budget d'erreur épuisé. Modifier un seuil se fait désormais par une pull request sur main.tf.

Niveau de difficulté : ●●●○○ (3/5)