Serviço Amazon OpenSearch agora traz monitoramento de aplicativos, nativo Serviço gerenciado da Amazon para Prometheus integração e rastreamento de agente de IA juntos em IU do OpenSearchespaço de trabalho de observabilidade. Você pode consultar métricas do Prometheus com PromQL juntamente com logs e rastreamentos armazenados no Amazon OpenSearch Service, rastreie toda a cadeia de raciocínio de um agente de IA até a chamada de ferramenta com falha e faça uma busca detalhada de uma visualização de integridade no nível de serviço até o período exato que causou uma falha no checkout, tudo isso sem sair da interface.
Nesta postagem, percorremos dois cenários do mundo actual usando o aplicativo de amostra OpenTelemetry: um planejador de viagens multiagente enfrentando processamento lento e um fluxo de checkout falhando silenciosamente em um microsserviço. Perseguimos cada um até sua causa raiz usando esses novos recursos.
Cenário 1: Um agente de IA com baixo desempenho
Seu planejador de viagens multiagente está ativo e os usuários começam a relatar respostas lentas. Com o novo recurso de rastreamento de agentes de IA no Amazon OpenSearch Service, você pode rastrear o caminho completo de processamento do agente para identificar exatamente onde as coisas deram errado.
Em qualquer espaço de trabalho de observabilidade na interface do OpenSearch, navegue até Mapa de aplicação no painel de navegação esquerdo.
Você pode ver a topologia completa do seu sistema, incluindo o agente de viagens e os subagentes que ele chama. O nó do agente de viagens mostra latência elevada e erros ocasionais. Selecione-o e o painel lateral confirmará que a latência aumentou, mas o gráfico de latência mostra picos intermitentes em vez de degradação consistente.
O mapa do aplicativo indica que algo está errado, mas a compreensão por que um agente de IA com desempenho insatisfatório exige a visualização de sua cadeia de raciocínio. Selecione Rastreamentos de agente no painel de navegação esquerdo e filtre por nome de serviço e intervalo de tempo.
Selecione um dos rastreamentos para ver a árvore de rastreamentos. Ao contrário de uma cascata de span tradicional, essa visualização é organizada em torno da cadeia de raciocínio do agente: a extensão do agente raiz, as chamadas LLM feitas, as ferramentas que ele invocou e como elas aninharam cada etapa codificada por cores por tipo. O mapa de rastreamento fornece um gráfico visible direcionado da mesma execução. Você pode ver qual modelo foi chamado, quantos tokens de entrada e saída foram consumidos e as mensagens reais enviadas e recebidas do modelo.
Houve erro em uma chamada de ferramenta dentro do agente meteorológico. O agente então passou mais tempo raciocinando sobre a falha antes de retornar uma resposta parcial explicando os picos intermitentes de latência e falhas ocasionais.
Por que isso é importante para os agentes de IA
Os agentes tomam decisões autônomas com base nas respostas do LLM, nos resultados das ferramentas e no raciocínio encadeado. Ao contrário dos microsserviços tradicionais com caminhos de código determinísticos, o comportamento do agente varia entre as execuções. Sem o rastreamento semântico que seize esses sinais específicos da IA, a análise da causa raiz é uma adivinhação. A árvore de rastreamento revelou o nome do modelo, contagens de tokens e falha na chamada da ferramenta porque o planejador de viagens foi instrumentado com as convenções semânticas generativas de IA do OpenTelemetry. A próxima seção descreve como.
Instrumentando agentes de IA
A instrumentação automática do OpenTelemetry enriquece os spans com atributos conhecidos para chamadas HTTP, banco de dados e gRPC. Os agentes de IA precisam de um conjunto diferente de atributos, como qual LLM foi chamado, quais tokens foram consumidos, quais ferramentas foram invocadas, que a instrumentação padrão não cobre.
O Convenções semânticas OpenTelemetry gen_ai definir atributos padrão para esses sinais, incluindo gen_ai.operation.title, gen_ai.utilization.input_tokens, gen_ai.request.mannequine gen_ai.device.title. Quando o Amazon OpenSearch Service recebe intervalos com esses atributos, ele os categoriza por tipo de operação (agente, LLM, ferramenta, incorporações, recuperação) e renderiza a árvore de rastreamento do agente e as visualizações do mapa de rastreamento.
O Python SDK fornece uma maneira de gerar esses intervalos. Para enviar rastreamentos para o Amazon OpenSearch Ingestion, configure o SDK com autenticação AWS Signature versão 4 (SigV4). O AWSSigV4OTLPExporter assina criptograficamente cada solicitação HTTP para ajudar a impedir a ingestão não autorizada de dados. A identidade de chamada precisa de uma política IAM que conceda osis:Ingest no ARN do seu pipeline. As credenciais são resolvidas por meio da cadeia padrão de provedores de credenciais da AWS.
from opensearch_genai_observability_sdk_py import register, AWSSigV4OTLPExporter
exporter = AWSSigV4OTLPExporter(
endpoint="https://pipeline.us-east-1.osis.amazonaws.com/v1/traces",
service="osis",
area="us-east-1",
)
register(service_name="my-agent", exporter=exporter)
Use o @observe decorador para rastrear funções do agente e enrich() para adicionar metadados do modelo:
@observe(op=Op.EXECUTE_TOOL)
def get_weather(metropolis: str) -> dict:
return {"metropolis": metropolis, "temp": 22, "situation": "sunny"}
@observe(op=Op.INVOKE_AGENT)
def assistant(question: str) -> str:
enrich(mannequin="gpt-4o", supplier="openai")
knowledge = get_weather("Paris")
return f"{knowledge('situation')}, {knowledge('temp')}C"
outcome = assistant("What is the climate?")
O SDK também oferece suporte à instrumentação automática para OpenAI, Anthropic, Amazon Bedrock, LangChain, LlamaIndex e outros. Como a instrumentação é construída nos padrões OpenTelemetry, qualquer estrutura de agente que emita spans com gen_ai.* atributos é compatível com OpenSearch UI.
Cenário 2: investigando um problema de microsserviço
Os agentes de IA são apenas uma parte da maioria dos ambientes de produção. A mesma interface apresenta telemetria de microsserviços convencionais, onde o fluxo de trabalho de solução de problemas segue um caminho mais acquainted.
Sua finalização de compra de comércio eletrônico começa a paginar durante uma janela de tráfego intenso. Na IU do OpenSearch, navegue até Serviços APM no painel de navegação esquerdo. Cada serviço instrumentado é listado juntamente com seus indicadores de saúde. O serviço de checkout mostra uma taxa de erro elevada.
Selecione o serviço afetado. A visualização detalhada mostra as métricas de solicitação, erro e duração (RED): a taxa de solicitação está subindo, a taxa de falhas aumentou nos últimos 15 minutos e a duração do p99 dobrou. Você pode ver exatamente quando a degradação começou.
Analise os períodos correlacionados da janela de tempo afetada. A lista de span mostra várias solicitações com falha, todas atingindo o mesmo endpoint. Selecione um para ver a cascata de rastreamento completa. O serviço de checkout chamado prepareOrderque falhou ao tentar recuperar um produto do catálogo. A mensagem de erro nos detalhes do intervalo informa exatamente o que deu errado, essa é a causa raiz.
Verificando a infraestrutura com PromQL
Em ambos os cenários, a próxima questão pure é se o problema tem origem na aplicação ou na infra-estrutura abaixo dela. Com a nova integração do Amazon Managed Service for Prometheus, você pode responder a essa pergunta sem sair da interface do OpenSearch.
As métricas do Prometheus agora podem ser consultadas diretamente no mesmo espaço de trabalho usando a sintaxe nativa do PromQL, junto com os logs e rastreamentos que você já navegou.
Para o tempo limite do banco de dados no Cenário 2, execute uma consulta PromQL para verificar a taxa de transferência de leitura/gravação da instância do banco de dados para a mesma janela de tempo. Para o problema de latência do agente no Cenário 1, verifique as métricas de tempo de resposta do ponto remaining LLM para ver se a lentidão se origina do fornecedor do modelo.
Essa é uma decisão arquitetônica importante: as métricas continuam no Amazon Managed Service for Prometheus, os logs e os rastreamentos continuam no Amazon OpenSearch Service e nenhum sinal é copiado ou armazenado em um segundo armazenamento. Cada back-end continua sendo o único armazenamento para o tipo de dados para o qual foi criado especificamente para lidar, enquanto a interface do usuário do OpenSearch federa consultas em ambos em tempo de execução. O custo, a retenção e o modelo operacional de cada loja permanecem intactos enquanto o fluxo de trabalho de solução de problemas se resume a uma única interface.
Para configurar os pipelines do OpenTelemetry Collector e do OpenSearch Ingestion que roteiam métricas para o Amazon Managed Service for Prometheus, consulte Ingerindo telemetria de aplicativo.
Como está conectado
O diagrama a seguir mostra a arquitetura ponta a ponta. Aplicativos instrumentados com OpenTelemetry enviam rastreamentos, logs e métricas por OTLP para o Amazon OpenSearch Ingestion. O OpenSearch Ingestion roteia cada sinal para o armazenamento apropriado: rastreamentos e logs chegam ao Amazon OpenSearch Service, enquanto as métricas fluem para o Amazon Managed Service for Prometheus. A UI do OpenSearch consulta ambas as lojas para renderizar o mapa do aplicativo, o catálogo de serviços, os rastreamentos do agente e as visualizações de métricas.
Toda a experiência se baseia em bases de código aberto, Prometheus para métricas, OpenSearch para logs e rastreamentos e OpenTelemetry para instrumentação, para que as equipes que já executam um coletor OpenTelemetry possam adotá-lo atualizando a configuração de exportação do coletor para apontar para o Amazon OpenSearch Ingestion, sem necessidade de agentes proprietários ou instrumentação reescrita.
Começando
Para ativar esses recursos, faça login no espaço de trabalho de observabilidade do OpenSearch UI, selecione o Engrenagem ícone no canto inferior esquerdo para abrir Configurações e configuração e verifique se o Observabilidade:apmEnabled a alternância está ativada na seção Observabilidade. A UI do OpenSearch está disponível sem custo adicional para clientes do Amazon OpenSearch Service.
Discover localmente primeiro. O Pilha de observabilidade do OpenSearch oferece um ambiente totalmente configurado, incluindo monitoramento de aplicativos, rastreamento de agentes e integração do Prometheus, executado em sua máquina com um único comando de instalação. Ele vem com exemplos de serviços instrumentados, incluindo um planejador de viagens multiagente, para que você possa explorar todo o fluxo de trabalho com dados de telemetria reais prontos para uso.
Para desenvolvimento de agentes de IA. Saúde do Agente é uma ferramenta de observabilidade de código aberto e orientada para avaliação, projetada para o desenvolvimento native. Ele fornece gráficos de fluxo de execução, rastreamento de token e visibilidade de invocação de ferramenta diretamente no ciclo de desenvolvimento, antes de você enviar para a produção.
Para produção. O SDK Python fornece configuração de uma linha e rastreamento baseado em decorador com convenções semânticas gen_ai, com suporte de instrumentação automática para OpenAI, Anthropic, Amazon Bedrock, LangChain, LlamaIndex e outros. Veja o Documentação do Amazon OpenSearch Service e o Guia de integração do Amazon Managed Service for Prometheus para a experiência gerenciada completa.