Alertes Elementary edr monitor

edr monitor est la commande CLI Elementary qui envoie des alertes. Elle lit les résultats de tests depuis votre entrepôt, évalue quels tests ont échoué ou émis des avertissements lors de la dernière exécution, et envoie des notifications aux destinations configurées.

La façon la plus rapide de la voir en action :

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

Avant de configurer toute alerte, vérifiez que vous avez des résultats de tests à notifier. Exécutez edr report --select last_invocation et vérifiez que les résultats de tests apparaissent dans le HTML généré. Si le rapport est vide, les tables d’Elementary n’ont pas encore été peuplées — retournez au guide d’installation.

edr report vs edr monitor

Les deux commandes servent des objectifs différents, et il vaut la peine d’être clair sur la distinction.

edr report génère un fichier HTML autonome pour un examen humain. On l’ouvre dans un navigateur, on explore l’historique des tests, on voit les graphiques d’anomalies, on investigue des échecs spécifiques. Il est conçu pour les rapports planifiés et la consommation asynchrone — pas pour les alertes automatisées.

edr monitor est conçu pour l’automatisation. Il s’exécute après chaque dbt build, vérifie les nouveaux échecs, et envoie des notifications. Il ne génère pas de rapport à consulter ultérieurement ; il envoie et oublie.

Exécutez edr report lorsque vous souhaitez partager un snapshot avec des parties prenantes ou revoir l’exécution de la veille lors de votre bilan matinal. Exécutez edr monitor dans votre pipeline CI/CD ou sur un calendrier après chaque dbt build. Ils sont complémentaires, pas alternatifs.

Configuration des métadonnées d’alerte

Ce qui apparaît dans une alerte dépend des métadonnées que vous avez ajoutées à vos modèles. Sans métadonnées, les alertes sont minimalistes — juste le nom du test et la table. Avec des métadonnées, elles incluent des mentions de propriétaires, des tags pertinents et des liens vers le bon canal.

models:
  - name: mrt__finance__revenue
    meta:
      owner: "@jessica.jones"
      subscribers: ["@jessica.jones", "@joe.joseph"]
      description: "Agrégation de revenus quotidienne pour le reporting finance"
      tags: ["critical", "finance"]
      channel: finance-data-alerts
      alert_suppression_interval: 24

Quelques champs qui ne sont pas évidents depuis la documentation :

Le champ owner contrôle qui est mentionné dans le corps de l’alerte. subscribers étend cette mention à des personnes supplémentaires. Si vous ne les définissez pas, Elementary envoie une alerte sans mention — ce qui signifie qu’elle sera vue quand quelqu’un fait défiler le canal, pas quand quelqu’un doit agir.

channel route l’alerte vers un canal Slack spécifique plutôt que vers votre canal par défaut. C’est ainsi que l’on garde les échecs finance dans #finance-data-alerts et les échecs marketing dans #marketing-data-alerts, plutôt que de tout déverser dans un canal partagé que tout le monde finit par mettre en sourdine.

alert_suppression_interval contrôle combien de temps Elementary attend avant de renvoyer une alerte pour le même test en échec. Définissez-le à 24 et un test qui échoue à 9h n’alertera pas à nouveau avant 9h le lendemain, même s’il continue d’échouer à chaque exécution entre-temps. Cela est couvert plus en détail dans Elementary Alert Fatigue Reduction.

Valeurs par défaut basées sur les chemins

Définir des métadonnées sur des modèles individuels fonctionne bien à petite échelle. Pour les projets plus importants, il vaut mieux avoir des valeurs par défaut s’appliquant à des répertoires entiers sans avoir à répéter la configuration sur chaque modèle.

Dans dbt_project.yml :

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

Chaque modèle sous marts/finance/ route maintenant vers #finance-data-alerts avec un intervalle de suppression de 12 heures, sans aucun YAML par modèle. Les modèles individuels peuvent toujours surcharger ces valeurs par défaut s’ils nécessitent un comportement différent.

Exécution de edr monitor en CI/CD

Le pattern typique est d’exécuter edr monitor comme étape dans votre pipeline après la complétion de dbt build ou dbt test.

# Exemple GitHub Actions
- name: Run dbt build
  run: dbt build

- name: Send Elementary alerts
  run: edr monitor --slack-token $SLACK_TOKEN --slack-channel-name data-alerts
  env:
    SLACK_TOKEN: ${{ secrets.SLACK_TOKEN }}

edr monitor lit depuis les tables d’entrepôt d’Elementary, il ne réexécute donc pas les tests — il vérifie simplement les résultats que dbt build a déjà écrits. Les tables d’entrepôt sont l’interface entre l’exécution dbt et les alertes Elementary.

Pour un routage plus avancé — envoyer des échecs différents vers des canaux différents, filtrer par tag ou propriétaire — voir Elementary Alert Routing with Filters.