Kesalahan Waktu Tunggu Gateway Buruk 502

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

Gejala

Aplikasi klien menerima error 502 Bad Gateway. Message Processor menampilkan error ini ke aplikasi klien jika 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:

Penyebab Deskripsi Langkah-langkah pemecahan masalah dapat dilakukan oleh
Waktu tunggu handshake TLS/SSL Waktu tunggu terjadi selama Handshake TLS/SSL antara Message Processor dan server backend. Pengguna Edge Private dan Public Cloud

Penyebab: Waktu tunggu handshake TLS/SSL

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 melibatkan beberapa langkah. Error ini biasanya terjadi saat handshake TLS/SSL antara Message Processor dan server backend mengalami waktu tunggu.

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 Trace Apigee Edge.

  1. Di UI Edge, aktifkan sesi Trace untuk proxy API yang terpengaruh.

  2. Jika detail migrasi untuk permintaan API yang gagal menunjukkan hal berikut, kemungkinan terjadi error waktu tunggu handshake TLS/SSL. Kemungkinan penyebab error 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 di Message Processor. Jika Anda melihat bahwa error terjadi setelah 55 detik, hal ini menunjukkan bahwa waktu tunggu adalah kemungkinan penyebab masalah.
    2. Tentukan apakah error menampilkan kesalahan: messaging.adaptors.http.BadGateway. Sekali lagi, error ini biasanya menunjukkan bahwa waktu tunggu terjadi.

    3. Jika Anda menggunakan Edge Private Cloud, perhatikan nilai kolom X-Apigee.Message-ID dalam output detail migrasi 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 detail migrasi:

      2. Scroll ke bawah dan perhatikan 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 Public Cloud atau Private Cloud.

Langkah-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 melanjutkan ke Langkah-Langkah Diagnostik Lebih Lanjut untuk Pengguna Private dan Public Cloud.

  1. Periksa apakah Anda dapat terhubung ke server backend tertentu langsung dari setiap Message Processor menggunakan perintah telnet:

    1. Jika server backend di-resolve ke satu alamat IP, gunakan perintah ini:

      telnet BackendServer-IPaddress 443

    2. Jika server backend di-resolve ke beberapa alamat IP, gunakan nama host server backend dalam perintah telnet seperti yang ditunjukkan di bawah:

      telnet BackendServer-HostName 443

    Jika Anda dapat terhubung ke server backend tanpa error, lanjutkan ke langkah berikutnya.

    Jika perintah telnet gagal, Anda harus berkoordinasi dengan tim jaringan untuk memeriksa konektivitas antara message processor dan server backend.

  2. Periksa file log Message Processor untuk mengetahui bukti kegagalan handshake. Buka file:

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

    dan cari ID pesan unik (nilai X-Apigee.Message-ID yang Anda temukan di file detail migrasi). 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 di file log message processor, lanjutkan penyelidikan lebih lanjut. Buka Langkah-Langkah diagnostik lebih lanjut untuk pengguna Edge Private dan Public Cloud.

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

Langkah-langkah diagnostik lebih lanjut untuk pengguna Edge Private dan Public Cloud

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

  1. Jika Anda adalah pengguna Private Cloud, Anda dapat mengambil paket TCP/IP di server backend atau Message Processor. Sebaiknya, ambil paket di server backend, karena paket didekripsi di server backend.
  2. Jika Anda adalah pengguna Public Cloud, Anda tidak memiliki akses ke Message Processor. Namun, mengambil paket TCP/IP di server backend dapat membantu menentukan masalah.

  3. Setelah memutuskan tempat untuk mengambil paket TCP/IP, gunakan perintah tcpdump berikut untuk mengambil 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 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/Message Processor, Anda harus mencoba penggunaan perintah tcpdump lainnya. Lihat tcpdump untuk mengetahui informasi selengkapnya tentang alat ini dan varian lain dari perintah ini.

  4. Analisis paket TCP/IP menggunakan alat Wireshark atau alat serupa. Screenshot berikut menunjukkan paket TCP/IP di Wireshark.

  5. Perhatikan di output Wireshark, bahwa handshake TCP tiga arah berhasil diselesaikan dalam 3 paket pertama.

  6. Message Processor kemudian mengirim pesan "Client Hello" dalam paket #4.

  7. 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.

  8. Jika Message Processor tidak menerima konfirmasi apa pun setelah 3 kali percobaan ulang, Message Processor akan mengirim pesan FIN, ACK ke server backend untuk menunjukkan bahwa Message Processor menutup koneksi.

  9. Seperti yang ditunjukkan dalam sesi Wireshark contoh, koneksi ke backend berhasil (langkah #1). Namun, handshake SSL mengalami waktu tunggu karena server backend tidak pernah merespons.

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

Menggunakan Pemantauan 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 skenario contoh yang menunjukkan cara memecahkan masalah 5xx dengan API Anda menggunakan Pemantauan API. Misalnya, Anda mungkin ingin menyiapkan pemberitahuan untuk mendapatkan notifikasi saat jumlah kesalahan messaging.adaptors.http.BadGateway melebihi batas tertentu.

Resolusi

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

Perhatikan bahwa batasan firewall dapat diterapkan di berbagai lapisan jaringan. Penting untuk memastikan bahwa batasan di semua lapisan jaringan dihapus terkait IP Message Processor untuk memastikan aliran traffic yang lancar antara Apigee Edge dan server backend.

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

Informasi Diagnostik yang Harus Dikumpulkan

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

  1. Jika Anda adalah pengguna Public Cloud, berikan informasi berikut:
    1. Nama Organisasi
    2. Nama Lingkungan
    3. Nama Proxy API
    4. Perintah curl lengkap untuk mereproduksi error
    5. File Detail Migrasi yang menunjukkan error
    6. Paket TCP/IP yang diambil di server backend
  2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
    1. Pesan Error Lengkap yang diamati
    2. Paket Proxy API
    3. File Detail Migrasi yang menunjukkan 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.
  3. Detail tentang bagian mana dalam Playbook ini yang telah Anda coba dan insight lainnya yang akan membantu kami mempercepat penyelesaian masalah ini.