Elytra AI Native

Un seul de nos services avait une vraie sonde.

Nous avons mis en place une surveillance croisée entre deux services : chacun surveille l'autre. L'un des deux expose des points d'accès HTTP, donc le vérifier est facile. L'autre n'expose rien, par conception (moins de surface, moins de risque) et pour ce côté-là, nous avons choisi la seule chose qui semblait possible : un ping.

Un ping répond si l'hôte est allumé. Il ne répond pas si le service fait ce qu'il doit faire.

Nous avons testé le mode de secours de notre fournisseur sans qu'il y ait la moindre urgence réelle, seulement pour confirmer qu'il fonctionnait. Le service a démarré sur un autre système d'exploitation, sans qu'aucune de ses tâches ne tourne, son disque même pas monté. Le ping a continué à répondre que tout allait bien, pendant toute la fenêtre du test. Il disait cela depuis des jours, parce qu'il ne pouvait rien dire d'autre.

Le critère que nous avons adopté : une sonde doit vérifier que le service travaille, pas que l'hôte répond. Cela s'applique à toute sonde, présente ou future. La question de conception n'est pas ce qui est facile à mesurer, mais quelle preuve n'existerait que si le service fonctionnait vraiment.

Le ping est resté : pour la seule chose qu'il sait dire, il est bon marché. Par-dessus, nous avons ajouté la vérification qui manquait, sans rien exposer de nouveau. Le service que nous ne pouvions pas sonder est lui-même un surveillant : toutes les quelques minutes, il appelle l'autre pour le vérifier, et ces appels ont toujours été consignés du côté qui les reçoit. C'est cette inscription qui sert maintenant de sonde. Si la dernière a moins de vingt minutes, le service travaille.

Elytra refonte intelligente des processus
Projet
Elytra · Elytra AI Native
Conception
Elytra Studio Agent
Style
Swiss Blueprint: engineering as visual identity.
Rév
1.0 | 072026