Observabilidade LLM na AWS: auditar destinos de extensão do AgentCore

A resposta prática para observabilidade LLM na AWS não é “abrir o painel do CloudWatch”. Primeiro, prove onde o Amazon Bedrock AgentCore deve entregar spans, depois pesquise todos os destinos que ainda possam conter evidências, verifique a identidade da sessão e do rastreamento, rejeite observações obsoletas e junte o rastreamento a um recibo separado para o resultado externo pretendido. Essa ordem é importante porque o destino do AgentCore pode mudar. A documentação atual da AWS diz que novos agentes com suporte podem enviar períodos para um grupo de log por agente, enquanto configurações mais antigas podem usar o compartilhado aws/spans grupo. Versões ADOT anteriores 0.18.0 ignore a configuração de destino unificado. A alteração da configuração não move vãos antigos. Uma consulta apenas no grupo de logs atual pode, portanto, produzir um diagnóstico falso de “sem telemetria”, mesmo quando a evidência faltante está exatamente onde a configuração anterior a colocou. Este guia cria uma auditoria sem conteúdo para esse limite. Ele usa identidade de recurso, versão, destino, carimbos de data/hora, identificadores de correlação, estado de execução e um recebimento de resultado booleano. Não requer prompts, respostas, argumentos de ferramentas ou segredos. Localize a evidência antes de declará la desaparecida Observabilidade do AgentCorefornece métricas integradas para recursos do AgentCore e armazena métricas, intervalos e logs no Amazon CloudWatch. O limite importante é que as métricas integradas não são iguais aos rastreamentos de aplicativos. A AWS documenta intervalos padrão para recursos de memória, enquanto o tempo de execução do agente e os detalhes do rastreamento do gateway dependem da instrumentação. Isso cria três questões distintas: 1. O caminho de observação da AWS está habilitado? O CloudWatch Transaction Search deve estar habilitado e o destino do segmento de rastreamento deve ser CloudWatch Logs. 2. Onde devem chegar os períodos atuais? A resposta depende da configuração do destino unificado, do suporte da região, da idade do agente, da função de execução e da versão do ADOT. 3. Onde podem permanecer os intervalos históricos? Qualquer destino usado antes de uma mudança permanece parte da janela de investigação porque a AWS não migra os dados de intervalo existentes. OGuia de configuração do AgentCorefornece um limite operacional particularmente útil: a entrega unificada por agente requer aws opentelemetry distro =0.18.0 . Versões anteriores ignoram a configuração e entregam spans ao grupo compartilhado. O mesmo guia requer permissão para instalar a política de recursos relevante do CloudWatch Logs. Use esses fatos para calcular um destino esperado antes de consultar: Observação Escopo de pesquisa atual esperado Conclusão do operador Pesquisa de transação desativada Nenhum é confiável ainda Corrigir configuração; não inferir a saúde do agente Segmentos de rastreamento não roteados para o CloudWatch Logs Nenhum é confiável ainda Corrija o pré requisito de destino Unificado solicitado, ADOT abaixo 0.18.0 Compartilhado aws/spans Um grupo por agente em branco é um erro no escopo da consulta Política unificada de ativos e funções permitida Grupo de logs de tempo de execução por agente Verifique os intervalos atuais lá Destino alterado durante a janela de revisão Grupos atuais e anteriores Pesquise ambos; velhos vãos ficam onde pousaram Esta tabela não é deliberadamente uma única verificação de “telemetria presente”. Um registro ausente no grupo por agente pode significar falha na configuração, entrega bloqueada, uma versão antiga do ADOT ou um registro histórico correto no grupo compartilhado. Esses estados precisam de reparos diferentes. Mantenha um registro de transição de destino Não faça do ambiente ativo sua única fonte de verdade. Armazene um pequeno registro de transição ao lado do runbook: O registro não contém conteúdo de prompt ou resposta. Ele responde à questão do planejamento de consultas que um painel não pode reconstruir posteriormente: quais destinos se sobrepõem à janela do incidente? Execute uma auditoria AgentCore com reconhecimento de migração A auditoria utilizada neste artigo avalia onze casos fixos. Seu contrato de insumos é intencionalmente pequeno: A sua ordem de decisão é mais importante que a sua sintaxe: Executar o classificador sobre o fixture produziu: Os casos abrangem pesquisa de transação desabilitada, destino de rastreamento errado, ADOT antigo consultado apenas no grupo por agente, evidência histórica omitida após uma troca, autoridade de entrega insuficiente, intervalo de corrente ausente, evidência obsoleta, correlação quebrada, espera de aprovação legítima, conclusão falsa e resultado saudável com reconhecimento de migração. Este é um teste de decisão, não uma prova sobre uma conta ativa da AWS. Adapte suas entradas de sua própria configuração e consultas canário. Preservar a ordem: caso contrário, um genérico telemetry missing o veredicto pode ocultar o fato muito mais acionável de que o operador procurou no lugar errado. Preservar a identidade da sessão, a identidade do rastreamento e a atualização A AWS descreve a observabilidade do AgentCore como uma hierarquia: uma sessão contém rastreamentos e um rastreamento contém intervalos. Odocumentação de telemetriatorna essa hierarquia explícita. É útil apenas se a identidade sobreviver ao caminho da solicitação. Para chamadas de tempo de execução do AgentCore instrumentadas por ADOT, o guia de configuração documenta dois detalhes de propagação: enviar X Amzn Bedrock AgentCore Runtime Session Id então o ID da sessão atinge a telemetria downstream; invocar o tempo de execução com traceId=<traceId quando um ID de rastreamento deve ser propagado. Registre se esses identificadores estão presentes, e não seu contexto de carga sensível. Um período sem sessão juntável ainda pode provar que o código foi executado, mas não pode suportar um cronograma de incidente no nível da sessão. Classifique isso como correlation broken , não é saudável. A frescura precisa de um contrato igualmente explícito. Um vestígio encontrado na semana passada não prova que a entrega funciona agora. Definir: Escolha a idade máxima entre a cadência esperada e a tolerância a incidentes do fluxo de trabalho. Cinco minutos são razoáveis ​​para um canário de cada minuto; não é razoável para um lote noturno. Armazene o limite com o veredicto para que “fresco” permaneça inspecionável. Esperar também precisa de evidências. Se um rastreamento mostrar uma dependência de aprovação limitada com um proprietário e a execução for retomável, retorne waiting . Não a coloque como travada apenas porque nenhuma nova extensão de ferramenta apareceu. Se o registro de aprovação estiver ausente, contraditório ou expirado, devolva uncertain ou escalar de acordo com o runbook. Exigir um recibo de resultado após o rastreamento Um rastreamento completo responde “o caminho de execução instrumentado foi concluído?” Não responde necessariamente “o trabalho pretendido aconteceu?” A distinção é visível em falhas comuns: uma ferramenta de upload retorna antes que o destino confirme o objeto; uma API de mensagem aceita uma solicitação, mas a mensagem nunca chega ao canal pretendido; um agente grava um arquivo local enquanto o artefato necessário pertence ao armazenamento remoto; a chamada do modelo final é bem sucedida depois que uma transação downstream já foi revertida; uma espera de aprovação é convertida incorretamente em sucesso do terminal. Orientação prescritiva da AWSrecomenda correlacionar as evidências do LLM com o impacto posterior. Uma implementação com privacidade mínima pode fazer isso com um recibo de resultado: O recibo deve ser produzido pela verificação determinística mais forte disponível: um objeto HEAD , um banco de dados lido por uma chave estável, uma busca de API pública, uma soma de verificação ou um teste direcionado. Não deve conter o corpo do objeto, prompt, resposta ou segredo. Mantenha os dois veredictos separados: Evidência de rastreamento Recibo de resultado Estado Ausente ou obsoleto Qualquer A evidência de observabilidade é insuficiente Completo Ausente false complete Aguardando aprovação registrada Ainda não esperado waiting Completo e fresco Presente e verificado healthy para este resultado testado A linha final tem escopo definido. Isso prova o canário e o destino fixos, não todas as rotas, todas as tarefas ou a qualidade semântica da saída. Adote a auditoria sem coletar conteúdo Um recibo de produção útil precisa apenas de dados suficientes para distinguir as camadas de falha: identificadores de recursos e terminais do agente em formato editado ou com hash; Região e tempo de observação; Pesquisa de transação e status de destino de rastreamento; Versão ADOT e configuração de destino unificado; classes de destino atuais e anteriores; se ambos os destinos foram pesquisados ​​para a janela de investigação; horário canário correspondente mais recente; presença de ID de sessão e ID de rastreamento; estado de execução e estado de aprovação limitado; identidade de operação estável e status determinístico de recebimento de resultados. Mantenha o texto do prompt, as respostas do modelo, os argumentos da ferramenta, as credenciais, os cabeçalhos brutos e as cargas do cliente fora deste recibo. Se for necessária uma inspeção de conteúdo mais profunda para um incidente específico, autorize e defina o escopo separadamente. A auditoria também tem limites. Ele não comprova a cobertura da instrumentação em todas as rotas de aplicação, a integridade da amostragem, a retenção do CloudWatch, a recuperação de exportação ou a qualidade semântica da resposta. Isso prova que o caminho de evidência selecionado está configurado e pesquisável, o canário é atualizado e correlacionado e o resultado externo selecionado tem seu próprio recibo. Isso é suficiente para evitar um erro de categoria caro: alterar o agente porque um operador pesquisou o destino de intervalo errado. A Sidewisp está atualmente em prévia privada.Sua função pretendida é transformar evidências como cobertura de destino, atualização, correlação, estado de espera e verificação de resultados em uma visão clara da saúde. Os adaptadores de monitoramento Production AgentCore e CloudWatch não são enviados atualmente, portanto, este artigo é um padrão operacional que você pode aplicar agora, e não uma afirmação de queSidewispjá executa esta auditoria.