2026-07-31T17:58:32.263Z

OpenTelemetry LLM Observabilité: fixer le schéma avant le vert

Une vérification de la durée d'exécution de la GenAI basée sur la révision pour la dérive du schéma, la confidentialité, la couverture, la fraîcheur, l'attente et les résultats vérifiés.

L'observabilité OpenTelemetry LLM n'est utile que si la télémétrie a une signification déclarée. Avant de traiter une trace de GenAI comme preuve opérationnelle, fixez la révision de la convention sémantique, validez les champs requis pour chaque opération, rejetez la capture de contenu non approuvée, prouvez que les opérations attendues sont présentes, puis évaluez séparément la fraîcheur, l'état de travail et le résultat externe. Cet ordre est important en juillet 2026. Le site Web d'OpenTelemetry indique désormais les conventions de GenAI à un référentiel dédié. Lors de la révision de la source inspectée pour cet article, 434c91dcc34ed038e3048c07720ddfed2c6bddfc , le README indique toujours son URL de schéma comme TODO du référentiel et le document générateur de la durée du client sont marqués Development . Ce n'est pas une raison d'éviter OpenTelemetry. C'est une raison de rendre explicite la compatibilité. Un tableau de bord contenant des étendues GenAI peut encore combiner un ancien producteur, un collectionneur actuel et une requête écrite pour une troisième forme d'attribut. La configuration sécurisée est un petit profil d'acceptation versionné à côté de la configuration de votre collectionneur. Enfonce le contrat que tu exploites réellement Le référentiel GenAI d'OpenTelemetry couvre les clients LLM, les agents, l'exécution des outils, l'évaluation, la mémoire, la récupération et le MCP. Ses documents sont en partie générés à partir de modèles YAML, ce qui est précieux car la source est inspectable et testable. Cela signifie également que "nous utilisons OTel" est trop vague pour être une allégation de compatibilité. Enregistrer quatre identités avec chaque déploiement d'instrumentation: L'identité Exemple Pourquoi ça compte ? Source de la convention Référentiel plus engagement SHA Définit le contrat d'attribut et d'exploitation que vous avez examiné Package d'instruments Nom et version du colis Identifie l'émetteur de l'espace Pipeline de collecteurs Configurer le digeste et l'identifiant de déploiement Identifie les transformateurs, les filtres et les exportateurs Contrat de demande Tableau de bord ou version d'alerte Identifie les domaines que le verdict attend Ne déduisez pas la révision de la convention à partir des champs qui arrivent. Ce qui transforme la dérive silencieuse en compatibilité apparente. Si un producteur ne peut pas déclarer sa révision, classez le lot comme schema drift jusqu'à ce que vous ayez testé et enregistré cette forme de producteur. Ceci est particulièrement important lorsque des instruments de cadre natifs et externes coexistent. Le orientation sur l'observabilité de l'agent d'OpenTelemetry décrit les compromis d'entretien de l'instrumentation cuite et met en garde contre le risque de collision de paquets externes. Dans le cas contraire, le même appel modèle peut être observé deux fois, ou une route peut rester sur une convention plus ancienne après une mise à niveau partielle. La règle pratique est simple: un producteur de télémétrie attendu par parcours d'exploitation, une révision déclarée de la convention par cohorte de déploiement et une trace canarienne qui doit passer avant la promotion de la cohorte. Valider un petit profil opérationnel avant le schéma complet Un validateur de convention sémantique complet peut être généré à partir des modèles de référentiel. Une porte opérationnelle devrait commencer plus petite. Appliquez uniquement les champs qui affectent vos décisions actuelles, puis élargissez le profil à mesure que vous utilisez plus d'opérations. Lors de la révision fixée, les marques Tableau d'intervalle d'inférence: gen ai.operation.name selon les besoins; gen ai.provider.name selon les besoins; error.type selon les conditions requises lorsque l'opération se termine par une erreur; gen ai.request.model selon les conditions requises lorsqu'il est disponible; les messages d'entrée, les messages de sortie, les instructions du système et les définitions de l'outil en tant qu'options. Ces niveaux d'exigences ne doivent pas être aplatisés en " champ présent ou absent. " Une période d'erreur sans error.type a perdu une classe de preuves que la convention attend. Un modèle de demande manquant peut être légitime lorsqu'il n'était pas disponible. Le contenu rapide et le contenu de réponse devraient rester absent, sauf si une politique explicite permet la collecte. L'audit accompagnant met en œuvre ce profil étroit: La vérification du contenu examine uniquement l'attribut keys . Il ne lit ni ne stocke aucun texte rapide, aucun texte de réponse, aucune instruction système ni aucun argument d'outil. C'est suffisant pour capturer une capture accidentelle sans transformer le validateur en un autre puits de données sensibles. Il y a ici une limitation délibérée: ce profil n'est pas l'ensemble des spécifications OpenTelemetry. Il teste un contrat révisable utilisé pour un verdict opérationnel. Lorsque la source en amont change, mettre à jour la révision fichée, comparer les définitions générées, ajuster le fichier et le redémarrer avant de mettre à niveau les producteurs. Couverture de l'audit avant d'interpréter une trace nette Une durée conforme peut encore être une preuve incomplète. Si la demande prévoyait invoke agent , chat et execute tool , mais que la trace ne contient que les deux premiers, le verdict correct est coverage gap , pas sain. Construire les opérations attendues à partir de la topologie du flux de travail plutôt que des intervalles observés: Cela évite un test circulaire dans lequel la télémétrie définit sa propre intégrité. L'ensemble attendu peut provenir d'un manifeste de libération, d'un itinéraire d'outil enregistré ou d'une définition du flux de travail. Il doit être suffisamment petit pour être maintenu et suffisamment spécifique pour exposer une trajectoire d'instrumentation manquante. Les tentatives automatiques nécessitent des soins. La prose actuelle de l'espace client dit qu'une période logique devrait couvrir la durée de l'opération, y compris les répétitions automatiques. Votre demande peut également conserver des espaces de transport au niveau de l'essai. Ne comptez pas ces deux couches comme des duplications d'agents. Décidez si la couverture est exprimée à l'opération logique, tentative, ou les deux, puis faites la relation explicite. De même, un nom de fournisseur n'est pas nécessairement le propriétaire ultime du modèle. La convention note que l'instrumentation peut connaître une plateforme proxy ou d'hébergement plutôt que le fournisseur en amont transparent. Traiter le gen ai.provider.name comme un facteur de discrimination de format et de routage dans son champ de compétence documenté, et non comme un oracle de facturation ou de provenance de modèle. Gardez le schéma, la santé et le résultat séparés. Une fois le schéma et la couverture passés, la trace est admissible à informer une décision sanitaire. Ce n'est pas une décision en soi. Utilisez une priorité explicite: 1. Schema identity le producteur correspond il à la révision fixée? 2. Validité du schéma sont ils requis et les champs conditionnels valides? 3. Politique de contenu sont ils autorisés pour cette route ? 4. Coverage sont elles représentées toutes les opérations attendues? 5. Freshness est ce que les preuves sont suffisamment récentes pour le flux de travail? 6. E état de travail est ce que l'agent travaille, attend, est il coincé, est il incertain ou est il complet? 7. Outcome existe t il le résultat promis à sa destination? Le dispositif de dix cas pour cet article rend ces couches mal à l'aise délibérément. Elle comprend: un producteur non soutenu et un producteur hérité; une période d'inférence manquante à gen ai.provider.name ; une période d'erreur manquant à error.type ; une clé de contenu d'opt in sans autorisation; un flux de travail manquant de la durée de l'outil attendue; une trace complète sans reçu de résultat; une trace vérifiée mais périmée; une attente légitime d'approbation humaine; un cas frais, couvert et vérifié par les résultats. Exécutez l' artefact avec: Le résultat exécuté a classé exactement dix cas: Le cas complete no receipt est la limite clé. Sa révision par le producteur correspond. Ses étendues contiennent les champs requis par le profil. Les opérations d'agent et de modèle attendues existent. La télémétrie est fraîche. Il renvoie toujours unverified parce qu'aucun reçu de destination ne prouve l'existence du billet, du fichier, du déploiement ou d'un autre résultat promis. Le cas waiting for approval préserve une limite différente. Les dernières étendues conformes s'arrêtent à une approbation humaine nommée avec un propriétaire et une date limite. Ce n'est pas une étagère. La page d'un opérateur comme si l'agent avait échoué détruirait des informations utiles de l'État. Transformer l'audit en contrôle des décharges et des incidents Faites ce test à trois instants. Avant une mise à niveau de l'instrumentation , saisissez la révision actuelle, les versions du paquet, la digestion du collecteur et les opérations attendues. Rejouez le dispositif fixe contre la pile proposée. Un verdict modifié doit être expliqué avant la promotion. Pendant le déploiement , émettez un canary sans contenu à travers chaque modèle, agent et route d'outil enregistré. Vérifiez que chaque canary arrive une fois, porte l'identité de producteur attendue, passe le profil opérationnel et reste recherchable dans la fenêtre de fraîcheur. Pendant un incident , préserver les quatre couches au lieu de les effondrer en "l'observabilité est cassée". Un écart de couverture nécessite la réparation de l'instrumentation. La télémétrie stagnante nécessite un diagnostic du collectionneur ou de l'exportateur. waiting appelle le propriétaire nommé. unverified demande une vérification de destination, pas une nouvelle tentative de modèle. Ne réparez pas automatiquement un agent parce qu'un champ de télémétrie a changé. La dérive des conventions peut rendre les preuves incertaines sans rendre le travail sous jacent malsain. Fermez la récupération active, identifiez la couche de preuve ratée et utilisez le plus petit test réversible qui rétablisse la confiance. Le profil du schéma a aussi besoin d'un propriétaire. Le fait de tenir un engagement pour toujours n'est pas une sécurité; c'est une stagnation éventuelle. Assignez une cadence d'examen, surveillez le référentiel GenAI et demandez une différence de fixation lors du déplacement de la broche. Si OpenTelemetry publie une URL stable du schéma GenAI plus tard, adoptez la lorsque vos producteurs et vos requêtes la prennent en charge, mais gardez la couverture, la fraîcheur, l'attente et les contrôles de résultats indépendants. Sidewisp est actuellement en préversion privée. Son expérience publique est un site Web d'accès anticipé et une démonstration interactive; la collecte des agents de production santé, les adaptateurs hôtes et la récupération ne sont pas expédiés dans le référentiel actuel du site Web. La direction du produit est une couche de santé autour des temps d'exécution existants, pas un collecteur OpenTelemetry, un rétroacteur de suivi ou un fixateur autonome. Si les preuves appuyées sur la révision et la vérification des résultats séparées correspondent aux défaillances que vous devez détecter, vous pouvez rejoindre la prévisualisation privée de Sidewisp et décrire le parcours d'exécution et de télémétrie de l'agent que vous utilisez.