Halaman ini diterjemahkan oleh Cloud Translation API.

Kesalahan Waktu Tunggu Gateway Buruk 502

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Gejala

Aplikasi klien menerima error 502 Bad Gateway. Pemroses Pesan menampilkan error ini ke aplikasi klien saat tidak menerima respons dari server backend.

Pesan error

Aplikasi klien menerima kode respons berikut:

HTTP/1.1 502 Bad Gateway

Selain itu, Anda mungkin melihat pesan error berikut:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Kemungkinan Penyebab

Kemungkinan penyebab masalah ini tercantum dalam tabel berikut:

Cause	Deskripsi	Langkah-langkah pemecahan masalah dapat dilakukan dengan
Waktu tunggu handshake TLS/SSL habis	Waktu tunggu habis selama Handshake TLS/SSL antara Pemroses Pesan dan server backend.	Pengguna Edge Private dan Public Cloud

Penyebab: Waktu tunggu handshake TLS/SSL habis

Di Apigee Edge, Anda dapat menyiapkan koneksi TLS/SSL ke server backend untuk mengaktifkan komunikasi TLS antara Edge Message Processor dan server backend.

Handshake TLS/SSL mencakup beberapa langkah. Error ini biasanya terjadi saat waktu tunggu handshake TLS/SSL antara Message Processor dan server backend habis.

Diagnosis

Bagian ini menjelaskan cara mendiagnosis waktu tunggu handshake TLS/SSL dengan benar. Petunjuk untuk Edge Private Cloud dan Public Cloud dicantumkan.

Menyelidiki output sesi Trace

Langkah-langkah berikut menjelaskan cara melakukan diagnosis awal masalah menggunakan alat Apigee Edge Trace.

Di UI Edge, aktifkan Sesi pelacakan untuk proxy API yang terpengaruh.
Jika pelacakan untuk permintaan API yang gagal menampilkan hal berikut, kemungkinan terjadi error waktu tunggu handshake TLS/SSL. Kemungkinan penyebab error ini adalah firewall server backend memblokir traffic dari Apigee.
1. Tentukan apakah error 502 Bad Gateway terjadi setelah 55 detik, yang merupakan periode waktu tunggu default yang ditetapkan pada Message Processor. Jika Anda melihat bahwa error terjadi setelah 55 detik, ini menunjukkan bahwa waktu tunggu mungkin merupakan penyebab masalah.
2. Tentukan apakah error menunjukkan kesalahan: messaging.adaptors.http.BadGateway. Sekali lagi, error ini biasanya menunjukkan waktu tunggu yang terjadi.
3. Jika Anda menggunakan Edge Private Cloud, catat nilai kolom X-Apigee.Message-ID dalam output rekaman aktivitas seperti yang ditunjukkan di bawah. Pengguna Private Cloud dapat menggunakan nilai ID ini untuk melakukan pemecahan masalah lebih lanjut, seperti yang dijelaskan nanti.
  1. Klik ikon Data Analytics Direkam di jalur trace:
  2. Scroll ke bawah dan catat nilai kolom yang disebut X-Apigee.Message-ID.

Untuk mengonfirmasi bahwa waktu tunggu TLS/SSL Handshake adalah penyebab error, ikuti langkah-langkah di bagian berikut, bergantung pada apakah Anda menggunakan Public Cloud atau Private Cloud.

Langkah diagnostik tambahan hanya untuk pengguna Edge Private Cloud

Jika menggunakan Apigee Edge Private Cloud, Anda dapat melakukan langkah-langkah berikut untuk membantu memverifikasi penyebab error handshake. Pada langkah ini, Anda akan memeriksa file log Message Processor untuk mendapatkan informasi yang relevan. Jika menggunakan Edge Public Cloud, Anda dapat melewati bagian ini dan membuka Langkah Diagnostik Lebih Lanjut untuk Pengguna Cloud Pribadi dan Publik.

Periksa apakah Anda dapat terhubung ke server backend tertentu langsung dari setiap Pemroses Pesan menggunakan perintah telnet:
1. Jika server backend me-resolve ke satu alamat IP, gunakan perintah ini:
```
telnet BackendServer-IPaddress 443
```
2. Jika server backend me-resolve ke beberapa alamat IP, gunakan nama host server backend dalam perintah telnet seperti yang ditunjukkan di bawah ini:
```
telnet BackendServer-HostName 443
```
Jika Anda dapat terhubung ke server backend tanpa error, lanjutkan ke langkah berikutnya.

Jika perintah telnet gagal, Anda harus bekerja sama dengan tim jaringan untuk memeriksa konektivitas antara pemroses pesan dan server backend.
Periksa file log Message Processor untuk mengetahui bukti kegagalan handshake. Buka file:

/opt/apigee/var/log/edge-message-processor/system.log

dan telusuri ID pesan unik (nilai X-Apigee.Message-ID yang Anda temukan dalam file rekaman aktivitas). Tentukan apakah Anda melihat pesan error handshake yang terkait dengan ID pesan seperti yang ditunjukkan di bawah:
```
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout
```

Jika Anda melihat error ini dalam file log pemroses pesan, lanjutkan penyelidikan lebih lanjut. Buka Langkah diagnostik lebih lanjut untuk pengguna Edge Private dan Cloud Publik.

Jika Anda tidak melihat pesan handshake di file log, buka Informasi Diagnostik Harus Mengumpulkan

Langkah diagnostik lebih lanjut untuk pengguna Edge Private dan Cloud Publik

Untuk lebih menentukan masalahnya, Anda dapat menggunakan alat tcpdump untuk menganalisis paket TCP/IP guna mengonfirmasi apakah waktu tunggu habis selama handshake TLS/SSL.

Jika Anda adalah pengguna Cloud Pribadi, Anda dapat merekam paket TCP/IP di server backend atau Message Processor. Sebaiknya, tangkap paket tersebut di server backend, karena paket didekripsi di server backend.
Jika Anda adalah pengguna Cloud Publik, Anda tidak memiliki akses ke Message Processor; tetapi, mengambil paket TCP/IP di server backend dapat membantu menentukan masalah.
Setelah memutuskan tempat untuk merekam paket TCP/IP, gunakan perintah tcpdump berikut untuk merekam paket TCP/IP.
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
- Jika Anda mengambil paket TCP/IP di server backend, gunakan alamat IP publik Message Processor dalam perintah tcpdump. Untuk mendapatkan bantuan dalam menggunakan perintah untuk memeriksa traffic server backend, lihat tcpdump.
- Jika Anda mengambil paket TCP/IP di Message Processor, gunakan alamat IP publik server backend dalam perintah tcpdump. Untuk mendapatkan bantuan menggunakan perintah untuk memeriksa traffic Message Processor, lihat tcpdump.
- Jika ada beberapa alamat IP untuk server backend/Pemroses Pesan, Anda harus mencoba penggunaan perintah tcpdump lainnya. Lihat tcpdump untuk mengetahui informasi selengkapnya tentang alat ini dan untuk varian lain dari perintah ini.
Analisis paket TCP/IP menggunakan alat Wireshark atau alat serupa. Screenshot berikut menunjukkan paket TCP/IP di Wireshark.
Perhatikan dalam output Wireshark, bahwa handshake TCP tiga arah berhasil diselesaikan dalam 3 paket pertama.
Pemroses Pesan kemudian mengirim pesan "Client Hello" dalam paket #4.
Karena tidak ada konfirmasi dari server backend, Message Processor mengirim ulang pesan "Client Hello" beberapa kali dalam paket 5, 6, dan 7 setelah menunggu interval waktu yang telah ditentukan.
Jika Pemroses Pesan tidak menerima konfirmasi setelah 3 percobaan ulang, Pemroses Pesan akan mengirim pesan FIN, ACK ke server backend untuk menunjukkan bahwa koneksi ditutup.
Seperti yang Anda tunjukkan dalam contoh sesi Wireshark, koneksi ke backend berhasil (langkah #1), tetapi waktu tunggu handshake SSL habis karena server backend tidak pernah merespons.

Jika Anda telah melakukan langkah-langkah pemecahan masalah dalam playbook ini dan menentukan bahwa waktu tunggu habis menyebabkan error handshake TLS/SSL, buka bagian Penyelesaian.

Menggunakan Monitoring API untuk mengidentifikasi masalah

Pemantauan API memungkinkan Anda mengisolasi area masalah dengan cepat untuk mendiagnosis masalah error, performa, dan latensi serta sumbernya, seperti aplikasi developer, proxy API, target backend, atau platform API.

Ikuti langkah-langkah dalam contoh skenario yang menunjukkan cara memecahkan masalah 5xx pada API Anda menggunakan Pemantauan API. Misalnya, Anda dapat menyiapkan pemberitahuan untuk menerima notifikasi saat jumlah error messaging.adaptors.http.BadGateway melebihi batas tertentu.

Resolusi

Biasanya, waktu tunggu handshake SSL terjadi karena pembatasan firewall di server backend yang memblokir traffic dari Apigee Edge. Jika telah mengikuti langkah-langkah diagnostik dan menentukan bahwa penyebab error handshake adalah waktu tunggu habis, Anda harus melibatkan tim jaringan untuk mengidentifikasi penyebab dan memperbaiki pembatasan firewall.

Perhatikan bahwa pembatasan firewall dapat diberlakukan pada lapisan jaringan yang berbeda. Pastikan batasan di semua lapisan jaringan dihapus terkait IP Message Processor untuk memastikan kelancaran alur traffic antara Apigee Edge dan server backend.

Jika tidak ada batasan firewall dan/atau masalah masih berlanjut, buka Harus Mengumpulkan Informasi Diagnostik.

Harus Mengumpulkan Informasi Diagnostik

Jika masalah berlanjut meskipun setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut. Hubungi dan bagikan ke Dukungan Apigee Edge:

Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:
1. Nama Organisasi
2. Nama Lingkungan
3. Nama Proxy API
4. Menyelesaikan perintah curl untuk mereproduksi error
5. File Rekaman Aktivitas yang menampilkan error
6. Paket TCP/IP yang ditangkap di server backend
Jika Anda adalah pengguna Cloud Pribadi, berikan informasi berikut:
1. Pesan Error Lengkap diamati
2. Paket Proxy API
3. File Pelacakan yang menampilkan error
4. Log Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Paket TCP/IP yang diambil di server backend atau Message Processor.
Detail tentang bagian dalam Playbook ini yang telah Anda coba dan insight lainnya yang akan membantu kami mempercepat penyelesaian masalah ini.