Monitors, SLO et Terraform

1. Les monitors #

Alerter dans Datadog.

Types #

{{#is_alert}}
CPU à {{value}} % sur {{host.name}} ({{env.name}}).
Runbook : https://wiki.example.org/cpu
@slack-alertes-plateforme @pagerduty-plateforme
{{/is_alert}}
{{#is_recovery}}Retour à la normale sur {{host.name}}.{{/is_recovery}}

Bonne Pratique : Les variables de modèle ({{host.name}}) et les blocs conditionnels permettent un seul monitor « multi-alert » par service au lieu d'un par hôte.

2. SLO et dashboards #

Piloter.

SLO #

Un SLO Datadog se définit à partir de monitors (temps de bon fonctionnement) ou de métriques (ratio bons / total), avec une cible et une fenêtre (7, 30 ou 90 jours). Des monitors de burn rate s'y rattachent (voir la formation SRE pour les concepts).

Dashboards et notebooks #

• Dashboards avec variables de modèle ($env, $service) pour un seul dashboard par type de service.
• Notebooks pour les enquêtes et post-mortem : graphes et texte au même endroit.
• Powerpacks pour réutiliser des groupes de widgets.

3. Datadog as code #

Terraform.

Exemple #

terraform {
  required_providers { datadog = { source = "DataDog/datadog" } }
}
provider "datadog" {
  api_url = "https://api.datadoghq.eu/"      # clés : variables DD_API_KEY et DD_APP_KEY
}

resource "datadog_monitor" "cpu" {
  name    = "CPU élevé sur {{host.name}}"
  type    = "metric alert"
  query   = "avg(last_5m):avg:system.cpu.user{env:prod} by {host} > 85"
  message = "{{#is_alert}}CPU à {{value}} % sur {{host.name}}{{/is_alert}} @slack-alertes-plateforme"
  monitor_thresholds {
    critical = 85
    warning  = 75
  }
  tags = ["env:prod", "team:plateforme", "managed-by:terraform"]
}

terraform init && terraform plan && terraform apply

À savoir : Les monitors et dashboards existants s'exportent en JSON depuis l'interface ; des outils comme terraformer génèrent le code Terraform correspondant pour reprendre l'existant.