Visão geral da observabilidade

A observabilidade do agente na Gemini Enterprise Agent Platform oferece visibilidade abrangente do desempenho, do comportamento e da integridade dos agentes implantados e dos servidores do Protocolo de Contexto de Modelo (MCP, na sigla em inglês). Ao monitorar as principais métricas, rastrear caminhos de execução e observar o sistema multiagente como um todo, é possível diagnosticar problemas, otimizar o consumo de recursos e melhorar a confiabilidade dos agentes.

Este documento apresenta uma visão geral das ferramentas de observabilidade disponíveis na Gemini Enterprise Agent Platform, incluindo topologia de todo o sistema, monitoramento de agentes individuais e métricas do servidor MCP.

Configuração de telemetria

Para preencher esses painéis, topologias e traces de observabilidade, seus agentes precisam ser configurados para enviar dados de telemetria no formato OpenTelemetry para sistemas de armazenamento no Google Cloud Observability.

Verifique se os ambientes do agente e do servidor MCP estão configurados corretamente para emitir esses dados. Os componentes integrados do Google Cloud emitem automaticamente telemetria no formato do OpenTelemetry. Por exemplo, o Model Armor emite nativamente telemetria padronizada, permitindo que você exponha e monitore facilmente interceptações de políticas em tempo real diretamente nos dados de trace, sem precisar de nenhuma instrumentação personalizada.

Para instruções e requisitos de configuração da telemetria do agente, consulte os seguintes recursos:

Indicadores de observabilidade

A Gemini Enterprise Agent Platform oferece observabilidade por meio de métricas, traces e registros.

Ao selecionar um agente específico no Registry, a guia Observabilidade oferece um conjunto de painéis direcionados para monitorar a integridade das operações de TI, o desempenho e o uso da infraestrutura. Use a navegação à esquerda na guia Observabilidade para alternar entre as seguintes visualizações:

  • Visão geral: monitora o uso geral no período selecionado, incluindo o total de sessões, a média de turnos por sessão e o total de invocações do agente. Os gráficos de série temporal mostram o uso de tokens (entrada x saída), o volume geral de tráfego do agente, os percentis de latência (p50, p95, p99) e as taxas de erro.
  • Avaliação: exibe monitores on-line para avaliação contínua de qualidade. Isso inclui widgets de série temporal que monitoram a qualidade média das respostas, as métricas de segurança, as taxas de alucinação e a qualidade do uso de ferramentas.
  • Modelos: detalha o desempenho pelo modelo de fundação subjacente. É possível monitorar a latência p95, o total de chamadas, as taxas de erro, as falhas de cota e o uso de tokens isolados por modelos específicos.
  • Ferramentas: monitora as ferramentas e os serviços externos conectados ao agente. Essa visualização detalha a latência p95, as contagens de chamadas e as taxas de erro por ferramenta, além da frequência de interações em que nenhuma ferramenta foi chamada.
  • Uso: fornece métricas no nível da infraestrutura para o ambiente de execução do agente, incluindo alocação de CPU do contêiner, alocação de memória do contêiner e uso de tokens.
  • Registros: mostra um fluxo filtrável de registros brutos do agente, incluindo gravidade, carimbos de data/hora e resumos de execução para solução de problemas detalhada. Para mais informações, consulte Ver registros agênticos.

Além dos painéis na guia Observabilidade, é possível usar a guia Traces do agente para inspecionar a execução detalhada de sessões específicas, incluindo gráficos acíclicos dirigidos de períodos e entradas/saídas. Para mais informações, consulte Ver traces do agente. Também é possível usar a guia Topologia para ver as dependências de entrada e saída específicas desse único agente.

Para servidores MCP, é possível monitorar a contagem de solicitações e a duração da solicitação p95 para acompanhar a utilização e a capacidade de resposta.

Como auditar ações de agentes

Para dar suporte a auditorias de segurança e compliance corporativas, a Gemini Enterprise Agent Platform usa a geração de registros de atribuição dupla para registrar a atividade do agente no Cloud Logging. Quando um agente executa uma ação ou chama uma ferramenta em nome de uma pessoa (autoridade delegada pelo usuário), os registros de auditoria e execução registram a identidade do agente baseada em SPIFFE (principal://... nos registros de auditoria ou spiffe://... nos registros de execução) e a identidade do usuário humano que iniciou a ação. Quando um agente age de forma autônoma, os registros atribuem a ação diretamente à identidade exclusiva do agente.

Os auditores e administradores de segurança podem isolar e analisar eventos iniciados por agentes no Cloud Logging filtrando a flag is_agentic=true em consultas de registro. Combinar is_agentic=true com a identidade do agente ou o principal do usuário permite rastrear caminhos de execução de ponta a ponta e verificar a aplicação de políticas em todas as interações do agente.

Parada de emergência e expectativas de propagação de políticas

Ao responder a um incidente de segurança ou comportamento anômalo do agente, a Agent Platform oferece duas camadas complementares para interromper a atividade do agente:

  • Encerramento imediato do ambiente de execução ou redirecionamento de tráfego: excluir um agente implantado no Agent Runtime (runtimes.delete ou reasoningEngines.delete) encerra imediatamente as instâncias de contêiner, interrompe as sessões ativas e as invocações de streaming e invalida permanentemente a identidade do agente SPIFFE assim que a operação de exclusão é concluída. Como alternativa, é possível redirecionar 100% do tráfego raiz para uma revisão comprovadamente boa usando trafficSplitManual ou arquivar revisões preexistentes atualizando spec.deployment_spec.agent_gateway_config.
  • Revogação de acesso com base em políticas: adicionar uma DENY regra às Políticas de Acesso Unificadas (UAPs) aplicadas pelo Gateway de Agente (iamEnforcementMode: "ENFORCE") ou aplicar uma política de negação ou revogação de papel do Identity and Access Management (IAM) bloqueia as chamadas de API de ferramentas e de saída, preservando o contêiner de ambiente de execução para análise forense. No entanto, as UAPs e as atualizações da política do IAM são consistentes: as mudanças diretas na política geralmente entram em vigor em até 2 minutos, mas podem levar até 7 minutos ou mais para serem propagadas globalmente (consulte Propagação de mudanças de acesso), e as atualizações de associação de grupos ou principalSet podem levar de vários minutos a horas para serem sincronizadas. As atualizações de política são avaliadas em novas verificações de autorização e não fecham as conexões de streaming já estabelecidas, a menos que sejam autorizadas novamente.

Para um kill switch imediato durante um incidente ativo, exclua o ambiente de execução do agente ou redirecione o tráfego de revisão, além de aplicar uma regra de negação de política. Para instruções detalhadas, consulte Parada de emergência e revogação de acesso.

Latência de telemetria e descoberta de segurança

Diferentes controles de observabilidade e segurança operam em diferentes programações de ingestão e avaliação. Entender essas expectativas de latência ajuda os responsáveis pela resposta a incidentes a distinguir entre a aplicação inline e a detecção assíncrona de ameaças.

A tabela a seguir resume o modelo de avaliação e a latência esperada para cada sinal de telemetria e indicador seguro na Agent Platform:

Sinal ou controle Modelo de avaliação e ingestão Latência típica
Registros de auditoria do Cloud e registros de solicitação do Gateway de Agente (cloudaudit.googleapis.com/*, networkservices.googleapis.com/gateway_requests) Gerados de forma síncrona quando as chamadas de API e as verificações de autorização do gateway são avaliadas e, em seguida, ingeridos no Logging. Quase em tempo real (geralmente pesquisável na Análise de registros em segundos). Filtros de atualização da CLI restritos, como --freshness=6h, podem ocasionalmente perder registros de índice indexados recentemente. Use --freshness=1d ao verificar eventos recentes.
Registros de execução do Agent Runtime do agente (aiplatform.googleapis.com/reasoning_engine_stdout, reasoning_engine_stderr) Transmitidos de forma assíncrona do contêiner de ambiente de execução para o Logging. Normalmente, ficam visíveis segundos após a emissão.
Traces distribuídos no Cloud Trace Exportados de forma assíncrona à medida que os períodos do OpenTelemetry são concluídos, sujeitos às regras samplingRate e parentBasedSampling configuradas. Geralmente, é possível pesquisar em segundos após a conclusão do período.
as métricas do Cloud Monitoring. Amostras periódicas do Agent Runtime, do Gateway de Agente e de pipelines de detecção de anomalias. Amostras coletadas a cada 60 a 120 segundos, com um atraso de visibilidade de até 180 a 420 segundos no Metrics Explorer e nos painéis.
Aplicação de políticas inline (Gateway de Agente, Identity-Aware Proxy, Model Armor) Avaliado de forma síncrona no caminho da solicitação ativa antes que uma chamada de ferramenta, solicitação do MCP ou comando de modelo seja concluído. Intercepção em linha em tempo real (atraso de pós-processamento zero).
Detecção de Agentes com Anomalias e descobertas do Security Command Center (Security Command Center) (AGENT_SESSION_ANOMALY) Avaliado de forma assíncrona fora de banda em um pipeline de detecção de várias camadas após a ingestão de registros e traces de sessão, adicionando latência zero às respostas do agente em tempo real. A ativação do escopo inicial leva aproximadamente 40 minutos. As métricas de anomalia são amostradas a cada 120 segundos (com até 420 segundos de atraso na visibilidade), e uma latência de sincronização adicional é aplicada antes que as descobertas confirmadas apareçam no Security Command Center.

Retenção inviolável para registros de auditoria

As entradas dos Registros de Auditoria do Cloud são imutáveis por padrão: depois que o Logging grava uma entrada de registro de auditoria, o payload e os metadados dela não podem ser modificados. Os registros de auditoria de atividade do administrador e de eventos do sistema são armazenados no bucket de registros _Required, que aplica um período de armazenamento fixo de 400 dias e não pode ser modificado ou excluído.

Por padrão, os registros de auditoria de acesso a dados (cloudaudit.googleapis.com/data_access), os registros de política negada (cloudaudit.googleapis.com/policy_denied), os registros de solicitação do gateway de agente (networkservices.googleapis.com/gateway_requests) e os registros de execução do agente de atribuição dupla (is_agentic=true) são roteados para o bucket de registros _Default com um período de armazenamento de 30 dias.

Para aplicar a retenção de gravação única e várias leituras (WORM, na sigla em inglês) à prova de adulteração para evidências de conformidade, encaminhe os registros de auditoria do agente e do gateway para um bucket personalizado do Logging, configure um período de armazenamento personalizado (de 1 a 3.650 dias) e bloqueie permanentemente o bucket. Bloquear um bucket de registros é uma ação irreversível que impede que qualquer pessoa, incluindo Proprietários do projeto e Administradores da organização, exclua o bucket, exclua entradas de registro antes que o período de armazenamento expire ou reduza o período de armazenamento.

Para criar e bloquear um bucket personalizado do Logging para registros de auditoria de agentes usando a Google Cloud CLI, execute os seguintes comandos:

gcloud logging buckets create BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --locked \
    --project=PROJECT_ID

Substitua:

  • BUCKET_ID: um identificador exclusivo para o bucket de registro de auditoria (por exemplo, agent-audit-worm-bucket).
  • LOCATION: o local do bucket (por exemplo, global, us ou eu).
  • RETENTION_DAYS: o número de dias para reter entradas de registro (entre 1 e 3650).
  • PROJECT_ID: o ID do projeto do Google Cloud .

Para proteger um bucket de registros bloqueado contra remoção se o projeto pai for excluído, coloque uma garantia de projeto no projeto. Como alternativa, é possível exportar registros de auditoria para um bucket do Cloud Storage configurado com uma política de retenção bloqueada (Bloqueio de bucket). Para mais informações, consulte Configurar e gerenciar buckets de registros.

Exportar registros de auditoria para um SIEM

Para centralizar o monitoramento de segurança, a correlação e o arquivamento de conformidade de longo prazo, é possível exportar continuamente os registros de auditoria do agente, as decisões de autorização do Gateway de Agente e os registros de execução do is_agentic=true para o Google Security Operations (Google SecOps) ou um sistema de gerenciamento de informações e eventos de segurança (SIEM) de terceiros.

É possível configurar um coletor do Logging no nível do projeto ou um coletor agregado no nível da organização ou da pasta para rotear registros para os seguintes destinos:

  • Google Security Operations: faça a ingestão de registros de auditoria do Cloud, registros do Gateway de Agente e descobertas de AGENT_SESSION_ANOMALY do Security Command Center no Google SecOps de forma nativa ou por um feed do Pub/Sub ou do Cloud Storage para investigar sessões de agentes com a telemetria de segurança empresarial. Para instruções de configuração, consulte Exportar dados do Google Cloud para o Google SecOps.
  • Pub/Sub (Pub/Sub): transmita registros de auditoria do agente em tempo real para um tópico do Pub/Sub para ingestão por plataformas SIEM de terceiros (como Splunk, Datadog ou QRadar) usando uma assinatura do Pub/Sub ou um conector do Dataflow. Para mais detalhes, consulte Rotear registros para o Pub/Sub.
  • BigQuery ou Análise de Observabilidade: exporte registros para um conjunto de dados do BigQuery ou vincule um bucket de registros com a Análise de Observabilidade ativada ao BigQuery para executar consultas de conformidade SQL em identidades de agentes, delegações de usuários e negações de políticas de gateway.
  • Cloud Storage: exporte arquivos de registro JSON em lote para um bucket do Cloud Storage com o Bloqueio de bucket ativado para arquivamento imutável de longo prazo.

Para criar um coletor de registros do Logging que transmita registros de auditoria do agente e do gateway para um tópico do Pub/Sub para ingestão de SIEM, siga estas etapas:

  1. Crie o coletor de registros com um filtro de inclusão que capture os Registros de auditoria do Cloud, os registros de solicitação do Gateway de Agente, os registros do Agent Runtime e as entradas de atribuição dupla (is_agentic=true):

    gcloud logging sinks create SINK_NAME \
    pubsub.googleapis.com/projects/DESTINATION_PROJECT_ID/topics/TOPIC_ID \
    --log-filter='logName:("cloudaudit.googleapis.com" OR "networkservices.googleapis.com%2Fgateway_requests" OR "aiplatform.googleapis.com%2Freasoning_engine") OR jsonPayload.is_agentic=true OR labels.is_agentic="true"' \
    --project=PROJECT_ID

    Substitua:

    • SINK_NAME: um nome para o coletor de registros (por exemplo, agent-audit-siem-sink).
    • DESTINATION_PROJECT_ID: o ID do projeto que hospeda o tópico de destino do Pub/Sub.
    • TOPIC_ID: o ID do tópico do Pub/Sub ao qual o SIEM se inscreve.
    • PROJECT_ID: o ID do projeto de onde você está exportando registros. Para exportar em uma organização inteira, substitua --project=PROJECT_ID por --organization=ORGANIZATION_ID --include-children.

  2. Recupere a identidade da conta de serviço do gravador do coletor e conceda a ela o papel de Publicador do Pub/Sub (roles/pubsub.publisher) no tópico de destino:

    WRITER_IDENTITY=$(gcloud logging sinks describe SINK_NAME \
    --project=PROJECT_ID \
    --format='value(writerIdentity)')

gcloud pubsub topics add-iam-policy-binding TOPIC_ID \
    --project=DESTINATION_PROJECT_ID \
    --member="${WRITER_IDENTITY}" \
    --role="roles/pubsub.publisher"

Convenções de IA generativa do OpenTelemetry

Os traces de agentes e os registros de comandos e respostas dependem muito das convenções semânticas do OpenTelemetry para sistemas de IA generativa para padronizar como a telemetria de IA generativa é capturada, estruturada e informada.

A adesão a essas convenções é fundamental para o rastreamento de agentes, porque estabelece um formato universal e independente de fornecedor para descrever fluxos de trabalho de agentes complexos e de várias etapas, como execuções de ferramentas, etapas de recuperação e consumo de tokens. Essa padronização ajuda na interoperabilidade perfeita entre diferentes back-ends de observabilidade e ferramentas de análise, dentro e fora do Google Cloud.

A seguir