Sur cette page

PagerDuty

L’Integrator envoie chaque alerte a PagerDuty sous forme d’evenement Events API v2. Un moniteur = un incident : les alertes suivantes y sont fusionnees, et le retablissement du moniteur le resout. Il vous faut la cle d’une integration Events API V2 sur un service PagerDuty.

Comment Mugnsoft utilise PagerDuty
API PagerDuty Events API v2 - https://events.pagerduty.com/v2/enqueue
Cle La cle d’integration, envoyee comme routing_key
Cle d’incident dedup_key = <sonde>:<moniteur>, par exemple probe-paris:url_web-shop_probe-paris. Toutes les alertes du moniteur arrivent dans le meme incident.
Statut non OK Evenement trigger : ouvre l’incident, ou est dedoublonne dans l’incident ouvert
Severite CRITICAL → critical ; MAJOR, ERROR, TIMEOUT, EXCEPTION, CONFIG → error ; MINOR → warning
Retour a OK Evenement resolve : resout l’incident - avec On change, et aussi avec On fail seul
Resume Le titre de l’alerte : [CRITICAL] web-shop · HTTP 503 · probe-paris
Details Moniteur, type, statut, cible, sonde, heure du controle et message en details personnalises ; la sonde comme source ; un lien Locate in 3D view

Etape 1 : creer l’integration dans PagerDuty

Il faut le role Manager (ou superieur) sur le service.

  1. Dans PagerDuty, allez dans Services → Service Directory et ouvrez le service qui doit recevoir les incidents Mugnsoft, ou creez-en un (+ New Service) avec la politique d’escalade de l’equipe d’astreinte.
  2. Ouvrez l’onglet Integrations et cliquez sur Add another integration (ou Add an integration).
  3. Cherchez et selectionnez Events API V2, puis cliquez sur Add.
  4. Depliez la nouvelle integration avec le chevron a sa droite et copiez l’Integration Key (32 caracteres).

Guide officiel : PagerDuty - Services and Integrations. Reference API : Events API v2.

La cle permet a quiconque d’ouvrir des incidents sur le service : traitez-la comme un secret. Mugnsoft la stocke chiffree.

Etape 2 : configurer Mugnsoft

Par defaut pour tous les moniteurs d’un Integrator - Integrator → General → Notifications → PagerDuty : activez On fail et/ou On change, et collez la cle dans Default API key.

Par moniteur - moniteur → Actions → carte PagerDuty : activez le ou les declencheurs. Laissez API Key vide pour utiliser le defaut de l’Integrator, ou collez la cle d’un autre service pour alerter une autre equipe.

Enregistrez les deux formulaires avec l’icone disquette.

Declencheurs recommandes :

Objectif On fail On change
Alerter sur un echec durable, resoudre automatiquement actif (regle : p. ex. error, after 2, for 1) inactif
Refleter chaque changement de statut dans un incident inactif actif

Avec On fail seul, l’incident est ouvert quand la regle est satisfaite et resolu quand le moniteur revient a OK ; les echecs courts qui ne satisfont jamais la regle n’ouvrent rien. Les evenements trigger portant la cle d’un incident ouvert y sont dedoublonnes : les alertes ON FAIL repetees ne rappellent pas l’astreinte.

Tester

Depuis Mugnsoft - dans le bloc Notifications de l’Integrator, cliquez sur ⚡ sur la carte PagerDuty. L’Integrator ouvre un incident de test ([TEST] Mugnsoft notification test) avec la cle indiquee dans le champ, ou son defaut enregistre, et le resout aussitot. Cela alerte la personne d’astreinte : prevenez-la, ou testez sur un service avec une politique d’escalade de test.

PagerDuty met les evenements en file avant de verifier que la cle existe : une cle bien formee mais erronee est aussi acceptee. Verifiez que l’incident de test apparait dans le journal des incidents du service : s’il n’apparait pas, la cle appartient a un autre service ou a un autre compte.

A la main, depuis la machine de l’Integrator :


# Ouvrir un incident de test
curl -s -X POST https://events.pagerduty.com/v2/enqueue \
  -H "Content-Type: application/json" \
  -d '{"routing_key":"VOTRE_CLE_INTEGRATION","event_action":"trigger","dedup_key":"mugnsoft-test","payload":{"summary":"Incident de test Mugnsoft","source":"mugnsoft","severity":"info"}}'

# Le resoudre
curl -s -X POST https://events.pagerduty.com/v2/enqueue \
  -H "Content-Type: application/json" \
  -d '{"routing_key":"VOTRE_CLE_INTEGRATION","event_action":"resolve","dedup_key":"mugnsoft-test"}'

Chaque appel doit repondre {"status":"success","message":"Event processed",...} (HTTP 202).

Lancez ensuite le test de bout en bout.

Depannage

L’Integrator journalise l’erreur PagerDuty (sendMsgPagerDuty - [moniteur] - all 3 attempts failed: <erreur>).

Symptome Cause et action
events API v2 returned HTTP 400: Invalid routing key Cle mal formee ou tronquee. Recopiez l’Integration Key de l’integration Events API V2 du service et relancez le test.
Le test reussit mais aucun incident n’apparait Cle bien formee mais erronee (autre service, autre compte, ou ancienne cle Events API V1), integration ou service desactive, ou service en mode maintenance.
HTTP 429 Limitation de debit : une regle ON FAIL for 0 checks sur de nombreux moniteurs envoie un evenement a chaque controle. Utilisez for N checks.
Les incidents n’arrivent plus apres une mise a jour en 4.3.0 La cle appartient a une integration Events API V1. Creez une integration Events API V2 et remplacez la cle (voir l’avertissement en haut).
Les incidents ne se resolvent jamais Le retablissement a ete retenu par Debounce status-change alerts sur la sonde et le moniteur a de nouveau echoue avant d’etre stable.
Plusieurs incidents pour une panne Un incident par moniteur et par sonde, par conception : un site controle depuis trois sondes ouvre trois incidents. Regroupez-les avec le regroupement d’alertes de PagerDuty si besoin.
Un incident resolu dans PagerDuty revient Le moniteur est toujours en echec : l’evenement trigger suivant ouvre un nouvel incident avec la meme cle.

Plus d’elements dans Depannage.

Traductions

SIGNL4