Routage des alertes Elementary avec des filtres

Le routage par canal via les métadonnées de modèle (définir channel: finance-data-alerts sur un modèle ou un répertoire) gère le cas courant : router par appartenance d’équipe. Mais parfois on souhaite un routage basé sur les caractéristiques de l’échec — sévérité, tags ou type de ressource — plutôt que sur le propriétaire du modèle. C’est là qu’intervient le flag --filters de edr monitor.

Le pattern de base : exécuter edr monitor plusieurs fois dans la même étape de pipeline avec des arguments de filtre différents et des canaux de destination différents. Chaque invocation interroge les mêmes tables Elementary mais envoie un sous-ensemble différent d’alertes vers une destination différente.

Filtrage par tag

Les tags sur les modèles sont la dimension de routage la plus flexible car on contrôle ce que les tags signifient. Un tag critical route vers un canal haute priorité ; un tag finance route vers le canal de l’équipe finance :

# 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

Cela fonctionne lorsque les tags ont été appliqués de manière cohérente dans le YAML des modèles :

models:
  - name: mrt__finance__revenue
    meta:
      tags: ["critical", "finance"]

Un modèle tagué avec critical et finance apparaîtra dans les deux exécutions — ce qui est généralement souhaité pour un modèle à la fois à forts enjeux et appartenant à une équipe.

Filtrage par propriétaire

Router les alertes vers le canal de l’équipe propriétaire du modèle en échec :

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

Le filtre owners correspond au champ owner dans les métadonnées du modèle. C’est complémentaire au routage par tag — on peut router par propriétaire vers le canal d’équipe pour une attention routinière, et par tag vers un canal critique pour une réponse immédiate.

Filtrage par statut

Tous les échecs ne sont pas équivalents. fail signifie que le test a échoué ; warn signifie qu’il a dépassé le seuil d’avertissement mais pas le seuil d’erreur. Des urgences différentes justifient des canaux différents :

# Uniquement les échecs durs — action immédiate requise
edr monitor --filters statuses:fail --slack-channel-name failures-only

# Avertissements à examiner — quelqu'un devrait y jeter un œil, sans paniquer
edr monitor --filters statuses:warn --slack-channel-name warnings-review

Cela se combine bien avec la configuration de la sévérité des tests dans dbt. Les tests de sévérité warn signalent « à examiner prochainement ». Les tests de sévérité error signalent « quelque chose est cassé maintenant ». Les envoyer vers des canaux différents rend cette distinction visible sans que personne ait à lire attentivement l’alerte pour savoir laquelle c’est.

Combinaison de filtres

Plusieurs flags --filters se combinent en conditions AND, mais les valeurs séparées par des virgules dans un filtre sont en OR :

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

Cela envoie des alertes pour les modèles (pas les sources ou les tests) tagués avec finance OU marketing. Les deux conditions doivent être vraies (AND), mais l’une ou l’autre valeur de tag satisfait le filtre tags (OR). Utile pour couvrir les modèles critiques sans lister chaque modèle explicitement.

Le pattern de pipeline multi-étapes

En assemblant tout cela 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

Chaque étape est indépendante. Un échec critique finance apparaît dans #critical-alerts et #finance-data. Un échec marketing non critique n’apparaît que dans #marketing-data. La logique de filtrage est dans le pipeline, pas dans les tables de l’entrepôt.

Un point à garder en tête : chaque invocation de edr monitor interroge l’entrepôt. Avec 10 règles de routage séparées, cela représente 10 requêtes. Sur BigQuery en tarification à la demande, cela s’accumule à l’échelle — pas de manière dramatique, mais cela justifie de consolider les filtres similaires lorsque c’est possible.

PagerDuty et gestion des incidents (Elementary Cloud)

La commande edr monitor OSS route vers Slack et Teams. Elementary Cloud étend cela à PagerDuty, Opsgenie, Jira, Linear, ServiceNow, e-mail et webhooks personnalisés.

L’approche Cloud diffère du pattern CLI multi-filtre — au lieu d’exécuter plusieurs commandes monitor, on configure des règles d’alertes dans l’interface Elementary Cloud qui mappent les échecs de tests sur des incidents en fonction du statut, des tags et des types de ressources.

Un exemple de règle : « si statut = fail ET tag = critical, créer un incident P1 dans PagerDuty ». Cloud gère également le regroupement automatique des incidents (les nouveaux échecs liés à un incident ouvert sont regroupés plutôt que de créer des tickets séparés) et la résolution automatique lorsque des exécutions réussies arrivent.

Pour les utilisateurs OSS qui ont besoin d’une intégration PagerDuty sans passer à Cloud, l’approche bridge fonctionne : envoyer les alertes Elementary vers un canal Slack qui déclenche PagerDuty via l’intégration PagerDuty native de Slack. Moins élégant qu’une intégration Cloud native, mais obtient la même notification d’astreinte sans le coût de licence.

Le modèle de sévérité de triage qui détermine quelle alerte va où est couvert dans Data Team On-Call Strategies.