Ringkasan pelacakan terdistribusi

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Pelacakan terdistribusi untuk Load Balancer Aplikasi memberikan visibilitas menyeluruh ke permintaan saat permintaan tersebut berpindah dari klien Anda, melalui load balancer, dan ke layanan backend Anda.

Cloud Load Balancing terintegrasi dengan Cloud Trace untuk membuat span trace untuk permintaan yang diproses load balancer. Karena load balancer adalah titik entri untuk traffic aplikasi Anda, memulai dan menyebarkan konteks trace di load balancer akan memastikan visibilitas diagnostik di seluruh jalur permintaan. Anda dapat menggunakan trace ini untuk mengidentifikasi bottleneck latensi, mengisolasi hop yang gagal, dan memecahkan masalah error di seluruh arsitektur multi-tingkat.

Load balancer menghasilkan trace yang sesuai dengan standar terbuka (Konteks Trace W3C dan OpenTelemetry). Layanan backend yang diinstrumentasikan dengan OpenTelemetry dapat melanjutkan trace yang dimulai oleh load balancer.

Catatan: Selama Pratinjau, pelacakan terdistribusi tunduk pada batasan tertentu. Untuk mengetahui informasi selengkapnya, lihat Batasan dalam dokumen ini.

Manfaat utama

Pelacakan terdistribusi dengan Cloud Trace memberikan manfaat berikut:

• Visibilitas permintaan menyeluruh: melacak jalur permintaan di seluruh Load Balancer Aplikasi eksternal dan internal serta layanan backend yang menjadi tujuan perutean traffic.
• Kemampuan observasi edge: menangkap span trace di aturan penerusan, sebelum load balancer memilih backend, sehingga Anda dapat melihat error edge dan latensi yang tidak dapat dideteksi oleh instrumentasi backend.
• Konfigurasi telemetri yang dipisahkan: tentukan setelan pelacakan di resource TelemetryPolicy mandiri tanpa mengubah konfigurasi pemilihan rute load balancer Anda.
• Korelasi lintas telemetri: menghubungkan span trace dengan log permintaan Cloud Load Balancing dan metrik Cloud Monitoring untuk menentukan asal latensi atau error.

Load balancer yang didukung

Tabel berikut mencantumkan load balancer yang mendukung pelacakan terdistribusi dan mode sampling yang didukung setiap load balancer:

Load balancer	Skema load balancing	Pengambilan sampel probabilistik	Sampling berbasis induk
Load Balancer Aplikasi eksternal global	EXTERNAL_MANAGED
Load Balancer Aplikasi eksternal regional	EXTERNAL_MANAGED
Load Balancer Aplikasi internal regional	INTERNAL_MANAGED
Load Balancer Aplikasi internal lintas region	INTERNAL_MANAGED

Load Balancer Aplikasi klasik tidak mendukung pelacakan terdistribusi.

Cara kerja pelacakan terdistribusi

Untuk mengonfigurasi pelacakan terdistribusi, buat resource TelemetryPolicy di Network Services API. Kebijakan telemetri menentukan hal berikut:

• Targets: aturan penerusan load balancer yang ingin Anda lacak.
• Konfigurasi pelacakan: setelan pengambilan sampel yang menentukan permintaan mana yang dilacak oleh load balancer.

Saat permintaan tiba di aturan penerusan yang ditargetkan oleh kebijakan telemetri, load balancer akan memutuskan apakah akan mengambil sampel permintaan tersebut. Jika permintaan diambil sampelnya, load balancer akan membuat span trace, mengirimkan span ke Cloud Trace, dan menyebarkan konteks trace ke backend di header permintaan traceparent W3C.

Lampiran aturan penerusan

Kebijakan telemetri menargetkan aturan penerusan load balancer, yang mewakili frontend load balancer. Dengan melampirkan pelacakan di aturan penerusan, load balancer dapat melacak semua traffic yang memasuki alamat IP virtual (VIP) dan port, termasuk permintaan yang gagal sebelum load balancer memilih backend.

Kebijakan telemetri memiliki karakteristik berikut:

• Siklus proses independen: kebijakan telemetri terpisah dari layanan backend, peta URL, dan proxy target. Anda dapat membuat, mengubah, atau menghapus kebijakan telemetri tanpa mengubah cara load balancer merutekan traffic.
• Dapat digunakan kembali di seluruh frontend: satu kebijakan telemetri dapat menargetkan beberapa aturan penerusan, sehingga Anda dapat menerapkan setelan pelacakan yang konsisten di beberapa frontend load balancer.
• Cakupan lokasi: buat kebijakan telemetri di lokasi global untuk menargetkan aturan penerusan global, seperti yang digunakan oleh Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi internal lintas region. Buat kebijakan telemetri di suatu region untuk menargetkan aturan penerusan regional di region tersebut, seperti yang digunakan oleh Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional.

Mode sampling

Pelacakan terdistribusi mendukung mode pengambilan sampel berikut. Untuk mengetahui informasi selengkapnya tentang mode pengambilan sampel yang didukung setiap load balancer, dalam dokumen ini, lihat Load balancer yang didukung.

• Sampling probabilistik: load balancer mengambil sampel proporsi permintaan tetap, yang Anda tetapkan di kolom samplingRate. Misalnya, nilai 0.01 mengambil sampel 1% permintaan. Sampling probabilistik didukung di semua load balancer yang didukung.

• Parent-based sampling: load balancer mematuhi keputusan pengambilan sampel di header traceparent yang masuk dari klien atau layanan upstream. Anda mengonfigurasi sampling berbasis induk di kolom parentBasedSampling. Sampling berbasis induk hanya didukung di Load Balancer Aplikasi internal.

  Saat Anda mengaktifkan pengambilan sampel berbasis induk, load balancer akan menangani permintaan sebagai berikut:

  • Jika header traceparent yang masuk memiliki flag sampel yang ditetapkan, load balancer akan mengambil sampel permintaan pada rasio yang ditentukan di kolom parentBasedSampling.samplingRate. Misalnya, tetapkan kolom ini ke 1.0 untuk melacak semua permintaan yang telah diambil sampelnya oleh layanan upstream.
  • Jika header traceparent yang masuk tidak memiliki flag sampel yang ditetapkan, load balancer tidak akan mengambil sampel permintaan. Perilaku ini mengikuti keputusan upstream dan spesifikasi OpenTelemetry, yang mencegah trace yang terputus muncul di Cloud Trace.
  • Jika permintaan tidak menyertakan header traceparent, load balancer akan menerapkan samplingRate dasar pengukuran.

Penanganan header konteks trace

Load balancer menangani header traceparent W3C sebagai berikut:

• Tracing tidak diaktifkan, atau permintaan tidak diambil sampelnya: load balancer meneruskan header traceparent yang masuk ke backend tanpa perubahan.
• Permintaan diambil sampelnya dan tidak menyertakan header traceparent: load balancer menghasilkan ID trace dan ID span baru, serta menetapkan flag trace ke 03 (acak dan diambil sampelnya).
• Permintaan diambil sampelnya dan menyertakan header traceparent: load balancer mempertahankan ID trace dan flag acak yang masuk, menghasilkan ID span baru, dan menetapkan flag yang diambil sampelnya.

Layanan backend yang menggunakan SDK OpenTelemetry dengan propagator W3C Trace Context akan otomatis membaca header traceparent dan melanjutkan trace. Untuk mengetahui informasi selengkapnya, lihat Konteks trace.

Kasus penggunaan umum

Bagian ini menjelaskan skenario umum untuk pelacakan terdistribusi.

Memantau edge etalase

Etalase e-commerce menggunakan Load Balancer Aplikasi eksternal global untuk menerima traffic pelanggan. Untuk memantau latensi edge dan error seperti respons 404 dan kegagalan TLS, Anda melampirkan kebijakan telemetri dengan pengambilan sampel probabilistik ke aturan penerusan etalase. Frekuensi sampling yang rendah, seperti 0.01 (1%), membuat biaya penyerapan Cloud Trace dapat diprediksi selama peristiwa traffic puncak.

Mempertahankan kontinuitas trace di seluruh layanan checkout

Permintaan checkout dikirim dari storefront melalui Load Balancer Aplikasi internal ke layanan internal untuk keranjang, inventaris, dan pembayaran. Untuk memastikan bahwa permintaan checkout yang diambil sampelnya di etalase dilacak di setiap hop internal, Anda mengaktifkan pengambilan sampel berbasis induk di load balancer internal dengan parentBasedSampling.samplingRate sebesar 1.0. Traffic internal rutin yang tidak membawa keputusan pengambilan sampel upstream akan diambil sampelnya pada nilai dasar samplingRate.

Mengisolasi bottleneck latensi

Saat latensi checkout meningkat atau error 5xx melonjak, Anda membandingkan span load balancer di Cloud Trace dengan log permintaan load balancer dan metrik latensi. Perbandingan ini membantu Anda menentukan apakah masalah berasal dari edge load balancer, di hop load balancer internal, atau di layanan backend.

Harga

Load balancer tidak mengenakan biaya untuk pembuatan span trace. Namun, Cloud Trace mengenakan biaya untuk penyerapan span trace sesuai dengan harga Cloud Trace.

Untuk mengelola biaya penyerapan untuk workload produksi dengan traffic tinggi, sebaiknya gunakan samplingRate sebesar 0.01 (1%) atau 0.001 (0,1%).

Batasan

Selama Pratinjau, pelacakan terdistribusi untuk Load Balancer Aplikasi memiliki batasan berikut:

• Sampling berbasis induk tidak didukung di Load Balancer Aplikasi eksternal.
• Atribut span kustom tidak didukung.
• Anda tidak dapat mengonfigurasi pelacakan terdistribusi menggunakan Gateway API Google Kubernetes Engine atau Terraform.
• Satu kebijakan telemetri dapat menargetkan hingga 50 resource.

Pelacakan terdistribusi untuk Agent Gateway

Jika Anda menggunakan Agent Gateway untuk mengelola traffic agen AI, lihat Memantau traffic melalui Agent Gateway untuk mengetahui informasi tentang cara memantau traffic agen.

Langkah berikutnya

• Melacak traffic masuk dengan Cloud Trace
• Ringkasan Cloud Trace
• Menemukan dan menjelajahi trace