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 yang berlaku untuk
Waktu tunggu keep-alive tidak dikonfigurasi dengan benar Waktu tunggu keep-alive tidak dikonfigurasi dengan benar antara Edge Microgateway dan server target. Pengguna Edge Publik dan Private Cloud
Server target menutup koneksi lebih awal Server target menutup koneksi lebih awal saat Edge Microgateway mengirim payload permintaan. Pengguna Edge Publik dan Private Cloud

Langkah-langkah diagnosis umum

  1. Periksa log Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Telusuri untuk mengetahui apakah ada error 502 dengan kode ECONNRESET selama durasi tertentu (jika masalah terjadi sebelumnya) atau apakah ada permintaan yang 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 telah menyetel level logging ke warn atau info, pesan [warn] juga akan muncul, yang mencakup port dan hostname server target di elemen kedua. Dalam contoh ini, nilainya adalah X.X.X.X:8080, dan ini dapat digunakan nanti untuk mengambil 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 menutup koneksi dengan Edge Microgateway. Hal ini dapat ditelusuri di log untuk menentukan seberapa sering masalah tersebut terjadi.

Penyebab: Waktu tunggu keep-alive tidak dikonfigurasi dengan benar

Diagnosis

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

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

Menggunakan {i>tcpdump<i}

  1. Ambil rekaman 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. Analisis tcpdump yang ditangkap:

    Contoh output tcpdump: ( lihat gambar yang lebih besar)

    Pada 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 mengirimkan ACK.
    4. Dalam paket 250560, server mengirim pesan Continuation.
    5. Dalam paket 250561, klien mengirimkan ACK.
    6. Dalam paket 262436, server akan mengirimkan FIN, ACK ke klien yang memulai penutupan koneksi. Perhatikan bahwa waktu ini sekitar lima detik setelah paket sebelumnya (250561).
    7. Dalam paket 262441, klien mengirimkan permintaan POST lainnya. Namun, tindakan ini gagal karena server sudah memulai penutupan koneksi. Metode ini merespons dengan RST dalam paket 262441.

    Koneksi yang sama berhasil digunakan kembali setidaknya sekali dalam contoh ini, tetapi pada permintaan terakhir, server memulai penutupan koneksi setelah lima detik waktu tidak ada aktivitas, yang terjadi pada saat yang sama saat klien mengirim permintaan baru. Hal ini menunjukkan bahwa waktu tunggu keep-alive server backend kemungkinan besar lebih singkat atau sama dengan nilai yang ditetapkan di klien. Untuk memvalidasi hal 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 yang spesifik. Batas ini ditentukan oleh sistem operasi tempatnya berjalan. Contoh umumnya adalah container Windows, Linux, dan Docker.
  2. Mungkin saja ini disesuaikan dalam sistem operasi. Hubungi administrator sistem Anda. Secara default, sistem operasi Linux memiliki waktu tunggu keep-alive default selama dua jam.
  3. Selanjutnya, periksa properti waktu tunggu keep-alive yang dikonfigurasi di server backend. Misalkan server backend Anda dikonfigurasi dengan nilai 10 detik.
  4. Jika Anda menentukan bahwa nilai waktu tunggu keep-alive pada sistem operasi lebih tinggi daripada nilai properti waktu tunggu keep-alive di server backend seperti dalam contoh di atas, berarti itulah penyebab error 502.

Resolusi

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

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

Praktik Terbaik

Sangat disarankan agar komponen downstream selalu memiliki batas waktu tunggu keep-alive yang lebih rendah daripada yang dikonfigurasi pada server upstream untuk menghindari jenis kondisi race dan error 502 ini. Setiap hop downstream harus lebih rendah dari setiap hop upstream. Di Edge Microgateway, sebaiknya ikuti panduan berikut:

  1. Waktu tunggu keep-alive pada aplikasi klien atau load balancer harus kurang dari waktu tunggu keep-alive Edge Microgateway.

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

    edgemicro:
  keep_alive_timeout: 65000
  2. Waktu tunggu keep-alive sistem operasi Edge Microgateway harus kurang dari waktu tunggu keep-alive server target.
  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 menutup koneksi dengan upstream.

Penyebab: Server target menutup koneksi lebih awal

Diagnosis

  1. Gunakan langkah-langkah yang dijelaskan dalam Langkah-langkah diagnosis umum dan verifikasi apakah Anda mengalami error [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 mengirim permintaan ke server backend (target). Artinya, Edge Microgateway mengirim permintaan API ke server backend dan sedang menunggu respons. Namun, server backend 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 error atau informasi apa pun, buka Resolution dan perbaiki masalah di server backend Anda dengan tepat.
  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. Analisis tcpdump yang ditangkap:

    Contoh output tcpdump: ( lihat gambar yang lebih besar)

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

    1. Dalam paket 4, Edge Microgateway mengirim permintaan GET ke server target.
    2. Dalam paket 5, server target merespons dengan ACK untuk mengonfirmasi permintaan.
    3. Namun, dalam paket 6, server target mengirim FIN, ACK yang memulai penutupan koneksi, bukan merespons dengan payload respons.
    4. Pada paket 7 dan seterusnya, koneksi akan saling ditutup. Karena koneksi ditutup sebelum respons dikirim, Edge Microgateway akan menampilkan error 502 HTTP kembali ke klien.
    5. Perlu diketahui bahwa stempel waktu paket 8, 2021-06-23T03:52:24.110Z sesuai dengan stempel waktu saat error dicatat dalam log Edge Microgateway. Stempel waktu dalam file log dan dalam tcpdump sering kali dapat digunakan untuk menghubungkan error dengan paket yang sebenarnya.

    Resolusi

    Perbaiki masalah di server backend dengan tepat.

    Jika masalah berlanjut dan Anda memerlukan bantuan untuk memecahkan masalah 502 Bad Gateway Error atau Anda mencurigai bahwa ini adalah masalah dalam Edge Microgateway, buka Harus mengumpulkan informasi diagnostik.

    Harus mengumpulkan informasi diagnostik

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

    • File log: Folder default-nya adalah /var/tmp, tetapi mungkin diganti dalam file config.yaml utama (logging > dir parameter). Sebaiknya ubah log > level ke info sebelum memberikan file log ke Apigee Support.
    • File konfigurasi: Konfigurasi utama Edge Microgateway berada dalam file YAML di folder Edge Microgateway default, $HOME/.edgemicro. Tersedia file konfigurasi default bernama default.yaml, lalu satu file untuk setiap lingkungan ORG-ENV-config.yaml. Harap upload file ini secara lengkap untuk organisasi dan env.