AI Agente Observabilidade: Traços de amostras, Manter evidências de saúde

A observabilidade do agente AI não deve exigir a conservação de todos os vestígios, mas nunca deve permitir que a amostragem de vestígios decida se existe um evento de saúde crítico. Analise o caminho pesado de diagnóstico quando o volume ou o custo o exigir. Enviar recibos de saúde compactos e digitalizados falha de resultados, espera de aprovação, falha de ferramentas, tempo de execução inacessível e falta de entrega através de um caminho separado com as suas próprias verificações de entrega e de frescura. Essa divisão resolve um problema específico. Um rastro é uma excelente evidência de por que uma corrida se comportou como fez. Não é o único local a partir do qual um operador pode saber que falta o trabalho esperado. Um tempo de corrida que não pode ser alcançado pode não emitir nenhum rastro. Uma sessão que aguarda corretamente a aprovação pode não ter um período de erro. Uma execução pode terminar com extensões OK enquanto um verificador externo constata que o arquivo solicitado não existe. A falha razoável é, portanto, duas políticas de retenção, e não uma amostragem inteligente: aplicar amostragem de cabeça ou cauda para os vestígios de diagnóstico, e reter todos os recibos de saúde obrigatórios por um período mais curto e explicitamente limitado. Junte os dois registos com uma identificação de execução estável quando um rastro estiver disponível. Não armazenem pedidos crus ou cargas de ferramentas sem restrições apenas para manter o veredicto de saúde. Traços de amostras; guardar recibos de saúde A Documentação de amostragem da OpenTelemetry utiliza uma definição estreita e útil: um rastro recolhido na amostra é processado e exportado; um rastro não recolhido na amostra não é processado ou exportado. A amostragem da cabeça é tomada precocemente, comumente a partir de uma identificação de rastro e da percentagem desejada, sem inspecionar toda a rastreia. A amostragem de cauda aguarda mais ou todos os vestígios e pode manter vestígios por erro, latência, atributos ou outros critérios. Esses mecanismos otimizam uma população de vestígios. Uma política de saúde dos agentes responde a uma pergunta diferente: que observações são necessárias para decidir se o trabalho é saudável, à espera, preso, inacessível ou falsamente concluído? Registo Propósito Padrão de amostragem Exemplos de provas Traço de diagnóstico Explicar a execução e depurar uma execução selecionada Amostra quando justificada por volume e custo intervalos, duração da ferramenta, chamadas de modelo, caminho de erro Receita de saúde Preservar um facto operacional que altera o estado Mantém todas as espécies obrigatórias O resultado da predicada falhou, aprovação necessária, batimento cardíaco perdido. Métrica agregada Taxas de medição e capacidade Agregado antes do armazenamento, sempre que possível Taxa de retomada, profundidade da fila, perda de recibo Carga útil sensível Reproduzir conteúdo apenas sob uma autoridade separada Não cobrar por defeito Pronto, argumentos de ferramentas, resposta bruta A distinção não torna inútil a amostragem de cauda. Uma regra de cauda que sempre mantém vestígios contendo um espaço ERROR é valiosa. Ainda não pode manter um rastro que nunca chegou, e não pode inferir que um rastro de aparência bem sucedida falhou num controlo externo de entregabilidade. A Documentação do processador de amostragem de cauda do colecionador é explícita sobre um pré requisito importante: todos os intervalos de um rastro devem chegar à mesma instância do colecionador para uma decisão eficaz. Trate esse pré requisito como um limite, não como uma falha. A amostragem de vestígios opera após a existência de provas de vestígios. Os recibos de saúde também devem cobrir falhas fora desse caminho. Definir o contrato de saúde não incluído na amostra Mantenha o recibo pequeno o suficiente para que a retenção de todos os tipos obrigatórios seja ordinária, não heroica. Um registro útil precisa de identidade, semântica, frescura das evidências e fontenão de uma transcrição: Os dois relógios importam. O Modelo de dados OpenTelemetry Logs estável define o Timestamp como o momento em que ocorreu um evento na fonte e o ObservedTimestamp como o momento em que o sistema de recolha o observou. Preserve ambas as semânticas num recibo de saúde. Um recibo atrasado pode ainda descrever uma falha real, mas o seu atraso na entrega e a idade da prova devem permanecer visíveis. Utilize um breve registo obrigatório de tipo pertencente ao fluxo de trabalho, não ao fornecedor de armazenamento. Um conjunto inicial para operações de agentes pode ser: outcome failed : um verificador específico de tarefa rejeitou o resultado prometido; approval wait : a corrida tem uma dependência humana tipografada e um proprietário; tool error : uma operação requerida da ferramenta falhou após a sua política de retomada limitada; runtime unreachable : um observador externo não conseguiu atingir o tempo de execução no prazo previsto; missing deliverable : a corrida declarou se concluída, mas o artefato esperado estava ausente. O produtor faz parte do contrato. Um verificador de resultados pode emitir outcome failed ; um adaptador de tempo de execução pode emitir approval wait ; um programador externo ou um observador cardíaco deve emitir runtime unreachable . Requer um tempo de execução inacessível para relatar a sua própria inacessível é um projeto circular. Para cada recibo, aplicar quatro verificações antes de mudar de estado: 1. Detuplicar por receipt id ou uma chave de evento estável. 2. Validar o schema version , o kind , o run id e a autoridade do produtor. 3. Compare o occurred at e o observed at com os limites de frescura por espécie. 4. Atualizar a saúde por prioridade explícita, preservando o unknown quando faltam provas necessárias. Não permita que um recibo autorize uma ação irreversível. Pode abrir um número, encaminhar uma espera ou preparar uma resposta limitada. A recuperação ainda necessita do limite de aprovação relevante e de uma nova observação que comprova um progresso útil ou o resultado esperado. Reproduzir a decisão de retenção A fixação conservada contém quarenta corridas sintéticas e cinco casos críticos deliberadamente diferentes. Determinista de 10% de amostragem de cabeça hashes cada rastro ID. A política de cauda mantém vestígios cujo status de extensão é ERROR . A terceira apólice retém todos os recibos de saúde registados. Faça isso com: O resultado fixo é: A amostra da cabeça mantém a 1, 3, 10, 25, 39 . A corrida 25 é o caso de erro de ferramenta, por isso faltam outros quatro casos críticos na amostra. A regra da cauda apenas ERROR também mantém o erro da ferramenta. Perde se de uma falha de resultado transportada por um rastro OK , de uma espera de aprovação transportada por um rastro UNSET , de um produto faltante transportado por um rastro OK e do tempo de execução inacessível que não produziu rastro. Este é um teste de política, não um resultado estatístico. As cinco corridas críticas foram deliberadamente distribuídas, de modo que a repetição contém tanto um caso retido quanto casos perdidos. Não alega que a amostragem de 10% geralmente capte um quinto dos incidentes ou que estes cinco tipos de eventos tenham a mesma frequência. Mudança os identificadores de rastreamento, a regra de amostragem ou a fixação e as contagens podem mudar. O que não deve mudar é o critério de aceitação: todos os tipos de recibos obrigatórios devem sobreviver ao caminho de saúde, incluindo um caso sem vestígios. Adicionar um novo veredicto operacional somente depois de adicionar seu produtor, esquema, fixação, regra de retenção e monitor de perda. Monitorar o caminho de recepção e retenção vinculada Um canal sem amostras ainda pode falhar. O desbordamento de filas, a rejeição de esquemas, credenciais expiradas, erros do relógio, bugs do produtor e interrupções de armazenamento podem fazer desaparecer a evidência de saúde. Monitorar o canal com sinais que não dependem exclusivamente do canal em si: Contas de receitas esperadas por produtor e por fenda de fluxo de trabalho; Batimento cardíaco do produtor e último tempo de entrega bem sucedido; Contadores de recepção rejeitados, duplicados e atrasados; Capacidade de fila de colecionadores e contadores de lançamento; Canários periódicos de ponta a ponta com uma identificação de recibo conhecida; Reconciliação entre as operações programadas, as conclusões declaradas e os resultados recebidos. A ausência não deve tornar se verde. Se um verificador de resultados não tiver relatado uma corrida que o exija, marque o sinal de resultado indisponível ou incerto. Se o próprio observador externo estiver obsoleto, não pretenda que o tempo de execução seja alcançável. Uma camada de saúde deve expor lacunas nas suas próprias evidências. Manter todos os recibos de saúde também não significa manter os para sempre. Escolha a retenção da decisão de operação: tempo suficiente para investigar, reconciliar evidências atrasadas e auditar uma intervenção aprovada. Cotações mais antigas agregadas quando os registos individuais não são mais necessários. Remova ou hash os caminhos locais, o conteúdo do usuário, o texto rápido, as cargas úteis de ferramentas e o material de credenciais antes da exportação. Armazenar uma classe de erro digest ou bounded quando apoiar a decisão. A troca é explícita. Um canal compacto obrigatório custa engenharia extra e duplica uma pequena quantidade de metadados de rastreamento. Em troca, os controles de volume de rastreamento não podem apagar silenciosamente os fatos que conduzem à saúde. A amostragem da cauda continua útil para selecionar detalhes de diagnóstico em torno de erros conhecidos; um recibo obrigatório dá lhe o incidente mesmo quando o status de rastreamento é bem sucedido, incompleto ou ausente. Antes de adotar o padrão, reproduza casos reais desinfetados de um fluxo de trabalho: conclusão saudável, sucesso falso, espera de aprovação, falha de ferramenta, batimento cardíaco perdido e interrupção do coletor. Verifique os dois lados. A política de rastreamento deve cumprir a sua meta de custos e a política de recepção deve conservar todos os veredictos necessários sem recolher cargas úteis sensíveis. A direção do produto da Sidewisp é uma camada de saúde em torno dos tempos de execução dos agentes existentes: evidências, frescura, progresso útil, estados de espera, resultados verificados e limites explícitos de aprovação. Não é um sistema de execução de substituição, um gateway obrigatório, um produto de rastreamento bruto ou um fixador autônomo. A Sidewisp está atualmente em prévia privada. O site público e o sistema de artigos estão ao vivo, enquanto a coleta de agentes de produção saúde, adaptadores de tempo de execução, gerenciamento de cron, análise de custos de tokens e recuperação geralmente não são enviados. Se este limite de retenção de evidências coincidir com os modos de falha necessários para operar, pode juntar se à pré visualização privada e descrever os tipos de tempo de execução e de receção que importam. Referências primárias OpenTelemetry: Amostragem terminologia de amostragem de rastreamento, amostragem de cabeça e cauda e compensações operacionais; revisado em 26 de julho de 2026. OpenTelemetry Collector Contrib: Processador de amostragem de cauda agrupamento de vestígios, tipos de políticas, afinidade do colecionador, vestígios caídos e períodos atrasados; revisado em 26 de julho de 2026. OpenTelemetry: Modelo de dados de registos semântica estável Timestamp e ObservedTimestamp ; revisado em 26 de julho de 2026.