Observabilité multi-agents : auditer la topologie de coordination

L'observabilité multi agents devrait répondre à une question plus stricte que « est ce que chaque période enregistrée est terminée ? » Il devrait vous indiquer si les agents qui ont réellement participé et les itinéraires qu'ils ont réellement utilisés correspondent à la conception de coordination approuvée pour cette exécution. La valeur par défaut pratique est un contrat de topologie versionnée : un petit manifeste des agents autorisés, des bords dirigés autorisés et des bords attendus dans la phase d'exécution en cours. Joignez ce manifeste aux reçus d'interaction sans contenu. Une trace réussie peut alors être classée comme fonctionnelle, en attente, incomplète, dangereuse, ambiguë ou faussement complète au lieu de devenir verte par défaut. C’est important car une trace enregistre ce qui s’est passé. Il ne peut pas contenir une période pour une délégation requise qui n'a jamais eu lieu. Il ne peut pas non plus décider qu'un itinéraire direct observé était interdit à moins que vous ne fournissiez le graphique prévu. La même distinction apparaît dans les directives d'architecture actuelles : le modèle Microsoft architecture de référence multi agents appelle les flux de messages inter agents et les modèles de coordination comme des signaux d'observabilité spéciaux, tandis que le Azure Architecture Center prévient que l'orchestration multi agents ajoute une surcharge de coordination et de nouveaux modes de défaillance. Utiliser la complexité la plus faible qui satisfait de manière fiable la tâche ; lorsque plusieurs agents sont justifiés, rendre leur topologie testable. Une trace ne peut pas prouver la topologie prévue API de traçage de OpenTelemetry fournit les primitives de corrélation appropriées : trace et étendue de l'identité, de la filiation, des liens, des événements, des horodatages, des attributs et du statut. Ces primitives peuvent décrire une arborescence d'appels observée ou une relation asynchrone. Ils ne déclarent pas quels agents étaient autorisés, quelle version de route était active ou quel Edge aurait dû apparaître mais ne l'est pas. Supposons qu'un orchestrateur délègue la recherche, que le chercheur remette des preuves à un vérificateur et que ce dernier rende un verdict. Chaque événement observé peut avoir status: "ok" dans au moins cinq mauvaises situations : l'exécution a utilisé la politique de routage d'hier ; le chercheur a appelé directement un éditeur, sans passer par l'examen ; un agent non enregistré est entré dans le graphique ; l'orchestrateur a délégué deux fois le même itinéraire détenu ; le parent a déclaré l'achèvement avant le retour du vérificateur. Une requête « tous les événements OK » ne voit aucune erreur dans ces enregistrements. Un audit de topologie compare plutôt deux ensembles : Gardez cette couche sans contenu. Un reçu nécessite des identités d'exécution et d'agent stables, le type d'itinéraire, la version de la topologie, l'identité de l'événement, l'heure d'observation et l'état local. Il n'a pas besoin d'invites, de réponses, de secrets, d'arguments d'outil ou de chemins de fichiers absolus. Le contrat est délibérément distinct du quorum d'achèvement du déploiement. Un quorum demande si les branches requises sont retournées. Un graphique d'attente demande quelle dépendance bloque la progression. Un reçu de transfert durable demande si la responsabilité a survécu à une file d'attente ou à une limite de redémarrage. La conformité de la topologie pose une question préalable : est ce même le graphe de coordination que nous avions l'intention d'exécuter ? Construire un contrat de coordination versionné Commencez par des identités explicites et des bords dirigés. Ne déduisez pas le graphique autorisé à partir de ce qui apparaît dans la dernière trace ; cela ne fait que bénir la dérive après coup. L'ensemble autorisé n'est pas le même que l'ensemble attendu. Une phase de recherche uniquement pourrait s'attendre à deux délégations et à aucun avantage pour les éditeurs. Une phase de publication complète peut s'attendre au transfert de la recherche, au retour du vérificateur, à la délégation de l'éditeur et au retour de l'éditeur. Épinglez cet ensemble spécifique à la phase lorsque l’exécution commence. Sinon, un avantage facultatif peut devenir discrètement obligatoire au milieu d’un échec, ou un avantage requis peut disparaître de la définition avant que quiconque ne le remarque. Un classificateur compact peut utiliser cette priorité : 1. contrat périmé — la version de l'événement diffère de la version épinglée ; 2. agent inconnu — l'un ou l'autre point d'extrémité se trouve en dehors de l'ensemble d'identités approuvé ; 3. bord interdit — l'itinéraire dirigé et le type d'interaction ne sont pas autorisés ; 4. itinéraire ambigu — le même bord possédé apparaît plus d'une fois sans règle de multiplicité explicite ; 5. faux complet — un terminal parent ne dispose pas d'un avantage attendu ou d'un reçu de résultat vérifié ; 6. en attendant — une arête attendue est absente, la dépendance nommée est explicite et le délai n'est pas dépassé ; 7. incomplet — un front attendu est toujours absent après son échéance ; 8. en bonne santé ou travaillant — l'ensemble observé correspond au plan actuel, le « sain » étant réservé à un résultat final vérifié. La commande est importante. Si un agent fantôme utilise une route interdite et que le parent est également en retard, « incomplet » est trop faible : l'opérateur doit d'abord contenir une topologie non approuvée. A l’inverse, une attente déclarée avant son échéance n’est pas une impasse. Il s’agit d’un état de dépendance sain qui devrait atteindre le bon propriétaire sans déclencher une réinitialisation destructrice. Le routage dynamique est la principale limitation. Un système peut légitimement choisir parmi des agents spécialisés au moment de l'exécution. Représentez ce choix sous la forme d'une classe Edge limitée ou produisez le plan d'exécution exact avant l'expédition. Un caractère générique tel que orchestrator est facile à entretenir mais supprime la majeure partie de la valeur diagnostique. Les modifications de version doivent être auditables et une exécution ne doit jamais adopter silencieusement une nouvelle version à mi parcours. L'échantillonnage est une autre limite. Des traces lourdes peuvent être échantillonnées, mais les reçus de topologie compacte utilisés pour les décisions de santé ne peuvent pas disparaître dans le cadre de la même politique. Si un reçu requis n'est pas disponible, signalez le uncertain ou incomplete ; ne reconstruisez pas le vert à partir d’une trace partielle. Rejouez la dérive avant de faire confiance à l'achèvement J'ai relu neuf cas sans contenu contre le contrat ci dessus. Le problème comprenait un achèvement sain, un travail en cours, une attente légitime, un bord manqué après la date limite, une topologie obsolète, une route directe interdite, un agent inconnu, une propriété de route en double et un terminal parent sans accusé de réception. L’audit déterministe correspondait aux neuf états attendus. Une règle naïve : au moins un événement existe, chaque statut d'événement local est ok , et le parent n'a pas échoué marqué les neuf caisses sont vertes . Un seul était en bonne santé. Six de ces neuf verts naïfs étaient dangereux, incomplets, périmés, ambigus ou faussement complets ; les deux autres travaillaient et attendaient, ce qui ne devrait pas s'effondrer en parfaite santé. Cas Tous les événements enregistrés, OK ? Verdict de topologie Signification de l'opérateur : Graphique complet et reçu des résultats Oui healthy Le graphique prévu et le résultat final sont vérifiés Bords actuellement planifiés Oui working Un travail utile peut se poursuivre ; n'intervenez pas Retour manquant avant la date limite Oui waiting Notifier ou observer la dépendance nommée Même retour manquant après la date limite Oui incomplete Étudier le premier bord absent attendu Ancienne version de topologie Oui stale contract Arrêtez de comparer l'exécution avec la mauvaise conception Itinéraire direct non approuvé Oui forbidden edge Contenir l'itinéraire avant de réessayer de travailler Participant inconnu Oui unknown agent Vérifier l'identité et l'autorité Itinéraire détenu en double Oui ambiguous route Réconcilier la propriété et les éventuels effets de duplication Terminal parent, retour absent Oui false complete Rouvrez la course ; l'achèvement manque de preuves requises Vous pouvez reproduire la décision avec une petite fonction sur des touches de bord normalisées : Exécutez les vérifications de topologie avant l’évaluation de la progression, de la qualité ou des résultats. Gardez ensuite les limites du verdict explicites : la conformité topologique prouve uniquement que la forme de coordination approuvée a été respectée ; working nécessite de nouvelles preuves d’un mouvement utile, pas simplement davantage d’événements ; waiting nécessite une dépendance et une date limite nommées ; healthy l'achèvement nécessite une destination déterministe ou un reçu livrable lorsqu'il y en a un disponible ; les preuves incertaines doivent rester incertaines ; toute récupération active nécessite une autorité, une visibilité et une vérification post action limitées. Cela donne à un opérateur une règle d’adoption étroite : ne faites pas confiance à une réalisation multi agents tant que la topologie épinglée de l’exécution, la phase actuelle et la réception du résultat final ne sont pas d’accord. Un graphique correspondant est une preuve nécessaire et non une preuve que la réponse est correcte. Sidewisp est actuellement en préversion privée. Son site public à accès anticipé et sa démonstration interactive sont en direct, mais un adaptateur de surveillance multi agents de production, un collecteur de santé en direct et un exécuteur de récupération automatisé ne sont pas livrés. Le rôle prévu de Sidewisp est d'ajouter une couche de santé autour des environnements d'exécution existants et de faciliter l'inspection des preuves, de la gravité, de l'incertitude et de la prochaine action la plus sûre, et non de remplacer le moteur d'exécution ou d'agir sans l'autorité humaine.