Documentation de l'observabilité de Datadog LLM: couverture des instruments d'audit

Le moyen utile de lire la documentation d'observabilité Datadog LLMZ est en tant que contrat d'instrumentation versionné, et non en tant que preuve que chaque étape importante de l'agent est visible. Avant de faire confiance à une trace, vérifiez quatre choses: vos versions de cadre et de traceur sont prises en charge ensemble, exactement un chemin de configuration est actif, le prélèvement d'échantillons préserve les preuves requises pour les décisions de santé, et chaque effet externe a une réception déterministe des résultats. Cette distinction est importante car une trace apparemment complète peut encore cacher une écriture de base de données personnalisée, une intégration non prise en charge, une attente légitime d'approbation ou un produit manquant. L'audit ci dessous transforme ces lacunes en huit verdicts explicites. Il n'utilise pas de requêtes, de réponses, de clés API ou de données client. Commencez par le contrat de support, pas le tableau de bord. Le Avis général sur l'observabilité des agents de Datadog indique qu'une demande d'application apparaît comme une trace et que les intervalles représentent des choix ou des étapes de flux de travail. C'est le bon modèle pour enquêter sur la latence, les erreurs, l'utilisation des jetons et le parcours d'un agent. Il ne s'agit pas d'une promesse selon laquelle une demande arbitraire est entièrement instrumentalisée. Le référence à l'instrumentation automatique limite le suivi automatique aux cadres et bibliothèques pris en charge. Il dirige explicitement les opérateurs vers l'instrumentation manuelle pour les autres appels API, les requêtes de base de données et les fonctions internes. Traiter la documentation comme quatre contrats liés: Contrat Des preuves à enregistrer Un échec qu'une trace verte peut cacher Compatibilité temps d'exécution, version de cadre, version de traceur, mode module le parcours de code non pris en charge émet des intervalles partiels ou nulles Département d'entreprise un mode d'installation activé, un site, un nom de l'application, un transport duplication d'initialisation ou d'envoi de données à la mauvaise destination Couverture politique d'échantillonnage et un manifeste des opérations qui doit être visible un événement de santé requis est échantillonné ou n'a jamais été utilisé Le résultat réception d'attente et réception d'achèvement spécifique à la destination l'agent rapporte l'achèvement mais l'effet demandé est absent Ces contrats doivent être vérifiés par rapport à une photo de documentation datée. Le 30 juillet 2026, la table Python de Datadog a répertorié LangGraph =0.2.23 avec ddtrace =3.10.1 . La même page énumère différents minimums pour d'autres cadres et langues. Nous avons installé le dernier package est donc une preuve plus faible que ce paire d'applications/traceurs exact répond à la ligne de support vérifiée. Le Références du SDK ajoute une autre limite: la configuration de ligne de commande Python avec ddtrace run et la configuration en code avec LLMObs.enable() sont des alternatives. Sa section de code prévient de ne pas les combiner. La référence expose également DD LLMOBS SAMPLE RATE , ce qui signifie que la conservation des traces est une décision de l'exploitant plutôt qu'une garantie de santé intrinsèque. Effectuer un audit d'instrumentation sur huit cas L'appareil d'audit fixe une ligne de support Python, LangGraph 0.2.23 et ddtrace 3.10.1 , puis modifie un fait opérationnel par cas. Conserver la structure ci dessous comme instrumentation cases.json et étendre son tableau cases aux huit conditions décrites par la sortie enregistrée: Utilisez cette règle de décision dans audit datadog instrumentation.mjs : Exécuter l'audit: La course enregistrée a évalué huit matchs et correspond aux huit verdicts attendus: L'ordre des chèques est délibéré. La compatibilité vient en premier lieu parce qu'un intervalle manquant d'une paire non prise en charge ne doit pas être diagnostiqué comme une défaillance de l'application. Le démarrage est le prochain parce que deux voies de configuration créent un état de collecte ambigu. La couverture suit parce qu'un traceur correctement initialisé peut toujours omettre les preuves requises. Les contrôles d'attente et de résultats sont les derniers parce qu'ils décrivent le travail et non le transport télémétrique. Il s'agit d'une vérification de la configuration et des contrats de preuve. Il connecte not à un locataire Datadog ou prouve l'ingestion. Après son passage, envoyez une piste canarienne et confirmez que les étendues de racine et d'enfant attendues apparaissent sous l'application prévue, le site, l'environnement et la fenêtre de temps. Prendre une décision d'échantillonnage sur la couverture Datadog documente un taux d'échantillonnage de l'agent observable configurable. L'échantillonnage est utile lorsque les traces de diagnostic complètes sont coûteuses, mais il crée une conséquence opérationnelle stricte: l'absence d'une trace échantillonnée ne peut prouver l'absence d'une course, d'un appel à l'outil ou d'une défaillance. Garder deux voies de preuve lorsque les décisions en matière de santé doivent couvrir chaque course: 1. Des traces diagnostiques peuvent être prélevées. Ils conservent de riches détails pour enquête. 2. Les reçus médicaux obligatoires restent compacts et sans échantillonnage. Ils enregistrent l'identité de l'exécution, l'état, la fraîcheur, la propriété d'attente, la destination attendue et le statut de vérification des résultats. Le fichier renvoie coverage gap lorsque sampleRate est inférieur à 1 et qu'il n'existe pas de registre de santé obligatoire. Ça ne veut pas dire que la course a échoué. La conclusion correcte est plus étroite: les preuves disponibles ne peuvent pas soutenir une affirmation de santé générale. Cela empêche également une erreur d'alerte courante. Une trace d'échantillonnage manquante ne doit pas qualifier un opérateur de panne. Comparons d'abord le reçu de course non échantillonné, le rythme cardiaque de course et la fraîcheur de la collecte. S'intensifier uniquement lorsque les preuves démontrent une défaillance pertinente pour l'utilisateur ou restent indisponibles après une date limite explicite. Ajoutez des étendues manuelles aux limites d'effet L'instrumentation automatique est un point de départ, pas une carte des résultats de votre entreprise. Supposons qu'un agent appelle un modèle et un outil pris en charge, puis exécute une fonction interne nommée write release manifest . Le modèle et l'outil peuvent terminer normalement tandis que cette dernière fonction échoue silencieusement. Créer un petit manifeste d'opération avant le déploiement: L'audit renvoie instrumentation gap lorsque l'opération requise n'est pas couverte automatiquement ou manuellement. Ne réparez pas ce problème en ajoutant des spans à chaque fonction d'aide. Les limites des instruments qui modifient la décision de l'opérateur: appels entre les services, écritures durables, vérification des autorisations, transitions d'approbation, tentatives de répétition avec des effets externes et vérification de destination. Le reçu le plus fort doit provenir de la destination. Pour un fichier, vérifiez le chemin prévu et digérez. Pour une demande de retrait, consultez le service d'hébergement pour les relations publiques et les vérifications requises. Pour un message, conservez l'identifiant accepté du fournisseur et concilier la livraison lorsque le flux de travail l'exige. La durée terminée sans erreur est une preuve d'activité; elle n'est pas la même que le résultat demandé existe. Gardez l'attente au lieu de l'étiqueter comme coincé Les traces d'agents incluent souvent de longues pauses. Certains sont des échecs; d'autres sont des attentes correctes d'une personne, d'un fournisseur ou d'une fenêtre programmée. La durée seule ne peut les distinguer. Une attente légitime a besoin d'un petit reçu: En l'absence de propriétaire, de date limite et d'identité réalisable, l'appareil renvoie ambiguous wait . Il ne renvoie pas immédiatement stuck , car les preuves sont insuffisantes. Avec un reçu valide, la surveillance peut rester silencieuse jusqu'à la date limite, diriger la demande vers la bonne personne et vérifier plus tard que le travail a repris. Cette distinction empêche les opérateurs de retrouver un travail sain en le réessayant. Une nouvelle tentative dangereuse à une limite d'effet externe peut créer des billets, des messages, des paiements ou des déploiements dupliqués même lorsque la course initiale était simplement en attente de confirmation. Lisez la trace de Datadog et le reçu de résultat ensemble Utilisez la trace Datadog pour répondre: Les appels de cadre et de modèle attendus sont ils apparus? Quels temps ont échoué, ralenti ou consommé des jetons inhabituels? L'arbre de traces a t il préservé la structure attendue des parents et des enfants? La preuve est elle fraîche et est elle associée à l'application prévue? Utilisez le reçu de santé séparé pour répondre: La course était elle attendue à ce moment là ? Est ce qu'elle fonctionne, attend, est coincée, incertaine ou complète? Tous les effets nécessaires ont ils eu lieu une fois ? La destination contient elle le résultat promis? L'appareil final est intentionnellement inconvenient: le tracé est pris en charge, la configuration est propre, le prélèvement d'échantillons est terminé et aucune opération n'est manquantemais la course revendique complete sans reçu de résultat. Son verdict est false green . C'est la limite à respecter. Datadog peut fournir des traces détaillées, une évaluation, une latence, une erreur et des preuves de jetons. Votre demande doit toujours définir ce que signifie le succès et le vérifier là où le résultat se trouve. Sidewisp applique la même distinction de santé en premier dans sa direction de produit: l'activité n'est pas un progrès utile, l'attente n'est pas automatiquement bloquée et l'achèvement d'une commande n'est pas un résultat vérifié. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production ne sont généralement pas expédiés aujourd'hui; le site public est une expérience d'accès précoce et une démonstration de produits. La séquence de déploiement pratique est courte: saisissez la date de la documentation, enregistrez la ligne de support, choisissez un chemin de démarrage, déclarez la limite d'échantillonnage, répertoriez les opérations d'effet requises, reproduisez les huit appareils, puis envoyez un canary en direct et vérifiez sa destination. Ce n'est qu'après que tous ces reçus soient d'accord qu'une trace verte deviendra un verdict d'agent vert.