Anda sedang melihat dokumentasi Apigee Edge.
Buka
dokumentasi Apigee X. info
Gejala
Aplikasi klien mendapatkan kode status HTTP 502
dengan pesan
Bad Gateway
sebagai respons untuk panggilan API.
Kode status HTTP 502
berarti klien tidak menerima respons yang valid dari
server backend yang seharusnya benar-benar memenuhi permintaan.
Pesan error
Aplikasi klien mendapatkan kode respons berikut:
HTTP/1.1 502 Bad Gateway
Selain itu, Anda mungkin melihat pesan error berikut:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Kemungkinan penyebab
Salah satu penyebab umum untuk 502 Bad Gateway Error
adalah error Unexpected EOF
, yang dapat disebabkan oleh alasan berikut:
Penyebab | Detail | Langkah-langkah yang diberikan untuk |
---|---|---|
Server target dikonfigurasi dengan tidak benar | Server target tidak dikonfigurasi dengan benar untuk mendukung koneksi TLS/SSL. | Pengguna Edge Publik dan Private Cloud |
EOFException dari Server Backend | Server backend dapat mengirim EOF secara tiba-tiba. | Khusus pengguna Edge Private Cloud |
Waktu tunggu keep alive tidak dikonfigurasi dengan benar | Biarkan waktu tunggu aktif tidak dikonfigurasi dengan benar di Apigee dan server backend. | Pengguna Edge Publik dan Private Cloud |
Langkah-langkah diagnosis umum
Untuk mendiagnosis error, Anda dapat menggunakan salah satu metode berikut:
Pemantauan API
Untuk mendiagnosis error menggunakan API Monitoring:
Dengan API Monitoring, Anda dapat menyelidiki error 502
dengan mengikuti langkah-langkah seperti yang dijelaskan dalam Menyelidiki masalah. Definisinya yaitu:
- Buka dasbor Investigasi.
- Pilih Status Code di menu drop-down dan pastikan jangka waktu yang tepat dipilih saat error
502
terjadi. - Klik kotak dalam matriks jika Anda melihat jumlah error
502
yang tinggi. - Di sisi kanan, klik View Logs untuk error
502
yang akan terlihat seperti berikut: - Sumber Kesalahan adalah
target
- Kode Kesalahan adalah
messaging.adaptors.http.UnexpectedEOFAtTarget
Di sini, kita dapat melihat informasi berikut:
Hal ini menunjukkan bahwa error 502
disebabkan oleh target karena EOF yang tidak terduga.
Selain itu, catat Request Message ID
untuk error 502
guna penyelidikan
lebih lanjut.
Alat pelacak
Untuk mendiagnosis error menggunakan alat Trace:
- Aktifkan
sesi rekaman aktivitas, dan buat panggilan API untuk mereproduksi masalah
502 Bad Gateway
. - Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitas.
- Jelajahi berbagai fase rekaman aktivitas dan temukan lokasi terjadinya kegagalan.
-
Anda akan melihat kegagalan setelah permintaan dikirim ke server target seperti yang ditunjukkan di bawah ini:
-
Tentukan nilai X-Apigee.fault-source dan X-Apigee.fault-code di AX (Data Analytics Dicatat) Phase dalam trace.
Jika nilai X-Apigee.fault-source dan X-Apigee.fault-code cocok dengan nilai yang ditunjukkan dalam tabel berikut, Anda dapat mengonfirmasi bahwa error
502
berasal dari server target:Header respons Nilai X-Apigee.fault-sumber target
Kode-X-Apigee.fault messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Selain itu, catat
X-Apigee.Message-ID
untuk error502
guna penyelidikan lebih lanjut.
Log akses NGINX
Untuk mendiagnosis error menggunakan NGINX:
Anda juga dapat melihat log akses NGINX untuk menentukan penyebab kode status
502
. Cara ini sangat berguna jika masalah pernah terjadi sebelumnya, atau jika masalah tersebut terputus-putus dan Anda tidak dapat merekam aktivitas di UI. Gunakan langkah-langkah berikut untuk menentukan informasi ini dari log akses NGINX:
- Periksa log akses NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Telusuri error
502
untuk proxy API tertentu selama durasi tertentu (jika masalah terjadi di masa lalu) atau untuk permintaan apa pun yang masih gagal dengan502
. - Jika terjadi error
502
, periksa apakah error tersebut disebabkan oleh target yang mengirimUnexpected EOF
. Jika nilai X-Apigee.fault-source dan X- Apigee.fault-code cocok dengan nilai yang ditunjukkan pada tabel di bawah, error502
disebabkan oleh target menutup koneksi secara tiba-tiba:Header Respons Nilai X-Apigee.fault-sumber target
Kode-X-Apigee.fault messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Berikut adalah contoh entri yang menunjukkan error
502
yang disebabkan oleh server target:
Selain itu, catat ID pesan untuk error 502
guna penyelidikan lebih lanjut.
Penyebab: Server target tidak dikonfigurasi dengan benar
Server target tidak dikonfigurasi dengan benar untuk mendukung koneksi TLS/SSL.
Diagnosis
- Gunakan API Monitoring, Trace tool, atau
Log akses NGINX untuk menentukan ID pesan,
kode fault, dan sumber fault untuk error
502
. - Mengaktifkan rekaman aktivitas di UI untuk API yang terpengaruh.
- Jika rekaman aktivitas untuk permintaan API yang gagal menampilkan hal berikut:
- Error
502 Bad Gateway
akan terlihat segera setelah permintaan alur target dimulai. error.class
menampilkanmessaging.adaptors.http.UnexpectedEOF.
Kemungkinan besar masalah ini disebabkan oleh konfigurasi server target yang salah.
- Error
- Dapatkan definisi server target menggunakan panggilan Edge management API:
- Jika Anda adalah pengguna Cloud Publik, gunakan API ini:
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- Jika Anda adalah pengguna Private Cloud, gunakan API ini:
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
Contoh definisi
TargetServer
yang salah:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- Jika Anda adalah pengguna Cloud Publik, gunakan API ini:
-
Ilustrasi definisi
TargetServer
adalah contoh untuk salah satu kesalahan konfigurasi umum, yang dijelaskan sebagai berikut:Anggaplah server target
mocktarget.apigee.net
dikonfigurasi untuk menerima koneksi aman (HTTPS) pada port443
. Namun, jika Anda melihat definisi server target, tidak ada atribut/tanda lain yang menunjukkan bahwa server tersebut dimaksudkan untuk koneksi aman. Hal ini menyebabkan Edge memperlakukan permintaan API yang dikirim ke server target tertentu sebagai permintaan HTTP (tidak aman). Jadi, Edge tidak akan memulai proses SSL Handshake dengan server target ini.Karena server target dikonfigurasi untuk hanya menerima permintaan HTTPS (SSL) di
443
, server tersebut akan menolak permintaan dari Edge atau menutup koneksi. Akibatnya, Anda akan mendapatkan errorUnexpectedEOFAtTarget
pada Pemroses Pesan. Pemroses Pesan akan mengirimkan502 Bad Gateway
sebagai respons kepada klien.
Resolusi
Selalu pastikan bahwa server target dikonfigurasi dengan benar sesuai kebutuhan Anda.
Untuk contoh ilustrasi di atas, jika ingin membuat permintaan ke server target (HTTPS/SSL) yang aman, Anda harus menyertakan atribut SSLInfo
dengan tanda enabled
yang ditetapkan ke true
. Meskipun Anda dapat menambahkan atribut SSLInfo
untuk server target dalam definisi endpoint target itu sendiri, sebaiknya tambahkan atribut SSLInfo
sebagai bagian dari definisi server target untuk menghindari kebingungan.
- Jika layanan backend memerlukan komunikasi SSL satu arah, maka:
- Anda harus mengaktifkan TLS/SSL dalam definisi
TargetServer
dengan menyertakan atributSSLInfo
tempat tandaenabled
ditetapkan ke benar (true) seperti yang ditunjukkan di bawah:<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- Jika Anda ingin memvalidasi sertifikat server target di Edge, kami juga perlu
menyertakan truststore (berisi sertifikat server target) seperti yang ditunjukkan di bawah ini:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Ciphers/> <ClientAuthEnabled>false</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <Protocols/> <TrustStore>mocktarget-truststore</TrustStore> </SSLInfo> </TargetServer>
- Anda harus mengaktifkan TLS/SSL dalam definisi
- Jika layanan backend memerlukan komunikasi SSL dua arah, maka:
- Anda harus memiliki atribut
SSLInfo
dengan tandaClientAuthEnabled
,Keystore
,KeyAlias
, danTruststore
yang ditetapkan dengan tepat, seperti yang ditunjukkan di bawah ini:<TargetServer name="mocktarget"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
- Anda harus memiliki atribut
Referensi
Load balancing di seluruh server backend
Penyebab: EOFException dari server backend
Server backend dapat mengirim EOF (Akhir File) secara tiba-tiba.
Diagnosis
- Gunakan API Monitoring, Trace tool, atau
Log akses NGINX untuk menentukan ID pesan,
kode fault, dan sumber fault untuk error
502
. - Periksa log Pemroses Pesan (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) dan telusuri untuk mengetahui apakah Anda memilikieof unexpected
untuk API tertentu atau jika Anda memilikimessageid
unik untuk permintaan API, Anda dapat menelusurinya.Contoh pelacakan tumpukan pengecualian dari log Message Processor
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na] at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na] at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na] at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
Pada contoh di atas, Anda dapat melihat bahwa error
java.io.EOFException: eof unexpected
terjadi saat Message Processor mencoba membaca respons dari server backend. Pengecualian ini menunjukkan akhir file (EOF), atau akhir streaming telah tercapai secara tidak terduga.Artinya, Pemroses Pesan mengirim permintaan API ke server backend dan sedang menunggu atau membaca respons. Namun, server backend menghentikan koneksi secara tiba-tiba sebelum Pemroses Pesan mendapatkan respons atau dapat membaca respons lengkap.
- Periksa log server backend Anda dan lihat apakah ada error atau informasi yang dapat menyebabkan server backend menghentikan koneksi secara tiba-tiba. Jika Anda menemukan error/informasi, buka Resolution dan perbaiki masalah di server backend Anda dengan tepat.
- Jika Anda tidak menemukan error atau informasi apa pun di server backend, kumpulkan output
tcpdump
di Pemroses Pesan:- Jika host server backend Anda memiliki satu alamat IP, gunakan perintah berikut:
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- Jika host server backend Anda memiliki beberapa alamat IP, gunakan perintah berikut:
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
Biasanya, error ini disebabkan karena server backend merespons kembali dengan
[FIN,ACK]
segera setelah Pemroses Pesan mengirim permintaan ke server backend.
- Jika host server backend Anda memiliki satu alamat IP, gunakan perintah berikut:
-
Perhatikan contoh
tcpdump
berikut.Sampel
tcpdump
diambil saat502 Bad Gateway Error
(UnexpectedEOFAtTarget
) terjadi - Dari output TCPDump, Anda akan melihat urutan peristiwa berikut:
- Dalam paket
985
, Pemroses Pesan mengirimkan permintaan API ke server backend. - Dalam paket
986
, server backend langsung merespons kembali dengan[FIN,ACK]
. - Dalam paket
987
, Pemroses Pesan merespons dengan[FIN,ACK]
ke server backend. - Pada akhirnya, koneksi ditutup dengan
[ACK]
dan[RST]
dari kedua sisi. - Karena server backend mengirim
[FIN,ACK]
, Anda mendapatkan pengecualianjava.io.EOFException: eof unexpected
di Pemroses Pesan.
- Dalam paket
- Hal ini dapat terjadi jika ada masalah jaringan pada server backend. Minta agar tim operasi jaringan Anda menyelidiki masalah ini lebih lanjut.
Resolusi
Perbaiki masalah di server backend dengan tepat.
Jika masalah berlanjut dan Anda memerlukan bantuan untuk memecahkan 502 Bad Gateway Error
atau Anda mencurigai bahwa ini adalah masalah dalam Edge, hubungi Dukungan Apigee Edge.
Penyebab: Waktu tunggu terus aktif tidak dikonfigurasi dengan benar
Sebelum mendiagnosis apakah ini adalah penyebab error 502
, baca konsep berikut.
Koneksi persisten di Apigee
Apigee secara default (dan jika mengikuti standar HTTP/1.1) menggunakan koneksi persisten saat berkomunikasi dengan server backend target. Koneksi persisten dapat meningkatkan performa dengan mengizinkan koneksi TCP dan TLS/SSL yang sudah ada dan (jika ada) untuk digunakan kembali, sehingga mengurangi overhead latensi. Durasi selama koneksi harus dipertahankan dikontrol melalui properti waktu tunggu keep alive (keepalive.timeout.millis
).
Server backend dan Apigee Message Processor menggunakan waktu tunggu tetap aktif agar koneksi tetap terbuka satu sama lain. Setelah tidak ada data yang diterima dalam durasi waktu tunggu keep alive, server backend atau Pemroses Pesan dapat menutup koneksi dengan server lainnya.
Proxy API yang di-deploy ke Pemroses Pesan di Apigee secara default memiliki waktu tunggu tetap aktif yang ditetapkan ke 60s
kecuali jika diganti. Setelah tidak ada data yang diterima untuk 60s
, Apigee akan menutup koneksi dengan server backend. Server backend juga akan mempertahankan waktu tunggu keep alive, dan setelah waktu ini berakhir, server backend akan menutup koneksi dengan Pemroses Pesan.
Implikasi konfigurasi waktu tunggu keep alive yang salah
Jika Apigee atau server backend dikonfigurasi dengan waktu tunggu keep alive yang salah, hal tersebut akan mengakibatkan kondisi race yang menyebabkan server backend mengirim End Of File
(FIN)
yang tidak terduga sebagai respons terhadap permintaan untuk resource.
Misalnya, jika waktu tunggu keep alive dikonfigurasi dalam Proxy API atau Pemroses Pesan dengan nilai yang lebih besar atau sama dengan waktu tunggu server backend upstream, kondisi race berikut dapat terjadi. Artinya, jika Pemroses Pesan tidak menerima data apa pun hingga mendekati ambang batas waktu tunggu untuk tetap aktif server backend, permintaan akan masuk dan dikirim ke server backend menggunakan koneksi yang ada. Hal ini dapat menyebabkan 502 Bad Gateway
karena error EOF tak terduga seperti yang dijelaskan di bawah:
- Misalnya waktu tunggu keep alive yang ditetapkan pada Pemroses Pesan dan server backend adalah 60 detik dan tidak ada permintaan baru yang muncul hingga 59 detik setelah permintaan sebelumnya dilayani oleh Pemroses Pesan tertentu.
- Pemroses Pesan akan memproses permintaan yang masuk pada detik ke-59 menggunakan koneksi yang ada (karena waktu tunggu keep alive belum berlalu) dan mengirimkan permintaan tersebut ke server backend.
- Namun, sebelum permintaan tiba di server backend, batas waktu tunggu keep-live telah terlampaui pada server backend.
- Permintaan Pemroses Pesan untuk resource sedang diproses, tetapi server backend mencoba menutup koneksi dengan mengirimkan paket
FIN
ke Pemroses Pesan. - Selagi menunggu data diterima, Pemroses Pesan akan menerima
FIN
yang tidak terduga, dan koneksi dihentikan. - Hal ini akan menghasilkan
Unexpected EOF
, yang kemudian502
ditampilkan ke klien oleh Pemroses Pesan.
Dalam kasus ini, kami mengamati error 502
terjadi karena nilai waktu tunggu keep-alive 60 detik yang sama dikonfigurasi pada Pemroses Pesan dan server backend. Demikian pula, masalah ini juga dapat terjadi jika nilai yang lebih tinggi dikonfigurasi untuk waktu tunggu keep alive di Pemroses Pesan daripada di server backend.
Diagnosis
- Jika Anda adalah pengguna Cloud Publik:
- Gunakan alat Pemantauan atau Pelacakan API (seperti yang dijelaskan dalam
Langkah-langkah diagnosis umum) dan pastikan Anda memiliki kedua setelan
berikut:
- Kode error:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Sumber kesalahan:
target
- Kode error:
- Buka Menggunakan tcpdump untuk penyelidikan lebih lanjut.
- Gunakan alat Pemantauan atau Pelacakan API (seperti yang dijelaskan dalam
Langkah-langkah diagnosis umum) dan pastikan Anda memiliki kedua setelan
berikut:
- Jika Anda adalah pengguna Private Cloud:
- Gunakan Alat pelacakan atau
log akses NGINX untuk menentukan ID pesan,
kode kesalahan, dan sumber kesalahan untuk error
502
. - Telusuri ID pesan di log Message Processor
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - Anda akan melihat
java.io.EOFEXception: eof unexpected
seperti yang ditunjukkan di bawah ini:2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1 NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms lastIO=479ms isOpen=true.onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80) at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
- Error
java.io.EOFException: eof unexpected
menunjukkan bahwa Pemroses Pesan menerimaEOF
saat masih menunggu untuk membaca respons dari server backend. - Atribut
useCount=7
dalam pesan error di atas menunjukkan bahwa Pemroses Pesan telah menggunakan kembali koneksi ini sekitar tujuh kali, dan atributbytesWritten=159
menunjukkan bahwa Pemroses Pesan telah mengirim payload permintaan sebesar159
byte ke server backend. Namun, metode ini menerima nol byte kembali saatEOF
yang tidak terduga terjadi. -
Hal ini menunjukkan bahwa Pemroses Pesan telah menggunakan kembali koneksi yang sama beberapa kali, dan pada kesempatan ini mengirim data, tetapi sesaat setelahnya menerima
EOF
sebelum data apa pun diterima. Artinya, ada kemungkinan besar bahwa waktu tunggu keep alive server backend lebih pendek atau sama dengan yang disetel di proxy API.Anda dapat menyelidiki lebih lanjut dengan bantuan
tcpdump
seperti yang dijelaskan di bawah.
- Gunakan Alat pelacakan atau
log akses NGINX untuk menentukan ID pesan,
kode kesalahan, dan sumber kesalahan untuk error
Menggunakan {i>tcpdump<i}
- Catat
tcpdump
di server backend dengan perintah berikut:tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- Analisis
tcpdump
yang ditangkap:Berikut contoh output tcpdump:
Pada contoh
tcpdump
di atas, Anda dapat melihat hal berikut:- Dalam paket
5992,
, server backend menerima permintaanGET
. - Dalam paket
6064
, kode ini merespons dengan200 OK.
- Dalam paket
6084
, server backend menerima permintaanGET
lain. - Dalam paket
6154
, kode ini merespons dengan200 OK
. - Dalam paket
6228
, server backend menerima permintaanGET
ketiga. - Kali ini, server backend menampilkan
FIN, ACK
ke Pemroses Pesan (paket6285
) yang memulai penutupan koneksi.
Koneksi yang sama berhasil digunakan kembali dua kali dalam contoh ini, tetapi pada permintaan ketiga, server backend memulai penutupan koneksi, saat Pemroses Pesan menunggu data dari server backend. Hal ini menunjukkan bahwa waktu tunggu keep alive server backend kemungkinan lebih pendek atau sama dengan nilai yang disetel di proxy API. Untuk memvalidasi hal ini, lihat Membandingkan waktu tunggu keep alive di Apigee dan server backend.
- Dalam paket
Membandingkan waktu tunggu keep alive di Apigee dan server backend
- Secara default, Apigee menggunakan nilai 60 detik untuk properti waktu tunggu keep alive.
-
Namun, ada kemungkinan Anda telah mengganti nilai default di Proxy API. Anda dapat memverifikasi hal ini dengan memeriksa definisi
TargetEndpoint
spesifik di Proxy API yang gagal yang memberikan error502
.Contoh konfigurasi TargetEndpoint:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
Pada contoh di atas, properti waktu tunggu keep alive diganti dengan nilai 30 detik (
30000
milidetik). - Selanjutnya, periksa properti waktu tunggu keep alive yang dikonfigurasi di server backend. Misalnya, server backend Anda dikonfigurasi dengan nilai
25 seconds
. - Jika Anda menentukan bahwa nilai properti waktu tunggu keep alive di Apigee lebih tinggi daripada nilai properti waktu tunggu keep alive di server backend seperti dalam contoh di atas, maka itulah penyebab error
502
.
Resolusi
Pastikan properti waktu tunggu keep alive selalu lebih rendah di Apigee (di komponen Proxy API dan Pemroses Pesan) dibandingkan dengan yang ada di server backend.
- Tentukan nilai yang ditetapkan untuk waktu tunggu keep alive di server backend.
- Konfigurasikan nilai yang sesuai untuk properti waktu tunggu keep alive di Proxy API atau Pemroses Pesan, sehingga properti waktu tunggu terus aktif lebih rendah daripada nilai yang ditetapkan pada server backend, menggunakan langkah-langkah yang dijelaskan dalam Mengonfigurasi waktu tunggu keep alive di Pemroses Pesan.
Jika masalah masih berlanjut, buka Harus mengumpulkan informasi diagnostik.
Praktik Terbaik
Sangat disarankan agar komponen downstream selalu memiliki batas waktu tunggu aktif yang lebih rendah daripada yang dikonfigurasi pada server upstream untuk menghindari jenis kondisi race dan error 502
ini. Setiap hop downstream harus lebih rendah dari setiap hop upstream. Di Apigee Edge, sebaiknya ikuti panduan berikut:
- Waktu tunggu klien untuk tetap aktif harus kurang dari waktu tunggu penyimpanan Edge Router.
- Waktu tunggu masa aktif Router Edge harus kurang dari waktu tunggu aktif Pemroses Pesan.
- Waktu tunggu keep-alive Pemroses Pesan harus kurang dari waktu tunggu keep alive server target.
- Jika Anda memiliki hop lain di depan atau di belakang Apigee, aturan yang sama harus diterapkan. Anda harus selalu membiarkannya sebagai tanggung jawab klien downstream untuk menutup koneksi dengan upstream.
Harus mengumpulkan informasi diagnostik
Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut, lalu hubungi Dukungan Apigee Edge.
Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:
- Nama organisasi
- Nama lingkungan
- Nama Proxy API
- Selesaikan perintah
curl
untuk mereproduksi error502
- File rekaman aktivitas yang berisi permintaan dengan error
502 Bad Gateway - Unexpected EOF
- Jika error
502
tidak terjadi saat ini, berikan jangka waktu dengan informasi zona waktu saat error502
terjadi di masa lalu.
Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
- Pesan error lengkap yang diamati untuk permintaan yang gagal
- Organisasi, Nama Lingkungan, dan nama Proxy API yang Anda amati error
502
-nya - Paket Proxy API
- File rekaman aktivitas yang berisi permintaan dengan error
502 Bad Gateway - Unexpected EOF
- Log akses NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Log Pemroses Pesan
/opt/apigee/var/log/edge-message-processor/logs/system.log
- Jangka waktu dengan informasi zona waktu saat error
502
terjadi Tcpdumps
dikumpulkan di Pemroses Pesan atau server backend, atau keduanya saat error terjadi