AI Observabilité de l'agent pour les limites de taux: mesure après retrait de la dette

Un HTTP 429 ne signifie pas par lui même qu'un agent AI est coincé. Traiter la course comme waiting seulement tant que quatre preuves sont valides: la limite de non avant du fournisseur est connue, une reprise durable est prévue à cette limite ou après elle, l'autorité de reprise reste, et le résultat attendu a encore une limite limite. Si une preuve échoue, l'opérateur a besoin d'un diagnostic différent et non d'une nouvelle tentative générique. Cette distinction est importante parce que le même processus silencieux peut être une bonne contrainte, une reprise précoce, une erreur ou une tâche qui ne peut plus être terminée à temps. Le nombre de demandes et l'activité du processus ne peuvent pas distinguer ces états. Réponse courte: attendez seulement que quatre preuves tiennent Commencez par un contrat d' événement pour chaque appel à gaz: Ensuite, évaluez les preuves dans cet ordre: 1. Limite: Est ce que le client peut normaliser le signal du fournisseur à retry not before ? 2. Wake: y a t il une nouvelle tentative programmée durable à ce moment là ou après ? 3. A Autorité: La course a t elle encore une tentative, un temps et un budget de coûts autorisés ? 4. Ooutcome: outcome deadline retry not before laisse t il suffisamment de temps pour terminer et vérifier le travail prévu? Une course n'est pas saine simplement parce qu'elle dort jusqu'à la bonne seconde. Supposons que le fournisseur demande une attente de 15 minutes, mais que la livraison soit due dans 10 minutes. Le client peut obéir parfaitement au protocole alors que la tâche est déjà opérationnellement perdue. Éclairer ce conflit au lieu de montrer une attente verte. Définir une métrique diagnostique locale: Le retry after debt ms est présenté ici comme une mesure opérationnelle, et non comme un champ HTTP, une facture de fournisseur ou un SLO universel. Il sépare le temps délibérément livré à la contrainte du fournisseur de l'exécution du modèle, du travail des outils, du retard du planificateur et de la vérification des résultats. La tendance est à l'échelle de la durée et de la portée des quotas; ne pas combiner des locataires ou des ressources non liés dans un total trompeur. Enregistrer la limite du fournisseur avant de juger l'agent RFC 6585 définit HTTP 429 en tant que Too Many Requests. Une réponse peut inclure Retry After , mais la norme ne définit délibérément pas si le fournisseur compte en fonction de la crédibilité, des ressources, du serveur ou d'un autre champ d'application. Votre événement de santé a donc besoin de la réponse et de la meilleure clé de portée des quotas disponible. Une étiquette globale provider throttled est trop grossière lorsqu'un seul projet ou point final est limité. La sémantique HTTP définit Retry After en tant que date HTTP ou retard non négatif en quelques secondes. Préserver la valeur brute pour l'enquête, mais la normaliser immédiatement: Pour une date HTTP, enregistrez l'horloge du client si vous le pouvez. Pour un champ manquant ou non valide, définissez la limite à l'inconnu. Une politique peut alors choisir un backoff exponentiel limité, mais l'observabilité devrait dire uncertain boundary ; elle ne devrait pas inventer la permission du fournisseur de réessayer. Le calendrier local a besoin de son propre reçu. Stoc scheduled retry at , identifiant d'emploi du planificateur, numéro de tentative, et le dernier battement cardiaque confirmé du planificateur. Lorsqu'une nouvelle tentative démarre réellement, émettez retry started at ; lorsque le fournisseur répond, émettez retry finished at et le nouveau statut. Cela rend deux échecs opposés visibles: E: retry started at < retry not before Le client ajoute de la pression avant la limite déclarée. Missé: temps de démarrage actuel dépasse scheduled retry at + wake grace , mais aucun reçu de démarrage de réessayer n'existe. L'absence de circulation est saine dans la première fenêtre d'attente et malsaine après la veille. Le silence seul n'est pas un état. Une mise en œuvre concrète de la production renforce le besoin d'une autorité limitée. Le Guide de réessayer AWS SDK sépare l'étranglement des défaillances transitoires, utilise une rétroaction exponentielle avec un jitter et s'arrête lorsque les tentatives maximales ou le quota de retrait sont épuisés. Les retards exacts d'AWS ne sont pas une politique universelle d'agents. La leçon réutilisable est d'exposer la classification, le backoff et l'arrêt des conditions au lieu de les cacher à l'intérieur d'une bibliothèque client. Effectuer l'audit de six cas L'appareil inspectable pour cet article fixe now à 2026 07 26T18:42:00Z et donne à chaque course un instant 429. L'audit applique une grâce de réveil de 30 secondes et vérifie la récupération avant les états d'échec, puis le budget, la date limite, la reprise anticipée, la réveil manquée et l'attente valide. Les six lignes NDJSON produisent six résultats différents: Healthy wait waiting backpressure : une limite de 60 secondes, une veille alignée, trois tentatives et neuf minutes de tête. Earrly loop early retry loop : une nouvelle tentative commence 105 secondes avant la limite du fournisseur. Missé le réveil stuck missed wake : l'heure prévue et le passage de grâce sans reçu de réessai. La date limite est bloquée deadline exhausted : l'atterrissage instantané non précédent cinq minutes après la date limite du résultat. Le budget est épuisé retry budget exhausted : la limite est courte, mais aucune tentative autorisée ne reste. Recovered recovered : une nouvelle tentative post frontière rend 200 et un reçu de résultat suit. Le total mesuré est de 1 230 000 millisecondes de retrait de la dette: 20,5 minutes sur les six instantanés. Ce nombre est utile parce qu'il est inspectable, mais il n'est pas automatiquement mauvais. 60 secondes dans l'attente saine est intentionnelle. Neuf cents secondes dans la course bloquée par la date limite est décisive parce que le reste de la tête est négatif. Interprétez la dette à côté des résultats, pas comme un score indépendant. La ligne de récupération empêche également un faux succès commun. Une réponse de 200 prouve qu'une nouvelle tentative a été effectuée; elle ne prouve pas que l'agent a produit le fichier demandé, envoyé le message approuvé, mis à jour le dossier ou passé la validation. Fermez l'incident uniquement lorsqu'un reçu déterministique correspond à l'exécution initiale et à la livrabilité attendue. Transformer chaque état en une action limitée Utilisez une action par diagnostic: Pour le waiting backpressure , laissez la course en paix et vérifiez que la veille durable existe toujours. Pour early retry loop , arrêtez ce chemin de réessayer, préservez la limite du dernier fournisseur et vérifiez si plusieurs couches de réessayer multiplient les demandes. Pour stuck missed wake , effectuer une vérification du planificateur. Recréer ou déclencher une nouvelle tentative uniquement dans le cadre de l'autorité initiale et tenter le budget. Pour deadline exhausted , notifier au propriétaire que le résultat actuel ne peut pas respecter sa date limite. Ne cachez pas le conflit avec un délai plus long. Pour retry budget exhausted , arrêtez et faites apparaître les preuves du fournisseur final. Un budget plus important est une décision politique humaine. Pour recovered , vérifiez le résultat prévu avant de régler la question. Pour une limite ou une portée de quota inconnue, marquez l'état incertain et recueillez des preuves; ne devinez pas si l'agent est sain ou cassé. Gardez la limite proche de la décision. Les fournisseurs peuvent omettre le Retry After , exposer plusieurs quotas qui se chevauchent ou s'accrocher à un intermédiaire. Les horloges peuvent dériver. Les SDK peuvent réessayer à l'intérieur avant que le temps d'exécution de l'agent ne remarque une erreur. Installez la couche la plus basse qui peut exposer les reçus de tentative, puis corrélatez vers le haut par les identifiants d'exécution et de tentative. N'utilisez jamais des jetons, des instructions, des organes de réponse ou des clés secrètes pour diagnostiquer le timing. 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. Le Sidewisp n'est pas un temps de fonctionnement de remplacement, une passerelle obligatoire, un produit de traçage brut, un avion de contrôle d'entreprise ou un fixateur autonome. La raison pratique de l'adhésion à l'aperçu privé est d'aider à façonner les preuves de santé telles que les limites des fournisseurs, les réveils durables, les budgets des essais et les résultats vérifiés, et non pour obtenir une capacité de surveillance déjà disponible en général. La règle d'exploitation est étroite: honorer le fournisseur de contrainte, mais ne confondre pas l'attente conforme avec le progrès sain. Une course à rythme limité ne reste en bonne santé que si sa limite, sa veille, son autorité et sa date limite de sortie sont d'accord; après la réessaye, seul le résultat prévu ferme la boucle.