Surveillance de l'agent pour le travail prévu: construire une enveloppe d'exécution prévue

La surveillance des agents pour le travail prévu devrait commencer par une question: a t il commencé, terminé et produit le résultat promis dans sa fenêtre autorisée? Une sortie verte du processus, un battement cardiaque récent et une trace complète ne peuvent pas répondre à cette question seuls. Le défaut pratique est une enveloppe expected run . Pour chaque événement, consignez l'heure prévue, un délai de démarrage autorisé, un délai maximum d'exécution et une date limite pour la vérification du produit livré. Gardez ces timestamps séparés. Une tâche peut être en attente légitime, être en retard pour commencer, continuer à travailler, être en retard, être dupliquée ou terminée sans résultat. L'effondrement de ces états en running et failed crée des alertes bruyantes et cache un faux succès. Ce guide construit cette enveloppe comme un contrat neutre en temps d'exécution. Le dispositif de neuf cas inclus est synthétique, pas une preuve de production, mais il est exécutable et expose les décisions qu'un système de surveillance doit prendre. Ancrer l' enregistrement à l' événement prévu Ne déduisez pas le temps attendu à partir de la première ligne. Obtenir l'heure prévue de l'événement du planificateur et la conserver comme scheduled at . Kubernetes 1.32 et plus tard ajoute batch.kubernetes.io/cronjob scheduled timestamp aux Jobs créés. Google Cloud Scheduler envoie X CloudScheduler ScheduleTime , qui reste constant lors des tentatives de réessayer. Ces valeurs survivent à un début tardif et rendent les tentatives réessayées attribuables au même événement. Utilisez une clé de fente stable: Alors gardez ces champs: Le outcome ref doit identifier les éléments de preuve et ne pas contenir le produit délicat. Il pourrait s'agir d'un hash, d'une version d'objet, d'un identifiant de test ou d'une clé de ligne de base de données. Un fichier généré simplement existant peut ne pas être suffisant; la vérification doit correspondre à la promesse réelle, comme todays bref existe, a cinq éléments cités, et est stocké à la destination attendue. Le contrat de planification est important car l'exécution n'est pas nécessairement une seule fois. Kubernetes documente qu'un CronJob peut parfois créer deux emplois ou aucun emploi et conseille des charges de travail idempotentes. Cloud Scheduler décrit au moins une livraison et exige également des cibles idempotentes. La surveillance doit donc traiter les démarches dupliquées comme un état de première classe et non comme une anomalie impossible. Calculer trois délais, pas un délai Définir l'enveloppe avec trois limites indépendantes: Les valeurs devraient provenir de répartitions de temps d'exécution observées et des exigences de l'entreprise, et non d'un préréglage universel. Une tâche prévue à 9h00 peut être parfaitement saine quand elle commence à 9h40. Le même retard de 40 secondes peut violer une promesse de dépêche de moins de minutes. Amazon EventBridge Scheduler, par exemple, documente la précision de l'invocation de 60 secondes; traiter la seconde 01 comme late aurait mal interprété le contrat du scheduler. Les trois limites répondent à différentes questions: État Les preuves Réponse de l'opérateur waiting for start Il n'y a pas de course, mais start deadline n'a pas passé Attends ! missed start Aucune course n' existe après start deadline Vérifiez le calendrier et la facilité d'accès running Une course est active avant finish deadline Laissez le tranquille. overrun La course active a passé finish deadline Vérifiez les progrès avant d'interrompre outcome pending Le processus est terminé; la fenêtre de vérification reste ouverte Attendez le vérificateur outcome missing Délais de vérification passé sans preuve Enquêter sur le faux succès duplicate start Plus d'une course revendique la même clé Contient des effets indésirables; inspecter la cause des essais répétés healthy Le résultat promis a été vérifié. Fermez l'événement suspended Une pause de maintenance ou d'approbation explicite couvre l'espace Supprimer les échecs; conserver les preuves d'audit Cet ordre prévient deux erreurs courantes. Premièrement, l'absence n'est pas un échec tant que le délai applicable n'a pas expiré. Deuxièmement, l'achèvement d'un processus n'est pas l'achèvement d'une tâche. Une course qui sort à 09:06 peut rester outcome pending jusqu'à la fin de son téléchargement, de son test ou de sa vérification de destination. Il ne devient outcome missing qu'après l'expiration de cette fenêtre de grâce séparée. Un cambriolage n'est pas non plus la permission de tuer un agent. Vérifiez si des progrès utiles sont toujours en cours, s'ils attendent un système externe et si l'interruption est réversible. L'enveloppe indique où l'attention est justifiée; elle ne prend pas la décision de récupération. Reproduire le classifiant avec neuf cas maladroits L'artefact d'exécution évalue les fixations délimitées à nouvelle ligne avec un classificateur déterministe. Faites le avec: L'appareil utilise une grâce de départ de deux minutes, un temps d'exécution maximal de dix minutes et une grâce de deux minutes. Le résultat est le suivant: Le classifiant de base est délibérément petit: Cette expérience démontre la valeur des limites explicites, mais elle ne prouve pas que les seuils choisis correspondent à une vraie charge de travail. Il suppose également qu'un planificateur effectue des cartes de l'événement en toute clarté sur un seul espace. Le ventilateur d'événements, le travail historique reproduit manuellement et les tâches avec plusieurs livrables requis nécessitent un modèle d'identité élargi. Manœuvrer des duplicates, des chevauchements, des fuseaux horaires et des pauses explicitement Les retries et les chevauchements sont liés, mais pas identiques. Une nouvelle tentative peut se reproduire après une défaillance du transport. Un chevauchement peut commencer la prochaine fente pendant que la précédente est encore active. Retenez à la fois slot key et run id , puis appliquez le comportement de simulation déclaré par le planificateur. Kubernetes expose les politiques de concurrence Allow , Forbid et Replace . En vertu de Forbid , un événement manqué alors que le poste précédent est actif est considéré comme manqué. Sous Replace , la nouvelle occurrence déplace l'ancien Job. Votre état de surveillance devrait préserver cette raison, sinon un remplacement intentionnel ressemble à un accident. Pour les tâches d'effets secondaires, déduplicer sur la clé de la fente à destination ainsi que sur le moniteur. Une seconde "exécution réussie" peut envoyer une deuxième facture, surécrire un rapport plus récent ou publier le même message deux fois. Le moniteur peut exposer le risque, mais l'idempotence appartient à la charge de travail et au contrat de destination. Les fuseaux horaires ont besoin d'une règle tout aussi explicite. Conserver les timestamps d'événements en UTC tout en conservant l'identifiant de fuseau horaire de l'IANA et l'expression originale du calendrier. Les transitions qui économisent la lumière du jour sont spécifiques au programmeur. EventBridge Scheduler documentait qu'une heure locale inexistante pendant le printemps avant est sautée et une heure locale répétée pendant l'automne retour court une fois. Ne synthétisez pas un événement " manqué " que le planificateur n'a jamais promis. Enfin, les pauses doivent être modélisées et non cachées en désactivant les alertes. Enregistrez qui a fait une pause dans l'horaire, pourquoi, le début et l'expiration de l'horaire, et si le rattrapage est attendu. Kubernetes note que les occurrences de CronJob suspendues sont considérées comme manquées et peuvent être exécutées immédiatement après la suspension lorsqu'aucune date limite de démarrage n'est fixée. Un moniteur qui oublie la pause peut inonder l'opérateur précisément lorsque la maintenance est terminée. Transformer l'enveloppe en une règle de fonctionnement silencieuse Commencez par un agent critique, pas chaque trace: 1. Lisez l'horodatage, le fuseau horaire, la politique de réessayer et la politique de synchronisation. 2. Assurez vous d'assigner une clé avant le début du travail et de la conserver pendant les tentatives répétées. 3. Choisissez start grace , max runtime et outcome grace parmi les exigences réelles et les durées observées. 4. Définir un vérificateur déterministique des résultats. 5. Reprenez l'histoire récente à travers les neuf États avant d'activer les notifications. 6. Page uniquement lorsqu'une promesse pertinente à l'utilisateur est en dehors de son enveloppe; garder waiting for start , running et outcome pending visibles mais silencieux. Réviser les seuils après changements d'horaire, de modèle, d'outil ou de destination. Un modèle plus grand peut augmenter le temps d'exécution sans modifier la précision. Une API externe plus lente peut prolonger la vérification des résultats. La dérive des seuils est une dette de configuration, pas une preuve qu'un agent est devenu peu fiable. Ce contrat fixe également une limite de données utile. Vous avez besoin de timestamps, d'identifiants stables, d'état et d'une référence à des preuves de vérification. Vous n'avez pas besoin d'instructions automatiques, de réponses, de charges utiles d'outils ou de traces complètes. Ne les collectez que si un diagnostic les nécessite et si votre politique de confidentialité le permet. Le Sidewisp est destiné à transformer des signaux tels que des horaires manqués, des stands, des défaillances d'outils et des résultats manquants en une vue prioritaire de la santé avec des preuves explicites et des limites d'approbation. Le moteur de surveillance de la production et les adaptateurs de temps d'exécution ne sont généralement pas expédiés aujourd'hui. Sidewisp est actuellement en préversion privée. Si ce contrat prévu correspond à une défaillance que vous exploitez, l'inscription à l'avant première privée est la prochaine étape restreintenon une affirmation selon laquelle Sidewisp surveille déjà vos agents en direct. Sources primaires Documentation du travail de Kubernetes CronJob timestamps programmés, délais de démarrage, politique de concurrence, suspension, création approximative et idempotence. Vue d'ensemble du Google Cloud Scheduler à la livraison au moins une fois, comportement de réessayer, idempotence, et l'en tête de temps planifié stable. Types de calendrier de planificateur d'événements AmazonBridge précision d'invocation, fuseaux horaires et comportement d'économie de lumière du jour.