502 Bad Gateway - Soket ditutup

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

Gejala

Aplikasi klien menerima kode status HTTP 502 Bad Gateway dengan kode ECONNRESET sebagai respons untuk panggilan API di Edge Microgateway.

Pesan error

Klien akan melihat kode respons berikut: 

HTTP/1.1 502 Bad Gateway

Responsnya akan menyertakan pesan error berikut: 

{"message":"socket hang up","code":"ECONNRESET"}

Kemungkinan penyebab

Penyebab Deskripsi Petunjuk pemecahan masalah berlaku untuk
Waktu tunggu keep-alive tidak dikonfigurasi dengan benar Waktu tunggu tetap aktif tidak dikonfigurasi dengan benar antara Edge Microgateway dan server target. Pengguna Edge Public dan Private Cloud
Server target menutup koneksi sebelum waktunya Server target menutup koneksi sebelum waktunya saat Edge Microgateway mengirim payload permintaan. Pengguna Edge Public dan Private Cloud

Langkah-langkah diagnosis umum

  1. Periksa log Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Telusuri apakah ada error 502 dengan kode ECONNRESET selama durasi tertentu (jika masalah terjadi di masa lalu) atau jika ada permintaan masih gagal dengan 502. 
    2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
[emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
[microgateway-core][][GET][502][socket hang up][ECONNRESET][]
  3. Jika Anda memiliki level logging yang disetel ke warn atau info, akan ada menjadi pesan [warn] yang mencakup nama host dan port server target pada . Dalam contoh ini, variabelnya adalah X.X.X.X:8080, dan dapat digunakan nanti untuk merekam tcpdump. 
    2021-06-23T03:52:24.109Z
[warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
[][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
[targetRequest error][GET][][socket hang up][ECONNRESET][395]
  4. Kode error [socket hang up][ECONNRESET] menunjukkan bahwa server target telah memutus koneksi dengan Edge Microgateway. Hal ini dapat dicari di log untuk menentukan seberapa sering itu terjadi.

Penyebab: Waktu tunggu keep-alive tidak dikonfigurasi dengan benar

Diagnosis

  1. Gunakan langkah-langkah dalam Langkah-langkah diagnosis umum dan verifikasi apakah Anda mendapatkan Error [socket hang up][ECONNRESET].

  2. Jika ya, maka selidiki lebih lanjut dengan bantuan tcpdump seperti yang dijelaskan di bawah:

Menggunakan tcpdump

  1. Mengambil tcpdump antara Edge Microgateway dan server backend di sistem operasi host Edge Microgateway dengan perintah berikut: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Menganalisis tcpdump yang diambil:

    Contoh output tcpdump: ( lihat gambar yang lebih besar)

    Dalam contoh tcpdump di atas, Anda dapat melihat hal berikut:

    1. Dalam paket 250288, klien mengirim permintaan POST.
    2. Dalam paket 250371, server merespons dengan 200 OK.
    3. Dalam paket 250559, klien mengirim ACK.
    4. Dalam paket 250560, server mengirimkan Continuation untuk membuat pesan email baru.
    5. Dalam paket 250561, klien mengirim ACK.
    6. Dalam paket 262436, server mengirim FIN, ACK ke klien yang memulai penutupan koneksi. Perhatikan bahwa ini sekitar lima detik setelah paket sebelumnya (250561).
    7. Dalam paket 262441, klien mengirim POST lain permintaan. Namun, ini gagal karena server telah memulai penutupan koneksi jarak jauh. Aplikasi merespons dengan RST dalam paket 262441.

    Koneksi yang sama berhasil digunakan kembali setidaknya sekali dengan sukses dalam contoh ini, tetapi permintaan terakhir, server memulai penutupan koneksi setelah lima detik waktu tidak ada aktivitas, yang terjadi bersamaan dengan saat klien mengirim permintaan baru. Ini menunjukkan bahwa waktu tunggu tetap- server backend kemungkinan besar lebih pendek atau sama dengan nilai yang ditetapkan dalam klien. Untuk memvalidasi ini, lihat Membandingkan waktu tunggu keep-alive di Edge Microgateway dan server backend.

Membandingkan waktu tunggu keep-alive

  1. Edge Microgateway tidak memiliki properti waktu tunggu keep-alive tertentu. Penting ditentukan oleh sistem operasi di mana ia berjalan. Contoh umumnya adalah Windows, Linux, dan container Docker.
  2. Mungkin saja ini disesuaikan di sistem operasi. Hubungi administrator sistem. Secara {i>default<i}, sistem operasi Linux memiliki {i>keep-alive<i} {i>default<i} waktu tunggu selama dua jam.
  3. Selanjutnya, periksa properti waktu tunggu keep-alive yang dikonfigurasi di server backend Anda. Mari katakanlah server backend Anda dikonfigurasi dengan nilai 10 detik.
  4. Jika Anda menentukan bahwa nilai waktu tunggu pertahanan tetap di sistem operasi adalah lebih tinggi dari nilai properti waktu tunggu keep-alive di server backend di atas, maka itulah penyebab error 502.

Resolusi

Pastikan bahwa properti waktu tunggu keep-alive selalu lebih rendah di sistem operasi tempat Edge Microgateway berjalan dibandingkan dengan yang ada di server backend.

  1. Menentukan nilai yang ditetapkan untuk waktu tunggu keep-alive di server backend.
  2. Mengonfigurasi nilai yang sesuai untuk properti waktu tunggu keep-alive di sistem operasi sistem, sehingga properti waktu tunggu keep-alive lebih rendah dari nilai yang ditetapkan pada backend server Anda, dengan menggunakan langkah-langkah yang berlaku untuk sistem operasi Anda.

Praktik Terbaik

Sangat disarankan bahwa komponen downstream selalu memiliki waktu tunggu keep-alive yang lebih rendah daripada yang dikonfigurasi di server hulu untuk menghindari kondisi {i>ras<i} semacam ini dan 502 error. Setiap hop downstream harus lebih rendah dari setiap hop upstream. Di Tepi Microgateway, sebaiknya gunakan panduan berikut:

  1. Waktu tunggu keep-alive pada aplikasi klien atau load balancer harus lebih kecil dari Waktu tunggu tetap aktif Edge Microgateway.

    Untuk mengonfigurasi waktu tunggu keep-alive di Edge Microgateway, tambahkan keep_alive_timeout nilai ke File ~/.edgemicro/org-env-config.yaml.

    edgemicro:
  keep_alive_timeout: 65000
  2. Waktu tunggu tetap aktif sistem operasi Edge Microgateway harus kurang dari target server tetap aktif.
  3. Jika Anda memiliki hop lain di depan atau di belakang Edge Microgateway, aturan yang sama harus diterapkan. Anda harus selalu membiarkannya sebagai tanggung jawab klien downstream untuk menutupnya koneksi dengan upstream.

Penyebab: Server target menutup koneksi sebelum waktunya

Diagnosis

  1. Gunakan langkah-langkah yang dijelaskan dalam Langkah-langkah diagnosis umum dan verifikasi apakah Anda mendapatkan {i>error<i} [socket hang up][ECONNRESET].
  2. Jika ya, selidiki lebih lanjut dengan bantuan tcpdump seperti yang dijelaskan di bawah.

    Pesan error [targetRequest error][GET][][socket hang up][ECONNRESET] pada contoh di atas menunjukkan bahwa error ini terjadi saat Edge Microgateway mengirimkan permintaan ke server backend (target). Yaitu, Edge Microgateway mengirimkan Permintaan API ke server backend dan menunggu respons. Namun, backend server menghentikan koneksi secara tiba-tiba sebelum Edge Microgateway menerima respons.

  3. 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 kesalahan atau informasi selengkapnya, lalu buka Penyelesaian dan perbaiki masalah dengan tepat di server backend Anda.
  4. Jika Anda tidak menemukan error atau informasi apa pun di server backend, kumpulkan Output tcpdump di server Edge Microgateway: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Menganalisis tcpdump yang diambil:

    Contoh output tcpdump: ( lihat gambar yang lebih besar)

    Dalam contoh tcpdump di atas, Anda dapat melihat hal berikut:

    1. Dalam paket 4, Edge Microgateway mengirim permintaan GET ke target server tertentu.
    2. Dalam paket 5, server target merespons dengan ACK untuk mengonfirmasi permintaan.
    3. Namun, dalam paket 6, alih-alih merespons dengan payload respons, target server mengirim FIN, ACK yang memulai penutupan koneksi.
    4. Dalam paket 7 dan seterusnya, koneksi ditutup satu sama lain. Karena koneksinya ditutup sebelum respons dikirim, Edge Microgateway akan menampilkan 502 HTTP {i>error<i} kembali ke klien.
    5. Perhatikan bahwa stempel waktu paket 8, 2021-06-23T03:52:24.110Z sesuai dengan stempel waktu saat error dicatat di Edge Microgateway log. Stempel waktu dalam file log dan di tcpdump sering kali dapat digunakan untuk mengorelasikan kesalahan dengan paket yang sebenarnya.

    Resolusi

    Perbaiki masalah di server backend dengan tepat.

    Jika masalah berlanjut dan Anda memerlukan bantuan pemecahan masalah 502 Bad Gateway Error atau Anda menduga ada masalah dalam Edge Microgateway, buka Harus mengumpulkan informasi diagnostik.

    Harus mengumpulkan informasi diagnostik

    Jika masalah berlanjut bahkan setelah mengikuti instruksi di atas, kumpulkan informasi diagnostik, lalu hubungi Dukungan Apigee Edge:

    • File log: Folder default adalah /var/tmp, tetapi mungkin diganti di file config.yaml utama (logging > dir parameter). Penting sebaiknya ubah log > level menjadi info sebelum menyediakan file log ke Dukungan Apigee.
    • File konfigurasi: Konfigurasi utama Edge Microgateway berada di File YAML di folder Edge Microgateway default, $HOME/.edgemicro. Terdapat file konfigurasi default bernama default.yaml, lalu satu file konfigurasi untuk setiap lingkungan ORG-ENV-config.yaml. Harap upload file ini secara penuh untuk organisasi dan lingkungan yang terkena dampak.