Splunk LLM Observabilité: maintenir les appels de l'évaluateur hors de santé de l'agent

L'observabilité de Splunk LLM peut montrer des performances utiles, une qualité, un jeton, un coût estimé et des preuves de traces pour un agent instrumenté. Le défaut opérationnel sécurisé, cependant, n'est pas la page AI Agents est peuplée, donc l'agent est en bonne santé. D'abord prouver que le pipeline de mesure est complet, que les appels des évaluateurs ne sont pas comptés comme des travaux d'application, que la couverture de l'évaluation a un dénominateur connu et que le résultat demandé existe en dehors de la trace. Ce guide construit cette preuve sans recueillir de conseils ou de réponses. Le dispositif comprenant huit cas produit une réception sans contenu et les routes se dirigent chacune vers l'un des États suivants: ingestion incomplète, défaut de contrat métrique, évaluateur observé par lui même, risque de cardinalité élevée, révision de la politique de contenu, couverture d'évaluation diminuée, observable mais non vérifiée, ou saine avec des preuves couvertes et vérifiées. Auditer le parcours de mesure avant de lire le score La documentation de configuration actuelle de Splunk rend deux détails de télémétrie opérationnellement importants. Tout d'abord, des métriques d'histogramme sont requises pour les pages de surveillance de l'agent AI. Lorsque l'exportateur SignalFx est utilisé, l'établissement du collecteur documenté est send otlp histograms: true . La configuration spécifie également la temporalité delta par: Une trace visible ne prouve pas que ce chemin métrique est correct: les intervalles et les histogrammes peuvent échouer indépendamment. Deuxièmement, l'instrumentation Python AI peut exécuter des évaluations dans le même processus que l'application. Splunk documente ce commutateur, dont la valeur par défaut est fausse: Dans ce mode par défaut, les appels LLM effectués par des évaluateurs tels que DeepEval peuvent être utilisés aux côtés des appels d'application. La mise en place de véritables évaluations d'exécution dans un processus enfant avec le SDK OpenTelemetry désactivé, empêchant les appels des évaluateurs de contaminer la télémétrie des applications. Splunk marque cet isolement comme requis pour l'instrumentation OpenAI lorsque les évaluations sont activées et facultatives pour d'autres cadres documentés. Cette distinction change le sens d'un graphique. Supposons qu'une invocation d'agent appelle un modèle deux fois, puis un évaluateur fait trois autres appels de modèle. Si l'évaluateur partage le processus instrumenté, un agrégat naïf peut signaler cinq appels, leurs jetons combinés et leur latence combinée. L'activité supplémentaire est réelle, mais ce n'est pas la preuve que l'agent a fait plus de progrès. Il s'agit d'un travail de mesure qui observe le travail de mesure. Enregistrer un reçu sans contenu par déploiement: Aucun de ces champs n'a besoin d'un prompt, d'une réponse, d'un argument d'outil, d'un secret ou d'un identifiant client. Ils décrivent la santé du pipeline de preuves. Les trois premières vérifications répondent à différentes questions: histogramsExported : le collecteur a t il exporté la télémétrie de l'histogramme requise par les pages de surveillance AI? deltaTemporality : le contrat de métriques correspond il à la configuration documentée? aiSpanVisible : est ce qu'au moins une nouvelle étendue de GenAI a atteint la vue Splunk attendue ? Ne les effondre pas dans une seule telemetry ok booléenne. Si les spans arrivent mais que les histogrammes ne le font pas, l'enquête sur les traces peut fonctionner pendant que les panneaux agrégés restent incomplets. Si les données sont anciennes, une page peuplée peut encore être obsolète. Gardez la source de preuve et le temps d'observation à côté de la réception dans une mise en œuvre réelle. Donnez à chaque score de qualité un dénominateur de couverture Splunk décrit un score de qualité de l'agent AI comme le pourcentage d'évaluations passées pour une mesure. Sa documentation AI Agents dit que les intervalles sont échantillonnés pour calculer ces scores, et un score inférieur à 80% indique un problème de qualité. Cette règle peut être utile pour l'échantillon évalué. Il ne constitue pas, en soi, la preuve que chaque invocation admissible a été évaluée ou que l'échantillon représente chaque type de tâche. Suivez quatre numéros ensemble: 1. les délais de candidature admissibles; 2. taux d'échantillonnage d'évaluation configuré; 3. les résultats de l'évaluation complétés; 4. Les résultats de l'évaluation sont réduits. Pour une fenêtre d'audit déterministe, calculer: Avec 400 intervalles éligibles, un taux d'échantillonnage de 0,25, 100 évaluations et zéro baisse, la couverture observée est de 25% et correspond à l'attente configurée. Cela signifie que Znot les 300 autres spans ont passé. Cela signifie que leur état d'évaluation est en dehors de l'échantillon. La configuration Python de Splunk expose également une taille de file d'attente d'évaluation. Une limite positive s'applique à la répression; lorsque la file d'attente est pleine, de nouveaux éléments sont abandonnés avec un avertissement. La documentation recommande une limite dans la plage 1001000 en fonction du débit et de la mémoire, tandis que le zéro ou le non défini laisse la file d'attente illimitée. Chaque choix a un compromis: une file d'attente illimitée peut transformer le retard d'évaluation en pression de mémoire; une file d'attente limitée peut préserver le processus mais réduire la couverture de l'évaluation; un compteur de six chiffres en file d'attente signifie que 94 évaluations terminées ne peuvent honnêtement pas représenter 100 évaluations admissibles à un taux d'échantillonnage de 100%. L'audit renvoie donc EVALUATION COVERAGE DROPPED , qui n'est pas en bonne santé et qui n'est pas un agent défaillant. L'agent a peut être accompli un travail utile; les preuves nécessaires au verdict de qualité sont incomplètes. Les dimensions métriques ont besoin d'une limite similaire. Splunk permet de copier les attributs contextuels de GenAI dans des dimensions métriques, mais prévient explicitement que gen ai.conversation.id peut causer des problèmes de cardinalité élevée. Gardez l'identité par conversation sur les intervalles lorsque cela est nécessaire pour le diagnostic. Ne le transforme pas automatiquement en dimension métrique. Un environnement de déploiement ou un niveau de locataire à faible cardinalité est généralement plus sûr pour l'agrégation; le bon ensemble dépend toujours du trafic et des limites des locataires. Garder le contenu capture une exception explicite La documentation du service LLM de Splunk indique que la collecte des demandes et des réponses est désactivée par défaut et prévient que le contenu peut contenir des informations sensibles ou personnellement identifiables. Son parcours d'installation note également que de grandes entrées et sorties capturées peuvent dépasser les limites de backend et causer des problèmes de performance. Cet audit n'a pas besoin de contenu. Il peut vérifier l'exportation de l'histogramme, la temporalité, l'isolement du processus, le prélèvement d'échantillons, les gouttes, les dimensions, la visibilité des traces et le reçu de destination en utilisant uniquement les métadonnées. Si une enquête de qualité distincte nécessite réellement un contenu capturé, passez le par un examen de la politique de contenu: identifier l'évaluateur exact qui a besoin de contenu; indiquer si la capture se produit sur des étendues, des événements ou les deux; la conservation, l'accès, le masquage et la suppression des documents; le comportement de la charge utile à l'essai; vérifier que les définitions de l'outil ne sont pas capturées simplement parce que la capture de messages a été activée; désactiver la capture après l'enquête limitée si la collecte continue n'est pas justifiée. L'appareil renvoie CONTENT POLICY REVIEW lorsque la capture est activée sans reçu d'homologation. Ce verdict est délibérément ni sain ni cassé. Il dit que l'instrumentation a franchi une limite de données que le contrôle de santé opérationnel ne peut pas autoriser. La même restriction s'applique au coût estimé. Splunk indique que son estimation des coûts des agents multiplie le coût du fournisseur publié par le nombre de jetons disponibles et ne représente pas la facturation réelle. Étiquettez l'estimation, conservez la date de fixation des prix et ne la conciliez pas silencieusement avec une facture ou un rabais caché spécifique au fournisseur. Effectuer l'audit des preuves sur huit cas L'artefact reproduisable utilise une règle de priorité. Des résultats antérieurs bloquent les états verts ultérieurs: Exécutez le fichier enregistré: Il reproduit huit cas et rapporte huit résultats distincts: couvert et vérifié HEALTHY COVERED VERIFIED : Télémétrie requise, échantillon déclaré, gouttes zéro et accord de résultats. Evaluateur auto observé EVALUATOR SELF OBSERVED : Les appels du juge peuvent entrer dans la télémétrie des applications. histogrammes manquants INGESTION INCOMPLETE : Une trace ne prouve pas l'arrivée des mesures requises. ZError temporalité METRIC CONTRACT MISMATCH : Le contrat métrique exporté diffère de l'installation documentée. conversation id as metric HIGH CARDINALITY RISK : L'identité par conversation a été promue dans une dimension métrique. contenu capturé non examiné CONTENT POLICY REVIEW : Une frontière de données sensibles a été franchie sans reçu. Evaluation en file d'attente abandonnée EVALUATION COVERAGE DROPPED : 94 résultats ne peuvent pas représenter une attente de 100. trace without outcome OBSERVABLE NOT VERIFIED : Des preuves d'exécution existent, mais le résultat promis ne l'est pas. Il s'agit d'un audit de configuration synthétique, pas d'un test de conformité en direct. Il ne peut pas prouver qu'un collecteur est accessible, qu'un rôle inclut la capacité requise, qu'une fenêtre d'incident est couverte par la conservation ou qu'une destination contient le délivrable attendu. Remplacez les valeurs de l'appareil par des observations de votre environnement et préservez unknown lorsqu'une valeur ne peut pas être mesurée. Arrêtez la trace avant le verdict de santé. Les vues de trace et d'interaction AI de Splunk répondent à des questions importantes sur les opérations du modèle, les erreurs, l'utilisation des jetons, la latence et la qualité de la réponse évaluée. Un verdict d'agent santé a une limite supplémentaire: le travail demandé a t il été effectué? Choisissez la vérification déterministique de destination la plus forte disponible: un fichier existe sur le chemin attendu et correspond à un schéma ou à un hash; une demande de retrait existe dans le référentiel prévu et l'engagement; un message existe à la destination prévue avec la clé d'idempotence attendue; une mutation de la base de données est visible sous l'identifiant de locataire et d'exploitation prévu; un ensemble d'essais passé sur l'artefact produit; une approbation humaine est toujours en attente, donc la course est waiting , pas échoué. Rejoignez ce reçu à la trace avec un identifiant de sécurité minimale. Gardez le contenu disponible à sa source. Une période réussie plus un reçu manquant est OBSERVABLE NOT VERIFIED ; ce n'est pas une autorisation automatique pour réessayer, car l'effet externe peut exister mais être temporairement illisible. La règle pratique est simple: faire confiance à la vue Splunk après le passage de son propre chemin de mesure, interpréter les scores de qualité dans leur couverture connue et clarifier la santé de l'agent uniquement lorsque le résultat prévu est vérifié séparément. Le Sidewisp suit la même orientation du produit de première épreuve: distinguer l'activité des progrès utiles, exposer les éléments de preuve manquants et séparer la vérification des résultats de l'achèvement des traces. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production et son moteur de récupération ne sont pas présentés ici comme étant généralement disponibles; le site public est une expérience d'accès précoce et une démonstration de produit. Les sources Configurer le AI, documentation de la nuée de l'observabilité Splunk. Configurer l'agent Python pour les applications AI 0.1.14 et supérieures, documentation de la nuée de l'observabilité Splunk. Suivre les agents AI, dernière mise à jour le 16 juin 2026. Surveiller les services LLM, dernière mise à jour le 12 mai 2026.