Configurer des alertes de qualité des données avec Elementary

Un dashboard qui affiche les échecs de la veille, c’est utile. Une alerte qui vous prévient d’un problème avant que vos parties prenantes ne le remarquent, c’est mieux. Les équipes data proactives détectent les problèmes en amont parce que leur système d’alertes surveille en permanence à leur place.

Elementary peut envoyer des alertes vers Slack, Microsoft Teams, PagerDuty et d’autres outils de gestion d’incidents. Cet article explique comment configurer chaque canal, router les alertes vers les bonnes personnes et maintenir un ratio signal/bruit acceptable.

Prérequis

Ce guide suppose qu’Elementary est installé et opérationnel. Votre table elementary_test_results doit contenir les résultats d’exécution de vos tests de qualité des données. Si vous partez de zéro, consultez d’abord le guide d’installation d’Elementary.

Vérification rapide :

# Vérifier que vous avez des résultats de tests sur lesquels alerter
edr report --select last_invocation

Si vous voyez des résultats de tests dans le rapport généré, vous êtes prêt à configurer les alertes.

Alertes de base avec `edr monitor`

La commande edr monitor exécute les tests Elementary et envoie des alertes en cas d’échec. L’appel de base :

edr monitor --slack-token $SLACK_TOKEN --slack-channel-name data-alerts

Cela envoie des alertes vers un canal Slack pour tout test en échec ou en warning lors de la dernière exécution.

edr report génère un fichier HTML pour la revue manuelle, tandis que edr monitor est conçu pour l’automatisation. Exécutez monitor dans votre pipeline CI/CD ou planifiez-le après chaque dbt build.

Configurer les métadonnées d’alerte

Contrôlez ce qui apparaît dans les alertes via les métadonnées de test dans vos fichiers YAML :

models:
  - name: mrt__finance__revenue
    meta:
      owner: "@jessica.jones"
      subscribers: ["@jessica.jones", "@joe.joseph"]
      description: "Daily revenue aggregation for finance reporting"
      tags: ["critical", "finance"]
      channel: finance-data-alerts
      alert_suppression_interval: 24

Les champs owner et subscribers définissent qui est mentionné. Le champ channel route les alertes vers des canaux Slack spécifiques. Le champ alert_suppression_interval empêche les alertes répétées pour un même test en échec pendant le nombre d’heures indiqué.

Intégration Slack

Slack est la destination d’alerte la plus courante. Elementary propose deux méthodes d’intégration.

Par token (recommandé)

L’intégration par token offre un contrôle total : canaux personnalisés par modèle, mention d’utilisateurs et upload de fichiers pour des informations détaillées sur les échecs.

Créez une application Slack et ajoutez ces scopes de bot token :

channels:join
channels:read
chat:write
files:write
users:read
users:read.email
groups:read

Installez l’application dans votre workspace et copiez le bot token.

Configurez dans votre profil Elementary ou passez les paramètres directement en CLI :

# Dans votre config Elementary
slack:
  token: xoxb-your-slack-token
  channel_name: data-alerts
  group_alerts_by: "table"

Ou en ligne de commande :

edr monitor \
  --slack-token $SLACK_TOKEN \
  --slack-channel-name data-alerts \
  --group-by table

Par webhook

Les webhooks sont plus simples à mettre en place, mais limités à un seul canal et sans mention d’utilisateurs. Créez un incoming webhook dans Slack, puis :

edr monitor --slack-webhook $SLACK_WEBHOOK_URL

Utilisez cette méthode pour une mise en place rapide ou quand vous n’avez pas besoin de routage par modèle.

Routage par canal

Routez différentes alertes vers différents canaux selon l’emplacement du modèle ou ses métadonnées.

Routage par modèle dans le YAML du modèle :

models:
  - name: mrt__marketing__campaigns
    config:
      meta:
        channel: marketing-data-alerts

Routage par chemin dans dbt_project.yml :

models:
  your_project:
    marts:
      marketing:
        +meta:
          channel: marketing-data-alerts
      finance:
        +meta:
          channel: finance-data-alerts

Tous les modèles sous marts/marketing/ sont désormais routés vers le canal marketing, et ceux sous marts/finance/ vers le canal finance.

Intégration Microsoft Teams

L’intégration Teams utilise des webhooks avec des Adaptive Cards pour le formatage.

Note : Microsoft a déprécié les Incoming Webhooks fin 2025. Migrez vers Power Automate Workflows si ce n’est pas déjà fait.

Configuration actuelle par webhook :

teams:
  notification_webhook: https://your-org.webhook.office.com/webhookb2/...
  group_alerts_by: "table"

Ou en CLI :

edr monitor --teams-webhook $TEAMS_WEBHOOK_URL

Limitations à connaître :

Les mentions d’utilisateurs ne sont pas entièrement supportées
Les options de formatage riche sont plus limitées que sur Slack
La dépréciation des webhooks nécessite de planifier la migration

Pour les organisations qui standardisent sur Teams, envisagez les Power Automate Workflows qui se déclenchent sur des événements webhook et offrent plus de contrôle sur le formatage des messages.

PagerDuty et gestion d’incidents

Elementary Cloud étend les alertes au-delà de Slack et Teams vers les plateformes de gestion d’incidents : PagerDuty, Opsgenie, Jira, Linear, ServiceNow et email.

Configurer PagerDuty (Elementary Cloud)

Accédez à la page Environments dans Elementary Cloud
Cliquez sur “Connect incident management tool”
Sélectionnez PagerDuty
Autorisez Elementary (nécessite le rôle “User” dans PagerDuty)
Configurez les règles d’alerte

Les règles d’alerte associent les échecs de tests Elementary à des incidents PagerDuty en fonction de :

Statut : fail vs warn
Tags : critical, high, medium
Types de ressource : model, source, test

Exemple de règle : “Si status = fail ET tag = critical, créer un incident P1 dans PagerDuty.”

Autres intégrations

Elementary Cloud supporte également :

Opsgenie : Configuration similaire à PagerDuty, adapté aux équipes déjà sur Atlassian
Jira : Création de tickets pour les échecs nécessitant un suivi
Linear : S’intègre aux workflows d’ingénierie
ServiceNow : Intégration ITSM entreprise
Email : Notifications simples sans dépendance à une plateforme de chat
Webhooks (bêta) : Intégrations personnalisées avec n’importe quel système

Pour les utilisateurs OSS qui ont besoin de PagerDuty, vous pouvez faire le pont en envoyant les alertes Elementary vers un canal Slack qui déclenche PagerDuty via l’intégration PagerDuty de Slack.

Stratégies de routage des alertes

Au-delà du routage par canal, vous pouvez exécuter plusieurs commandes edr monitor avec différents filtres pour créer un routage sophistiqué.

Filtrage par tag

# Alertes critiques vers le canal urgent
edr monitor --filters tags:critical --slack-channel-name critical-alerts

# Alertes de l'équipe finance
edr monitor --filters tags:finance --slack-channel-name finance-data

Filtrage par propriétaire

edr monitor --filters owners:@finance-team --slack-channel-name finance-data

Filtrage par statut

# Uniquement les échecs, pas les warnings
edr monitor --filters statuses:fail --slack-channel-name failures-only

# Uniquement les warnings pour revue
edr monitor --filters statuses:warn --slack-channel-name warnings-review

Combinaison de filtres

Les filtres multiples fonctionnent en conditions AND :

edr monitor \
  --filters resource_types:model \
  --filters tags:finance,marketing \
  --slack-channel-name business-critical

Cela alerte sur les modèles taggés finance OU marketing.

Pattern d’automatisation

Exécutez plusieurs commandes monitor dans votre pipeline CI/CD :

# Dans GitHub Actions
- name: Alert on critical failures
  run: edr monitor --filters tags:critical --slack-channel-name critical-alerts

- name: Alert finance team
  run: edr monitor --filters tags:finance --slack-channel-name finance-data

- name: Alert marketing team
  run: edr monitor --filters tags:marketing --slack-channel-name marketing-data

Réduire la fatigue d’alerte

Rien ne tue un système d’alertes plus vite que le bruit. Quand chaque alerte ressemble à un faux positif, les équipes cessent d’y prêter attention.

Intervalles de suppression

Empêchez les alertes répétées pour un même test en échec :

meta:
  alert_suppression_interval: 24  # Heures

Si un test échoue à 9h et reste en échec, vous ne recevrez pas d’autre alerte avant 9h le lendemain. C’est essentiel pour les tests qui ne peuvent pas être corrigés immédiatement.

Configurez au niveau du test, du modèle ou du projet :

# Valeur par défaut projet dans dbt_project.yml
models:
  your_project:
    +meta:
      alert_suppression_interval: 12

Regroupement des alertes

Consolidez plusieurs échecs en un seul message :

edr monitor --group-by table

Au lieu de 10 alertes distinctes pour 10 tests en échec sur la même table, vous recevez une seule alerte listant tous les échecs. Cela réduit considérablement le bruit lors de cascades d’erreurs.

Définissez un seuil pour déclencher le regroupement :

edr monitor --group-alerts-threshold 5

En dessous de 5 échecs, les alertes sont envoyées individuellement. Au-dessus, elles sont consolidées.

Personnaliser le contenu des alertes

Contrôlez les champs qui apparaissent dans les alertes :

meta:
  alert_fields: ["description", "owners", "tags", "subscribers"]

Supprimez les champs qui ajoutent du bruit sans valeur ajoutée.

Gestion des données sensibles

Désactivez les données d’exemple dans les alertes quand les tables contiennent des données personnelles :

edr monitor --disable-samples

Ou configurez par modèle :

models:
  - name: mrt__customers__personal_info
    meta:
      disable_samples: true

Gestion d’incidents avec Elementary Cloud

Elementary Cloud ajoute le regroupement automatique d’incidents : quand de nouveaux échecs sont liés à des incidents ouverts, ils sont regroupés plutôt que de créer des tickets séparés. Les exécutions réussies résolvent automatiquement les incidents, ce qui réduit le nettoyage manuel.

Stratégies d’astreinte pour les équipes data

L’astreinte d’une équipe data diffère de l’astreinte traditionnelle en ingénierie logicielle. Les équipes data gèrent souvent le support, le triage et le développement simultanément. La même personne qui investigue un problème de qualité des données peut aussi construire de nouveaux pipelines.

Processus de triage

Établissez une catégorisation claire :

Sévérité	Critères	Réponse	Canal
Critique	Breach de SLA, panne production, impact revenu	Page immédiate	PagerDuty
Warning	Dégradation de qualité, problèmes potentiels	Jour ouvré suivant	Slack
Info	Consigné pour revue, aucune action requise	Revue hebdomadaire	Aucun

Runbooks dans les métadonnées de test

Liez la documentation de troubleshooting directement dans vos définitions de tests :

data_tests:
  - unique:
      column_name: customer_id
      config:
        meta:
          description: |
            Duplicate customer IDs detected.
            Runbook: https://docs.company.com/data/customer-dedup
            Contact: @data-platform-team

Quand ce test échoue, l’alerte inclut le lien vers le runbook. Les nouveaux membres de l’équipe peuvent résoudre les problèmes sans avoir à chercher la documentation.

Métriques à suivre

Mesurez la santé de votre système d’alertes :

Métrique	Ce qu’elle vous apprend
Volume d’alertes	Le système est-il trop bruyant ?
Taux de faux positifs	Les alertes sont-elles actionnables ?
Temps de prise en charge (MTTA)	À quelle vitesse les gens réagissent-ils ?
Temps de résolution (MTTR)	Combien de temps les problèmes restent-ils ouverts ?

Un taux de faux positifs élevé érode la confiance. Un MTTR élevé peut indiquer des runbooks manquants ou un manque de clarté sur les responsabilités.

Considérations pour la rotation

Quelques patterns qui fonctionnent pour les équipes data :

Combiner astreinte et sprints de développement : la personne d’astreinte gère les incidents ET travaille sur des améliorations qui réduisent les incidents futurs
Rotation hebdomadaire avec document de passation : documentez les problèmes ouverts, les problèmes récurrents et le contexte pour la personne suivante
Réponse par niveaux : les ingénieurs juniors gèrent le triage initial, puis escaladent les problèmes complexes aux ingénieurs seniors

Et ensuite

Vous avez maintenant des alertes configurées pour prévenir les bonnes personnes des bons problèmes au bon moment. La dernière pièce du puzzle est de décider ce qu’il faut construire soi-même ou acheter via une plateforme d’observabilité dédiée. Le prochain article de cette série couvre la décision build vs buy pour les outils de qualité des données.