Datadog LLM Observabilidade para Bedrock: Prove o rastro interno

Datadog LLM Observabilidade para Bedrock pode explicar uma chamada de modelo capturada ou invocação de agente, mas um vestígio visível ainda não é um veredicto de saúde. Para um Agente Amazon Bedrock existente, são necessários cinco recibos: a configuração pretendida foi preparada, o alias ou versão correta foi executada, eventos de rastreamento interno chegaram, qualquer ação de transferência atingiu um estado definido, e o resultado prometido existe em seu destino. Essa distinção importa agora. A AWS diz que a Amazon Bedrock Agents é agora Amazon Bedrock Agents Classic e não estará mais aberta a novos clientes a partir de 30 de julho de 2026; os clientes existentes podem continuar a usá lo. Este guia constitui, portanto, uma auditoria das instalações existentes da Bedrock Agents Classic. Não se trata de uma recomendação de campo verde e não se assume que uma integração com o AgentCore tenha telemetria idêntica. Comece com o contrato exato do Bedrock que está a rastrear. A primeira armadilha é tratar o rastreamento de Bedrock como uma característica. Datadog documenta o rastreamento automático dos métodos de execução do Bedrock InvokeModel() e InvokeModelWithResponseStream() . Esses intervalos podem conter latência, erros, mensagens e uso de tokens para uma chamada modelo. Um Agente Bedrock usa uma operação diferente: InvokeAgent . A referência atual de instrumentação automática do Datadog diz que sua integração com Python Bedrock Agents rastreia a chamada geral InvokeAgent por padrão. Para expor os passos intraagentes, o pedido deve utilizar o enableTrace=True . A AWS dá ao mesmo interruptor um significado operacional: a habilitação de rastreamento segue o processo de raciocínio, as ações e o resultado do agente. A resposta InvokeAgent é um fluxo de eventos que pode conter pedaços de saída, eventos de rastreamento, erros, citações e uma carga útil de controle de retorno. Portanto, ver apenas a chamada externa prova menos do que ver a orquestração, a base de conhecimentos, o guarda roupa e a evidência do grupo de ação dentro dela. Capa de evidências O que isso prova O que não prova Espaço do modelo de cama Uma invocação de modelo capturada, duração, erros e campos de uso disponíveis Que versão do agente pediu a chamada ou se a tarefa terminou InvokeAgent extensão de raiz A aplicação invocou o tempo de execução do Agente Bedrock Aquela orquestração aninhada foi capturada . Eventos de rastreamento aninhados A invocação selecionada expôs o raciocínio interno e as etapas de ação Que o projecto previsto tenha sido elaborado ou que exista o efeito externo Parcela de resposta concluída Bedrock respondeu a resposta final da interação. Que o entregado prometido passou aceitação Receita de destino Um arquivo, registro, mensagem ou outro efeito esperado existe e é válido Por que um agente anterior se comportou assim ? O padrão útil é manter a instrumentação automática para chamadas suportadas e adicionar um pequeno recibo de saúde livre de conteúdo em torno do InvokeAgent . Não carregue pedidos, credenciais, argumentos de ferramentas ou respostas completas apenas para estabelecer o estado. Armazenar identificadores, timestamps, booleans, contagens e hashes quando eles são suficientes. Recolher cinco recibos para cada invocação importante A auditoria torna se gerenciável quando cada fronteira possui um recibo. 1. Receita de configuração preparada A AWS distingue o projeto de trabalho das versões preparadas e dos pseudónimos. Após alterar o esboço de trabalho, deve prepará lo antes do teste ou da implantação. A AWS também recomenda verificar o valor preparedAt do agente. Registo: A regra determinista é simples: Se falhar, classifique a corrida como CONFIG NOT PREPARED . Não depurar um rastro detalhado como se representasse a configuração pretendida. 2. Receita de identidade de invocação Reutilizar o mesmo Bedrock sessionId somente quando continuar a mesma conversa. Mantenha o alias ou a versão selecionada ao lado de um hash de sentido único do identificador de sessão. Isso liga o espaço de raiz do Datadog, o fluxo de eventos do Bedrock e o alcance esperado do operador sem reter o conteúdo do usuário. Um rastro recente com o alias errado é evidência de escopo errado, não evidência saudável. 3. Receita de cobertura interna Estabelecer a habilitação de rastreamento no pedido quando a questão operacional depender de passos internos: Nunca imprima os valores num diagnóstico de produção. O recibo só requer: Se o espaço da raiz existir, mas o rastro for desativado ou não ocorrer nenhum evento aninhado, retorne o TRACE INCOMPLETE . É um veredicto de cobertura. Não prova que o agente falhou. Da mesma forma, um espaço de raiz do Datadog faltante deve ser TRACE MISSING , não AGENT FAILED . A amostragem, a configuração do exportador, o transporte, as versões de biblioteca não suportadas ou a ordem de instrumentação podem remover evidências. O Datadog expõe uma configuração da taxa de amostragem de rastreamento, por isso a ausência deve preservar a incerteza. 4. Receita do Estado de ação Um agente pode invocar um grupo de ação apoiado pela Lambda, consultar uma base de conhecimentos ou devolver o controle ao aplicativo de chamada. No caminho de retorno controle, o pedido recebe a ação prevista e deve apresentar um resultado para continuar. Registrar se: ocorreu um erro de ação; Chegou uma carga útil de controlo de retorno; O pedido apresentou o resultado da ação correspondente; Uma resposta ainda está pendente. Quando o controlo de devolução estiver presente e não tiver sido apresentado nenhum resultado, o estado correto é WAITING FOR ACTION RESULT . Tem um proprietário e uma ação seguinte. Chamá lo de preso cria alertas barulhentos; chamá lo completo perde o trabalho. 5. Receita do resultado O Datadog pode colocar avaliações personalizadas ao lado de um rastro, e essas avaliações são úteis para verificações subjetivas de qualidade ou políticas. Preferir um verificador determinista quando a promessa é inspecionável: Entrega de arquivo: caminho esperado, MIME, tamanho, soma de verificação e esquema; Escrever base de dados: chave de registro, versão e campos exigidos; Mensagem de saída: recibo do fornecedor e hash de destino; implantação: revisão alvo mais uma verificação de saúde independente; Resposta de conhecimento: citações necessárias mais uma regra de aceitação de domínio. O recibo do resultado deve conter a prova mínima necessária para reproduzir o veredicto. Uma resposta dizendo done não é um desses campos. Executa a regra de decisão de oito estados O artefacto acompanhante aplica os recibos em ordem fixa. Fronteiras anteriores impedem que evidências posteriores criem um falso verde: Eu corri este classificador contra oito casos sem conteúdo. Todos os oito coincidiram com os veredictos esperados: A fixação dá deliberadamente o outcomeVerified: true à caixa de preparação em desatualização. Ele ainda retorna CONFIG NOT PREPARED , porque um resultado da configuração preparada erroneamente não pode certificar a liberação prevista. Também dá uma resposta completa de Bedrock ao caso falso completo; sem o recibo de destino, o veredicto final permanece vermelho. A rota de cada veredicto para uma ação limitada O classificador é útil apenas se os seus estados alterarem o próximo movimento do operador. O veredicto Primeira acção Não o faça. CONFIG NOT PREPARED Preparar o esboço previsto, confirmar o preparedAt , e depois repetir um canário. Diagnóstico de vestígios antigos como o novo lançamento TRACE MISSING Verificar as versões do SDK e do tracer suportados, a ordem de inicialização, a entrega ao exportador e a amostragem Tente novamente o agente como se a ausência provasse falha . TRACE INCOMPLETE Confirme que o enableTrace=True e os eventos aninhados chegam ao rastro do Datadog Liga para a cobertura completa de agentes WORKING Esperar dentro do prazo da invocação enquanto os progressos aninhados mudarem Alerta apenas sobre o tempo passado WAITING FOR ACTION RESULT Enviar o pedido de controlo de devolução ao seu proprietário com um prazo Reinicie o agente ou marque o preso ACTION FAILED Inspectar a primeira ação falhada e o seu limite de erro; tentar novamente apenas se o efeito for seguro Reproduzir um efeito colateral incerto cegamente FALSE COMPLETE Execute o verificador de destino e repare o resultado faltante Aceitar o texto de resposta final como entrega HEALTHY Mantenha o recibo compacto e feche a corrida Preservação de cargas úteis sensíveis Just in case Esta ordem também esclarece a propriedade do incidente. Os problemas de cobertura de dados pertencem à instrumentação ou ao transporte. Uma espera de controlo de devolução pertence ao aplicativo ou ao ser humano que é dono da decisão externa. Uma ação fracassada pertence ao limite da ferramenta. Um documento de entrega faltante pertence ao verificador de resultados. Um alerta de erro genérico agente não pode conter essas distinções. Mantém os limites de Datadog e Sidewisp honestos Datadog Agent Observability é o lugar certo para inspecionar traços capturados, estrutura de espaço, latência de modelo e ferramenta, uso de tokens disponíveis, erros e avaliações. A documentação de integração do Bedrock fornece passos concretos de configuração e validação, incluindo a verificação do status do rastreador e o depuração dos problemas de transmissão. A auditoria acima acrescenta um limite de libertação e de resultado; não diminui a evidência de rastreamento. Impede que essa evidência responda a uma pergunta que não foi concebida para responder sozinha. Permanecem três limitações: 1. A fixação valida a prioridade da decisão, não a veracidade dos dados AWS, Datadog ou destino. 2. A amostragem pode eliminar intencionalmente os vestígios. Uma cobertura SLO necessita de um canário controlado ou de outro denominador; a ausência de traços de produção por si só é ambígua. 3. Um juiz LLM pode ajudar na qualidade subjetiva das respostas, mas não deve substituir uma verificação determinista do destino para um efeito inspecionável. Para as implementações existentes do Bedrock Agents Classic, a linha de chegada prática é, portanto, a versão atual preparada, o escopo de invocação correto, o rastreamento interno completo quando necessário, o estado de ação resolvido e o resultado verificado. Qualquer coisa menos deve continuar a funcionar, a esperar, a ser incerta ou a falhar. A Sidewisp está atualmente em prévia privada. Pretende adicionar uma camada de saúde do agente em torno dos tempos de execução existentes, mas os adaptadores de produção Bedrock e Datadog não são enviados. Junte se à prévia privada se este fluxo de trabalho de evidências para a saúde coincidir com a forma como você opera agentes; continue usando Datadog e AWS como a documentação atual suporta hoje. Fontes Datadog Amazon integração Bedrock Instrumentação automática do Datadog para a Observabilidade do Agente Datadog: Agentes de monitoramento construídos no Amazon Bedrock AWS InvokeAgent API referência AWS: Test e solução de problemas comportamento do agente