Observabilidade do New Relic LLM: prove que uma rota possui cada chamada

A observabilidade do New Relic LLM pode mostrar latência do modelo, tokens, erros, rastreamentos e dados de resposta de IA. Ele não pode, por si só, dizer a um operador se dois coletores contaram a mesma chamada de modelo ou se o agente produziu o resultado externo solicitado. O padrão prático é nomear um proprietário de instrumentação para cada limite de chamada de modelo , correlacionar cada registro a um ID de chamada sem conteúdo e manter um recibo separado para a entrega. Essa regra é importante porque a New Relic documenta vários caminhos legítimos. É nativoMonitoramento de IAusa agentes APM. New Relic também documentaOpenLIT sobre OTLPpara rastreamentos e métricas eOpenLLMetry sobre OTLPpara vestígios. LiteLLM tem um separadoIntegração da Nova Relíquiaconstruído em torno de seu retorno de chamada e do agente New Relic Python. Esses caminhos são opções e não evidências de que todos deveriam instrumentar o mesmo limite. Um painel pode ser preenchido enquanto a propriedade está errada, a evidência está obsoleta, um campo obrigatório está ausente ou uma chamada de modelo concluída não tem resultado verificado. Declare a rota antes de confiar na carta Comece com um manifesto de implantação, não com uma consulta. Deve identificar o serviço, o limite que está sendo instrumentado, o único proprietário autorizado a reportar esse limite, os tipos de sinal que o proprietário pode emitir, o campo de correlação e o limite de atualização. A distinção entre um proprietário e um tipo de sinal evita um erro grosseiro de desduplicação. Um proprietário declarado pode emitir deliberadamente um intervalo de APM e um evento de mensagem de IA para a mesma chamada. Esses registros são complementares quando compartilham o mesmo ID de chamada e o contrato de implantação espera ambos. Um registro OpenLIT e um registro OpenLLMetry para esse mesmo limite são dois proprietários, mesmo que seus campos sejam semelhantes. O manifesto deve ser produzido pela implantação que permitiu a instrumentação. Não infira isso de qualquer entidade que apareça na IU. Os caminhos de configuração estabelecem a identidade de maneira diferente: O monitoramento da New Relic AI começa com um agente APM e uma biblioteca ou estrutura compatível. OpenLIT envia rastreamentos e métricas para o endpoint OTLP da New Relic. OpenLLMetry envia rastreamentos para esse endpoint e New Relic deriva a entidade de serviço do OpenTelemetry service.name atributo de recurso. LiteLLM permite um newrelic retorno de chamada e usa o agente New Relic Python para telemetria APM. Sua documentação diz que o retorno de chamada registra uma mensagem de inicialização e que os detalhes do rastreamento podem levar de dois a três minutos para aparecer. Isto é suficiente para exigir um registro de rota explícito. Não há evidência de que qualquer par específico sempre duplique uma chamada. A reivindicação operacional segura é mais restrita: se dois proprietários são observados para uma fronteira cujo manifesto permite um, os totais e os veredictos de saúde são ambíguos até que a implantação seja reconciliada. Use um identificador de chamada opaco em vez de um hash de prompt. Um envelope de observação útil pode permanecer livre de conteúdo: O conteúdo de prompt e resposta é desnecessário para propriedade, atualização, presença de campo de token ou verificação de destino. LiteLLM documenta uma versão específica da New Relic turn off message logging configuração e uma opção de ambiente que desativa a gravação de conteúdo de monitoramento de IA. Trate a retenção de conteúdo como uma decisão de privacidade separada; não ative o apenas para fazer a auditoria de propriedade funcionar. Repita os oito estados que uma visão verde esconde A auditoria anexa utiliza oito chamadas sintéticas. Aplica esta precedência: 1. nenhuma observação; 2. esperado proprietário ausente; 3. mais de um proprietário; 4. tipo de sinal inesperado ou campo obrigatório ausente; 5. evidências obsoletas; 6. espera legítima; 7. conclusão sem recibo de resultado; 8. conclusão com um recibo de resultado. A precedência é importante. Um registro obsoleto do proprietário correto não é íntegro. Um novo registro do proprietário errado também não é saudável. A espera é avaliada somente depois que a propriedade, a forma e o frescor passam, portanto, uma pausa de aprovação não pode ocultar a quebra da coleção. O equipamento completo não contém avisos ou respostas. Executá lo produz oito veredictos diferentes: O classificador é deliberadamente pequeno: Cada veredicto não saudável aponta para um reparo diferente: Veredicto O que estabelece Próxima ação limitada NO TELEMETRY Nenhum registro chegou para a chamada esperada Verifique a inicialização da instrumentação, a acessibilidade do exportador e a janela de consulta ROUTE DRIFT Os dados chegaram, mas não do proprietário declarado Compare o manifesto de implantação com o processo em execução e desative o caminho não intencional MULTIPLE OWNERS Mais de um proprietário de instrumentação observou o limite Colocar a chamada em quarentena dos totais; escolha um proprietário ou registre uma exceção de migração com limite de tempo SCHEMA GAP A propriedade está correta, mas a evidência é inutilizável ou incompleta Corrija o mapeamento de campo ou contrato de tipo de sinal antes de alertar sobre ele STALE As últimas evidências excedem a idade permitida Inspecione o atraso do exportador, o enfileiramento, o alinhamento do relógio e o tempo de consulta WAITING A coleção está íntegra e uma dependência nomeada permanece Notificar o proprietário ou aguardar até o prazo registrado; não reinicie o agente OUTCOME UNVERIFIED A chamada do modelo foi concluída sem comprovação do efeito solicitado Execute a verificação determinística do destino HEALTHY Propriedade, evidências, estado de trabalho e resultado, todos concordam Guarde o recibo e aplique a janela normal de estabilidade MULTIPLE OWNERS não deve excluir ou mesclar registros automaticamente. Durante uma migração planeada, a recolha dupla pode ser útil. Torne a exceção explícita com um horário de início, horário de término, proprietários e regra de reconciliação. Mantenha as observações de migração fora dos denominadores de custo de produção e confiabilidade até que os dois caminhos sejam comparados. Caso contrário, um aparente pico de token pode ser uma mudança de instrumentação, e não uma mudança de comportamento. O acessório também mostra porque um estado vermelho genérico é fraco. ROUTE DRIFT é um problema de implantação; STALE pode ser um problema de ingestão ou de janela de consulta; WAITING não é um fracasso; e OUTCOME UNVERIFIED requer uma verificação de destino em vez de outra consulta de rastreamento. Junte a observabilidade a um recibo de resultado A documentação de monitoramento de IA da New Relic descreve evidências de desempenho, custo, token, resposta, rastreamento e feedback do usuário. Esses são sinais úteis sobre a camada de IA. Uma resposta de modelo ainda pode ser seguida por uma chamada de ferramenta com falha, um arquivo não confirmado, um e mail que nunca foi enviado ou um trabalho que está aguardando aprovação. Por esse motivo, mantenha o recibo de destino fora da telemetria de chamada de modelo: O destino e o método de verificação dependem da obra. Use uma versão do objeto para um upload de arquivo, um hash de commit e verificações de uma alteração de código, um ID de mensagem do provedor para uma entrega ou uma leitura de API para uma mutação de configuração. Um código de saída de comando é mais fraco quando o resultado prometido existe em outro lugar. Na repetição, false complete e healthy têm os mesmos dois tipos de sinal do lado da New Relic, proprietário, campos e atualização. Apenas o recibo de destino muda. Esse é o limite operacional: a observabilidade do LLM explica a evidência da chamada do modelo; o recibo comprova que o resultado pretendido pelo agente existe. Uma implementação prática é pequena: 1. Escolha um limite real de chamada de modelo. 2. Registre o proprietário esperado da instrumentação e os tipos de sinal permitidos na implantação. 3. Gere um ID de chamada sintético e consulte cada tipo de evento relevante da New Relic para ele. 4. A implementação falhará se o proprietário esperado estiver ausente ou se algum proprietário não declarado aparecer. 5. Verifique os campos obrigatórios e um intervalo de atualização limitado. 6. Registro working , uma dependência de espera nomeada ou complete separadamente. 7. Exigir um recibo de destino determinístico antes de se mudar complete para saudável. 8. Repita após uma atualização de SDK, retorno de chamada, exportador ou agente. Este procedimento tem uma limitação: não prova que cada integração apoiada pela New Relic irá duplicar cada combinação de estrutura. Isso prova se sua implantação observada corresponde ao contrato de propriedade declarado. Ele também não substitui as verificações de compatibilidade do New Relic ou um teste completo de conformidade do esquema OpenTelemetry. O papel pretendido do Sidewisp é adjacente a esta distinção: combinar evidências sobre acessibilidade, progresso útil, ferramentas, resultados, tempo e orçamento numa visão de saúde do agente. A Sidewisp está atualmente em prévia privada. O produto ao vivo é um site de demonstração e acesso antecipado; um adaptador New Relic de produção, mecanismo de monitoramento e executor de recuperação automatizado não são enviados. Use a auditoria acima com seus sistemas atuais de telemetria e destino, em vez de presumir que o Sidewisp os coleta ou corrige hoje. A resolução é simples o suficiente para ser aplicada: um proprietário de instrumentação declarado por limite de chamada de modelo, vários tipos de sinal somente quando o manifesto permitir, novas evidências sem conteúdo, um estado de espera explícito e um recebimento de resultado independente. Uma visão verde da New Relic se torna confiável para as operações dos agentes somente depois que esses limites são acordados.