Comment nous t'informons ou t'alertons
Une panne ne vaut la peine d'être détectée que si les bonnes personnes en sont informées. Nous envoyons des notifications là où ton équipe est déjà et à tes propres systèmes via des webhooks.
Les canaux
Chaque canal reçoit le même message : quel monitor, depuis quand et pourquoi. Ci-dessous, tu trouveras une liste des canaux disponibles.
-
Email Chaque forfait
Un message à n'importe quelle adresse. L'adresse e-mail doit être confirmée une fois.
-
Webhook (POST) Chaque forfait
Un corps JSON avec les données pertinentes envoyé à une URL que tu as fournie. Pour ton automatisation : ouvre un ticket, alerte une personne, change une lumière de statut.
-
Webhook (GET) Chaque forfait
Les mêmes champs que le webhook POST mais maintenant en tant que paramètres de requête, pour un récepteur qui accepte une requête GET.
-
PagerDuty Starter et plus
Un incident via l'Events API v2, ouvert lors d'une panne et résolu lors de la reprise, pour que l'escalade de PagerDuty prenne le relais.
-
Slack Pro et Business
Un message dans un canal, rouge pour une panne et vert pour un rétablissement, via un webhook.
-
Microsoft Teams Pro et Business
Le même message dans un canal Teams, via un webhook.
-
Discord Pro et Business
Le même message dans un canal Discord, via un webhook de canal.
-
Telegram Pro et Business
Le même message dans un chat, via ton propre bot.
Qui entend quoi, et quand
Confirmé en premier
Rien n'est envoyé sur la seule parole d'une sonde. Une défaillance devient une panne lorsque des sondes sur trois continents sont d'accord, donc une alerte signifie que le site est hors ligne plutôt qu'un problème réseau.
Règles et escalade
Une règle décrit qui est informé de quels monitors et à quel moment. Mets la liste d'astreinte dans un groupe de contacts avec un délai par membre. Cela fonctionne comme ta politique d'escalade.
Rétabli, dit une fois
Tout le monde informé de la panne est informé quand elle se termine, avec sa durée. Nous ne te réveillerons pas pour te dire que la panne est finie.
Teste avant d'en avoir besoin
Chaque adresse a un bouton qui envoie un test par le même chemin qu'une vraie alerte, formulé pour ne pas être pris pour une vraie panne.
Le webhook, pour tes propres systèmes
Une adresse webhook est une URL à toi. On l'appelle quand une panne est confirmée, quand elle se termine, et quand tu appuies sur tester. POST envoie les champs dans un corps JSON ; GET les envoie comme paramètres de requête. L'URL est stockée chiffrée et n'est plus jamais affichée en entier, car quiconque la possède peut y envoyer des requêtes.
| Champ | Ce qu'il contient |
|---|---|
| reason | down quand une panne est confirmée, recovery quand elle se termine, test quand quelqu'un a appuyé sur le bouton |
| monitor | Le nom du monitor |
| monitor_id | Son id |
| target | Ce qu'il vérifie : l'URL, l'hôte ou le nom |
| type | Le type de vérification, sous un nom court comme https, dns ou ssl_cert |
| cause | Pourquoi il a échoué, en quelques mots, quand on le sait |
| error_class | La même chose sous un nom court qu'un programme peut utiliser, comme timeout, connection ou certificate_expired |
| started | Quand la panne a commencé |
| confirmed_at | Quand l'échec a été confirmé |
| confirmed_from | Les continents qui l'ont confirmée, sous forme de liste de noms. |
| degraded | true quand le monitor est lent ou perd des paquets plutôt que down |
| resolved | Quand elle s'est terminée, comme un timestamp ISO 8601, lors d'une recovery |
| duration | Combien de temps elle a duré, en toutes lettres, lors d'une recovery |
| incident_id | L'id de l'incident, le même pour la panne et sa recovery |
Un champ sans valeur est null dans le JSON et omis dans un GET. Tu dois répondre avec un statut inférieur à 400. Tout autre statut est considéré comme un échec de livraison et sera réessayé après 30 secondes, 2 minutes et 10 minutes, puis abandonné : une alerte qui n'est pas arrivée dans un quart d'heure est de l'histoire, pas une nouvelle.