Observabilité New Relic LLM : prouver qu'une route possède chaque appel

L’observabilité de New Relic LLM peut afficher la latence du modèle, les jetons, les erreurs, les traces et les données de réponse de l’IA. Il ne peut pas, à lui seul, indiquer à un opérateur si deux collecteurs ont compté le même appel de modèle ou si l'agent a produit le résultat externe demandé. La méthode par défaut pratique consiste à nommer un propriétaire d'instrumentation pour chaque limite d'appel de modèle , à corréler chaque enregistrement à un ID d'appel sans contenu et à conserver un reçu séparé pour le livrable. Cette règle est importante car New Relic documente plusieurs chemins légitimes. C'est natifSurveillance de l'IAutilise des agents APM. New Relic documente égalementOpenLIT sur OTLPpour les traces et les métriques etOpenLLMetry sur OTLPpour les traces. LiteLLM a unIntégration de la nouvelle reliqueconstruit autour de son rappel et de l'agent New Relic Python. Ces voies sont des options et non la preuve que tous devraient instrumenter la même frontière. Un tableau de bord peut être rempli alors que la propriété est erronée, que les preuves sont périmées, qu'un champ obligatoire est absent ou qu'un appel de modèle terminé n'a aucun résultat vérifié. Déclarez l'itinéraire avant de faire confiance à la carte Commencez par un manifeste de déploiement, pas une requête. Il doit identifier le service, la limite instrumentée, le propriétaire autorisé à signaler cette limite, les types de signaux que le propriétaire peut émettre, le champ de corrélation et la limite de fraîcheur. La distinction entre un propriétaire et un type de signal évite une erreur de déduplication grossière. Un propriétaire déclaré peut délibérément émettre un span APM et un événement de message AI pour le même appel. Ces enregistrements sont complémentaires lorsqu'ils partagent le même identifiant d'appel et que le contrat de déploiement prévoit les deux. Un enregistrement OpenLIT et un enregistrement OpenLLMetry pour cette même limite sont deux propriétaires, même si leurs champs se ressemblent. Le manifeste doit être produit par le déploiement qui a activé l’instrumentation. Ne le déduisez pas de l’entité qui apparaît dans l’interface utilisateur. Les chemins d'installation établissent l'identité différemment : La surveillance de New Relic AI commence par un agent APM et une bibliothèque ou un framework pris en charge. OpenLIT envoie des traces et des métriques au point de terminaison OTLP de New Relic. OpenLLMetry envoie des traces à ce point de terminaison et New Relic dérive l'entité de service d'OpenTelemetry service.name attribut de ressource. LiteLLM permet un newrelic callback et utilise l'agent New Relic Python pour la télémétrie APM. Sa documentation indique que le rappel enregistre un message d'initialisation et que les détails de la trace peuvent prendre deux à trois minutes pour apparaître. Cela suffit pour exiger un enregistrement d'itinéraire explicite. Cela ne prouve pas qu'une paire particulière dupliquera toujours un appel. La revendication de sécurité opérationnelle est plus étroite : si deux propriétaires sont observés pour une limite dont le manifeste en autorise une, les totaux et les verdicts de santé sont ambigus jusqu'à ce que le déploiement soit concilié. Utilisez un identifiant d'appel opaque plutôt qu'un hachage d'invite. Une enveloppe d’observation utile peut rester sans contenu : Le contenu des invites et des réponses n'est pas nécessaire pour la propriété, la fraîcheur, la présence du champ de jeton ou la vérification de la destination. LiteLLM documente à la fois un projet spécifique à New Relic turn off message logging paramètre et un commutateur d’environnement qui désactive l’enregistrement du contenu de surveillance AI. Traitez la conservation du contenu comme une décision distincte en matière de confidentialité ; ne l’activez pas simplement pour faire fonctionner l’audit de propriété. Rejouez les huit états que cache une vue verte L'audit qui l'accompagne utilise huit appels synthétiques. Il applique cette priorité : 1. aucune observation ; 2. propriétaire attendu absent ; 3. plus d'un propriétaire ; 4. type de signal inattendu ou champ obligatoire manquant ; 5. des preuves périmées ; 6. attente légitime ; 7. achèvement sans réception du résultat ; 8. achèvement avec un reçu de résultat. La priorité compte. Un dossier périmé provenant du bon propriétaire n’est pas sain. Un nouveau disque provenant du mauvais propriétaire n’est pas non plus sain. L'attente n'est évaluée qu'après la validation de la propriété, de la forme et de la fraîcheur, de sorte qu'une pause d'approbation ne peut pas masquer une collection interrompue. Le luminaire complet ne contient aucune invite ni réponse. Son exécution produit huit verdicts différents : Le classificateur est volontairement petit : Chaque verdict non sain pointe vers une réparation différente : Verdict Ce qu'il établit Prochaine action délimitée NO TELEMETRY Aucun enregistrement n'est arrivé pour l'appel attendu Vérifiez l'initialisation de l'instrumentation, l'accessibilité de l'exportateur et la fenêtre de requête ROUTE DRIFT Les données sont arrivées, mais pas du propriétaire déclaré Comparez le manifeste de déploiement avec le processus en cours et désactivez le chemin involontaire MULTIPLE OWNERS Plus d'un propriétaire d'instruments a observé la limite Mettre l'appel en quarantaine à partir des totaux ; choisissez un propriétaire ou enregistrez une exception de migration limitée dans le temps SCHEMA GAP La propriété est correcte, mais les preuves sont inutilisables ou incomplètes Corrigez le mappage de champ ou le contrat de type signal avant d'alerter dessus STALE La dernière preuve dépasse l'âge autorisé Inspecter le délai de l'exportateur, la file d'attente, l'alignement de l'horloge et l'heure des requêtes WAITING La collection est saine et une dépendance nommée demeure Prévenir le propriétaire ou attendre la date limite enregistrée ; ne redémarrez pas l'agent OUTCOME UNVERIFIED L'appel modèle réalisé sans preuve de l'effet demandé Exécutez la vérification déterministe de la destination HEALTHY La propriété, les preuves, l'état du travail et le résultat sont tous d'accord Conservez le reçu et appliquez la fenêtre de stabilité normale MULTIPLE OWNERS ne doit pas automatiquement supprimer ou fusionner les enregistrements. Lors d’une migration planifiée, la double collecte peut s’avérer utile. Rendre l'exception explicite avec une heure de début, une heure de fin, des propriétaires et une règle de rapprochement. Gardez les observations de migration en dehors des dénominateurs de coût de production et de fiabilité jusqu'à ce que les deux voies soient comparées. Sinon, un pic symbolique apparent pourrait être un changement d’instrumentation plutôt qu’un changement de comportement. Le luminaire montre également pourquoi un état rouge générique est faible. ROUTE DRIFT est un problème de déploiement ; STALE il peut s'agir d'un problème d'ingestion ou de fenêtre de requête ; WAITING n'est pas un échec ; et OUTCOME UNVERIFIED nécessite une vérification de destination plutôt qu'une autre requête de trace. Joindre l'observabilité à une réception de résultat La documentation de surveillance de l'IA de New Relic décrit les performances, les coûts, les jetons, les réponses, les traces et les commentaires des utilisateurs. Ce sont des signaux utiles sur la couche IA. Une réponse modèle peut toujours être suivie d'un appel d'outil ayant échoué, d'un fichier non validé, d'un e mail qui n'a jamais été envoyé ou d'une tâche en attente d'approbation. Pour cette raison, conservez le reçu de destination en dehors de la télémétrie de l'appel modèle : La destination et la méthode de vérification dépendent du travail. Utilisez une version d'objet pour un téléchargement de fichier, un hachage de validation et vérifie une modification de code, un ID de message de fournisseur pour une livraison ou une relecture d'API pour une mutation de configuration. Un code de sortie de commande est plus faible lorsque le résultat promis existe ailleurs. En rediffusion, false complete et healthy ont les deux mêmes types de signaux, propriétaire, champs et fraîcheur côté New Relic. Seul le reçu de destination change. C'est la limite opérationnelle : l'observabilité LLM explique les preuves d'appel de modèle ; le reçu prouve que le résultat escompté par l'agent existe. Un déploiement pratique est petit : 1. Choisissez une véritable limite d'appel de modèle. 2. Enregistrez le propriétaire de l'instrumentation attendu et les types de signaux autorisés dans le déploiement. 3. Générez un ID d’appel synthétique et interrogez chaque type d’événement New Relic pertinent. 4. Échec du déploiement si le propriétaire attendu est absent ou si un propriétaire non déclaré apparaît. 5. Vérifiez les champs obligatoires et un intervalle de fraîcheur limité. 6. Enregistrer working , une dépendance en attente nommée, ou complete séparément. 7. Exiger un reçu de destination déterministe avant de déménager complete en bonne santé. 8. Répétez l’opération après une mise à niveau du SDK, d’un rappel, d’un exportateur ou d’un agent. Cette procédure a une limite : elle ne prouve pas que chaque intégration prise en charge par New Relic doublera chaque combinaison de framework. Il prouve si votre déploiement observé correspond à son contrat de propriété déclaré. Il ne remplace pas non plus les contrôles de compatibilité de New Relic ni un test complet de conformité du schéma OpenTelemetry. Le rôle prévu de Sidewisp est adjacent à cette distinction : combiner des preuves sur l'accessibilité, les progrès utiles, les outils, les résultats, le temps et le budget dans une vue de la santé de l'agent. Sidewisp est actuellement en préversion privée. Le produit en direct est un site Web et une démonstration à accès anticipé ; un adaptateur New Relic de production, un moteur de surveillance et un exécuteur de récupération automatisée ne sont pas livrés. Utilisez l'audit ci dessus avec vos systèmes de télémétrie et de destination actuels plutôt que de supposer que Sidewisp les collecte ou les corrige aujourd'hui. La résolution est assez simple à appliquer : un propriétaire d'instrumentation déclaré par limite d'appel de modèle, plusieurs types de signaux uniquement lorsque le manifeste le permet, de nouvelles preuves sans contenu, un état d'attente explicite et une réception de résultat indépendante. Une vue verte New Relic ne devient fiable pour les opérations des agents qu’une fois que ces limites sont convenues.