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 mengembalikan {i>error<i} ini ke aplikasi klien ketika aplikasi itu 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	Waktu tunggu terjadi selama TLS/SSL Handshake antara Pemroses Pesan dan server backend.	Pengguna Edge Private Cloud 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 tercantum.

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 adalah periode waktu tunggu default yang disetel pada Pemroses Pesan. 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 habis.
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 Analytics Data Recorded di jalur rekaman aktivitas:
  2. Scroll ke bawah dan catat nilai kolom yang disebut X-Apigee.Message-ID.

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

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 Pemroses Pesan 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 Pemroses Pesan untuk melihat 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 dalam file log, buka Informasi Diagnostik Harus Mengumpulkan

Langkah diagnostik lebih lanjut untuk pengguna Edge Private dan Public Cloud

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 Private Cloud, Anda dapat menangkap paket TCP/IP di server backend atau Pemroses Pesan. Sebaiknya, ambil gambar di backend server web, 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 di mana harus menangkap paket TCP/IP, gunakan tcpdump perintah untuk menangkap 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 pada {i>Message Processor<i}, maka gunakan Alamat IP server backend di perintah tcpdump. Untuk bantuan menggunakan perintah untuk memeriksa traffic Pemroses Pesan, lihat tcpdump.
- Jika ada beberapa alamat IP untuk server backend/Pemroses Pesan, Anda harus mencoba penggunaan perintah tcpdump lainnya. Lihat tcpdump untuk informasi selengkapnya tentang alat ini dan untuk varian lain dari perintah ini.
Menganalisis paket TCP/IP menggunakan alat Wireshark atau alat serupa. Screenshot berikut menunjukkan paket TCP/IP di Wireshark.
Perhatikan pada output Wireshark, bahwa handshake TCP tiga arah berhasil selesai dalam 3 paket pertama.
Pemroses Pesan kemudian mengirimkan "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.
Ketika Pemroses Pesan tidak menerima konfirmasi apa pun setelah 3 kali percobaan ulang, klien akan mengirimkan pesan FIN, ACK ke server backend untuk menunjukkan bahwa koneksi ditutup.
Seperti yang Anda tunjukkan pada contoh sesi Wireshark, koneksi ke backend berhasil (langkah #1), namun, waktu handshake SSL habis karena backend server tidak pernah merespons.

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

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 diberi tahu saat jumlah error messaging.adaptors.http.BadGateway melebihi batas tertentu.

Resolusi

Biasanya waktu tunggu handshake SSL terjadi karena pembatasan {i>firewall<i} pada server backend yang memblokir traffic dari Apigee Edge. Jika Anda mengikuti langkah-langkah diagnostik dan menentukan bahwa penyebab kesalahan {i>handshake <i}adalah waktu tunggu habis, Anda perlu melibatkan tim jaringan untuk mengidentifikasi penyebabnya dan memperbaiki pembatasan firewall.

Perhatikan bahwa batasan firewall dapat diterapkan di berbagai lapisan jaringan. 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 diambil 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 mana saja dalam Playbook ini yang telah Anda coba dan wawasan lainnya yang akan membantu kami mempercepat penyelesaian masalah ini.