Des alertes que vous pouvez auditer

Les canaux

• E-mail — ce qui s'est passé, depuis quand, quelles régions de sondes l'ont confirmé, et un lien direct vers la sonde.
• Telegram — via un bot qu'okokumo exploite, donc la configuration se résume à appuyer sur Connecter puis sur Start, sans avoir à enregistrer votre propre bot.
• Slack — un webhook entrant que vous collez, livré en blocs formatés, avec un envoi de test depuis l'interface.
• Discord — un webhook entrant que vous créez dans votre propre serveur (Salon → Modifier le salon → Intégrations → Webhooks), collé de la même façon. Les alertes arrivent en embed — rouge en panne, vert au rétablissement, gris en pause — avec le changement d'état, l'heure, la raison et la cible, et le titre renvoie à la sonde. Rien à installer, aucun bot à inviter.
• Webhook — du JSON signé en HTTPS vers n'importe quel point d'entrée, réessayé avec temporisation, avec une charge utile documentée. Chaque livraison porte une signature HMAC pour que le destinataire puisse vérifier qu'elle vient bien de nous.

Il n'y a ni SMS ni appel téléphonique. Les deux figurent sur la liste de ce que ce produit ne fait pas.

Un canal ne reçoit rien avant d'être confirmé

Ajouter un canal se fait en deux étapes, pas une. L'e-mail se valide quand vous cliquez sur le lien envoyé à cette adresse ; le webhook, Slack et Discord se valident dès qu'une livraison de test réussit. Jusque-là le canal existe mais reste en attente, et un canal en attente ne reçoit rien.

C'est volontaire, et cela vaut la peine d'être compris plutôt que contourné : cela garantit qu'une alerte ne part jamais vers une destination que personne n'a confirmée — une adresse mal orthographiée, un webhook qui n'a jamais été joignable, un canal Slack supprimé. Le prix à payer, c'est qu'une sonde peut tomber sans vous prévenir si son seul canal n'a jamais été confirmé — ce qui est exactement la raison d'être du journal de livraison ci-dessous, qui le dit.

Le routage

Les canaux peuvent être rattachés à des sondes précises, ou laissés comme canal par défaut de l'organisation, qui couvre tout. L'API destinée aux clients peut donc réveiller un téléphone via Telegram pendant qu'une tâche de nuit écrit dans un salon Slack que personne ne regarde à 3 h du matin.

Un incident, une alerte

Un passage en panne n'envoie qu'une fois. Tant que l'état ne change pas, rien n'est renotifié — un service en panne pendant six heures ne produit pas six heures de messages, parce qu'un canal qui crie au loup finit en sourdine, et un canal en sourdine est pire que pas de supervision du tout. Le rétablissement envoie sa propre notification, pour que le silence n'ait jamais à être interprété.

En dessous, une panne doit être confirmée par une seconde région européenne indépendante avant que tout cela commence. Comment cela fonctionne →

Ce que personne d'autre ne vous montre

app.okokumo.com/checks/api

Chaque sonde tient un journal de livraison : ce qui a été envoyé, vers quel canal, quand — et ce qui a été ignoré, avec la raison. Dédupliqué parce que l'état n'avait pas changé. Ignoré parce que le canal était encore en attente. Échoué parce que le point d'entrée a renvoyé une 500.

Tous les produits de supervision affirment qu'ils vous alertent. Voilà l'affirmation que l'on peut vérifier, et c'est pourquoi ce journal est une fonctionnalité et non une table interne.

Via l'API

Les alertes d'une sonde sont lisibles via l'API REST versionnée avec une clé d'organisation, aux côtés des sondes, des statuts et des résultats. Documentation →