AI Observabilité de l'agent sous le horloge Skew: Récupération de l'ordre de l'événement

Un agent AI peut produire une trace parfaitement plausible dont les timestamps racontent une histoire impossible. Un résultat de l'outil apparaît avant la demande qui l'a provoqué. Une finition atterrit avant le début de la course. Un enregistrement d'avancement retardé arrive après le résultat et rend une course terminée active à nouveau. La réponse pratique n'est pas de réparer la chronologie en triant plus durement. Ne déduisez pas l'état de l'agent à partir des timbres de l'horloge murale. Gardez quatre pièces de preuve event at , observed at , source seq et depends on et utilisez chacune pour le travail qu'elle peut réellement soutenir. Reconstruire l'ordre causal à partir des dépendances et de la séquence par source. Utilisez l'horloge du collectionneur pour la fraîcheur des preuves. Mesurer les durées à l'aide d'une horloge monotone à l'intérieur d'un processus. Si un prédécesseur requis manque, le verdict de santé est uncertain , non bloqué, sain ou complet. Cette règle est assez petite pour tester. La fixation ci dessous met deux types de troubles horlogers et une chaîne causale cassée en onze événements. Une vérification déterministe récupère deux flux de travail et refuse d'inventer un ordre pour le troisième. Un moniteur de paroi peut inverser le travail. Le travail d'agent distribué traverse les horloges: l'hôte runtime, un serveur d'outils, une file d'attente, un vérificateur et le collectionneur peuvent tous marquer la même course. La synchronisation de l'horloge réduit leur désaccord; elle ne transforme pas ces horloges en une seule autorité causale. NTP lui même modélise le décalage de l'horloge, le retard du réseau, la dispersion et la distance de synchronisation plutôt que de promettre le même temps partout (RFC 5905). Le premier flux de travail de l'appareil fixe rend le problème visible. Son horloge d'agent est rapide de 45 secondes, tandis que son horloge d'outil est lente de 30 secondes. La chaîne de dépendance réelle est: Le classement des mêmes enregistrements par event at place g3 avant g1 . Un tableau de bord construit sur cet ordre peut calculer une durée d'outil négative, afficher un résultat final avant le début ou tromper les preuves arrivant plus tard pour une nouvelle transition d'état. Aucune de ces conclusions ne résulte du travail. Ils suivent de la comparaison des horloges murales qui ont des compensations différentes. Le modèle de données de journaux stable d'OpenTelemetry préserve la distinction nécessaire ici. Timestamp est lorsque l'événement s'est produit selon l'horloge d'origine; ObservedTimestamp est lorsque le système de collecte l'a observé (Modèle de données OpenTelemetry Logs). La conservation des deux est utile, mais aucun champ n'est une clé d'ordre universelle: champs Utilisation sûre Déduction dangereuse event at Affichage de l'heure source locale; corrélation avec l'évidence de l'hôte L'ordre causal ou la latence entre hôtes observed at Fraîcheur relative au collecteur et retard d'ingestion Le temps où le travail a réellement eu lieu source seq Ordre émis par une incarnation source Ordres provenant de sources non liées depends on Les limites causelles explicites entre les sources La preuve qu'un événement omis s'est produit dépassé monotoniquement Durée d'un processus au cours de sa durée de vie Marqueur d'heure comparable entre les machines La source de l'incarnation est importante. Un compteur doit être scope par quelque chose comme (source id, boot id) , parce qu'un processus redémarré peut recommencer à la séquence 1. Un entier à l'aspect global invite une fausse alarme différente: le collecteur lit un réinitialisateur attendu comme une répétition ou une régression. La distinction entre le temps mural et monotone est également opérationnelle, pas académique. Le paquet time de Go explique que les horloges murales sont soumises à des changements de synchronisation tandis que les horloges monotones sont destinées à mesurer le temps; les valeurs retournées par time.Now peuvent contenir les deux lectures afin que les opérations de temps écoulé restent robustes lorsque le temps murale change (Les horloges sont monotones.). D'autres temps d'exécution exposent des API différentes, mais la décision reste la même: calculer une durée d'outil local à partir d'un intervalle monotonique local, puis exporter cette durée comme preuve. Ne soustraisez pas les temps de paroi de deux machines non liées et appelez le résultat de latence. Reconstruire la causalité avant de classer la santé Le contrat de l'événement est délibérément compact: dependsOn crée le bord cross source de la demande au résultat. Les valeurs sourceSeq consécutives créent des bords locaux dans un flux (source, bootId) . L'audit combine ces bords, vérifie les prédécesseurs manquants et les lacunes de séquence, puis effectue un sort topologique. Les inversions de l'horloge murale et du temps du collecteur deviennent des diagnostics attachés aux bords; elles ne réécrivent pas le graphique. Exécutez l' artefact dans son répertoire: Son résumé fixe est le suivant: Le premier flux de travail est reconstitué malgré l'inversion de l'horloge d'origine. Le second a un échec différent de l'ordre naïf: d3 atteint le collectionneur avant son prédécesseur d2 , de sorte que le tri par observed at inverse leur dépendance. Le graphique retrouve toujours l'ordre prévu. Le troisième flux de travail contient un résultat de l'outil qui nomme b missing request , un événement absent de l'ensemble de preuves. Il semble également terminal avant début sous une sorte de mur horloge, mais l'audit ne le répare pas en devinant. Son statut est uncertain . Ce qui produit une décision utile pour la santé de l'agent: 1. Validate l'identité. Rejeter les identifiants d'événements dupliqués et les numéros de séquences de portée à une incarnation source. 2. Construire des bords locaux. Les valeurs de séquence source consécutives établissent l'ordre d'émission; un écart est une perte de preuve, pas une autorisation pour fermer l'écart. 3. Construisez des bordures cross source. Joignez vous aux demandes, aux résultats des outils, aux travaux délégués, aux approbations et aux vérifications des résultats avec des identifiants de prédécesseurs explicites. 4. Reject a inventé la certitude. Un prédécesseur manquant, une lacune de séquence ou un cycle rendent le verdict affecté incertain. 5. Order le graphique admissible. Sortir topologiquement la partie complète; conserver les inversions de l'horloge murale comme preuve de la qualité de l'horloge. 6. Classifier l'état seulement maintenant. Appliquer les règles de travail, d'attente, de blocage et de résultat à l'ordre causal plutôt qu'à l'ordre d'arrivée. Cela distingue l'activité des progrès utiles. Un rythme cardiaque tardif peut être frais chez le collectionneur mais causellement plus ancien qu'un résultat déjà vérifié. Il ne devrait pas rouvrir la course. Un résultat d'outil peut être observé récemment mais dépend d'une demande que le collectionneur n'a jamais vue. Il ne devrait pas prouver l'achèvement. Un événement d'approbation humaine peut légitimement laisser une course en attente même si aucun nouvel événement d'exécution ne suit; la dépendance nomme le bloqueur. Un détail de mise en œuvre empêche de nombreuses régressions accidentelles: rendre le réducteur de santé monotone là où le contrat de flux de travail le permet. Une fois que le résultat invoice 42 est vérifié indépendamment pour exécuter r7 , un événement tool requested plus ancien ne peut pas réduire ce résultat à working. Il peut mettre à jour le registre des preuves, révéler un retard de livraison ou soulever un problème de qualité de télémétrie, mais il ne peut pas effacer un fait vérifié plus fort. Traitez le temps comme une preuve avec une limite. La reconstruction causale n'est pas un remplacement de la synchronisation de l'horloge. Vous avez toujours besoin d'hôtes synchronisés pour les délais d'incidents lisibles, la validation des certificats, le comportement du planificateur et la corrélation opérationnelle. La règle empêche tout simplement le modèle de santé de prétendre plus que ces horloges ne prouvent. Il a aussi quatre limites nettes. Tout d'abord, observed at n'est autoritaire que par rapport au collectionneur qui l'a imprimé. Les files d'attente, les tentatives répétitives, la contrainte et les défaillances du collecteur peuvent augmenter le retard observé. Utilisez le pour demander depuis combien de temps ce collecteur a vu des preuves admissibles? Ne signalez pas automatiquement observed at event at comme latence réseau. Deuxièmement, un graphique de dépendance est seulement aussi complet que son instrumentation. Un prédécesseur manquant peut signifier la perte de paquets, le prélèvement d'échantillons, un bug de l'exportateur ou un producteur qui n'a jamais émis l'événement. Le résultat sûr est l'incertitude plus un manque de preuves nommé. Ce n'est pas la preuve que l'agent a échoué. Troisièmement, l'ordre causal ne permet pas de vérifier le résultat prévu. tool succeeded dit que l'outil est retourné avec succès sous son propre contrat. Il ne prouve pas que le fichier existe à la destination, que le courrier électronique a atteint le destinataire souhaité ou que le déploiement sert la version attendue. Gardez la vérification des résultats comme un événement séparé avec ses propres preuves. Quatrièmement, l'ordre topologique peut être partiel. Les branches indépendantes peuvent ne pas avoir d'ordre significatif entre elles. N'en fabriquez pas pour une plus belle chronologie. Présenter des branches concurrentes ensemble et exiger un quorum explicite de rejoindre ou de compléter avant de déclarer le parent complet. L'affirmation falsifiable pour cet article est étroite: pour le dispositif fourni à onze événements, l'audit doit reconstruire deux flux de travail, marquer l'incertitude de la chaîne brisée, conserver une inversion du temps d'origine et une inversion du temps de collecteur comme diagnostic, et exposer les deux cas naïfs de terminaux avant le démarrage. Si l'un de ces chiffres change, l'artefact échoue. Ce que cela signifie pour Sidewisp Le Sidewisp est destiné à ajouter une couche de santé autour des temps d'exécution des agents existants: distinguer les états de travail, d'attente, de blocage, d'incertitude et de vérification des résultats en utilisant des preuves avec fraîcheur et confiance. Les preuves causales conscientes de l'horloge correspondent à cette direction parce qu'une trace verte n'est pas utile si son ordre a été déduit à partir d'horloges incompatibles. Sidewisp est actuellement en préversion privée. Le site public et le système d'articles sont en direct, mais la collecte de l'agent de production santé, les adaptateurs de temps d'exécution, la gestion du cron, l'analyse des coûts des jetons et la récupération ne sont généralement pas expédiés. Cet article décrit un modèle d'exploitation et un artefact d'essai, et non une affirmation selon laquelle Sidewisp reconstruit actuellement les délais de production ou corrige la déformation de l'horloge. Le produit prévu n'est pas un système de remplacement, une passerelle obligatoire, un produit de traçage brut, un avion de contrôle d'entreprise ou un fixateur autonome. Il devrait être à côté des agents existants, montrer de l'incertitude lorsque la chaîne est incomplète et conserver l'autorité humaine sur toute action de récupération. Si l'horloge et le désordre de livraison cachent l'état réel de vos agents, rejoindre l'aperçu privé est la prochaine étape restreinte; ce n'est pas une promesse que la surveillance de la production soit disponible aujourd'hui. Le défaut opérationnel est donc simple: préserver le temps d'origine pour le contexte, le temps de collecte pour la fraîcheur, le temps écoulé monotone pour les durées locales et les limites explicites pour la causalité. Quand ces bords sont incomplets, dites le. Un uncertain honnête est plus sain qu'une fausse histoire magnifiquement triée.