Ringkasan kemampuan observasi

Observabilitas agen di Gemini Enterprise Agent Platform memberikan visibilitas komprehensif terhadap performa, perilaku, dan kondisi agen yang di-deploy dan server Model Context Protocol (MCP). Dengan memantau metrik utama, melacak jalur eksekusi, dan mengamati sistem multi-agen secara keseluruhan, Anda dapat mendiagnosis masalah, mengoptimalkan konsumsi resource, dan meningkatkan keandalan agen.

Dokumen ini memberikan ringkasan alat kemampuan observasi yang tersedia dalam Gemini Enterprise Agent Platform, termasuk topologi di seluruh sistem, pemantauan agen individual, dan metrik server MCP.

Penyiapan telemetri

Untuk mengisi dasbor, topologi, dan trace kemampuan observasi ini, agen Anda harus dikonfigurasi untuk mengirim data telemetri dalam format OpenTelemetry ke sistem penyimpanan di Google Cloud Observability.

Pastikan lingkungan agen dan server MCP Anda dikonfigurasi dengan benar untuk memunculkan data ini. Komponen Google Cloud bawaan otomatis memunculkan telemetri dalam format OpenTelemetry. Misalnya, Model Armor secara native memunculkan telemetri standar, sehingga Anda dapat mengekspos dan memantau intersepsi kebijakan real-time secara lancar langsung dalam data trace tanpa memerlukan instrumentasi kustom.

Untuk mengetahui petunjuk dan persyaratan penyiapan telemetri agen, lihat referensi berikut:

Sinyal kemampuan observasi

Gemini Enterprise Agent Platform menyediakan kemampuan observasi melalui metrik, trace, dan log.

Saat Anda memilih agen tertentu dari Registry, tab Observability menyediakan rangkaian dasbor yang ditargetkan untuk memantau kondisi operasional, performa, dan pemanfaatan infrastrukturnya. Gunakan navigasi sebelah kiri dalam tab Observability untuk beralih di antara tampilan berikut:

  • Ringkasan: Melacak penggunaan tingkat tinggi selama jangka waktu yang Anda pilih, termasuk total sesi, giliran rata-rata per sesi, dan total pemanggilan agen. Diagram deret waktu menampilkan penggunaan token (input versus output), volume traffic agen secara keseluruhan, persentil latensi (p50, p95, p99), dan tingkat error.
  • Evaluasi: Menampilkan monitor online untuk penilaian kualitas berkelanjutan. Hal ini mencakup widget deret waktu yang melacak kualitas respons rata-rata, metrik keamanan, tingkat halusinasi, dan kualitas penggunaan alat.
  • Model: Menguraikan performa berdasarkan model dasar yang mendasarinya. Anda dapat memantau latensi p95, jumlah total panggilan, tingkat error, kegagalan kuota, dan penggunaan token yang diisolasi oleh model tertentu.
  • Alat: Memantau alat dan layanan eksternal yang terhubung ke agen. Tampilan ini merinci latensi p95, jumlah panggilan, dan tingkat error per alat, serta frekuensi interaksi saat tidak ada alat yang dipanggil.
  • Penggunaan: Menyediakan metrik tingkat infrastruktur untuk lingkungan runtime agen, termasuk alokasi CPU container, alokasi memori container, dan penggunaan token.
  • Logs: Menampilkan aliran log agen mentah yang dapat difilter, termasuk tingkat keparahan, stempel waktu, dan ringkasan eksekusi untuk pemecahan masalah mendalam. Untuk mengetahui informasi selengkapnya, lihat Melihat log agen.

Selain dasbor di tab Observability, Anda dapat menggunakan tab Traces agen untuk memeriksa eksekusi langkah demi langkah dari sesi tertentu, termasuk directed acyclic graph span dan input/output. Untuk mengetahui informasi selengkapnya, lihat Melihat Trace Agen. Anda juga dapat menggunakan tab Topology untuk melihat dependensi masuk dan keluar tertentu untuk satu agen tersebut.

Untuk server MCP, Anda dapat memantau jumlah permintaan dan durasi permintaan p95 untuk melacak pemanfaatan dan responsivitas.

Mengaudit tindakan agen

Untuk mendukung audit keamanan dan kepatuhan perusahaan, Gemini Enterprise Agent Platform menggunakan logging atribusi ganda untuk mencatat aktivitas agen di Cloud Logging. Saat agen melakukan tindakan atau memanggil alat atas nama seseorang (otoritas yang didelegasikan pengguna), log audit dan eksekusi mencatat identitas agen berbasis SPIFFE (principal://... dalam log audit, atau spiffe://... dalam log eksekusi) dan identitas pengguna manusia yang memulai. Saat agen bertindak secara otonom berdasarkan otoritasnya sendiri, log akan mengatribusikan tindakan tersebut langsung ke identitas agen yang unik.

Auditor dan administrator keamanan dapat mengisolasi dan meninjau peristiwa yang dimulai agen di Cloud Logging dengan memfilter flag is_agentic=true dalam kueri log. Menggabungkan is_agentic=true dengan identitas agen atau akun utama pengguna memungkinkan Anda melacak jalur eksekusi end-to-end dan memverifikasi penerapan kebijakan di semua interaksi agen.

Ekspektasi penghentian darurat dan penerapan kebijakan

Saat merespons insiden keamanan atau perilaku agen yang tidak normal, Agent Platform menyediakan dua lapisan pelengkap untuk menghentikan aktivitas agen:

  • Penghentian runtime atau pengalihan traffic langsung: Menghapus agen yang di-deploy di Agent Runtime (runtimes.delete atau reasoningEngines.delete) akan langsung menghentikan instance container-nya, menghentikan sesi aktif dan pemanggilan streaming, serta membatalkan identitas agen SPIFFE-nya secara permanen setelah operasi penghapusan selesai. Atau, Anda dapat mengalihkan 100% traffic root ke revisi yang diketahui baik menggunakan trafficSplitManual atau mengarsipkan revisi yang sudah ada dengan memperbarui spec.deployment_spec.agent_gateway_config.
  • Pencabutan akses berbasis kebijakan: Menambahkan aturan DENY ke Unified Access Policies (UAP) yang diterapkan oleh Agent Gateway (iamEnforcementMode: "ENFORCE"), atau menerapkan kebijakan penolakan atau pencabutan peran Identity and Access Management (IAM), akan memblokir alat keluar dan panggilan API sekaligus mempertahankan container runtime untuk analisis forensik. Namun, UAP dan update kebijakan IAM pada akhirnya konsisten: perubahan kebijakan langsung biasanya berlaku dalam waktu 2 menit, tetapi dapat memerlukan waktu hingga 7 menit atau lebih lama untuk diterapkan secara global (lihat Penerapan perubahan akses), dan update keanggotaan grup atau principalSet dapat memerlukan waktu beberapa menit hingga jam untuk disinkronkan. Pembaruan kebijakan dievaluasi pada pemeriksaan otorisasi baru dan tidak menutup paksa koneksi streaming yang sudah dibuat kecuali jika diotorisasi ulang.

Untuk tombol penghentian darurat selama insiden aktif, hapus runtime agen atau alihkan traffic revisinya selain menerapkan aturan penolakan kebijakan. Untuk petunjuk langkah demi langkah, lihat Penghentian darurat dan pencabutan akses.

Latensi temuan keamanan dan telemetri

Kontrol keamanan dan kemampuan observasi yang berbeda beroperasi pada jadwal penyerapan dan evaluasi yang berbeda. Memahami ekspektasi latensi ini membantu respons insiden membedakan antara penegakan inline dan deteksi ancaman asinkron.

Tabel berikut merangkum model evaluasi dan latensi yang diharapkan untuk setiap sinyal telemetri dan sinyal aman di Agent Platform:

Sinyal atau kontrol Model evaluasi dan penyerapan Latensi umum
Log permintaan Cloud Audit Logs dan Agent Gateway (cloudaudit.googleapis.com/*, networkservices.googleapis.com/gateway_requests) Dibuat secara sinkron saat panggilan API dan pemeriksaan otorisasi gateway dievaluasi, lalu diserap ke Logging. Hampir real-time (biasanya dapat ditelusuri di Logs Explorer dalam hitungan detik). Filter keaktualan CLI yang sempit seperti --freshness=6h terkadang dapat melewatkan entri yang baru diindeks; gunakan --freshness=1d saat memverifikasi peristiwa terbaru.
Log eksekusi Agent Runtime (aiplatform.googleapis.com/reasoning_engine_stdout, reasoning_engine_stderr) Melakukan streaming secara asinkron dari container runtime ke Logging. Biasanya terlihat dalam hitungan detik setelah emisi.
Trace terdistribusi di Cloud Trace Diekspor secara asinkron saat span OpenTelemetry selesai, sesuai dengan aturan samplingRate dan parentBasedSampling yang dikonfigurasi. Biasanya dapat ditelusuri dalam hitungan detik setelah penyelesaian span.
Metrik Cloud Monitoring Diambil sampelnya secara berkala dari Agent Runtime, Agent Gateway, dan pipeline deteksi anomali. Sampelnya dibuat setiap 60 hingga 120 detik, dengan penundaan visibilitas hingga 180 hingga 420 detik di Metrics Explorer dan dasbor.
Penerapan kebijakan inline (Agent Gateway, Identity-Aware Proxy, Model Armor) Dievaluasi secara sinkron pada jalur permintaan aktif sebelum panggilan alat, permintaan MCP, atau perintah model selesai. Intersepsi inline real-time (tanpa penundaan pascapemrosesan).
Agent Anomaly Detection dan temuan Security Command Center (Security Command Center) (AGENT_SESSION_ANOMALY) Dievaluasi secara asinkron di luar band di seluruh pipeline deteksi berlapis setelah log dan rekaman aktivitas sesi diserap, sehingga tidak menambah latensi pada respons agen langsung. Pengaktifan cakupan awal memerlukan waktu sekitar 40 menit. Metrik anomali diambil sampelnya setiap 120 detik (dengan penundaan visibilitas hingga 420 detik), dan latensi sinkronisasi tambahan berlaku sebelum temuan yang dikonfirmasi muncul di Security Command Center.

Retensi yang tahan perusakan untuk log audit

Entri Cloud Audit Logs tidak dapat diubah secara desain: setelah Logging menulis entri log audit, payload dan metadatanya tidak dapat diubah. Log audit Aktivitas Admin dan Peristiwa Sistem disimpan di bucket log _Required, yang menerapkan periode retensi tetap selama 400 hari dan tidak dapat diubah atau dihapus.

Secara default, log audit Akses Data (cloudaudit.googleapis.com/data_access), log Kebijakan Ditolak (cloudaudit.googleapis.com/policy_denied), log permintaan Gateway Agen (networkservices.googleapis.com/gateway_requests), dan log eksekusi agen atribusi ganda (is_agentic=true) dirutekan ke bucket log _Default dengan periode retensi 30 hari.

Untuk menerapkan retensi write-once, read-many (WORM) yang tahan modifikasi untuk bukti kepatuhan, rutekan log gateway dan audit agen Anda ke bucket Logging kustom, konfigurasikan periode retensi kustom (dari 1 hingga 3.650 hari), dan kunci bucket secara permanen. Mengunci bucket Logging adalah tindakan yang tidak dapat diubah dan mencegah siapa pun, termasuk Project Owner dan administrator organisasi, menghapus bucket, menghapus entri log sebelum periode retensi data berakhir, atau mengurangi periode retensi data.

Untuk membuat dan mengunci bucket Logging kustom untuk log audit agen menggunakan Google Cloud CLI, jalankan perintah berikut:

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

Ganti kode berikut:

  • BUCKET_ID: ID unik untuk bucket log audit Anda (misalnya, agent-audit-worm-bucket).
  • LOCATION: Lokasi bucket (misalnya, global, us, atau eu).
  • RETENTION_DAYS: Jumlah hari untuk menyimpan entri log (antara 1 dan 3650).
  • PROJECT_ID: Project ID Google Cloud Anda.

Untuk melindungi bucket log yang terkunci agar tidak dihapus jika project induknya dihapus, tempatkan lien project pada project. Atau, Anda dapat mengekspor log audit ke bucket Cloud Storage yang dikonfigurasi dengan kebijakan retensi terkunci (Penguncian Bucket). Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi dan mengelola bucket log.

Mengekspor log audit ke SIEM

Untuk memusatkan pemantauan keamanan, korelasi, dan pengarsipan kepatuhan jangka panjang, Anda dapat terus mengekspor log audit agen, keputusan otorisasi Agent Gateway, dan log eksekusi is_agentic=true ke Google Security Operations (Google SecOps) atau sistem Security Information and Event Management (SIEM) pihak ketiga.

Anda dapat mengonfigurasi sink Logging level project atau sink gabungan level organisasi atau level folder untuk merutekan log ke tujuan berikut:

  • Google Security Operations: Serap Cloud Audit Logs, log Agent Gateway, dan temuan AGENT_SESSION_ANOMALY dari Security Command Center ke Google SecOps secara native atau melalui feed Pub/Sub atau Cloud Storage untuk menyelidiki sesi agen bersama telemetri keamanan perusahaan. Untuk petunjuk penyiapan, lihat Mengekspor data Google Cloud ke Google SecOps.
  • Pub/Sub (Pub/Sub): Melakukan streaming log audit agen secara real time ke topik Pub/Sub untuk penyerapan oleh platform SIEM pihak ketiga (seperti Splunk, Datadog, atau QRadar) menggunakan langganan Pub/Sub atau konektor Dataflow. Untuk mengetahui detailnya, lihat Merutekan log ke Pub/Sub.
  • BigQuery (BigQuery) atau Observability Analytics: Ekspor log ke set data BigQuery atau tautkan bucket log yang mendukung Observability Analytics ke BigQuery untuk menjalankan kueri kepatuhan SQL di seluruh identitas agen, delegasi pengguna, dan penolakan kebijakan gateway.
  • Cloud Storage: Ekspor file log JSON dalam batch ke bucket Cloud Storage dengan Kunci Bucket diaktifkan untuk pengarsipan yang tidak dapat diubah dalam jangka panjang.

Untuk membuat sink Logging yang mengalirkan log audit agen dan gateway ke topik Pub/Sub untuk penyerapan SIEM, selesaikan langkah-langkah berikut:

  1. Buat sink log dengan filter penyertaan yang menangkap Cloud Audit Logs, log permintaan Agent Gateway, log Agent Runtime, dan entri atribusi ganda (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

    Ganti kode berikut:

    • SINK_NAME: Nama untuk sink log Anda (misalnya, agent-audit-siem-sink).
    • DESTINATION_PROJECT_ID: Project ID yang menghosting topik Pub/Sub tujuan.
    • TOPIC_ID: ID topik Pub/Sub yang di-subscribe oleh SIEM Anda.
    • PROJECT_ID: Project ID tempat Anda mengekspor log. Untuk mengekspor di seluruh organisasi, ganti --project=PROJECT_ID dengan --organization=ORGANIZATION_ID --include-children.

  2. Ambil identitas akun layanan penulis sink dan berikan peran Pub/Sub Publisher (roles/pubsub.publisher) pada topik tujuan:

    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"

Konvensi AI generatif OpenTelemetry

Trace agen dan log perintah dan respons sangat bergantung pada Konvensi Semantik OpenTelemetry untuk sistem AI generatif untuk menstandarkan cara telemetri AI generatif diambil, disusun, dan dilaporkan.

Mematuhi konvensi ini sangat penting untuk pelacakan agen karena menetapkan format universal yang tidak bergantung pada vendor untuk mendeskripsikan alur kerja agen multi-langkah yang kompleks, seperti eksekusi alat, langkah pengambilan, dan konsumsi token. Standardisasi ini membantu interoperabilitas yang lancar di berbagai backend kemampuan observasi dan alat analisis, baik di dalam maupun di luar Google Cloud.

Langkah berikutnya