Observabilité de l'agent pour la famine en file d'attente: âge de la piste

L'observabilité de l'agent ne devrait pas qualifier une file d'attente de malsaine simplement parce qu'elle est longue. Il devrait se demander combien de temps la plus ancienne tâche runnable a attendu, si un travailleur est accessible, si un espace est libre et si des résultats vérifiés arrivent toujours. Ces faits distinguent une dépendance légitime d'une capacité insuffisante, d'un travailleur mort, d'une tâche empoisonnée ou d'un expéditeur qui a cessé de lui confier des tâches. La méthode par défaut est d'enregistrer eligibleAt pour chaque tâche et d'alerter lorsque now eligibleAt dépasse l'objectif de départ de cette classe de tâches. Ne démarrez pas l'horloge tant qu'une dépendance déclarée ou un délai de réessayer est toujours valide. La profondeur de la file d'attente reste un contexte utile, mais l'âge de course est le signal de décision. La profondeur de la file d'attente est le contexte, pas un diagnostic Un compte est comprimé à la différence des États. Dix tâches peuvent être en attente d'approbation humaine, prêtes à commencer, déjà louées à des travailleurs, retardées par un retard ou échouant à plusieurs reprises. Traiter les dix comme un seul arriéré rend une file d'attente chargée fragile et peut cacher une vieille tâche derrière un petit compte. Les services de file d'attente eux mêmes exposent la limitation. Amazon SQS publie à la fois ApproximateNumberOfMessagesVisible et ApproximateAgeOfOldestMessage , et étiquette de nombreuses valeurs approximatives en raison de son architecture distribuée. Google Pub/Sub est plus explicite dans son orientation de suivi: le nombre absolu de messages non reconnus n'est pas nécessairement significatif, tandis qu'un petit backlog constant avec une vieille époque de messages en constante croissance peut indiquer des messages bloqués. Pour le travail d'agent, l'âge des messages bruts est encore trop grossier. Une tâche qui a été mise en file à 09h00 mais bloquée par une approbation jusqu'à 10h00 ne devrait pas dépenser une heure de son budget initial avant d'être éligible. Définir: Laissez eligibleAt absent pendant qu'une dépendance limitée est ouverte. Enregistrer séparément le type de dépendance, le propriétaire et la date limite. Si aucune preuve d'admissibilité ni une dépendance valide n'existe, retournez uncertain ; ne convertissez pas les données manquantes en un zéro sain. Créer un registre des éligibilités Un enregistrement minimal peut rester libre de contenu: champs Question opérationnelle taskId Quelle identité de tâche sûre et opaque est affectée? eligibleAt Quand un travailleur pourrait il légitimement commencer ? dependency Qui ou quoi est le propriétaire de l'attente, et jusqu'à quand ? deliveryAttempts La tâche a t elle épuisé sa politique limitée de retrait ? workerHeartbeatAt Est ce qu'il est possible d'atteindre au moins un travailleur compatible? slots et active Est ce que la capacité est occupée ou disponible ? lastVerifiedProgressAt Les résultats sont ils encore en marche ? C'est délibérément plus petit qu'une trace. Le Documentation de suivi du SDK OpenAI Agents décrit les générations, les appels à la fonction, les barreaux de garde, les remises et les événements personnalisés. Ces enregistrements permettent d'expliquer l'exécution, mais ils ne disent pas quand une tâche en file d'attente est devenue éligible ou si le résultat prévu a été observé. Rejoignez des traces détaillées au registre par un identifiant d'exécution sécurisée; ne faites pas intervenir l'activité de trace pour la progression de la file d'attente. Utilisez un ordre de décision qui préserve la cause: 1. Les preuves d'admissibilité et de dépendance manquantes sont uncertain . 2. Aucune tâche exécutable plus un bail de dépendance valide est waiting . 3. L'âge à courir dans l'objectif de départ est healthy . 4. Une des tâches les plus anciennes au delà de son budget de livraison est poisoned head . 5. Le vieux travail en cours d'exécution plus les battements cardiaques des ouvriers obsolètes est worker unreachable . 6. Vieille fonctionnalité, toutes les machines occupées, et le progrès récent vérifié est capacity bound . 7. Un ancien travail exploitable plus un nouvel ouvrier et une place libre est dispatcher stuck . L'ordre est important. Si une tâche a déjà épuisé son budget de tentative, l'ajout de travailleurs n'est pas la première réparation. Si aucun travailleur n'est accessible, le détachement est prématuré. Si toutes les machines à sous sont occupées et que les résultats arrivent toujours, le système est lent contre son objectif mais pas immobile. Répétez sept états de file d'attente L'artefact d'accompagnement gelera le temps d'observation à 2026 07 26T04:50:00Z , définira une fenêtre de fraîcheur du travailleur de 120 secondes et un objectif de démarrage de 300 secondes, puis évaluera sept files d'attente synthétiques. La course produite: dispatcher gap est le cas décisif. Sa plus ancienne tâche exécutive a attendu 900 secondes, le battement cardiaque du travailleur n'a que 20 secondes, et les deux machines à sous sont libres. Une plus grande capacité n'aiderait pas; les preuves d'affectation ou de routage devraient être inspectées. En revanche, le all slots busy a un âge de fonctionnement de 840 secondes, aucun espace libre, et un résultat vérifié il y a 80 secondes. Il est limité en termes de capacité dans le cadre de l'objectif de ce dispositif. bounded dependency a été mis en file d'attente plus tôt que les deux cas, mais c'est waiting : l'approbation a un propriétaire nommé et une date limite future, donc il n'y a pas d'horloge exécutive à violer. Le silent worker maintient le vieux travail prêt séparé du défaut de disponibilité. poisoned oldest empêche une cinquième livraison ratée de disparaître dans une file d'attente d'apparence normale. Le missing eligibility reste incertain. L'expérience démontre la règle de décision, pas la prévalence. Un cas synthétique par État ne peut établir de seuils de production, et il ne modélise pas l'inversion prioritaire, les files d'attente partagées, la biaisée de l'horloge ou les contraintes d'affinité des tâches. L'âge parallèle avec le mouvement de la capacité et du résultat L'âge à courir ne devient actionable qu'à côté de la capacité et du progrès. Une vieille tâche avec chaque espace compatible occupé suggère une décision d'échelle ou de formation de la charge de travail. Le même âge avec un espace ouvert à l'expédition, l'itinéraire, l'affinité des tâches, ou un bail perdu. Évitez trois raccourcis tentants: Ne pas passer en moyenne la famine. Un retard de démarrage moyen faible peut coexister avec une tâche qui n'est jamais exécutée. Suivez l'âge le plus ancien et un percentile par classe de tâches. Ne mélangez pas les travaux bloqués et exécutables. Gardez l'âge de la dépendance visible, mais exclurez le de l'objectif de départ jusqu'à ce que la dépendance soit résolue ou que son bail expire. Ne déduisez pas les progrès des contrats de location ou des appels à outils. La capacité ne bouge réellement que lorsqu'un artefact spécifique à la tâche, une vérification de l'acceptation ou un reçu de destination changent. Choisissez l'objectif de départ de la promesse du travail. Une tâche de codage interactive, un rapport programmé et une réconciliation nocturne ne devraient pas partager 300 secondes parce que le dispositif le fait. Mesurer le temps normal d'admissibilité au démarrage, fixer un objectif révisable avec un tampon et le modifier. Partition par groupe de travailleurs ou classe de tâches compatibles afin qu'une file d'attente non liée ne puisse masquer la famine. Lorsque la date limite d'une dépendance passe, ne la prolongez pas en silence. Comptez l'admissibilité à partir des preuves que vous avez et avisez le propriétaire nommé. Lorsque le rythme cardiaque d'un travailleur est dépassé, vérifiez la connectivité avant de réessayer des emplois qui pourraient encore fonctionner ailleurs. Lorsqu'une tâche empoisonnée atteint son budget de livraison, quarantaine ou demande de révision plutôt que de lui permettre de monopoliser le chef de file d'attente. Gardez le diagnostic séparé de l' intervention L'âge réaliste vous dit qu'une promesse opérationnelle est tardive; les faits combinés suggèrent pourquoi. Ils n'autorisent pas une réparation automatique. Un verdict dispatcher stuck peut préparer une vérification limitée de l'expédition. capacity bound peut ouvrir une révision de la capacité. worker unreachable peut demander une vérification de la facilité d'accès. Aucun de ces États ne permet de redémarrer un hôte, de dupliquer un effet secondaire, de modifier les informations d'identification ou de dépenser au delà d'une limite de réessayer. Après toute action approuvée, il est nécessaire de fournir de nouvelles preuves: la tâche a reçu un bail, une empreinte digitale de progrès a été modifiée ou le résultat attendu a été vérifié de manière indépendante. Une commande qui a rendu zéro est une activité, pas une récupération. Il y a des limites importantes. Les mesures de l'âge du fournisseur peuvent être approximatives. Le biais de l'horloge peut créer des âges négatifs impossibles, alors comparez le temps de collecteur et le temps de producteur avant d'utiliser le résultat. Les files d'attente prioritaires peuvent légitimement laisser vieillir le travail à faible priorité; exposer la politique plutôt que de la qualifier de saine par accident. Une tâche peut également contenir un espace libre à travers un bail non observé, de sorte que les données manquantes du bail devraient diminuer la confiance. La règle résolue est étroite: démarrer l'horloge lorsque le travail est réellement exécutable, alerter sur la tâche exécutable la plus ancienne contre un objectif spécifique à la tâche, puis utiliser la fraîcheur du travailleur, les espaces libres, réessayer le budget et vérifier le mouvement des résultats pour classer la cause. Sidewisp est actuellement en préversion privée. Son site public et sa bibliothèque d'articles sont en direct, mais la collecte de l'agent de production santé, les adaptateurs de temps d'exécution et la récupération ne sont généralement pas expédiés. Le Sidewisp est conçu pour fonctionner aux côtés des temps d'exécution existants, et non pour les remplacer ou agir comme un fixateur autonome. Si les preuves d'âge exploitable permettraient de juger plus facilement les opérations de vos agents, vous pouvez vous joindre à l'accès anticipé tout en traitant le produit comme une prévisualisation plutôt que comme une surveillance déployée.