Surveillance de l'agent après réparation: rétablissement en cinq étapes

Un agent AI n'est pas récupéré simplement parce qu'un redémarrage, une nouvelle tentative ou une poussée est retournée avec succès. Le paramètre par défaut pratique pour la surveillance de agent consiste à vérifier la récupération en cinq étapes: enregistrer l'intervention autorisée, confirmer la disponibilité et la disponibilité, observer les progrès spécifiques à la tâche, vérifier le résultat promis de manière indépendante et surveiller une fenêtre de stabilité pour la récidive. Jusqu'à ce que le contrôle le plus strict applicable soit passé, conservez l'état comme recovering , uncertain ou needs human pas sain. Cette distinction est importante parce que la commande de réparation et le travail de l'utilisateur vivent à des niveaux différents. Un processus peut être redémarré tant que sa carte de crédit reste expirée. Un battement cardiaque peut reprendre pendant que l'agent répète le même appel à l'outil. Un agent peut déclarer l'achèvement alors que le fichier, le ticket, le message ou le déploiement est encore absent. La récupération est une affirmation de preuve, pas un événement d'activité. Éliminer un incident avec une échelle de vérification Utilisez une échelle au lieu d'un statut vert. Chaque étape répond à une question différente et doit préserver son propre temps, sa source et sa confiance. Pas de départ La question est posée Les preuves minimales Indiquer si elle échoue L'intervention L'action limitée exacte a t elle été autorisée et exécutée? référence d'approbation, type d'action, identifiant de tentative, résultat de sortie ou d'API needs human ou intervention failed Accès à l'information Le temps de course est il contactable et prêt à accomplir sa tâche? un rythme cardiaque frais et une vérification de préparation à la tâche unreachable ou alive only Les progrès réalisés Le travail utile a t il changé depuis l'intervention ? un artefact monotonique, une unité complète, un curseur, un delta d'essai ou un changement de destination alive only ou recovering Le résultat Le résultat promis existe t il et satisfait il à sa vérification déterministe? recherche, digestion, test, révision ou réception en provenance de destination Le système de contrôle de l'aéroport de false recovery , recovering ou uncertain Stabilité L'échec diagnostiqué a t il été absent assez longtemps pour se répéter? une fenêtre d'observation spécifique à la charge de travail sans symptôme répété relapsed ou recovered Le défaut raisonnable est conservateur: un agent qui est accessible mais n'a pas déplacé de travail utile est alive only ; un agent qui a repris le travail mesurable mais n'a pas atteint son résultat est recovering ; seule la preuve de résultat fraîche qui survit à la fenêtre de stabilité gagne recovered . Kubernetes utilise une séparation connexe pour les conteneurs. Son documentation de la sonde donne au démarrage, à la vitalité et à la préparation différents emplois: la vitalité peut déclencher un redémarrage, tandis que la préparation contrôle si un conteneur doit recevoir du trafic. Il prévient également que des sondes de vie incorrectes peuvent entraîner des pannes en cascade. L'analogie a une limiteune tâche d'agent n'est pas un Podmais le cours d'opération transfère: le processus doit être redémarré et le travail est prêt ne doit pas être le même test. Une fenêtre de stabilité n'est pas un sommeil arbitraire de cinq minutes. Choisissez l'intervalle le plus court au cours duquel l'échec initial a eu une bonne chance de revenir. Pour une boucle qui répète tous les deux appels à l'outil, observez au moins deux occasions d'appels à l'outil propres. Pour un éditeur prévu, attendez la date limite de son prochain résultat. Pour une défaillance de la carte d'identité, l'autorisation concernée doit être exercée une fois avec un contrôle non destructeur. La fenêtre doit être suffisamment longue pour falsifier la réparation, mais pas si longue que l'incident reste ambigu après l'existence de preuves décisives. Enregistrer une tentative de récupération, pas une séquence de commandes lâche Lier le diagnostic, l'autorité, l'intervention et la vérification à une identification de tentative immuable. Sinon, le moniteur peut rejoindre un battement cardiaque d'un redémarrage manuel ultérieur à un poussement automatisé plus tôt et signaler une récupération que personne ne peut expliquer. Un événement limité à la vie privée peut ressembler à ceci: Cet événement n'a pas besoin d'invitations, de réponses, de secrets, de charges utiles d'outils ou de chemins absolus. Il a besoin de la limite de l'action et de la limite des preuves. Conservez action completed comme reçu, pas comme verdict de récupération. Cette règle est particulièrement importante pour les API asynchrones. RFC 9110 section 15.3.3 dit qu'une réponse HTTP 202 Accepted signifie que le traitement n'a pas été terminé et pourrait ne jamais se produire; la réponse devrait décrire l'état actuel et indiquer un moniteur d'état. Si l'adaptateur de récupération d'un agent reçoit 202 , suivez ce moniteur ou consultez la destination. Ne traduisez pas accepté en fixé. Les traces ont la même limite de portée. OpenTelemetry définit un à longueur d'onde comme une unité de travail et son statut comme l'état de l'opération qu'il suit. Une période de restart agent propre prouve que l'opération n'a pas signalé d'erreur. Elle ne définit pas si un rapport a été produit, si un billet est arrivé ou si un déploiement sert la révision prévue. Lier la durée de l'intervention à des progrès ultérieurs et à des preuves de résultats; ne pas surcharger son statut. L'autorité appartient aussi au dossier. Si un redémarrage, un rafraîchissement des informations d'identification, l'envoi de messages ou le retour des informations nécessitent une approbation et qu'aucune approbation valide n'existe, le moniteur doit émettre needs human . Il ne doit pas tenter l'action et ensuite demander une autorisation rétrospective. Le rétablissement a aussi besoin d'une nouvelle tentative et d'un budget de temps. Une deuxième intervention après le premier échec est une nouvelle décision, pas une extension invisible du commandement initial. Reproduire le rythme cardiaque faux positif Le dispositif d'accompagnement contient huit cas synthétiques post intervention: absence d'autorité, erreur d'action, activité de rythme cardiaque uniquement, réouverture des progrès, récupération stable vérifiée, rechute, preuve de vérification périmée et fin déclarée par l'agent avec un résultat de destination manquant. Exécutez le classifiateur dans le répertoire des objets: Le résultat décisif est: La règle naïve action complétée et le rythme cardiaque présent rapporte six guérisons. L'échelle rapporte un. Ce n'est pas parce que l'échelle est pessimiste. L'un des cas est réellement recovering : des progrès utiles ont été repris et le résultat est toujours en attente. Un autre a de nouvelles preuves de résultats mais répète ensuite l'échec diagnostiqué, donc c'est relapsed . Un troisième a un résultat d'apparence vérifiée qui est de dix minutes en vertu d'un contrat de fraîcheur de deux minutes, donc c'est uncertain , pas raté ou sain. Le seuil de fraîcheur de la pièce 120 seconde est illustratif et n'est pas un défaut de production. La fraîcheur des preuves appartient au vérificateur. Une analyse des dossiers sur le stockage local peut être immédiatement décisive. Un index de recherche éventuellement cohérent peut avoir besoin d'un retard documenté. Si le vérificateur lui même n'est pas disponible, conservez uncertain et exposez le signal manquant. Ne redémarrez pas l'agent simplement pour que le tableau de bord redevienne vert. Le chapitre Surveillance des systèmes distribués de Google distingue les symptômes des causes et la boîte noire des preuves de la boîte blanche. Il traite également une réponse réussie au protocole avec un contenu incorrect comme une erreur pouvant nécessiter des tests de bout en bout. Dans cette échelle de récupération, le reçu d'intervention et la télémétrie en temps d'exécution constituent des preuves de cause en boîte blanche; la vérification des résultats natifs de destination est le test des symptômes de boîte noire. Les deux sont utiles, mais seul ce dernier résout ce que l'utilisateur a réellement perdu. Transformer la vérification de la récupération en contrat d'exploitation Pour chaque classe de tâches surveillée, définir l'échelle avant un incident: les états de défaillance permettant une intervention limitée; la personne ou la police autorisée à approuver chaque action; l'action réversible et ses limites d'effort, de temps et de coûts; la vérification de la préparation à l'exécution après l'action; un champ de progression utile avec une direction attendue; le vérificateur déterministique des résultats, sa date limite et sa limite de fraîcheur; l'opportunité de récidive qui ferme la fenêtre de stabilité; le chemin du retour ou de l'escalade lorsque la tentative échoue. Gardez le vocabulaire du verdict petit. Needs human signifie qu'une autorité, un secret ou une décision irréversible manquent. Intervention failed signifie que l'action approuvée n'a pas été achevée. Alive only signifie que le temps d'exécution est prêt mais que des progrès utiles sont absents. Recovering signifie que les progrès ont été repris pendant que le contrôle des résultats ou de la stabilité reste ouvert. Uncertain signifie que des preuves décisives manquent ou sont périmées. False recovery désigne la date limite du résultat passé sans le résultat promis. Relapsed signifie que le symptôme d'origine est retourné. Recovered signifie que le résultat spécifique à la tâche est vérifié et que la fenêtre de récurrence est restée propre. Il y a des limites honnêtes. Certains résultats ne peuvent être vérifiés de manière déterministe. Le client a accepté l'analyse peut exiger une décision humaine; le résumé est bon peut exiger une rubrique dont la fiabilité est elle même mesurée. Une destination peut également commettre un effet secondaire avant la fin des temps de réponse. Réconcilier avec une clé d'idempotence ou une recherche indépendante avant de réessayer. Lorsque les preuves ne peuvent pas résoudre l'état, gardez l'incertitude visible. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production, son analyse des coûts des jetons et son exécution de récupération ne sont généralement pas expédiés. L'orientation prévue est une couche de santé à côté des délais de fonctionnement existants qui rend explicite le diagnostic, l'autorité, la fraîcheur des preuves, les progrès utiles et la vérification des résultats. Il ne devrait pas devenir une passerelle de modèle obligatoire ou un fixateur autonome. Si ce modèle fonctionne avec vos agents, Joignez vous à l' avant première privée. Les sources Les Kubernètes: vitalité, préparation et démarrage des sondes Google SRE Book: Surveillance des systèmes distribués RFC 9110: Sémantique HTTP, 202 Acceptée Télémetry ouverte: Traces