Resumen de observabilidad

La observabilidad de agentes en Gemini Enterprise Agent Platform proporciona visibilidad integral del rendimiento, el comportamiento y el estado de los agentes implementados y los servidores del Protocolo de contexto del modelo (MCP). Si supervisas las métricas clave, rastreas las rutas de ejecución y observas tu sistema multiagente en su totalidad, puedes diagnosticar problemas, optimizar el consumo de recursos y mejorar la confiabilidad de tus agentes.

En este documento, se proporciona una descripción general de las herramientas de observabilidad disponibles en Gemini Enterprise Agent Platform, incluidas la topología de todo el sistema, la supervisión de agentes individuales y las métricas del servidor de MCP.

Configuración de la telemetría

Para propagar estos paneles de observabilidad, topologías y seguimientos, tus agentes deben estar configurados para enviar datos de telemetría en el formato de OpenTelemetry a los sistemas de almacenamiento en Google Cloud Observability.

Asegúrate de que los entornos de tu agente y del servidor de MCP estén configurados correctamente para emitir estos datos. Los componentes integrados de Google Cloud emiten telemetría de forma automática en el formato de OpenTelemetry. Por ejemplo, Model Armor emite de forma nativa telemetría estandarizada, lo que te permite exponer y supervisar sin problemas las intercepciones de políticas en tiempo real directamente en tus datos de seguimiento sin necesidad de ninguna instrumentación personalizada.

Para obtener instrucciones y requisitos de configuración de la telemetría del agente, consulta los siguientes recursos:

Indicadores de observabilidad

Gemini Enterprise Agent Platform proporciona observabilidad a través de métricas, seguimientos y registros.

Cuando seleccionas un agente específico del Registro, la pestaña Observabilidad proporciona un conjunto de paneles específicos para supervisar su estado operativo, rendimiento y uso de la infraestructura. Usa la navegación de la izquierda en la pestaña Observabilidad para alternar entre las siguientes vistas:

  • Descripción general: Realiza un seguimiento del uso de alto nivel durante el período seleccionado, incluidas las sesiones totales, los turnos promedio por sesión y las invocaciones totales del agente. Los gráficos de series temporales muestran el uso de tokens (entrada frente a salida), el volumen general de tráfico del agente, los percentiles de latencia (p50, p95, p99) y las tasas de error.
  • Evaluación: Muestra monitores en línea para la evaluación continua de la calidad. Esto incluye widgets de series temporales que hacen un seguimiento de la calidad promedio de las respuestas, las métricas de seguridad, las tasas de alucinación y la calidad del uso de herramientas.
  • Modelos: Desglosa el rendimiento por el modelo de base subyacente. Puedes supervisar la latencia de p95, los recuentos totales de llamadas, las tasas de error, los errores de cuota y el uso de tokens aislados por modelos específicos.
  • Herramientas: Supervisa las herramientas y los servicios externos conectados al agente. En esta vista, se detallan la latencia de p95, los recuentos de llamadas y las tasas de error por herramienta, así como la frecuencia de las interacciones en las que no se llamó a ninguna herramienta.
  • Uso: Proporciona métricas a nivel de la infraestructura para el entorno de ejecución del agente, incluida la asignación de CPU del contenedor, la asignación de memoria del contenedor y el uso de tokens.
  • Registros: Muestra un flujo filtrable de registros de agentes sin procesar, incluidos la gravedad, las marcas de tiempo y los resúmenes de ejecución para solucionar problemas en profundidad. Para obtener más información, consulta Visualiza los registros del agente.

Además de los paneles de la pestaña Observabilidad, puedes usar la pestaña Seguimientos del agente para inspeccionar la ejecución paso a paso de sesiones específicas, incluidos los grafos acíclicos dirigidos de intervalos y entradas/salidas. Para obtener más información, consulta Visualiza los seguimientos de agentes. También puedes usar la pestaña Topología para ver las dependencias de entrada y salida específicas de ese agente único.

En el caso de los servidores de MCP, puedes supervisar el recuento de solicitudes y la duración de las solicitudes p95 para hacer un seguimiento del uso y la capacidad de respuesta.

Auditorías de acciones de agentes

Para respaldar las auditorías de seguridad y cumplimiento empresarial, Gemini Enterprise Agent Platform usa el registro de atribución doble para registrar la actividad de los agentes en Cloud Logging. Cuando un agente realiza una acción o llama a una herramienta en nombre de una persona (autoridad delegada por el usuario), los registros de auditoría y ejecución registran la identidad del agente basada en SPIFFE (principal://... en los registros de auditoría o spiffe://... en los registros de ejecución) y la identidad del usuario humano que inicia la acción. Cuando un agente actúa de forma autónoma con su propia autoridad, los registros atribuyen la acción directamente a la identidad única del agente.

Los auditores y administradores de seguridad pueden aislar y revisar los eventos iniciados por el agente en Cloud Logging filtrando por la marca is_agentic=true en las consultas de registro. Combinar is_agentic=true con la identidad del agente o la principal del usuario te permite rastrear las rutas de ejecución de extremo a extremo y verificar la aplicación de políticas en todas las interacciones del agente.

Expectativas de detención de emergencia y propagación de políticas

Cuando se responde a un incidente de seguridad o a un comportamiento anómalo del agente, Agent Platform proporciona dos capas complementarias para detener la actividad del agente:

  • Finalización inmediata del entorno de ejecución o redireccionamiento del tráfico: Borrar un agente implementado en Agent Runtime (runtimes.delete o reasoningEngines.delete) finaliza de inmediato sus instancias de contenedor, detiene las sesiones activas y las invocaciones de transmisión, y, además, invalida de forma permanente su identidad de agente de SPIFFE una vez que se completa la operación de eliminación. Como alternativa, puedes volver a enrutar el 100% del tráfico raíz a una revisión que se sabe que es correcta con trafficSplitManual o archivar las revisiones preexistentes actualizando spec.deployment_spec.agent_gateway_config.
  • Revocación de acceso basada en políticas: Agregar una regla DENY a las políticas de acceso unificado (UAP) aplicadas por Agent Gateway (iamEnforcementMode: "ENFORCE") o aplicar una política de denegación o revocación de roles de Identity and Access Management (IAM) bloquea las llamadas a la API y a las herramientas salientes, a la vez que conserva el contenedor de entorno de ejecución para el análisis forense. Sin embargo, las actualizaciones de las políticas de IAM y de los UAP son coherentes de forma eventual: los cambios directos en las políticas suelen entrar en vigor en un plazo de 2 minutos, pero pueden tardar hasta 7 minutos o más en propagarse de forma global (consulta Propagación de cambios de acceso), y las actualizaciones de la membresía de grupos o de principalSet pueden tardar varios minutos o horas en sincronizarse. Las actualizaciones de políticas se evalúan en las nuevas verificaciones de autorización y no cierran de forma forzosa las conexiones de transmisión ya establecidas, a menos que se vuelvan a autorizar.

Para obtener un interruptor de apagado inmediato durante un incidente activo, borra el entorno de ejecución del agente o vuelve a enrutar el tráfico de su revisión, además de aplicar una regla de denegación de política. Para obtener instrucciones paso a paso, consulta Detención de emergencia y revocación de acceso.

Latencia de telemetría y hallazgos de seguridad

Los diferentes controles de observabilidad y seguridad operan en diferentes programas de transferencia y evaluación. Comprender estas expectativas de latencia ayuda a los encargados de responder incidentes a distinguir entre la aplicación de medidas por incumplimiento intercalada y la detección de amenazas asíncrona.

En la siguiente tabla, se resumen el modelo de evaluación y la latencia esperada para cada indicador de telemetría y seguridad en Agent Platform:

Señal o control Modelo de evaluación y transferencia Latencia típica
Registros de auditoría de Cloud y registros de solicitudes de Agent Gateway (cloudaudit.googleapis.com/*, networkservices.googleapis.com/gateway_requests) Se generan de forma síncrona cuando se evalúan las llamadas a la API y las verificaciones de autorización de la puerta de enlace y, luego, se transfieren a Logging. Casi en tiempo real (por lo general, se puede buscar en el Explorador de registros en cuestión de segundos). Los filtros de actualización de la CLI, como --freshness=6h, pueden omitir ocasionalmente las entradas indexadas recientemente. Usa --freshness=1d cuando verifiques eventos recientes.
Registros de ejecución de Agent Runtime (aiplatform.googleapis.com/reasoning_engine_stdout, reasoning_engine_stderr) Se transmiten de forma asíncrona desde el contenedor del entorno de ejecución hasta Logging. Por lo general, se pueden ver en cuestión de segundos después de la emisión.
Seguimientos distribuidos en Cloud Trace Se exportan de forma asíncrona a medida que se completan los intervalos de OpenTelemetry, sujetos a las reglas de samplingRate y parentBasedSampling configuradas. Por lo general, se puede buscar en cuestión de segundos después de que se completa el intervalo.
Métricas de Cloud Monitoring Se muestrean periódicamente desde Agent Runtime, Agent Gateway y las canalizaciones de detección de anomalías. Se hace un muestreo cada 60 a 120 segundos, con un retraso de visibilidad de hasta 180 a 420 segundos en el Explorador de métricas y los paneles.
Aplicación de políticas intercaladas (Agent Gateway, Identity-Aware Proxy y Model Armor) Se evalúan de forma síncrona en la ruta de solicitud en vivo antes de que se complete una llamada a la herramienta, una solicitud de MCP o una instrucción del modelo. Intercepción en línea en tiempo real (sin retraso de posprocesamiento)
Detección de anomalías en agentes y hallazgos de Security Command Center (Security Command Center) (AGENT_SESSION_ANOMALY) Se evalúa de forma asíncrona fuera de banda en una canalización de detección de varias capas después de que se transfieren los registros y los seguimientos de las sesiones, lo que agrega cero latencia a las respuestas de los agentes en vivo. La habilitación inicial del permiso tarda aproximadamente 40 minutos. Las métricas de anomalías se muestrean cada 120 segundos (con un retraso de visibilidad de hasta 420 segundos), y se aplica una latencia de sincronización adicional antes de que los hallazgos confirmados aparezcan en Security Command Center.

Retención con detección de alteraciones para los registros de auditoría

Las entradas de los Registros de auditoría de Cloud son inmutables por diseño: después de que Logging escribe una entrada de registro de auditoría, su carga útil y sus metadatos no se pueden modificar. Los registros de auditoría de la actividad del administrador y de los eventos del sistema se almacenan en el bucket de registros _Required, que aplica un período de retención fijo de 400 días y no se puede modificar ni borrar.

De forma predeterminada, los registros de auditoría de acceso a los datos (cloudaudit.googleapis.com/data_access), los registros de política denegada (cloudaudit.googleapis.com/policy_denied), los registros de solicitudes de Agent Gateway (networkservices.googleapis.com/gateway_requests) y los registros de ejecución de agentes de atribución doble (is_agentic=true) se enrutan al bucket de registros _Default con un período de retención de 30 días.

Para aplicar la retención de escritura única y lectura múltiple (WORM) a prueba de manipulaciones para la evidencia de cumplimiento, enruta los registros de auditoría y de puerta de enlace de tu agente a un bucket de Logging personalizado, configura un período de retención personalizado (de 1 a 3,650 días) y bloquea el bucket de forma permanente. Bloquear un bucket de Logging es una acción irreversible que impide que cualquier persona, incluidos los propietarios del proyecto y los administradores de la organización, borren el bucket, borren las entradas de registro antes de que venza su período de retención o reduzcan el período de retención.

Para crear y bloquear un bucket de Logging personalizado para los registros de auditoría de agentes con Google Cloud CLI, ejecuta los siguientes 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

Reemplaza lo siguiente:

  • BUCKET_ID: Es un identificador único para tu bucket de registros de auditoría (por ejemplo, agent-audit-worm-bucket).
  • LOCATION: Es la ubicación del bucket (por ejemplo, global, us o eu).
  • RETENTION_DAYS: Es la cantidad de días que se conservarán las entradas de registro (entre 1 y 3650).
  • PROJECT_ID: Es el ID del proyecto de Google Cloud .

Para proteger un bucket de registros bloqueado de que se quite si se borra su proyecto superior, coloca una retención de proyecto en el proyecto. Como alternativa, puedes exportar los registros de auditoría a un bucket de Cloud Storage configurado con una política de retención bloqueada (Bloqueo de bucket). Para obtener más información, consulta Configura y administra buckets de registros.

Exporta registros de auditoría a un SIEM

Para centralizar la supervisión de seguridad, la correlación y el archivado de cumplimiento a largo plazo, puedes exportar de forma continua los registros de auditoría de agentes, las decisiones de autorización de Agent Gateway y los registros de ejecución de is_agentic=true a Google Security Operations (Google SecOps) o a un sistema de administración de información y eventos de seguridad (SIEM) de terceros.

Puedes configurar un receptor de registros de Logging a nivel de proyecto o un receptor de registros agregado a nivel de organización o de carpeta para enrutar los registros a los siguientes destinos:

  • Google Security Operations: Transfiere registros de auditoría de Cloud, registros de Agent Gateway y hallazgos de AGENT_SESSION_ANOMALY de Security Command Center a Google SecOps de forma nativa o a través de un feed de Pub/Sub o Cloud Storage para investigar las sesiones de los agentes junto con la telemetría de seguridad empresarial. Para obtener instrucciones de configuración, consulta Exporta datos de Google Cloud a Google SecOps.
  • Pub/Sub (Pub/Sub): Transmite registros de auditoría de agentes en tiempo real a un tema de Pub/Sub para que lo transfieran plataformas de SIEM de terceros (como Splunk, Datadog o QRadar) con una suscripción a Pub/Sub o un conector de Dataflow. Para obtener más detalles, consulta Enruta registros a Pub/Sub.
  • BigQuery (BigQuery) o Estadísticas de observabilidad: Exporta registros a un conjunto de datos de BigQuery o vincula un bucket de registros habilitado para Estadísticas de observabilidad a BigQuery para ejecutar consultas de cumplimiento de SQL en identidades de agentes, delegaciones de usuarios y denegaciones de políticas de puerta de enlace.
  • Cloud Storage: Exporta archivos de registro JSON por lotes a un bucket de Cloud Storage con el bloqueo de bucket habilitado para el archivado inmutable a largo plazo.

Para crear un receptor de registros de Logging que transmita los registros de auditoría y de puerta de enlace del agente a un tema de Pub/Sub para la transferencia de SIEM, completa los siguientes pasos:

  1. Crea el receptor de registros con un filtro de inclusión que capture los Registros de auditoría de Cloud, los registros de solicitudes de Agent Gateway, los registros de Agent Runtime y las entradas de atribución doble (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

    Reemplaza lo siguiente:

    • SINK_NAME: Es un nombre para el receptor de registros (por ejemplo, agent-audit-siem-sink).
    • DESTINATION_PROJECT_ID: Es el ID del proyecto que aloja el tema de Pub/Sub de destino.
    • TOPIC_ID: Es el ID del tema de Pub/Sub al que se suscribe tu SIEM.
    • PROJECT_ID: Es el ID del proyecto desde el que exportas los registros. Para exportar en toda una organización, reemplaza --project=PROJECT_ID por --organization=ORGANIZATION_ID --include-children.

  2. Recupera la identidad de la cuenta de servicio del escritor del receptor y otórgale el rol de publicador de Pub/Sub (roles/pubsub.publisher) en el tema 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"

Convenciones de IA generativa de OpenTelemetry

Los seguimientos de agentes y los registros de instrucciones y respuestas dependen en gran medida de las convenciones semánticas de OpenTelemetry para sistemas de IA generativa para estandarizar la forma en que se captura, estructura y, además, se informa la telemetría de IA generativa.

Cumplir con estas convenciones es fundamental para el seguimiento de agentes, ya que establece un formato universal y que no depende de un proveedor para describir flujos de trabajo de agentes complejos y de varios pasos, como las ejecuciones de herramientas, los pasos de recuperación y el consumo de tokens. Esta estandarización ayuda a lograr una interoperabilidad fluida entre diferentes backends de observabilidad y herramientas de análisis, tanto dentro como fuera de Google Cloud.

¿Qué sigue?