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:

Backend memiliki mode balancing 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 tersebut tidak memiliki mode load balancing 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 menghasilkan kode respons error HTTP (5XX) dan menampilkan kode respons error tersebut ke klien. Tidak semua error HTTP 5XX dihasilkan oleh load balancer—misalnya, jika backend mengirimkan respons HTTP 5XX ke load balancer, load balancer akan meneruskan respons tersebut ke kliennya.

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

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

Perubahan konfigurasi pada Load Balancer Aplikasi eksternal global, seperti penambahan atau penghapusan layanan backend, dapat mengakibatkan periode waktu 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 memulai pemecahan masalah, verifikasi kondisi backend

Sebelum memecahkan masalah error 5XX, pastikan backend Anda responsif dan health check lulus. Jika backend tidak responsif, GFE lapisan kedua tidak dapat meneruskan permintaan ke backend tersebut, yang dapat menyebabkan error 5XX meskipun semua hal lainnya dikonfigurasi dengan benar.

Pastikan ada aturan firewall yang dikonfigurasi untuk mengizinkan health check. Jika tidak ada, health check akan gagal, dan log load balancer mungkin menampilkan statusDetails dari 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 lain. Anda hanya akan melihat entri log health check yang berhasil setelah pemeriksaan health check menerima respons HTTP 200 OK dari backend.

Jika health check gagal, pecahkan masalah aplikasi backend dan aturan firewall Anda. Jika health check lulus, 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 berlanjut, gunakan kolom statusDetails di Cloud Logging untuk mengidentifikasi penyebabnya dan memecahkan masalahnya.

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 responsif untuk merutekan permintaan. Error ini dapat terjadi karena salah satu alasan berikut: Semua region telah mencapai atau melebihi 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 respons 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 backend instance yang tidak responsif, perhatikan bahwa failover atau overflow dibatasi untuk sejumlah grup instance alternatif yang terbatas. Jika Anda mengamati `failed_to_pick_backend` atau `failed_to_pick_backend_by_hash` meskipun memiliki grup instance yang responsif, kuras grup instance yang tidak responsif dengan menetapkan kapasitasnya ke nol. Hal ini 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 bisa mendapatkan SYN-ACK). Error ini juga dapat disebabkan oleh error GFE internal yang mencegahnya terhubung ke backend, atau dari pemadaman layanan regional atau gangguan jaringan (seperti kabel fiber yang terputus) 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 dari rentang GFE lapisan kedua `35.191.0.0/16`. Pastikan aplikasi di backend instance Anda berjalan dan memproses port yang dikonfigurasi di layanan backend. Periksa metrik backend instance (CPU, memori, koneksi) untuk melihat 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 memperkecil skala atau dihentikan, dan backend load balancer berjenis NEG. Solusi: Tetapkan waktu tunggu keepalive HTTP di server web backend (seperti Apache atau Nginx) agar lebih besar dari waktu tunggu load balancer yang berdurasi 600 detik. Nilai yang direkomendasikan adalah 620 detik. Jika Anda menggunakan GKE, hal ini terjadi saat pod sedang memperkecil skala atau dihentikan, dan backend load balancer adalah NEG. Untuk mengatasi masalah ini, pertimbangkan untuk meningkatkan `terminationGracePeriodSeconds` di 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 berdurasi 60 detik. `T_buffer` adalah buffer tambahan selama 30–45 detik untuk memungkinkan pod dinonaktifkan dengan aman. Untuk konfigurasi standar, nilai yang direkomendasikan adalah minimal 210 detik (3,5 menit). Periksa log aplikasi backend untuk menemukan error yang mungkin menyebabkan koneksi ditutup. Periksa metrik backend instance (CPU, memori, koneksi) untuk melihat 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 lebih banyak waktu untuk memproses permintaan, tingkatkan waktu tunggu layanan backend. Periksa masalah performa pada backend instance Anda (CPU, I/O, penundaan aplikasi) yang mungkin 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 infrastructure-as-code (seperti Terraform) memperbarui aturan load balancer dengan cara yang menghapus aturan peta URL untuk sementara sebelum menambahkannya kembali, atau karena masalah jaringan atau konfigurasi internal Google sementara selama peluncuran atau pengiriman konfigurasi. Solusi: Jika menggunakan otomatisasi, pastikan 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 tersebut 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 jsonPayload.statusDetail client_timed_out, artinya progres tidak memadai saat permintaan dari klien di-proxy atau respons dari backend di-proxy. Jika masalahnya disebabkan oleh klien yang mengalami masalah performa, Anda dapat menyelesaikan masalah ini dengan meningkatkan waktu tunggu layanan backend.

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

Alamat IP sumber untuk paket, seperti yang dilihat 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 menyajikan objek melalui load balancing, objek Cloud Storage harus dapat diakses secara publik. Pastikan untuk memperbarui izin objek yang disajikan agar dapat dibaca secara publik.

URL tidak menyajikan objek Cloud Storage yang diharapkan

Objek Cloud Storage yang akan disajikan 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 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 menyajikan 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 menggunakan alat seperti gzip atau DEFLATE.

Jika respons yang disajikan oleh load balancer tidak dikompresi, padahal seharusnya dikompresi, pastikan 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 yang 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 menyajikan respons terkompresi yang di-proxy-kan melalui Load Balancer Aplikasi eksternal:

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

Untuk mengonfigurasi backend Apache agar menyajikan respons terkompresi yang di-proxy-kan 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 cipher suite yang sesuai dengan spesifikasi HTTP/2. Misalnya, cipher suite TLS 1.2 tertentu tidak diizinkan oleh HTTP/2. Lihat Daftar Tolak Cipher Suite TLS 1.2.

Setelah Anda memverifikasi bahwa VM menggunakan protokol HTTP/2, pastikan penyiapan firewall Anda mengizinkan health checker dan load balancer untuk melewatinya.

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

Memecahkan masalah koneksi terputus untuk klien yang beroperasi di balik NAT tingkat operator

Saat klien terhubung ke Load Balancer Aplikasi eksternal melalui perangkat stateful perantara, seperti NAT tingkat operator (CGNAT), CGNAT melacak setiap koneksi TCP aktif dalam tabel status. Banyak CGNAT menerapkan waktu tunggu tidak ada aktivitas yang singkat—lebih singkat daripada waktu tunggu keepalive HTTP klien load balancer (610 detik secara default) dan waktu tunggu koneksi tidak ada aktivitas di kumpulan koneksi HTTP klien.

Jika koneksi tetap tidak ada aktivitas lebih lama dari waktu tunggu tidak ada aktivitas CGNAT, CGNAT akan otomatis menghapus entri koneksi dari tabel statusnya tanpa mengirim paket FIN atau RST TCP ke salah satu endpoint. Karena klien dan load balancer masih menganggap koneksi terbuka, permintaan HTTP berikutnya yang dikirim klien melalui koneksi tersebut akan dihapus atau ditolak oleh CGNAT, sehingga permintaan gagal.

Untuk mencegah koneksi terputus secara diam-diam bagi klien yang beroperasi di balik CGNAT atau perangkat stateful lainnya, lakukan salah satu hal berikut:

Kurangi waktu tunggu koneksi tidak ada aktivitas di kumpulan koneksi klien HTTP Anda ke nilai yang lebih singkat daripada waktu tunggu tidak ada aktivitas CGNAT dan waktu tunggu keepalive HTTP klien load balancer, sehingga klien menutup koneksi tidak ada aktivitas dengan baik sebelum status NAT berakhir.
Konfigurasikan keepalive tingkat aplikasi (seperti frame PING HTTP/2 berkala) pada interval yang lebih singkat daripada waktu tunggu tidak ada aktivitas CGNAT (tetapi setidaknya 30 detik antara frame PING pada koneksi tidak ada aktivitas untuk menghindari pembatasan kapasitas). Meskipun frame PING HTTP/2 tidak mereset waktu tunggu keepalive HTTP klien load balancer saat tidak ada aliran data yang aktif, frame tersebut menjaga pemetaan NAT perantara tetap aktif sehingga koneksi tetap valid atau dapat ditutup dengan baik.
Kurangi interval keepalive TCP sistem operasi sisi klien (misalnya, net.ipv4.tcp_keepalive_time di Linux) menjadi nilai yang lebih singkat daripada waktu tunggu tidak ada aktivitas CGNAT sehingga pemeriksaan TCP keluar berkala mencegah waktu tunggu pemetaan NAT habis. Perhatikan bahwa pemeriksaan keepalive TCP diproses di lapisan transpor dan tidak mereset waktu tunggu keepalive HTTP klien load balancer.

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 jika:

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

Jika traffic tidak dapat menjangkau endpoint, yang menyebabkan kode error 502, buat 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 pada 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 endpoint backend eksternal INTERNET_FQDN_PORT, pastikan origin Anda menampilkan 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 Certificate Authority publik dan belum habis masa berlakunya.
Saat menggunakan endpoint backend eksternal INTERNET_FQDN_PORT, sertifikat yang ditandatangani sendiri tidak diterima oleh load balancer, dan akan 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.

Memecahkan masalah penyisipan gateway tag Google

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

Untuk mengatasi masalah ini, gunakanLogs Explorerkonsol Google Cloud 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 injeksi 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 menyajikan konten situs untuk domain tempat gateway tag Google aktif. Konfigurasikan ini di konsol Google Cloud dengan membuka Load balancing > Edit > Backend configuration. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan logging di layanan backend yang ada. Frekuensi 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 error dengan memeriksa kolom jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. Tindakan ini akan menampilkan status ekstensi gateway tag Google itu sendiri.
- OK: Ekstensi menyelesaikan pemrosesannya tanpa error gRPC.
- Nilai apa pun selain OK (misalnya, INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED): 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 menghubungkan 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).
- Dampak pada permintaan pengguna: jika grpcStatus untuk ekstensi gateway tag Google bukan OK, periksa httpRequest.status dan jsonPayload.statusDetails di entri log yang sama. Misalnya, grpcStatus non-OK yang digabungkan 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 injeksi 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.