Datadog - Alerting, SLOs, Synthetics et PagerDuty

Pourquoi la plupart des équipes ratent leur alerting

L’alerting est le système nerveux de ton infrastructure. Bien configuré, il détecte les problèmes avant tes utilisateurs et réveille la bonne personne au bon moment. Mal configuré, c’est un flux de bruit que tout le monde ignore — jusqu’au jour où une vraie panne passe inaperçue.

Le piège numéro un s’appelle l’alert fatigue. Quand une équipe reçoit 50 alertes par jour, plus personne ne les lit. La règle d’or : chaque alerte doit être actionnable. Si personne ne peut ou ne doit agir quand elle se déclenche, c’est une information de dashboard, pas une alerte.

L’autre erreur classique est d’alerter sur les causes plutôt que les symptômes. “CPU à 80%” ne dit rien sur l’impact utilisateur — peut-être que c’est normal pendant un batch nocturne. “Taux d’erreur API > 5%” est un symptôme qui affecte directement tes utilisateurs et qui nécessite une action immédiate.

🧠 À retenir — Alerte sur les symptômes (latence, erreurs, indisponibilité), investigue les causes (CPU, mémoire, disque) via les dashboards. Les seuils d’alerte doivent être pilotés par tes SLOs, pas par des chiffres arbitraires.

Les types de monitors Datadog

Datadog propose plusieurs types de monitors, chacun adapté à un besoin spécifique. Le Metric Monitor est le plus courant : il surveille une métrique et alerte quand elle dépasse un seuil. L’Anomaly Monitor détecte les comportements anormaux par rapport à l’historique — pas besoin de seuil fixe, Datadog apprend le pattern normal (idéal pour le trafic web avec ses cycles jour/nuit). Le Composite Monitor combine plusieurs monitors avec de la logique booléenne pour réduire les faux positifs. Le Forecast Monitor prédit quand une métrique atteindra un seuil — parfait pour anticiper un disque plein.

La distinction clé : multi-alert vs simple alert. En simple alert, tu surveilles la moyenne globale. En multi-alert (by {host}), chaque groupe a son propre état — tu sais exactement quel host ou quel service a un problème :

# Simple alert — moyenne de tous les hosts
avg:system.cpu.user{env:prod} > 90

# Multi-alert — un statut par host (presque toujours préférable)
avg:system.cpu.user{env:prod} by {host} > 90

Un bon message de notification contient tout ce qu’il faut pour agir sans chercher. Les template variables de Datadog ({{host.name}}, {{value}}, {{threshold}}) rendent le message dynamique et contextuel :

## {{#is_alert}}🔴 ALERT{{/is_alert}}{{#is_warning}}🟡 WARNING{{/is_warning}} CPU élevé sur {{host.name}}

**Valeur actuelle :** {{value}}% | **Seuil :** {{threshold}}%

### Actions immédiates
1. Vérifier les processus : `ssh {{host.name}} 'top -bn1 | head -20'`
2. Chercher un déploiement récent : [Dashboard Deploys](https://app.datadoghq.eu/dashboard/xxx)
3. Runbook : [CPU High](https://wiki.internal/runbooks/cpu-high)

{{#is_alert}}@pagerduty-backend-oncall{{/is_alert}}
{{#is_warning}}@slack-backend-alerts{{/is_warning}}
{{#is_recovery}}✅ Résolu : CPU revenu à {{value}}%{{/is_recovery}}

💡 Tip DevOps — Utilise les blocs conditionnels {{#is_alert}} et {{#is_warning}} pour router les notifications : warning → Slack (informatif), alert → PagerDuty (action requise). Ça évite de réveiller l’on-call pour un simple warning.

SLOs : formaliser tes objectifs de fiabilité

Les SLOs (Service Level Objectives) transforment le vague “l’API doit être rapide” en mesurable “99.9% des requêtes répondent en moins de 500ms sur 30 jours glissants”. C’est la fondation de l’ingénierie de fiabilité (SRE).

Trois concepts s’emboîtent. Le SLI (Service Level Indicator) est la métrique mesurée — par exemple le ratio requêtes réussies / requêtes totales. Le SLO est l’objectif — 99.9%. L’Error Budget est ton droit à l’erreur : avec un SLO de 99.9% sur 30 jours, tu as environ 43 minutes de downtime autorisées par mois.

L’error budget est un outil de décision puissant. Budget confortable ? L’équipe peut déployer des features risquées. Budget presque épuisé ? On gèle les déploiements et on se concentre sur la fiabilité. C’est le contrat objectif entre vélocité et stabilité.

Pour créer un SLO metric-based dans Datadog, tu définis les “good events” et les “total events” :

Type: Metric-based
Good events:  sum:myapp.requests{env:prod,status:2xx}.as_count()
Total events: sum:myapp.requests{env:prod}.as_count()
Target: 99.9% sur 30 jours
Warning: 99.95%

Configure une alerte sur la consommation de l’error budget pour être prévenu avant qu’il ne soit épuisé :

Alerte si: Error budget consumed > 80% sur la fenêtre de 30 jours
Warning si: Error budget consumed > 50%
→ Notify: @slack-sre-channel

🔥 Cas réel — Google a popularisé les SLOs avec son livre “Site Reliability Engineering”. L’idée clé : si ton SLO est à 99.99% mais que tes utilisateurs passent par un réseau mobile à 99% de fiabilité, tu surinvestis. Le SLO doit refléter ce que les utilisateurs perçoivent réellement.

Synthetics : tester avant que les utilisateurs ne découvrent

Les tests Synthetics simulent des utilisateurs réels depuis des emplacements géographiques variés. Ils détectent les problèmes — endpoint down, certificat SSL expirant, parcours utilisateur cassé — avant que tes vrais utilisateurs ne soient impactés.

Les API Tests vérifient tes endpoints HTTP à intervalle régulier, avec des assertions sur le status code, le temps de réponse et le contenu du body :

# API Test — vérification de l'endpoint de santé
Test: API Health Check
URL: GET https://api.monapp.com/health
Fréquence: toutes les minutes
Locations: Paris, Frankfurt, London

Assertions:
  - Status code = 200
  - Response time < 500ms
  - Body contains "status": "ok"
  - Header content-type is application/json

Alerte si: échec depuis 2+ locations
→ @slack-backend-alerts @pagerduty-backend-oncall

Les SSL Tests surveillent l’expiration de tes certificats — une cause fréquente d’incidents évitables :

# SSL Test — anticiper l'expiration
Host: api.monapp.com:443
Fréquence: toutes les heures
Assertions:
  - Certificate is valid
  - Expires in more than 30 days
  - TLS version >= 1.2

Les Multistep API Tests enchaînent plusieurs requêtes avec extraction de variables — idéal pour valider un workflow complet (login → création de commande → vérification) :

# Multistep — workflow de commande E2E
Step 1 - Login:
  POST /auth/login → Extract: token from $.access_token

Step 2 - Create Order:
  POST /orders (Bearer {{token}}) → Assert: 201
  Extract: order_id from $.id

Step 3 - Verify:
  GET /orders/{{order_id}} → Assert: $.status = "pending"

Les Browser Tests lancent un vrai Chrome headless et simulent des clics, saisies et navigations. Tu peux les enregistrer via l’extension Datadog ou les coder manuellement.

⚠️ Attention — Pour tester des services internes (non exposés sur Internet), déploie un Private Location via Docker dans ton réseau. Sans ça, les tests Synthetics ne peuvent atteindre que les endpoints publics.

Intégration PagerDuty et escalade d’incidents

PagerDuty est le standard pour l’on-call et l’escalade. L’intégration avec Datadog envoie automatiquement les alertes critiques vers le bon service PagerDuty, avec le message complet, les graphiques snapshot et un lien direct vers le monitor.

La logique de notification recommandée :

# Dans le message du monitor :
{{#is_warning}}@slack-backend-alerts{{/is_warning}}     → Slack uniquement
{{#is_alert}}@pagerduty-backend-oncall{{/is_alert}}      → PagerDuty (page)
{{#is_recovery}}@slack-backend-alerts ✅ Résolu{{/is_recovery}} → Confirmation

L’escalade progressive chez PagerDuty garantit qu’un incident non acquitté remonte automatiquement :

Niveau 1 (immédiat)  : On-call engineer → 5 min pour acknowledge
Niveau 2 (+5 min)    : Team lead → 10 min pour acknowledge
Niveau 3 (+15 min)   : Engineering manager → bridge call

💡 Tip DevOps — Planifie des maintenance windows avant chaque déploiement pour éviter les alertes parasites. Via l’API Datadog, tu peux scripter la création de downtime dans ton pipeline CI/CD, juste avant le deploy.

Monitors as Code avec Terraform

Comme pour les dashboards, les monitors doivent être versionnés et reproductibles. Terraform permet de gérer toute la config d’alerting en code — monitors, SLOs, downtimes — avec review en PR et historique Git.

resource "datadog_monitor" "error_rate_high" {
  name    = "[API] Taux d'erreur élevé - {{service.name}}"
  type    = "query alert"
  message = <<-EOT
    ## 🔴 Taux d'erreur API : {{value}}%

    Plus de {{threshold}}% des requêtes retournent une erreur.

    1. [Error Logs](https://app.datadoghq.eu/logs?query=status:error+service:api)
    2. [APM Traces](https://app.datadoghq.eu/apm/errors?service=api)
    3. Runbook : https://wiki.internal/runbooks/error-rate

    {{#is_alert}}@pagerduty-backend-oncall{{/is_alert}}
    @slack-backend-alerts
  EOT

  query = "sum(last_5m):sum:myapp.errors{env:prod}.as_count() / sum:myapp.requests{env:prod}.as_count() * 100 > 5"

  monitor_thresholds {
    critical = 5
    warning  = 2
  }

  notify_no_data    = true
  no_data_timeframe = 10
  renotify_interval = 30
  tags = ["env:prod", "team:backend", "severity:critical"]
}

resource "datadog_service_level_objective" "api_availability" {
  name        = "API Availability 99.9%"
  type        = "metric"
  description = "99.9% des requêtes API doivent réussir sur 30 jours"

  query {
    numerator   = "sum:myapp.requests{env:prod,status:2xx}.as_count()"
    denominator = "sum:myapp.requests{env:prod}.as_count()"
  }

  thresholds {
    timeframe = "30d"
    target    = 99.9
    warning   = 99.95
  }
  tags = ["env:prod", "service:api"]
}

🔥 Cas réel — Une équipe SRE de 50 microservices gérait 200+ monitors à la main dans l’UI Datadog. Après migration vers Terraform, les monitors sont devenus des PR reviewables, les erreurs de config ont chuté de 80%, et le onboarding d’un nouveau service prend 5 minutes au lieu d’une heure.

Bonnes pratiques et pièges à éviter

Hygiène d’alerting :

• Fais une revue mensuelle de tous tes monitors : combien se sont déclenchés ? Combien ont été ignorés ? Les ignorés doivent être supprimés ou ajustés
• Classifie par sévérité : Info (dashboard only) → Warning (Slack) → Critical (PagerDuty) → Emergency (PagerDuty + appel)
• Utilise les Composite Monitors pour éviter les faux positifs pendant les déploiements (Error_Rate_High AND NOT Deploy_In_Progress)

SLOs :

• Définis les SLOs avec le métier, pas seul — un SLO trop ambitieux gaspille des ressources, trop lâche ne protège pas les utilisateurs
• Commence par un SLO conservateur (99.5%) et resserre progressivement
• Affiche l’error budget dans le dashboard de l’équipe — la visibilité change les comportements

Synthetics :

• Teste les parcours critiques business, pas juste /health
• Utilise les Private Locations pour les services internes
• Les SSL Tests évitent des incidents embarrassants — un certificat expiré est toujours une faute d’inattention

⚠️ Attention — L’evaluation delay est indispensable pour les métriques cloud (CloudWatch, GCP Monitoring) qui arrivent avec 5 à 10 minutes de retard. Sans délai, tu auras des faux positifs systématiques sur les monitors basés sur ces métriques.

🧠 À retenir — L’alerting est un système vivant qui nécessite un entretien régulier. Chaque alerte doit être actionnable, chaque SLO doit refléter l’expérience utilisateur réelle, et chaque test Synthetics doit couvrir un parcours critique. La clé : commence simple avec quelques monitors bien calibrés, puis itère. Mieux vaut 10 alertes pertinentes que 100 ignorées.