Elastic LLM Observabilidade: Apoio à Auditoria antes do Green

A observabilidade elástica do LLM pode dizer lhe muito sobre chamadas de modelo, mas uma visão verde do Kibana ainda não é um veredicto de saúde do agente. Antes de confiar nele, verifique cinco camadas em ordem: o caminho de coleta, o suporte para o par de linguagem/provedor exato, a novidade da telemetria, os campos GenAI necessários e o resultado de destino. Essa ordem importa. Os documentos elásticos apresentam dois métodos de recolha: integrações de fornecedores para métricas e registros e rastreamento de aplicações através das distribuições elásticas de OpenTelemetry (EDOT). Esses métodos têm cobertura diferente. Mesmo um período de tempo LLM suportado e sem erros não prova que a lógica de negócios específica da aplicação tenha sido executada ou que o resultado prometido exista. Este guia transforma esses limites em uma pequena auditoria que você pode executar antes de limpar um incidente. Identificar o caminho de coleta antes de ler o painel de controle O LLM e AI de observabilidade agencial da Elastic descreve um amplo conjunto de integrações de provedores, traços de APM, métricas, logs e painéis de controle. O primeiro erro operacional é comprimir tudo isso em uma capacidade chamada monitorização elástica. Mantenha dois aviões de recolha separados: Avião O que produz a evidência Úteis para O que não estabelece Integração do fornecedor Um provedor ou serviço em nuvem envia métricas e registos Erros do fornecedor, latência, utilização, eventos de proteção, saúde da plataforma Que o seu pedido emitiu um período de LLM ou completou o seu próprio efeito de ferramenta Rastreamento das aplicações EDOT Um processo Java, Node.js ou Python instrumentado exporta extensões OTLP Fluxo de solicitações, chamadas de modelo, duração, erros, campos de tokens, correlação Que as bibliotecas não suportadas tenham sido instrumentadas ou que existe o deliverable externo Isto não é uma fraqueza do produto. É um limite de evidências. Uma integração do Bedrock pode fornecer métricas de serviço frescas enquanto uma aplicação Java não tem instrumentação documentada EDOT Bedrock LLM. Por outro lado, um espaço de cliente OpenAI pode ser completo enquanto uma escrita de banco de dados personalizada posterior não é instrumentada. O Página de suporte EDOT LLM atual da Elastic torna concreto o limite entre língua e fornecedor: Percurso do fornecedor EDOT Java EDOT Node.js EDOT Python : : : Cliente OpenAI Apoio Apoio Apoio AWS Bedrock Não incluído na lista Não incluído na lista Apoio Google Vertex AI Não incluído na lista Não incluído na lista Apoio A página etiqueta a observabilidade LLM nas três distribuições EDOT como prévia técnica e orienta os operadores para páginas específicas do SDK para versões exatas. Trata essa mesa como um instantâneo de apoio datado, não uma promessa de capacidade eterna. A auditoria começa, portanto, com duas perguntas às quais um painel de instrumentos não pode responder: 1. Que avião deve conter as provas deste incidente? 2. A linguagem implementada, o provedor, o pacote do cliente e a versão têm instrumentação documentada nesse avião? Se a resposta à segunda pergunta for não, não espere que apareça um espaço faltante. Classificar o caminho como não suportado, escolher instrumentos nativos ou manuais de OpenTelemetry documentados ou alterar o requisito de evidência. Nenhum erro no Elastic não é significativo quando o evento relevante nunca foi esperado para ser capturado. Suporte de teste e esquema como portas separadas Apoiado não significa observado, e observado não significa completo. O EDOT Python tabela de tecnologia documenta as versões do Python, os intervalos de pacotes do cliente, os nomes do rastreador e o status da convenção semântica. No momento da presente revisão, a sua linha de instrumentação OpenAI rotula as convenções semânticas como development . A mesma página diz explicitamente que a instrumentação automática não pode abranger estruturas personalizadas ou proprietárias, componentes não suportados de código fechado ou lógica de negócios específica de aplicativos. Isso dá nos quatro verificações distintas: 1. Support: a matriz documentada inclui o par de linguagem/provedor. 2. Reaccionabilidade: o colector e o caminho de ingestão aceitam telemetria corrente. 3. Presença: a corrida produz o esperado LLM span. 4. Schema: o espaço contém os campos necessários para a decisão do operador. Um contrato de campo mínimo pode exigir: Não confunda este exemplo com um esquema universal. Aplique as versões de convenção semântica e instrumentação utilizadas pela sua implantação. As antigas páginas da convenção GenAI da OpenTelemetry agora apontam para um Repositório dedicado de convenções semânticas da GenAI, que é outra razão para registrar a proveniência em vez de supor que um conjunto de atributos é atemporal. O classificador abaixo preserva os estados de falha importantes: Execute a auditoria contra um dispositivo em vez de testar apenas o caminho feliz: O acompanhamento de nove casos produziu nove veredictos esperados: Esta prioridade evita um erro comum de monitorização: deixar um sinal verde posterior ocultar uma lacuna de evidências anterior. Uma expansão bem sucedida não pode anular um cheque de colecionador inacessível, e uma expansão concluída não pode anular um recibo de destino faltante. Preservar a espera, a falta de evidências e o fracasso como estados diferentes Uma pausa de aprovação não é uma falha de instrumentação. Um período faltante não é automaticamente uma falha do fornecedor. Um caminho não apoiado não é telemetria obsoleta. Estas distinções alteram o próximo passo do operador: O veredicto Significado Ação seguinte limitada UNSUPPORTED PATH A instrumentação automática LLM esperada está fora da matriz documentada Adicionar extensões originais/manuais documentadas ou alterar o contrato de prova TELEMETRY STALE Existem provas relevantes, mas não dentro da janela de frescura da corrida Verifique a janela de exportação, coletor, ingestão, relógio e consulta INSTRUMENTATION GAP O caminho é suportado e a telemetria nova chega, mas o espaço LLM está ausente. Verificar a gama de pacotes, bootstrap, instrumentação desativada e identidade do rastreador SCHEMA GAP O espaço existe, mas não pode responder à pergunta requerida. Verifique a versão da convenção e o mapeamento de campos; informe o campo como indisponível enquanto isso WAITING Uma dependência ou aprovação nomeada é excepcional Avise o proprietário registrado; não tente novamente a ferramenta de forma cega FALSE COMPLETE Elastic mostra finalização limpa mas o resultado prometido não é verificado Realizar uma verificação determinista do destino antes de fechar o incidente Observe o que a tabela não recomenda: tratar cada lacuna como uma razão para reiniciar o agente. A recuperação sem diagnóstico pode duplicar efeitos externos, gastar mais tokens ou apagar evidências úteis. Para espera legítima, retém um proprietário, razão, hora de início, prazo e condição de retomada. Isso transforma uma pausa ambígua num estado operacional inspecionável. Se o prazo passar, o estado pode ficar preso ou precisar de atenção humana, mas a pausa original não foi um fracasso simplesmente porque não chegaram novos períodos. Exigir um recibo de resultado fora do rastro Um LLM span responde a uma pergunta de chamada de modelo. O material de entrega pertence ao pedido. Suponha que um agente peça a um modelo para preparar uma fatura, chama uma API interna e relata a conclusão. O Elastic pode mostrar: uma traça fresca; O fornecedor e o modelo esperados; Não há exceção; Latência plausível e contagem de tokens; Uma transacção raiz concluída. A fatura pode ainda estar ausente. A API personalizada pode ter aceitado o pedido sem comprometer se, um trabalhador assíncrono pode ter falhado ou o agente pode ter saltado a ferramenta e produzido apenas uma alegação textual. Defina o menor recibo determinista que prova o efeito prometido. Exemplos incluem: O objeto esperado existe no destino e corresponde a um hash de conteúdo; Uma linha de base de dados tem a chave de negócio prevista e o estado comprometido; Existe uma solicitação de puxão no repositório esperado e no SHA principal; Um ponto final de relatório retorna a nova versão e aprova a validação do esquema; um fornecedor de mensagens retorna um identificador de entrega que pode ser reconciliado posteriormente. Armazenar apenas as provas mínimas de segurança: A identificação de rastreamento fornece correlação. Não é a própria prova. Na fixação, a única diferença entre o FALSE COMPLETE e o HEALTHY é o outcomeVerified: true ; nenhum dos campos de intervalo elástico muda. Esta é a regra operacional central: limpar um incidente somente quando a cobertura telemétrica e a evidência dos resultados da aplicação concordarem. Tratar a privacidade e a deriva de versão como parte da saúde A visão geral da Elastic diz que o rastreamento LLM pode capturar pedidos e respostas. Isso pode ser útil para o diagnóstico, mas também muda os limites dos dados. Decidir explicitamente se o conteúdo é permitido antes de o habilitar. Preferir identificadores, comprimentos, hashes, classificações, contagens de tokens e categorias de erro editadas quando o conteúdo completo não é necessário. Registrar estes valores em cada auditoria de cobertura: Estabelecimento elástico e versão de distribuição EDOT; Tempo de execução de linguagem e versão instrumentada do pacote do cliente; Pacote de instrumentação ativa e nome do rastreador; Fonte e revisão da convenção semântica; o caminho de recolha e de ingestão; Os campos necessários e a janela de frescura; Política de captura de conteúdo; versão do verificador de destino. Reinicie a fixação quando algum desses valores mudar. Uma atualização do pacote pode adicionar suporte, renomear ou migrar campos, ou alterar a instrumentação padrão. Um objeto guardado no painel de instrumentos pode permanecer verde enquanto suas suposições silenciosamente se tornam obsoletas. O padrão prático é modesto: use Elastic para o modelo e evidências de aplicação que ele realmente coleta, mantenha os sinais não suportados ou faltantes explícitos e adicione um recibo determinista para o resultado que o usuário se importa. Isso produz uma decisão de saúde defensiva sem fingir que um painel de instrumentos possui cada camada. A Sidewisp está atualmente em prévia privada. Sua direção de produto é transformar evidências como acessibilidade, progresso, acesso a ferramentas, contexto, custo e resultados verificados em uma visão clara de saúde; adaptadores de monitoramento elástico ao vivo não são atualmente enviados. Se esta distinção entre a conclusão do rastro e o trabalho real for importante na sua pilha de agentes, a lista de espera de antevisão privada é o lugar apropriado para compartilhar o caso de falha que você precisa cobrir.