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

Cause Deskripsi Langkah pemecahan masalah dapat dilakukan dengan
Waktu tunggu handshake TLS/SSL Waktu tunggu habis selama TLS/SSL Berjabatan antara Pemroses Pesan dan server backend. Pengguna Cloud Pribadi dan Publik Edge

Penyebab: Waktu tunggu handshake TLS/SSL

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

Handshake TLS/SSL melibatkan beberapa langkah. Error ini biasanya terjadi saat handshake TLS/SSL antara Pemroses Pesan dan server backend kehabisan waktu.

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.

  1. Di UI Edge, aktifkan Sesi pelacakan untuk proxy API yang terpengaruh.

  2. 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 Pemroses Pesan. Jika Anda melihat error terjadi setelah 55 detik, artinya waktu tunggu kemungkinan menyebabkan masalah tersebut.
    2. Tentukan apakah error menampilkan 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 ditunjukkan di bawah. Pengguna Private Cloud dapat menggunakan nilai ID ini untuk melakukan pemecahan masalah lebih lanjut, seperti yang akan dijelaskan nanti.

      1. Klik ikon Analytics Data Recorded di jalur trace:

      2. Scroll ke bawah dan catat nilai kolom bernama 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 Private Cloud.

Langkah diagnostik tambahan khusus 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.

  1. 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 perlu bekerja sama dengan tim jaringan untuk memeriksa konektivitas antara pemroses pesan dan server backend.

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

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

    dan cari ID pesan unik (nilai X-Apigee.Message-ID yang Anda temukan dalam file pelacakan). Tentukan apakah Anda melihat pesan error handshake yang terkait dengan ID pesan seperti yang ditunjukkan di bawah ini:

    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 pemroses pesan, lanjutkan penyelidikan lebih lanjut. Buka Langkah diagnostik lebih lanjut untuk pengguna Edge Private dan Public Cloud.

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

Langkah diagnostik lebih lanjut untuk pengguna Edge Private dan Public Cloud

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

  1. Jika Anda adalah pengguna Private Cloud, Anda dapat merekam paket TCP/IP di server backend atau Pemroses Pesan. Sebaiknya, ambil gambar di server backend, karena paket didekripsi di server backend.
  2. Jika Anda adalah pengguna Cloud Publik, Anda tidak memiliki akses ke Pemroses Pesan; tetapi, mengambil paket TCP/IP di server backend dapat membantu menunjukkan masalah.

  3. Setelah menentukan tempat untuk menangkap 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 dari Pemroses Pesan dalam perintah tcpdump. Untuk bantuan penggunaan perintah dalam memeriksa traffic server backend, lihat tcpdump.

    • Jika Anda mengambil paket TCP/IP di Pemroses Pesan, gunakan alamat IP publik server backend dalam perintah tcpdump. Untuk bantuan penggunaan perintah guna memeriksa traffic Message Processor, lihat tcpdump.

    • Jika ada beberapa alamat IP untuk server backend/Pemroses Pesan, Anda perlu 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 dalam output Wireshark, bahwa handshake TCP tiga arah berhasil diselesaikan dalam 3 paket pertama.

  6. Prosesor Pesan kemudian mengirimkan pesan "Client Hello" dalam paket #4.

  7. Karena tidak ada konfirmasi dari server backend, Pemroses Pesan akan mengirim ulang pesan "Client Hello" beberapa kali dalam paket 5, 6, dan 7 setelah menunggu selama interval waktu yang telah ditentukan.

  8. Jika Message Processor tidak menerima konfirmasi setelah 3 kali percobaan ulang, pesan FIN, ACK akan dikirimkan ke server backend untuk menunjukkan bahwa koneksi sedang ditutup.

  9. Seperti yang Anda tunjukkan dalam contoh sesi Wireshark, koneksi ke backend berhasil (langkah #1), tetapi waktu handshake SSL habis karena server backend tidak pernah merespons.

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

Menggunakan API Monitoring untuk mengidentifikasi masalah

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

Ikuti contoh skenario yang menunjukkan cara memecahkan masalah 5xx pada API Anda menggunakan API Monitoring. Misalnya, Anda mungkin ingin menyiapkan pemberitahuan yang akan dikirimkan saat jumlah kesalahan messaging.adaptors.http.BadGateway melebihi batas tertentu.

Resolusi

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

Perhatikan bahwa pembatasan firewall dapat diberlakukan pada lapisan jaringan yang berbeda. Anda harus memastikan bahwa batasan di semua lapisan jaringan yang terkait dengan IP Pemroses Pesan telah dihapus untuk memastikan arus traffic yang lancar antara Apigee Edge dan server backend.

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

Harus Mengumpulkan Informasi Diagnostik

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

  1. 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 menunjukkan error
    6. Paket TCP/IP yang ditangkap 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 Rekaman Aktivitas yang menunjukkan error
    4. Log Prosesor Pesan /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Paket TCP/IP yang ditangkap di server backend atau Prosesor Pesan.
  3. Detail tentang bagian mana dalam Playbook ini yang telah Anda coba dan insight lain yang akan membantu kami menyelesaikan masalah ini dengan cepat.