Alerting Grafana et IRM (OnCall)

Cette page explique le fonctionnement global de l'alerting, ce qui est géré en configuration OpenTofu, et ce qui est personnalisable par chaque utilisateur dans son profil IRM.

Historique rapide:

• Le contact point principal était historiquement PagerDuty
• Pour les nodes en alerting.provider = "grafana", on utilise maintenant le flux Grafana/IRM
• Les alertes node CPU/Memory/Disk/Cron/Services sont gérées en OpenTofu, basées sur les métriques Prometheus remontées par Grafana Alloy (plus via pg-send)

Table des matières

• Vue d'ensemble
• Global vs utilisateur
• Pourquoi je reçois des emails alors que je veux seulement Slack
• Routage Slack par customer
• Comment la config OpenTofu est créée (commande ./console)
• Configurer un node avec utilisateurs cibles
• Mini checklist de diagnostic
• Bonnes pratiques ITN

Vue d'ensemble

Flux simplifié:

1. Grafana Alerting détecte un problème (état FIRING)
2. L'alerte est envoyée à l'intégration IRM
3. IRM applique la route (par défaut ou route spécifique node)
4. IRM envoie sur Slack (canal configure)
5. Si la chaîne d'escalade contient une étape notify_whole_channel, les membres du canal sont notifiés via leurs règles personnelles (email, mobile, etc.)

Alertes node gérées dans ce flux Grafana:

• CPU (load average)
• Memory
• Disk
• Cron jobs
• Services systemd

Quand l'alerte passe en RESOLVED, le cycle est clôturé.

Global vs utilisateur

Ce qui est global (OpenTofu)

C'est la configuration partagée de l'organisation:

• Intégration IRM globale (ITN Grafana Alerts)
• Chaîne d'escalade globale
• Routes Slack par défaut et routes par node
• Éventuels ciblages utilisateurs par node (notify_usernames)

Fichiers principaux:

• opentofu/infra/core/grafana/irm/terragrunt.hcl
• opentofu/modules/grafana/irm/main.tf
• opentofu/modules/grafana/irm/integration/main.tf
• opentofu/nodes/<role>/<node>/grafana/irm/integration/terragrunt.hcl

Ce qui est utilisateur (profil IRM)

Chaque utilisateur peut régler ses notifications personnelles dans IRM:

• email
• Slack
• mobile app
• téléphone / SMS (selon configuration)

Donc oui: les notifications sont paramétrables par utilisateur dans le profil IRM.

Configuration manuelle dans l'UI Grafana OnCall:

• URL profil: https://itnetwork.grafana.net/profile
• Navigation: Grafana -> Alerts & IRM -> OnCall (menu latéral gauche)
• Ouvrir l'onglet Users
• Cliquer sur votre profil utilisateur
• Aller dans Default Notifications (liste des étapes: email, Slack, wait, etc.)
• Supprimer les étapes email
• Garder ou ajouter uniquement Notify by Slack
• Refaire la même chose dans Important Notifications si nécessaire

Capture de référence:

Routage Slack par customer

Cas pratique pour les notifications Slack partagees avec un client.

Les contact points Slack par client se définissent dans l'infra, pas dans le profil utilisateur IRM.

Point clé de routage:

• Les alertes créées par OpenTofu portent le label managed_by = "opentofu"
• Les Notification Policies matchent d'abord sur ce label, puis sur customer=hds pour envoyer aussi vers le canal client HDS
• Le contact point par défaut de la notification policy reste pagerduty pour conserver la compatibilité historique

Configuration correspondante:

• Label managed_by dans les règles d'alertes: opentofu/modules/grafana/alert/main.tf
• Matchers managed_by + customer et continue=true: opentofu/infra/core/grafana/notification-policy/terragrunt.hcl
• Contact point par défaut pagerduty: opentofu/infra/core/grafana/notification-policy/terragrunt.hcl

Capture des Notification Policies:

customer = "" (ou pas de label customer exploitable)

• La policy customer hds ne matche pas
• L'alerte suit la route standard managed_by=opentofu
• Elle arrive sur le contact point IRM global ITN

customer = "hds"

• Si le label d'alerte customer=hds est présent, la policy customer = hds matche d'abord
• Le contact point client HDS est utilisé (slack_channel = "hds-alerts")
• La policy est en continue = true, donc l'alerte continue ensuite vers la route IRM standard

En pratique pour HDS:

• canal client dédié: hds-alerts
• plus la route IRM standard ITN (selon policy globale) : channel server-admin

Exemple de configuration HDS (canal partagé avec le client):

# opentofu/infra/customers/hds/contact-point/terragrunt.hcl
inputs = {
  contact_point_name = "HDS"
  slack_channel      = "hds-alerts"
}

Le routage customer est défini dans la policy globale:

# extrait: opentofu/infra/core/grafana/notification-policy/terragrunt.hcl
{
  contact_point_name = dependency.hds_contact_point.outputs.contact_point_name
  continue           = true
  matchers = [
    { label = "managed_by", match = "=", value = "opentofu" },
    { label = "customer",   match = "=", value = "hds" }
  ]
}

Le contact point Slack client HDS est défini en infra:

# extrait: opentofu/infra/customers/hds/contact-point/terragrunt.hcl
inputs = {
  contact_point_name = "HDS"
  slack_channel      = "hds-alerts"
}

Fichiers de configuration utiles:

• opentofu/infra/customers/hds/contact-point/terragrunt.hcl
• opentofu/infra/core/grafana/notification-policy/terragrunt.hcl
• opentofu/infra/core/grafana/contact-point/terragrunt.hcl

Comment la config OpenTofu est créée (commande ./console)

Le flux vient des scripts Chef quand on lance ./console build-alerting.

Règle de sélection:

• Seuls les nodes avec alerting.provider = "grafana" sont traités par le flux OpenTofu
• Les autres providers suivent les autres flux d'alerting

Création initiale de la config node:

1. La commande lit les nodes Chef et filtre provider = "grafana"
2. Elle crée le dossier OpenTofu du node s'il n'existe pas encore
3. Elle copie le skeleton OpenTofu dans ce dossier
4. Elle injecte les valeurs depuis le rôle Chef (disk, cpu, memory, customer)
5. Elle lance terragrunt init/plan/apply

Valeurs par défaut utilisées à la génération (si absentes dans Chef):

• disk = strict
• memory = strict
• cpu = strict
• customer = ""

Important sur le comportement des scripts:

• La génération de fichiers depuis le skeleton est faite seulement à la création initiale du node (si le dossier n'existe pas)
• Une fois la config créée, vous pouvez modifier directement les fichiers Terraform/Terragrunt dans opentofu/nodes/...
• Ces modifications manuelles sont conservées (pas de recopie du skeleton à chaque exécution)

Sources scripts:

• scripts/command.js
• scripts/lib/alerting/alerting.js
• scripts/lib/alerting/opentofu.js

Pourquoi je reçois des emails alors que je veux seulement Slack

Si une chaîne contient l'étape:

• Escalate to all Slack channel members (use with caution)

alors IRM notifie les membres du canal via leurs règles personnelles. Si un utilisateur a une règle email active, il recevra un email.

Important: l'envoi Slack peut deja etre assure par la route IRM (default_route.slack / route.slack) sans necessiter l'escalade vers les membres.

Actions utiles au quotidien

• Acquitter (ack) rapidement une alerte en cours de traitement
• Ajouter un commentaire de contexte dans l'incident
• Résoudre l'incident dès que le service est revenu
• Vérifier l'historique de l'alerte pour voir qui a été notifié et quand
• Ajuster ses règles perso IRM pour réduire le bruit (ex: désactiver email, garder Slack)

Configurer un node avec utilisateurs cibles

Le module node permet de cibler des utilisateurs en plus du canal Slack via notify_usernames.

Exemple (dans le terragrunt.hcl du node):

inputs = {
  role_name           = local.common.locals.role_name
  node_name           = replace(local.common.locals.node_name, "_", "-")
  slack_token         = local.slack_token
  slack_channel       = local.slack_channel
  escalation_chain_id = dependency.irm.outputs.escalation_chain_id
  integration_id      = dependency.irm.outputs.integration_id
  notify_usernames    = ["prenom.nom", "astreinte.web"]
}

Si notify_usernames = [], il n'y a pas de ciblage utilisateur additionnel.

Mini checklist de diagnostic

Quand un utilisateur signale des emails inattendus:

1. Vérifier la chaîne d'escalade (présence de notify_whole_channel)
2. Vérifier les règles personnelles du profil IRM de l'utilisateur
3. Vérifier que la route Slack est bien active
4. Confirmer si le besoin est:
   • global (changer la chaine/route)
   • spécifique utilisateur (changer son profil IRM)

Bonnes pratiques ITN

• Versionner toute modification globale dans OpenTofu
• Éviter les changements manuels durables dans l'UI IRM sans report dans l'infra as code (OpenTofu)