Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Memecahkan masalah terkait Load Balancer Aplikasi eksternal

Panduan ini menjelaskan cara memecahkan masalah konfigurasi untuk Load Balancer Aplikasi eksternal. Sebelum menyelidiki masalah, pahami halaman berikut:

Memecahkan masalah umum dengan Network Analyzer

Network Analyzer secara otomatis memantau konfigurasi jaringan VPC Anda dan mendeteksi konfigurasi yang kurang optimal dan kesalahan konfigurasi. Alat ini mengidentifikasi kegagalan jaringan, memberikan informasi penyebab utama, dan menyarankan kemungkinan solusi. Untuk mempelajari berbagai skenario kesalahan konfigurasi yang otomatis terdeteksi oleh Penganalisis Jaringan, lihat Insight load balancer dalam dokumentasi Penganalisis Jaringan.

Network Analyzer tersedia di konsol Google Cloud sebagai bagian dari Network Intelligence Center.

Buka Penganalisis Jaringan

Backend memiliki mode penyeimbangan yang tidak kompatibel

Saat membuat load balancer, Anda mungkin melihat error:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Hal ini terjadi saat Anda mencoba menggunakan backend yang sama di dua load balancer yang berbeda, dan backend tidak memiliki mode penyeimbangan yang kompatibel.

Untuk informasi selengkapnya, lihat referensi berikut:

Memecahkan masalah konektivitas umum

Error '5XX' yang tidak dapat dijelaskan

Error `HTTP 5XX' dapat ditampilkan oleh GFE lapisan pertama, GFE lapisan kedua, atau backend, bergantung pada tempat terjadinya kondisi error.

Bagian ini menjelaskan cara memecahkan masalah error 5XX yang dapat terjadi pada berbagai tahap proses distribusi permintaan untuk Load Balancer Aplikasi eksternal berbasis GFE.

Mengidentifikasi sumber error '5XX' menggunakan Cloud Logging

Untuk kondisi error yang disebabkan oleh masalah komunikasi antara proxy load balancer dan backend-nya, load balancer akan membuat kode respons error HTTP (5XX) dan menampilkan kode respons error tersebut kepada klien. Tidak semua error HTTP 5XX dibuat oleh load balancer—misalnya, jika backend mengirim respons HTTP 5XX ke load balancer, load balancer akan meneruskan respons tersebut ke kliennya.

Untuk menentukan apakah respons HTTP 5XX diteruskan dari backend atau dihasilkan oleh proxy load balancer, periksa kolom statusDetails di Cloud Logging.

Jika statusDetails adalah response_sent_by_backend, load balancer meneruskan respons 5XX dari backend. Pecahkan masalah di backend Anda.
Jika statusDetails adalah pesan kegagalan lainnya, respons 5XX dihasilkan oleh load balancer.

Perubahan konfigurasi pada Load Balancer Aplikasi eksternal global, seperti penambahan atau penghapusan layanan backend, dapat menyebabkan periode singkat saat Anda melihat respons HTTP 502 dengan statusDetails sebagai failed_to_pick_backend. Hal ini normal selama penerapan perubahan konfigurasi ke GFE secara global.

Sebelum Anda mulai memecahkan masalah, pastikan kesehatan backend

Sebelum memecahkan masalah error 5XX, pastikan backend Anda responsif dan health check berhasil. Jika backend tidak berfungsi dengan baik, GFE lapisan kedua tidak dapat meneruskan permintaan ke backend tersebut, yang dapat menyebabkan error 5XX meskipun semuanya dikonfigurasi dengan benar.

Pastikan ada aturan firewall yang dikonfigurasi untuk mengizinkan health check. Jika tidak ada satu pun, health check akan gagal, dan log load balancer mungkin menunjukkan statusDetails failed_to_pick_backend.
Pastikan traffic health check mencapai VM backend Anda. Untuk melakukannya, aktifkan logging health check dan telusuri entri log yang berhasil. Untuk load balancer baru, Anda mungkin tidak langsung melihat entri log health check yang berhasil. Hal ini mungkin karena status respons awal backend belum berubah dari UNHEALTHY ke status yang berbeda. Anda hanya melihat entri log health check yang berhasil setelah pemeriksa health check menerima respons HTTP 200 OK dari backend.

Jika health check gagal, lakukan pemecahan masalah pada aplikasi backend dan aturan firewall Anda. Jika health check berhasil, tetapi Anda masih melihat error 5XX, periksa kolom statusDetails di Cloud Logging untuk mengidentifikasi sumber error, seperti yang dijelaskan di bagian berikut.

Memecahkan masalah error berdasarkan `statusDetails`

Jika error HTTP 5XX terus terjadi, gunakan kolom statusDetails di Cloud Logging untuk mengidentifikasi penyebabnya dan memecahkan masalah yang sesuai.

Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi eksternal regional menghasilkan kode status HTTP yang bermakna, seperti HTTP 503 Service Unavailable dan HTTP 504 Gateway Timeout.
Load Balancer Aplikasi klasik selalu menggunakan kode status HTTP 502 Bad Gateway untuk semua error yang dihasilkan oleh load balancer.

statusDetails	Kemungkinan penyebab dan solusi
`failed_to_pick_backend` `failed_to_pick_backend_by_hash`	Penyebab: GFE lapisan kedua tidak dapat memilih backend yang berfungsi dengan baik untuk merutekan permintaan. Error ini dapat terjadi karena salah satu alasan berikut: Semua region berada pada atau di atas kapasitas. Load balancer tidak dapat menemukan backend yang tersedia berdasarkan hash yang dihitung. Load balancer tidak dapat menemukan backend yang cocok dengan konfigurasi layanan. Solusi: Pastikan backend Anda responsif dengan mengikuti langkah-langkah yang diuraikan dalam Memverifikasi keaktifan backend. Pastikan health check dikonfigurasi dengan benar menggunakan port, jalur, dan protokol yang tepat. Pastikan aturan firewall backend mengizinkan traffic health check dari penguji health check `35.191.0.0/16`. Jika Anda memiliki beberapa grup instance backend yang tidak responsif, perhatikan bahwa failover atau overflow dibatasi untuk sejumlah kecil grup instance alternatif. Jika Anda melihat `failed_to_pick_backend` atau `failed_to_pick_backend_by_hash` meskipun memiliki grup instance yang responsif, kosongkan grup instance yang tidak responsif dengan menyetel kapasitasnya ke nol. Hal ini akan memaksa load balancer untuk meneruskan traffic ke grup instance yang responsif.
`failed_to_connect_to_backend`	Penyebab: GFE lapisan kedua gagal membuat koneksi dengan instance backend (tidak dapat memperoleh SYN-ACK). Error ini juga dapat disebabkan oleh error GFE internal yang mencegahnya terhubung ke backend, atau dari gangguan jaringan atau pemadaman regional (seperti kabel serat optik putus) yang mencegah GFE lapisan pertama berkomunikasi dengan GFE lapisan kedua. Solusi: Pastikan aturan firewall di VM backend atau di jaringan VPC Anda mengizinkan traffic ke backend Anda dari rentang GFE lapisan kedua `35.191.0.0/16`. Pastikan aplikasi di instance backend Anda berjalan dan memproses permintaan di port yang dikonfigurasi di layanan backend. Periksa metrik instance backend (CPU, memori, koneksi) untuk tanda-tanda kehabisan resource.
`backend_connection_closed_before_data_sent_to_client`	Penyebab: Koneksi antara GFE lapisan kedua dan backend ditutup secara tidak terduga sebelum respons dapat dikirim ke klien. Masalah ini dapat disebabkan oleh server web backend atau perangkat perantara. Hal ini juga dapat terjadi saat Anda menggunakan GKE jika pod sedang diturunkan skalanya atau dihentikan, dan backend load balancer berjenis NEG. Solusi: Setel waktu tunggu keep-alive HTTP di server web backend (seperti Apache atau Nginx) agar lebih besar daripada waktu tunggu 600 detik load balancer. Nilai yang direkomendasikan adalah 620 detik. Jika Anda menggunakan GKE, hal ini terjadi saat Pod menurunkan skala atau menghentikan, dan backend load balancer adalah NEG. Untuk mengatasi hal ini, pertimbangkan untuk meningkatkan `terminationGracePeriodSeconds` dalam konfigurasi pod atau deployment Anda agar koneksi yang ada dapat ditutup dengan baik. Nilai idealnya adalah: `T_grace > T_preStop + T_drain + T_buffer` Dengan: `T_preStop` adalah durasi tidur hook `preStop` container, yang biasanya 120 detik untuk memungkinkan endpoint dihapus dari NEG. `T_drain` adalah waktu tunggu pengosongan koneksi layanan backend, yang biasanya 60 detik. `T_buffer` adalah buffer tambahan selama 30–45 detik untuk memungkinkan pod dimatikan dengan aman. Untuk konfigurasi standar, nilai yang direkomendasikan adalah minimal 210 detik (3,5 menit). Periksa log aplikasi backend untuk mengetahui error yang dapat menyebabkan koneksi ditutup. Periksa metrik instance backend (CPU, memori, koneksi) untuk tanda-tanda kehabisan resource.
`backend_timeout`	Penyebab: GFE lapisan kedua membuat koneksi dengan backend, tetapi backend tidak mengirim respons dalam waktu tunggu layanan backend yang dikonfigurasi. Solusi: Jika aplikasi Anda memerlukan waktu lebih lama untuk memproses permintaan, tambah waktu tunggu layanan backend. Periksa masalah performa pada instance backend Anda (CPU, I/O, penundaan aplikasi) yang dapat mencegah respons tepat waktu. Jika backend kelebihan beban, pertimbangkan untuk menskalakan resource backend atau mengoptimalkan aplikasi.
`retriable_error`	Penyebab: Error 503 ini dapat terjadi jika alat infrastruktur sebagai kode (seperti Terraform) memperbarui aturan load balancer dengan cara yang menghapus aturan peta URL untuk sementara sebelum menambahkannya kembali, atau karena masalah konfigurasi atau jaringan internal Google yang bersifat sementara selama peluncuran atau penerapan konfigurasi. Solusi: Jika menggunakan otomatisasi, periksa apakah otomatisasi tersebut melakukan update di tempat, bukan update hapus lalu buat untuk aturan peta URL. Jika Anda melihat error ini selama atau setelah perubahan konfigurasi, error ini mungkin bersifat sementara; tunggu beberapa menit hingga konfigurasi diterapkan secara global.

Mengatasi error HTTP `408`

Dengan traffic HTTP, jumlah waktu maksimum bagi klien untuk menyelesaikan pengiriman permintaannya sama dengan waktu tunggu layanan backend. Jika Anda melihat respons HTTP 408 dengan client_timed_out jsonPayload.statusDetail, ini berarti tidak ada progres yang memadai saat permintaan dari klien di-proxy atau respons dari backend di-proxy. Jika masalah disebabkan oleh klien yang mengalami masalah performa, Anda dapat menyelesaikan masalah ini dengan meningkatkan waktu tunggu layanan backend.

Traffic yang di-load balance tidak memiliki alamat sumber klien asli

Alamat IP sumber untuk paket, seperti yang terlihat oleh backend, bukan alamat IP eksternal load balancer. Load balancer berbasis proxy seperti Load Balancer Aplikasi eksternal menggunakan dua koneksi TCP untuk mengirimkan traffic dari klien ke backend:

Koneksi 1, dari klien asli ke load balancer (GFE atau subnet khusus proxy)
Koneksi 2, dari load balancer (GFE atau subnet khusus proxy) ke VM atau endpoint backend

Alamat IP sumber dan tujuan untuk setiap koneksi berbeda berdasarkan jenis Load Balancer Aplikasi eksternal yang Anda gunakan. Untuk mengetahui detailnya, lihat Alamat IP sumber untuk paket klien .

Mendapatkan error izin saat mencoba melihat objek di bucket Cloud Storage saya

Untuk menayangkan objek melalui load balancing, objek Cloud Storage harus dapat diakses secara publik. Pastikan untuk memperbarui izin objek yang ditayangkan sehingga objek tersebut dapat dibaca oleh publik.

URL tidak menyajikan objek Cloud Storage yang diharapkan

Objek Cloud Storage yang akan ditayangkan ditentukan berdasarkan peta URL dan URL yang Anda minta. Jika jalur permintaan dipetakan ke bucket backend di peta URL Anda, objek Cloud Storage ditentukan dengan menambahkan jalur permintaan lengkap ke bucket Cloud Storage yang ditentukan oleh peta URL.

Misalnya, jika Anda memetakan /static/* ke gs://[EXAMPLE_BUCKET], permintaan ke https://<GCLB IP or Host>/static/path/to/content.jpg akan mencoba menayangkan gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Jika objek tersebut tidak ada, Anda akan mendapatkan pesan error berikut, bukan objek:


NoSuchKey
The specified key does not exist.

Kompresi tidak berfungsi

Load Balancer Aplikasi eksternal tidak mengompresi atau mendekompresi respons itu sendiri, tetapi dapat menyajikan respons yang dihasilkan oleh layanan backend Anda yang dikompresi dengan menggunakan alat seperti gzip atau DEFLATE.

Jika respons yang disajikan oleh load balancer tidak dikompresi, padahal seharusnya dikompresi, periksa untuk memastikan bahwa software server web yang berjalan di instance Anda dikonfigurasi untuk mengompresi respons. Secara default, beberapa software server web otomatis menonaktifkan kompresi untuk permintaan yang menyertakan header Via, yang menunjukkan bahwa permintaan diteruskan oleh proxy. Karena merupakan proxy, Load Balancer Aplikasi eksternal menambahkan header Via ke setiap permintaan sebagaimana diwajibkan oleh spesifikasi HTTP. Untuk mengaktifkan kompresi, Anda mungkin harus mengganti konfigurasi default server web untuk memberi tahu server agar mengompresi respons sekalipun permintaan itu menyertakan header Via.

Untuk mengonfigurasi backend nginx agar menayangkan respons terkompresi yang di-proxy melalui Load Balancer Aplikasi eksternal:

Tetapkan direktif gzip_proxied dengan tepat (misalnya, ke any), dan
Tetapkan direktif gzip_vary ke on.

Untuk mengonfigurasi backend Apache agar menayangkan respons terkompresi yang di-proxy melalui Load Balancer Aplikasi eksternal:

Gunakan filter DEFLATE, dan
Tambahkan Vary Accept-Encoding ke header respons menggunakan modul mod_headers.

Memecahkan masalah backend yang tidak responsif

Memecahkan masalah terkait HTTP/2 ke backend

Pastikan backend instance Anda responsif dan mendukung protokol HTTP/2. Anda dapat memverifikasi hal ini dengan menguji konektivitas ke instance backend menggunakan HTTP/2. Pastikan VM menggunakan rangkaian cipher yang sesuai dengan spesifikasi HTTP/2. Misalnya, cipher suite TLS 1.2 tertentu tidak diizinkan oleh HTTP/2. Lihat Daftar Hitam Suite Cipher TLS 1.2.

Setelah Anda memverifikasi bahwa VM menggunakan protokol HTTP/2, pastikan konfigurasi firewall Anda mengizinkan pemeriksa kondisi dan load balancer untuk lewat.

Jika tidak ada masalah dengan penyiapan firewall, pastikan load balancer dikonfigurasi untuk berkomunikasi dengan port yang benar di VM.

Memecahkan masalah gRPC

Jika Anda menggunakan streaming gRPC dua arah dan klien terhubung ke Load Balancer Aplikasi eksternal global, server backend mungkin mengalami hang jika klien melakukan penutupan setengah langsung (mengirimkan flag END_STREAM segera setelah pembuatan streaming tanpa mengirimkan data apa pun). Hal ini terjadi karena konflik antara pengoptimalan HTTP/2 dan spesifikasi pembingkaian gRPC.

Load Balancer Aplikasi eksternal global mengoptimalkan traffic HTTP/2 dengan menggabungkan frame HEADERS dan frame DATA kosong (dengan END_STREAM) dari klien menjadi satu frame HEADERS dengan END_STREAM sebelum meneruskannya ke backend. Ini adalah pengoptimalan HTTP/2 standar per RFC 7540. Load balancer melakukan penggabungan frame ini saat frame tiba hampir secara bersamaan (penundaan 0 md).

Beberapa implementasi server gRPC (seperti grpc-go) tidak mendukung penerimaan flag END_STREAM pada frame HEADERS, sehingga menyebabkan backend menunggu tanpa batas. Spesifikasi gRPC melalui HTTP/2 secara ketat mewajibkan akhir streaming (EOS) ditunjukkan oleh tanda END_STREAM pada frame DATA terakhir yang diterima.

Untuk menghindari masalah server backend yang mengalami hang dan koneksi tetap terbuka hingga dihentikan secara paksa oleh klien yang mengirim RST_STREAM, Anda dapat menerapkan salah satu solusi berikut:

Tunda sedikit (misalnya, 10 md atau lebih) di sisi klien sebelum menutup sebagian streaming. Hal ini mencegah load balancer menggabungkan frame karena frame HEADERS sudah diteruskan.
Pastikan klien mengirim setidaknya satu pesan data sebelum menutup sebagian streaming.
Jika memungkinkan, beralihlah ke Load Balancer Aplikasi eksternal regional, yang tidak menggabungkan frame HEADERS dan frame DATA kosong, serta meneruskannya secara terpisah.

Memecahkan masalah backend eksternal dan NEG internet

Sebelum menyelidiki masalah, pahami halaman berikut:

Traffic tidak mencapai endpoint

Setelah Anda mengonfigurasi layanan, endpoint baru dapat dijangkau melalui Load Balancer Aplikasi eksternal saat:

Endpoint dilampirkan ke NEG internet.
FQDN terkait dapat di-resolve DNS dengan berhasil (jika Anda menggunakan jenis endpoint FQDN).
Endpoint dapat diakses melalui internet.

Jika traffic tidak dapat menjangkau endpoint, yang menghasilkan kode error 502, kueri data TXT DNS _cloud-eoips.googleusercontent.com menggunakan alat seperti dig atau nslookup. Catat CIDR (setelah ip4:) dan pastikan rentang ini diizinkan oleh firewall atau daftar kontrol akses (ACL) cloud Anda.

Setelah mengonfigurasi backend eksternal, permintaan ke backend eksternal gagal dengan error 5xx

Centang Logging.
Pastikan grup endpoint jaringan dikonfigurasi dengan IP:Port atau FQDN:Port yang benar untuk backend eksternal Anda.
Jika Anda menggunakan FQDN, pastikan FQDN tersebut dapat di-resolve melalui Google Public DNS. Anda dapat memverifikasi bahwa FQDN dapat di-resolve melalui Google Public DNS menggunakan langkah-langkah ini atau antarmuka web secara langsung.
Jika Anda mengakses load balancer hanya di IP eksternalnya, dan server web asal Anda mengharapkan nama host, pastikan Anda mengirim header Host HTTP yang valid ke backend dengan mengonfigurasi header permintaan kustom.
Jika Anda berkomunikasi dengan backend melalui HTTPS atau HTTP2 (seperti yang ditetapkan di kolom protocol layanan backend) yang dikonfigurasi sebagai INTERNET_FQDN_PORT endpoint backend eksternal, pastikan origin Anda menyajikan sertifikat TLS (SSL) yang valid dan FQDN yang dikonfigurasi cocok dengan SAN (Subject Alternative Name) dalam daftar SAN sertifikat. Sertifikat yang valid didefinisikan sebagai sertifikat yang ditandatangani oleh Otoritas Sertifikat publik dan yang masa berlakunya belum habis.
Saat menggunakan endpoint backend eksternal INTERNET_FQDN_PORT, sertifikat yang ditandatangani sendiri tidak diterima oleh load balancer, dan ditolak.
Saat menggunakan HTTPS atau HTTP/2 dengan endpoint jenis INTERNET_IP_PORT, tidak ada validasi sertifikat SSL/pemeriksaan SAN yang dilakukan. Artinya, Anda dapat menggunakan sertifikat yang ditandatangani sendiri. Saat menggunakan SSL, sebaiknya gunakan endpoint INTERNET_FQDN_PORT untuk memastikan sertifikat server dan SAN dapat divalidasi.

Respons dari backend eksternal saya tidak di-cache oleh Cloud CDN

Pastikan bahwa:

Anda telah mengaktifkan Cloud CDN di layanan backend yang berisi NEG yang mengarah ke backend eksternal dengan menyetel enableCDN ke benar (true).
Respons yang disajikan oleh backend eksternal Anda memenuhi persyaratan caching Cloud CDN. Misalnya, Anda mengirim header respons Cache-Control: public, max-age=3600 dari origin.

Memecahkan masalah NEG tanpa server

Sebelum menyelidiki masalah, pahami halaman berikut:

Permintaan gagal dengan error 404

Pastikan resource serverless yang mendasarinya (seperti App Engine, Cloud Run Functions, atau layanan Cloud Run) masih berjalan. Jika resource serverless dihapus, tetapi NEG serverless masih ada, Load Balancer Aplikasi eksternal akan terus mencoba merutekan permintaan ke layanan yang tidak ada. Hal ini akan menghasilkan respons 404.

Secara umum, Load Balancer Aplikasi eksternal tidak dapat mendeteksi apakah resource serverless yang mendasarinya berfungsi seperti yang diharapkan. Artinya, jika layanan Anda di satu region menampilkan error, tetapi infrastruktur Cloud Run, Cloud Run Functions, atau App Engine secara keseluruhan di region tersebut beroperasi secara normal, Load Balancer Aplikasi eksternal Anda tidak akan otomatis mengalihkan traffic ke region lain. Pastikan Anda menguji versi baru layanan secara menyeluruh sebelum merutekan traffic pengguna ke versi tersebut.

Menangani ketidakcocokan masker URL

Jika penerapan masker URL yang dikonfigurasi ke URL permintaan pengguna tidak menghasilkan nama layanan, atau jika menghasilkan nama layanan yang tidak ada, load balancer dapat menangani ketidakcocokan ini secara berbeda, bergantung pada platform komputasi tanpa server yang digunakan.

Cloud Run: Jika terjadi ketidakcocokan mask URL, load balancer akan menampilkan error HTTP 404 (Tidak Ditemukan).

Fungsi Cloud Run: Jika terjadi ketidakcocokan mask URL, load balancer akan menampilkan error HTTP 404 (Tidak Ditemukan).

Gateway API: Jika terjadi ketidakcocokan mask URL, load balancer akan menampilkan error HTTP 404 (Not Found).

App Engine: Jika terjadi ketidakcocokan mask URL, App Engine menggunakan dispatch.yaml dan logika perutean default App Engine untuk menentukan layanan yang akan menerima permintaan.

Memecahkan masalah penyisipan gateway tag Google

Gateway tag Google tidak menyisipkan tag dengan benar atau menyebabkan error.

Untuk mengatasi masalah ini, gunakan Google Cloud Logs Explorer konsol untuk menganalisis log yang dihasilkan oleh load balancer Anda. Masalah gateway tag Google tidak memengaruhi kode respons HTTP secara keseluruhan atau statusDetails permintaan halaman web. Respons HTTP akan dikirim tanpa modifikasi meskipun penyisipan tag Google gagal. Untuk mengidentifikasi error gateway, periksa grpcStatus eksekusi plugin di payload JSON load balancer Anda.

Pastikan Cloud Logging diaktifkan di layanan backend yang menayangkan konten situs untuk domain tempat gateway tag Google aktif. Konfigurasi ini di Google Cloud konsol dengan membuka Load balancing > Edit > Backend configuration. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan logging di layanan backend yang ada. Frekuensi pengambilan sampel logging yang lebih besar dari 0.0 harus ditetapkan untuk layanan backend tersebut.

Di konsol Google Cloud , buka halaman Logs Explorer dan pilih project yang benar.

Buka Logs Explorer
Sesuaikan rentang waktu untuk mencakup periode saat Anda mencurigai terjadinya masalah. Untuk mengetahui informasi selengkapnya, lihat Menggunakan pemilih rentang waktu.

Untuk melihat log permintaan yang ditangani oleh plugin injeksi gateway tag Google, gunakan kueri ini:

resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests"  \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"

Ganti PROJECT_ID dengan project ID Anda.

Identifikasi potensi kesalahan dengan memeriksa kolom jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. Bagian ini menampilkan status ekstensi gateway tag Google itu sendiri.
- OK: Ekstensi menyelesaikan pemrosesannya tanpa error gRPC.
- Nilai selain OK (misalnya, INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED): Hal ini menunjukkan error pada eksekusi ekstensi gateway tag Google.

Untuk menemukan log tempat ekstensi gateway tag Google melaporkan error, gunakan kueri berikut:

resource.type="http_load_balancer" logName="projects/PROJECT_IDlogs/requests" \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway" NOT jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus="OK"

Saat kueri sebelumnya menampilkan hasil, periksa seluruh entri log untuk mengorelasikan status ekstensi dengan hasil permintaan:
- Kegagalan ekstensi gateway tag Google: grpcStatus selain OK (terutama pada peristiwa RESPONSE_BODY) berarti proses penyisipan tag mengalami error. Kode gRPC tertentu memberikan petunjuk (misalnya, DEADLINE_EXCEEDED menunjukkan waktu tunggu habis).
- Dampak pada permintaan pengguna: jika grpcStatus untuk ekstensi gateway tag Google tidak OK, periksa httpRequest.status dan jsonPayload.statusDetails dalam entri log yang sama. Misalnya, OK grpcStatus non-gabungan dengan httpRequest.status: 500 dan jsonPayload.statusDetails: service_extensions_error menunjukkan bahwa kegagalan ekstensi gateway tag Google menyebabkan pengguna menerima error server.
- Frekuensi masalah: menganalisis stempel waktu dan frekuensi log error ini membantu menentukan apakah masalah penyisipan gateway tag Google sedang berlangsung, terjadi sesekali, atau terkait dengan peristiwa tertentu.

Jika Anda mengalami masalah selama penyiapan yang tidak dapat diselesaikan oleh dokumentasi, hubungi Dukungan Google Ads.

Memecahkan masalah terkait Load Balancer Aplikasi eksternal Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.