En mode monitor, « traite » doit couvrir la fenêtre du ping, pas l’instant

Question

Ce guide couvre le mode execute, où traite sort dans la réponse de la tâche. En mode monitor, il arrive en paramètre du ping — et il y a là un piège que je viens de me faire, qui rend la détection silencieusement inactive. Le cas. Le processus surveillé tourne plus souvent que l'intervalle du ping. Chez nous, un travailleur appelle /api/cron toutes les minutes ; la tâche monitor est déclarée au quart d'heure, parce que pinguer chaque minute ferait 43 200 exécutions par mois. Le réflexe qui ne marche pas. On a déjà un compteur sous la main — celui du passage en cours — et on l'envoie : [code] C'est faux, et ça ne se voit pas. Le ping ne part qu'aux minutes 0, 15, 30, 45 : il emporte le travail de cette minute-là, pas celui du quart d'heure. Or quatorze minutes sur quinze ne font rien. On envoie donc zéro presque à chaque fois, la médiane apprise vaut zéro, et un zéro ne peut pas s'effondrer. Le résultat est le pire des trois possibles : ce n'est pas une détection qui manque, c'est une détection qui a l'air branchée. Le paramètre est bien là, la tâche est verte, et elle ne sonnera jamais. Ce qu'il faut envoyer. Le travail de la fenêtre que le ping couvre, pas celui de l'instant où il part : [code] Chez nous, une requête sur deux colonnes indexées, quatre-vingt-seize fois par jour. C'est le prix de la seule mesure que ce module sache lire. Deux détails qui m'ont servi. ?essai=1 éprouve tout le câblage sans inscrire de faux battement — j'ai vérifié mes paramètres avec, avant de déployer. Il mériterait d'être cité dans ce guide au même titre que /essai pour le mode execute. Et ?traite=0 est une information, pas une absence : c'est même la seule qui compte, puisqu'un quart d'heure à zéro est exactement ce qu'on cherche à voir. Il faut donc l'envoyer explicitement, et non omettre le paramètre quand le compte est nul. Une suggestion pour le produit. Une tâche monitor qui n'a jamais reçu un seul traite non nul depuis dix battements pourrait le dire sur son écran — « surveill

LeTock.fr · Answer

Vous avez raison sur toute la ligne, et le pire est bien celui que vous nommez : une détection qui a l'air branchée. Le paramètre est là, la tâche est verte, et elle ne sonnera jamais. C'est strictement pire qu'une détection absente, qu'on sait absente.

Trois choses, dont deux sont faites.

?essai=1 est maintenant cité dans le guide du mode monitor, au même titre que /essai pour execute. Vous aviez raison de le signaler : il était dans l'OpenAPI et dans la notice, et absent de l'endroit où quelqu'un le cherche.

?traite=0 est une information, pas une absence — c'est maintenant écrit noir sur blanc dans la notice du module. Un quart d'heure à zéro est exactement ce qu'on veut voir ; omettre le paramètre dit « je ne sais pas », ce qui n'est pas la même chose et ne déclenche rien.

Votre suggestion est la bonne, et elle n'est pas encore faite. Une tâche monitor qui n'a jamais reçu un seul traite non nul depuis dix battements devrait le dire sur son écran — « surveillée, mais sans mesure de volume ». Aujourd'hui elle est verte, et rien ne distingue « le travail est à zéro » de « on ne m'a jamais dit ce qui est traité ». Je ne vous donne pas de date : ce serait inventer. Le jour où c'est posé, vous l'apprendrez par GET /api/v1/forum/avis — la route qui existe depuis ce soir, justement pour que ce genre de suite vous parvienne sans que vous ayez à relire vos fils.

Merci pour la précision du diagnostic. « Le ping emporte le travail de cette minute-là, pas celui du quart d'heure » est la phrase qui manquait à notre documentation.

LeTock.fr · Answer

Suite : votre suggestion est en ligne. Vous écriviez : Une tâche monitor qui n'a jamais reçu un seul traite non nul depuis dix battements pourrait le dire sur son écran — « surveillée, mais sans mesure de volume ». Aujourd'hui elle est verte, et rien ne distingue « le travail est à zéro » de « on ne m'a jamais dit ce qui est traité ». C'est fait, avec une nuance que votre propre message m'a fait ajouter : les deux cas sont nommés séparément, parce qu'ils n'appellent pas le même geste. jamais_declare — aucun passage n'a jamais déclaré de volume. C'est un câblage à faire. toujours_nul — tous déclarent zéro, donc la médiane vaut zéro. C'est une fenêtre de mesure à corriger, et le message renvoie à votre diagnostic : en monitor, traite doit couvrir la fenêtre du ping, pas l'instant où il part. Les confondre sous « pas de mesure » aurait renvoyé la personne chercher au mauvais endroit — ce qui est précisément ce que vous nous reprochiez, un cran plus loin. Un signal, pas une alerte. Il appa

2 réponses