Développement Web

Alertes Grafana vers Discord/Slack : tutoriel 2026

10 min de lecture

Configurer des alertes Grafana qui poussent vers Discord, Slack ou Telegram en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer).

Voir notre guide observabilité.

Étape 1 — Contact point

  1. Grafana → Alerting → Contact points → New contact point
  2. Type : Discord (Webhook)
  3. URL : webhook URL Discord (#alerts channel)
  4. Test → Save

Étape 2 — Notification policy

  1. Alerting → Notification policies → Edit
  2. Default contact point : Discord
  3. Group by : alertname, severity
  4. Group wait : 30s
  5. Group interval : 5m
  6. Repeat interval : 4h

Étape 3 — Première alerte CPU

  1. Alerting → Alert rules → New alert rule
  2. Name : « CPU high »
  3. Query : 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
  4. Condition : IS ABOVE 80
  5. Evaluation interval : 1m, for : 5m
  6. Annotations : summary « CPU > 80% sur {{ $labels.instance }} », description plus détaillée
  7. Save and exit

Alertes courantes

  • CPU > 80 % pendant 5 min
  • RAM > 90 %
  • Disque > 85 %
  • Container restart count > 3 en 10 min
  • HTTP errors 5xx > 1 % du trafic
  • Latence p95 > 500 ms
  • Pas de logs reçus depuis un host (heartbeat)
  • Certificate SSL expire dans 14 jours

Severity et routing

Pour différencier critique vs warning :

  • Labels severity=critical sur les alertes prod down → contact point SMS Twilio + Discord
  • Labels severity=warning → contact point Discord uniquement
  • Notification policies routent selon labels

Pour creuser ce sujet

Etape 1 : Comprendre le pipeline d’alertes Grafana

Grafana 11 (sortie en 2024, version stable utilisee en 2026) embarque un moteur d’alertes unifie. Le pipeline va de la datasource (Prometheus, Loki, MySQL…) vers une regle d’evaluation, puis un point de contact qui pousse la notification. Pour Discord, le point de contact est un webhook entrant configure cote serveur Discord. La latence end-to-end entre l’apparition d’un probleme et le ping dans le salon Discord est de 30 a 90 secondes selon votre intervalle d’evaluation.

A Dakar comme a Yaounde, les equipes de 2 a 5 personnes prefferent Discord a Slack pour le cout (gratuit, illimite) et pour la simplicite — un seul salon #alerts ou tout le monde voit les incidents en temps reel, meme depuis le telephone.

Etape 2 : Creer le webhook Discord dans le serveur cible

Dans votre serveur Discord, ouvrez les parametres du salon #alerts (icone roue dentee a cote du nom). Allez dans Integrations puis Webhooks et cliquez Nouveau Webhook. Donnez-lui un nom comme « Grafana Alerts » et une icone reconnaissable. Copiez l’URL — elle a la forme https://discord.com/api/webhooks/123456/abcdef.

Cette URL est un secret : qui la possede peut poster dans le salon. Stockez-la dans un gestionnaire de secrets (Vault, AWS Secrets Manager, ou variable d’environnement chiffree avec SOPS) — jamais dans le repo Git en clair.

Etape 3 : Tester le webhook avec curl avant Grafana

Avant de configurer Grafana, validez que le webhook fonctionne avec une requete curl simple. Cela isole les problemes : si curl marche mais pas Grafana, c’est dans Grafana qu’il faut chercher.

curl -X POST -H "Content-Type: application/json" \
  -d '{"content":"Test depuis Dakar"}' \
  https://discord.com/api/webhooks/123456/abcdef

Vous devez voir le message apparaitre dans #alerts en moins de 2 secondes. Si vous obtenez une erreur 401, l’URL est mauvaise ou le webhook a ete supprime. Si 429, vous etes rate-limite (5 requetes par 2 secondes par webhook) — Grafana respecte cette limite par defaut.

Etape 4 : Configurer le point de contact Discord dans Grafana

Dans l’interface Grafana, allez dans Alerting puis Contact points et cliquez Add contact point. Choisissez le type Discord. Collez l’URL du webhook dans le champ Webhook URL. Activez Use Discord username and avatar pour avoir une identite claire.

Le champ Message Content Template accepte du Go templating. Laissez-le par defaut pour un premier test, on l’ameliorera a l’etape suivante. Cliquez Test — un message de test doit arriver dans Discord. Sauvegardez ensuite avec Save contact point.

Etape 5 : Personnaliser le template du message Discord

Le template par defaut est verbeux. Pour un salon Discord, on veut un message court avec emoji, nom de l’alerte, valeur, et lien direct vers le dashboard. Ajoutez un template custom dans Alerting puis Notification templates.

{{ define "discord.message" }}
{{ if eq .Status "firing" }}🔴{{ else }}✅{{ end }} **{{ .GroupLabels.alertname }}**
{{ range .Alerts }}
> {{ .Annotations.summary }}
> Valeur : {{ .ValueString }}
{{ end }}
{{ end }}

Reference ce template dans le contact point via Message Content : {{ template « discord.message » . }}. Vous obtenez un message lisible en 2 lignes au lieu de 15. Les emoji 🔴/✅ permettent de scanner visuellement le salon en 2 secondes pour reperer les incidents en cours.

Etape 6 : Creer une regle d’alerte Prometheus pour la CPU

Demarrez par une alerte simple : CPU superieure a 85% pendant 5 minutes. Dans Alerting puis Alert rules, cliquez New alert rule. Choisissez la datasource Prometheus, ecrivez la requete PromQL.

100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Configurez la condition : WHEN last() OF query IS ABOVE 85. Definissez Pending period a 5m — l’alerte ne firera que si la condition reste vraie pendant 5 minutes consecutives, evitant les faux positifs sur des pics de 30 secondes. Sauvegardez sous le nom HighCPU.

Etape 7 : Lier la regle au point de contact via une politique

Dans Alerting puis Notification policies, editez la policy par defaut et changez le Default contact point pour Discord. Ou creez une policy specifique avec un matcher severity=critical qui route uniquement les alertes critiques vers Discord, et les warning vers email.

Ajoutez le label severity dans la regle : Custom labels severity=critical. Vous pouvez avoir plusieurs niveaux — critical vers Discord et SMS, warning vers Discord seulement, info vers email digest quotidien. Ce routage par severite evite la fatigue d’alerte qui rend l’equipe sourde aux notifications apres 2 semaines.

Etape 8 : Tester l’alerte de bout en bout

Pour valider que tout fonctionne, simulez une charge CPU sur un noeud non critique. Sur Linux, stress-ng fait l’affaire. Lancez-le 6 minutes pour declencher la pending period.

stress-ng --cpu 4 --timeout 360s

Surveillez le statut de l’alerte dans Grafana — elle doit passer Pending puis Firing. Le ping Discord doit arriver dans la minute qui suit le passage en Firing. Si rien n’arrive, verifiez les logs Grafana via journalctl -u grafana-server -f — vous y verrez les erreurs de webhook le cas echeant.

Etape 9 : Ajouter le silencing pour les fenetres de maintenance

Quand vous deployez une nouvelle version a 23h un samedi soir, vous ne voulez pas que les alertes de redemarrage de pods sonnent dans Discord. Creez un silence dans Alerting puis Silences avec les matchers appropries (ex: alertname=PodRestart) et une duree de 30 minutes.

Le silence supprime les notifications mais pas l’evaluation — l’alerte reste visible dans le dashboard pour traquer les anomalies. A la fin de la fenetre, le silence expire automatiquement et les alertes reprennent. Documentez chaque silence avec un commentaire qui pointe vers le ticket de deploiement, sinon vous oublierez et un silence permanent finira par cacher un vrai incident.

Etape 10 : Centraliser plusieurs Grafana dans un seul Discord

Si vous gerez plusieurs environnements (staging, prod-fr, prod-ci) avec un Grafana par environnement, configurez chaque Grafana avec son propre webhook Discord pointant vers un salon different ou utilise un template qui prefixe le message par l’environnement. Le prefixe permet de garder un seul salon central tout en distinguant la source.

{{ define "discord.message" }}
[{{ .CommonLabels.environment }}] 🔴 {{ .GroupLabels.alertname }}
{{ end }}

Pour la couche metrique en amont, voyez notre guide Drizzle multi-tenant qui detaille comment exposer des metriques par tenant. Pour les alertes liees aux migrations de schema, completez avec notre tutoriel zero-downtime.

Etape 11 : Creer une alerte Loki sur les logs d’erreur

Au-dela des metriques, surveillez vos logs applicatifs. Une alerte Loki peut detecter une rafale d’erreurs 500 et notifier Discord avant que vos utilisateurs n’ouvrent un ticket. La requete LogQL compte les lignes contenant « ERROR » sur les 5 dernieres minutes.

sum(count_over_time({app="api"} |= "ERROR" [5m])) > 10

Si plus de 10 erreurs en 5 minutes, l’alerte fire. Configurez Pending period a 1m pour reagir vite — les rafales d’erreurs sont generalement courtes mais signalent souvent un incident plus large (DB down, dependance externe en panne). Le webhook Discord recoit le ping en moins de 90 secondes apres l’apparition du probleme.

Etape 12 : Enrichir l’alerte avec un lien vers Loki

Le ping Discord doit pointer directement vers le dashboard ou la requete Loki preremplie pour permettre une investigation en un clic. Utilisez l’annotation runbook_url dans la regle d’alerte et incluez-la dans le template Go.

{{ define "discord.message" }}
🔴 **{{ .GroupLabels.alertname }}**
[Voir les logs]({{ .Alerts.0.Annotations.runbook_url }})
{{ end }}

Discord rend les liens markdown automatiquement. L’ingenieur d’astreinte clique, arrive sur Loki avec le filtre deja applique sur la fenetre temporelle pertinente, et commence a investiguer en 5 secondes au lieu de 5 minutes. Sur un incident a 3h du matin, ces 5 minutes gagnees changent tout.

Etape 13 : Sauvegarder la configuration en provisioning YAML

Cliquer dans l’UI Grafana pour configurer 50 alertes n’est pas viable. Provisionnez tout via fichiers YAML stockes dans /etc/grafana/provisioning/alerting/. Grafana relit ces fichiers au demarrage et garantit que la configuration est la meme sur tous vos environnements.

apiVersion: 1
groups:
  - orgId: 1
    name: cpu_alerts
    interval: 1m
    rules:
      - uid: high_cpu
        title: HighCPU
        condition: B
        data: [...]

Versionnez ce fichier dans Git, et tout changement passe par PR avec revue. Plus de configuration cliquee a 2h du matin que personne ne pourra reproduire le lendemain. Sur un projet a Niamey en 2025, cette discipline avait permis de reconstruire l’integralite du monitoring en 20 minutes apres une corruption disque sur le serveur Grafana — sans le YAML, ca aurait ete 2 jours de travail.

Etape 14 : Eviter le bruit avec le grouping intelligent

Sans grouping, une panne reseau qui touche 30 instances genere 30 messages Discord en quelques secondes. La policy de notification regroupe les alertes par labels — par defaut group_by inclut alertname et grafana_folder. Ajoutez group_wait a 30s pour laisser arriver les alertes connexes avant d’envoyer une seule notification consolidee.

group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h

repeat_interval evite le spam : tant que l’alerte reste firing, Grafana repete la notification toutes les 4h plutot que toutes les minutes. C’est generalement le bon compromis entre rappel utile et bruit insupportable. Ajustez selon la criticite de l’alerte — pour un incident DB primary down, 30 minutes est plus approprie.

Etape 15 : Documenter les runbooks lies aux alertes

Chaque alerte doit avoir un runbook lie : un document court qui explique en 5 etapes ce que doit faire l’ingenieur d’astreinte. Stockez les runbooks dans le repo infra a cote du YAML de configuration. L’annotation runbook_url de l’alerte pointe vers ce document, accessible en un clic depuis le ping Discord. Sans runbook, l’astreinte de minuit improvise — avec runbook, elle execute une procedure validee qui marche en 3 minutes au lieu de 30.

Etape 16 : Mesurer la qualite de votre alerting

Une fois le pipeline stabilise, mesurez deux indicateurs : le taux de faux positifs (alertes qui se resolvent seules sans intervention) et le MTTR (Mean Time To Repair). Si plus de 30% de vos alertes sont des faux positifs, vos seuils sont trop sensibles et l’equipe va developper une fatigue d’alerte qui finira par lui faire ignorer les vraies. Si le MTTR depasse 30 minutes, c’est souvent que les runbooks sont incomplets ou que les alertes manquent de contexte. Revoyez ces metriques chaque mois en stand-up dedie — c’est l’unique moyen de garder un systeme d’alertes utile sur la duree, plutot qu’un canal Discord que l’equipe finit par mute apres 6 mois d’usage intensif et bruyant.

Etape 17 : Etendre vers une page d’astreinte rotative

Quand l’equipe grandit au-dela de 3 personnes, mettez en place une astreinte rotative. Grafana s’integre avec Grafana OnCall (gratuit en open source) ou des services tiers comme PagerDuty et OpsGenie. La rotation hebdomadaire est le standard : chacun prend l’astreinte une semaine sur trois ou quatre. Le webhook Discord reste actif pour la visibilite collective, mais l’escalade SMS ou appel cible uniquement la personne d’astreinte courante. Cela evite que toute l’equipe soit reveillee a chaque incident, tout en garantissant qu’au moins une personne reagisse dans les 5 minutes.

Ajoutez aussi a votre routine une revue trimestrielle des alertes obsoletes : services demanteles, seuils devenus inadaptes, regles dupliquees apres refactoring. Sans cette purge, le systeme accumule de la dette qui finit par cacher les alertes vraiment utiles.

Partager
#2026 #Frontend #Tutoriel

Articles Similaires