관측 가능성 개요

Gemini Enterprise Agent Platform의 에이전트 모니터링 가능성은 배포된 에이전트와 모델 컨텍스트 프로토콜(MCP) 서버의 성능, 동작, 상태에 대한 포괄적인 가시성을 제공합니다. 주요 측정항목을 모니터링하고, 실행 경로를 추적하고, 멀티 에이전트 시스템을 전체적으로 관찰하면 문제를 진단하고, 리소스 소비를 최적화하고, 에이전트의 안정성을 개선할 수 있습니다.

이 문서에서는 시스템 전반의 토폴로지, 개별 에이전트 모니터링, MCP 서버 측정항목을 포함하여 Gemini Enterprise Agent Platform에서 사용할 수 있는 모니터링 가능성 도구를 간략하게 설명합니다.

원격 분석 설정

이러한 모니터링 가능성 대시보드, 토폴로지, trace를 채우려면 OpenTelemetry 형식의 원격 분석 데이터를 Google Cloud Observability의 스토리지 시스템으로 전송하도록 에이전트를 구성해야 합니다.

에이전트 및 MCP 서버 환경이 이 데이터를 내보내도록 올바르게 구성되어 있는지 확인합니다. 기본 제공 Google Cloud 구성요소는 OpenTelemetry 형식으로 원격 분석을 자동으로 내보냅니다. 예를 들어 Model Armor는 표준화된 원격 분석을 기본적으로 내보내므로 커스텀 계측 없이도 trace 데이터 내에서 실시간 정책 가로채기를 원활하게 노출하고 모니터링할 수 있습니다.

에이전트 원격 분석 설정 안내 및 요구사항은 다음 리소스를 참조하세요.

모니터링 가능성 신호

Gemini Enterprise Agent Platform은 측정항목, trace, 로그를 통해 모니터링 가능성을 제공합니다.

레지스트리에서 특정 에이전트를 선택하면 모니터링 가능성 탭에 운영 상태, 성능, 인프라 사용률을 모니터링할 수 있는 타겟팅된 대시보드 모음이 제공됩니다. 모니터링 가능성 탭 내에서 왼쪽 탐색 메뉴를 사용하여 다음 보기 간에 전환합니다.

  • 개요: 총 세션, 세션당 평균 차례, 총 에이전트 호출을 포함하여 선택한 기간 동안의 상위 수준 사용량을 추적합니다. 시계열 차트에는 토큰 사용량(입력 및 출력), 전체 에이전트 트래픽 양, 지연 시간 백분위수(p50, p95, p99), 오류율이 표시됩니다.
  • 평가: 지속적인 품질 평가를 위한 온라인 모니터를 표시합니다. 여기에는 평균 응답 품질, 안전 측정항목, 할루시네이션 비율, 도구 사용 품질을 추적하는 시계열 위젯이 포함됩니다.
  • 모델: 기본 파운데이션 모델별로 실적을 분류합니다. 특정 모델별로 p95 지연 시간, 총 호출 수, 오류율, 할당량 실패, 토큰 사용량을 모니터링할 수 있습니다.
  • 도구: 에이전트에 연결된 외부 도구 및 서비스를 모니터링합니다. 이 뷰에는 도구별 p95 지연 시간, 호출 수, 오류율과 도구가 호출되지 않은 상호작용 빈도가 자세히 표시됩니다.
  • 사용량: 컨테이너 CPU 할당, 컨테이너 메모리 할당, 토큰 사용량을 포함하여 에이전트의 런타임 환경에 대한 인프라 수준 측정항목을 제공합니다.
  • 로그: 심층 분석 문제 해결을 위한 심각도, 타임스탬프, 핵심 요약을 포함하여 필터링 가능한 원시 에이전트 로그 스트림을 표시합니다. 자세한 내용은 에이전트 로그 보기를 참조하세요.

모니터링 가능성 탭의 대시보드 외에도 에이전트의 trace 탭을 사용하여 스팬 및 입력/출력의 방향성 비순환 그래프를 포함한 특정 세션의 단계별 실행을 검사할 수 있습니다. 자세한 내용은 에이전트 trace 보기를 참조하세요. 토폴로지 탭을 사용하여 단일 에이전트의 특정 인바운드 및 아웃바운드 종속 항목을 볼 수도 있습니다.

MCP 서버의 경우 요청 수와 p95 요청 기간을 모니터링하여 사용률과 응답성을 추적할 수 있습니다.

에이전트 작업 감사

엔터프라이즈 보안 및 규정 준수 감사를 지원하기 위해 Gemini Enterprise Agent Platform은 이중 기여 분석 로깅을 사용하여 Cloud Logging에 에이전트 활동을 기록합니다. 에이전트가 사용자를 대신하여 작업을 수행하거나 도구를 호출하는 경우(사용자 위임 권한) 감사 및 실행 로그에는 SPIFFE 기반 에이전트 ID(감사 로그의 principal://... 또는 실행 로그의 spiffe://...)와 작업을 시작한 사람의 ID가 모두 기록됩니다. 에이전트가 자체 권한으로 자율적으로 작동하면 로그는 작업을 고유한 에이전트 ID에 직접 기여합니다.

감사자와 보안 관리자는 로그 쿼리에서 is_agentic=true 플래그를 필터링하여 Cloud Logging에서 에이전트가 시작한 이벤트를 격리하고 검토할 수 있습니다. is_agentic=true를 에이전트 ID 또는 사용자 주 구성원과 결합하면 엔드 투 엔드 실행 경로를 추적하고 모든 에이전트 상호작용에서 정책 시행을 확인할 수 있습니다.

긴급 중지 및 정책 전파 기대치

보안 사고 또는 비정상적인 에이전트 동작에 대응할 때 Agent Platform은 에이전트 활동을 중지하기 위한 두 가지 보완 레이어를 제공합니다.

  • 즉각적인 런타임 종료 또는 트래픽 재라우팅: Agent Runtime(runtimes.delete 또는 reasoningEngines.delete)에서 배포된 에이전트를 삭제하면 컨테이너 인스턴스가 즉시 종료되고, 활성 세션과 스트리밍 호출이 중지되며, 삭제 작업이 완료되면 SPIFFE 에이전트 ID가 영구적으로 무효화됩니다. 또는 trafficSplitManual를 사용하여 루트 트래픽의 100% 를 정상으로 알려진 버전으로 다시 라우팅하거나 spec.deployment_spec.agent_gateway_config를 업데이트하여 기존 버전을 보관처리할 수 있습니다.
  • 정책 기반 액세스 취소: Agent Gateway(iamEnforcementMode: "ENFORCE")에서 적용하는 통합 액세스 정책(UAP)에 DENY 규칙을 추가하거나 Identity and Access Management(IAM) 거부 정책 또는 역할 취소를 적용하면 포렌식 분석을 위해 런타임 컨테이너를 보존하면서 아웃바운드 도구 및 API 호출을 차단합니다. 하지만 UAP 및 IAM 정책 업데이트는 결과적 일관성을 갖습니다. 직접 정책 변경사항은 일반적으로 2분 이내에 적용되지만 전역적으로 전파되는 데 최대 7분 이상 걸릴 수 있으며(액세스 변경 전파 참조) principalSet 또는 그룹 멤버십 업데이트는 동기화하는 데 몇 분에서 몇 시간까지 걸릴 수 있습니다. 정책 업데이트는 새 승인 검사를 평가하며 다시 승인되지 않는 한 이미 설정된 스트리밍 연결을 강제로 닫지 않습니다.

활성 사고 중에 즉시 중지하려면 정책 거부 규칙을 적용하는 것 외에도 에이전트 런타임을 삭제하거나 버전 트래픽을 다시 라우팅하세요. 단계별 안내는 긴급 중지 및 액세스 취소를 참조하세요.

원격 분석 및 보안 발견 사항 지연 시간

모니터링 가능성 및 보안 제어에 따라 다른 수집 및 평가 일정이 적용됩니다. 이러한 지연 시간 기대치를 이해하면 사고 대응자가 인라인 시행과 비동기 위협 감지를 구분하는 데 도움이 됩니다.

다음 표에는 Agent Platform의 각 원격 분석 및 보안 처리된 신호에 대한 평가 모델과 예상 지연 시간이 요약되어 있습니다.

신호 또는 제어 평가 및 처리 모델 일반 지연 시간
Cloud 감사 로그 및 Agent Gateway 요청 로그(cloudaudit.googleapis.com/*, networkservices.googleapis.com/gateway_requests) API 호출 및 게이트웨이 승인 검사가 평가될 때 동기식으로 생성된 후 Logging에 수집됩니다. 거의 실시간(일반적으로 몇 초 이내에 로그 탐색기에서 검색 가능) --freshness=6h와 같은 좁은 CLI 최신성 필터는 최근에 색인이 생성된 색인 항목을 놓치는 경우가 있습니다. 최근 이벤트를 확인할 때는 --freshness=1d를 사용하세요.
Agent Runtime 실행 로그(aiplatform.googleapis.com/reasoning_engine_stdout, reasoning_engine_stderr) 런타임 컨테이너에서 Logging으로 비동기식으로 스트리밍됩니다. 일반적으로 전송 후 몇 초 이내에 표시됩니다.
Cloud Trace의 분산 trace OpenTelemetry 스팬이 완료되면 구성된 samplingRate 및 parentBasedSampling 규칙에 따라 비동기식으로 내보내집니다. 일반적으로 스팬 완료 후 몇 초 이내에 검색할 수 있습니다.
Cloud Monitoring 측정항목 Agent Runtime, Agent Gateway, 이상 감지 파이프라인에서 주기적으로 샘플링됩니다. 60~120초마다 샘플링되며 측정항목 탐색기 및 대시보드에서 최대 180~420초의 가시성 지연이 발생합니다.
인라인 정책 시행(Agent Gateway, IAP(Identity-Aware Proxy), Model Armor) 도구 호출, MCP 요청 또는 모델 프롬프트가 완료되기 전에 실시간 요청 경로에서 동기식으로 평가됩니다. 실시간 인라인 가로채기(후처리 지연 없음)
에이전트 이상 감지 및 Security Command Center(Security Command Center) 발견 항목(AGENT_SESSION_ANOMALY) 세션 로그와 trace가 수집된 후 다층 감지 파이프라인에서 비동기식으로 대역 외 평가가 이루어지므로 실시간 에이전트 응답에 지연 시간이 추가되지 않습니다. 초기 범위 사용 설정에는 약 40분이 소요됩니다. 이상 측정항목은 120초마다 샘플링되며(최대 420초의 가시성 지연), 확인된 발견 사항이 Security Command Center에 표시되기 전에 추가 동기화 지연 시간이 적용됩니다.

감사 로그의 조작 방지 보관

Cloud 감사 로그 항목은 설계상 변경할 수 없습니다. Logging에서 감사 로그 항목을 작성한 후에는 페이로드와 메타데이터를 수정할 수 없습니다. 관리자 활동 및 시스템 이벤트 감사 로그는 _Required 로그 버킷에 저장되며, 이 버킷은 400일의 고정 보관 기간을 적용하며 수정하거나 삭제할 수 없습니다.

기본적으로 데이터 액세스 감사 로그(cloudaudit.googleapis.com/data_access), 정책 거부 로그(cloudaudit.googleapis.com/policy_denied), Agent Gateway 요청 로그(networkservices.googleapis.com/gateway_requests), 이중 기여 에이전트 실행 로그(is_agentic=true)는 보관 기간이 30일인 _Default 로그 버킷으로 라우팅됩니다.

규정 준수 증거를 위해 변조 방지, WORM(Write Once Read Many) 보관을 시행하려면 에이전트 감사 및 게이트웨이 로그를 커스텀 Logging 버킷으로 라우팅하고 커스텀 보관 기간(1~3,650일)을 구성하고 버킷을 영구적으로 잠급니다. Logging 버킷을 잠그면 프로젝트 소유자와 조직 관리자를 포함한 누구도 버킷을 삭제하거나, 보관 기간이 만료되기 전에 로그 항목을 삭제하거나, 보관 기간을 줄일 수 없으며, 이 작업은 되돌릴 수 없습니다.

Google Cloud CLI를 사용하여 에이전트 감사 로그의 커스텀 Logging 버킷을 만들고 잠그려면 다음 명령어를 실행합니다.

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

다음을 바꿉니다.

  • BUCKET_ID: 감사 로그 버킷의 고유 식별자입니다(예: agent-audit-worm-bucket).
  • LOCATION: 버킷 위치(예: global, us 또는 eu)
  • RETENTION_DAYS: 로그 항목을 보관할 일수(1~3650)입니다.
  • PROJECT_ID: Google Cloud 프로젝트 ID입니다.

상위 프로젝트가 삭제될 때 잠긴 로그 버킷이 삭제되지 않도록 보호하려면 프로젝트에 프로젝트 선취권을 적용합니다. 또는 잠긴 보관 정책(버킷 잠금)으로 구성된 Cloud Storage 버킷으로 감사 로그를 내보낼 수 있습니다. 자세한 내용은 로그 버킷 구성 및 관리를 참조하세요.

SIEM으로 감사 로그 내보내기

보안 모니터링, 상관관계, 장기 규정 준수 보관을 중앙 집중화하기 위해 에이전트 감사 로그, Agent Gateway 승인 결정, is_agentic=true 실행 로그를 Google Security Operations(Google SecOps) 또는 서드 파티 보안 정보 및 이벤트 관리(SIEM) 시스템으로 지속적으로 내보낼 수 있습니다.

프로젝트 수준 Logging 싱크 또는 조직 수준 또는 폴더 수준 집계 싱크를 구성하여 로그를 다음 대상으로 라우팅할 수 있습니다.

  • Google Security Operations: Cloud 감사 로그, Agent Gateway 로그, Security Command Center의 AGENT_SESSION_ANOMALY 발견 항목을 기본적으로 또는 Pub/Sub 또는 Cloud Storage 피드를 통해 Google SecOps에 수집하여 엔터프라이즈 보안 원격 분석과 함께 에이전트 세션을 조사합니다. 설정 안내는 Google SecOps로 Google Cloud 데이터 내보내기를 참조하세요.
  • Pub/Sub(Pub/Sub): Pub/Sub 구독 또는 Dataflow 커넥터를 사용하여 서드 파티 SIEM 플랫폼(예: Splunk, Datadog, QRadar)에서 수집할 수 있도록 에이전트 감사 로그를 Pub/Sub 주제로 실시간 스트리밍합니다. 자세한 내용은 Pub/Sub로 로그 라우팅을 참조하세요.
  • BigQuery(BigQuery) 또는 Observability Analytics: 로그를 BigQuery 데이터 세트로 내보내거나 Observability Analytics가 사용 설정된 로그 버킷을 BigQuery에 연결하여 에이전트 ID, 사용자 위임, 게이트웨이 정책 거부에 대한 SQL 규정 준수 쿼리를 실행합니다.
  • Cloud Storage: 장기적인 변경 불가 보관처리를 위해 버킷 잠금이 사용 설정된 Cloud Storage 버킷으로 일괄 JSON 로그 파일을 내보냅니다.

SIEM 수집을 위해 에이전트 감사 및 게이트웨이 로그를 Pub/Sub 주제로 스트리밍하는 Logging 싱크를 만들려면 다음 단계를 완료합니다.

  1. Cloud 감사 로그, Agent Gateway 요청 로그, Agent Runtime 로그, 이중 기여 분석 항목(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

    다음을 바꿉니다.

    • SINK_NAME: 로그 싱크의 이름입니다(예: agent-audit-siem-sink).
    • DESTINATION_PROJECT_ID: 대상 Pub/Sub 주제를 호스팅하는 프로젝트 ID입니다.
    • TOPIC_ID: SIEM이 구독하는 Pub/Sub 주제의 ID입니다.
    • PROJECT_ID: 로그를 내보내는 프로젝트의 프로젝트 ID입니다. 전체 조직에서 내보내려면 --project=PROJECT_ID를 --organization=ORGANIZATION_ID --include-children로 바꿉니다.

  2. 싱크의 작성자 서비스 계정 ID를 검색하고 대상 주제에 대한 Pub/Sub 게시자 역할(roles/pubsub.publisher)을 부여합니다.

    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"

OpenTelemetry 생성형 AI 규칙

에이전트 trace 및 프롬프트 및 응답 로그는 생성형 AI 시스템의 OpenTelemetry 시맨틱 규칙을 크게 사용하여 생성형 AI 원격 분석이 캡처, 구조화, 보고되는 방식을 표준화합니다.

이러한 규칙을 준수하는 것은 에이전트 추적에 매우 중요합니다. 도구 실행, 검색 단계, 토큰 소비와 같은 복잡한 다단계 에이전트 워크플로를 설명하기 위한 범용적이고 공급업체에 구애받지 않는 형식을 설정하기 때문입니다. 이러한 표준화는 Google Cloud내부와 외부 모두에서 다양한 모니터링 가능성 백엔드와 분석 도구 간의 원활한 상호 운용성을 지원합니다.

다음 단계