EOF Gateway Buruk 502 Tidak Terduga

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

ini.

Gejala

Aplikasi klien mendapatkan kode status HTTP 502 dengan pesan Bad Gateway sebagai respons untuk panggilan API.

Kode status HTTP 502 berarti bahwa klien tidak menerima respons yang valid dari server backend yang harus benar-benar memenuhi permintaan.

Pesan error

Aplikasi klien mendapatkan kode respons berikut:

HTTP/1.1 502 Bad Gateway

Selain itu, Anda mungkin melihat pesan error berikut:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

Kemungkinan penyebab

Salah satu penyebab umum untuk 502 Bad Gateway Error adalah Unexpected EOF error, yang dapat disebabkan oleh alasan berikut:

Penyebab	Detail	Langkah-langkah yang diberikan untuk
Server target salah dikonfigurasi	Server target tidak dikonfigurasi dengan benar untuk mendukung koneksi TLS/SSL.	Pengguna Edge Public dan Private Cloud
EOFException dari Server Backend	Server backend mungkin mengirim EOF secara tiba-tiba.	Khusus pengguna Edge Private Cloud
Waktu tunggu keep alive tidak dikonfigurasi dengan benar	Pertahankan waktu tunggu aktif yang tidak dikonfigurasi dengan benar di Apigee dan server backend.	Pengguna Edge Public dan Private Cloud

Langkah-langkah diagnosis umum

Untuk mendiagnosis error, Anda dapat menggunakan salah satu metode berikut:

• Pemantauan API
• Alat rekaman aktivitas
• Log akses NGINX

Penyebab: Server target salah dikonfigurasi

Server target tidak dikonfigurasi dengan benar untuk mendukung koneksi TLS/SSL.

Diagnosis

1. Gunakan Pemantauan API, alat Trace, atau Log akses NGINX untuk menentukan ID pesan, kode kesalahan, dan sumber kesalahan untuk error 502.
2. Aktifkan rekaman aktivitas di UI untuk API yang terpengaruh.
3. Jika rekaman aktivitas permintaan API yang gagal menampilkan hal berikut:
   1. Error 502 Bad Gateway terlihat segera setelah permintaan alur target dimulai.
   2. error.class menampilkan messaging.adaptors.http.UnexpectedEOF.

      Kemungkinan besar masalah ini disebabkan oleh server target yang salah konfigurasi Anda.

4. Dapatkan definisi server target menggunakan panggilan API pengelolaan Edge:
   1. Jika Anda adalah pengguna Cloud Publik, gunakan API ini:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

   2. Jika Anda adalah pengguna Private Cloud, gunakan API ini:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

      Contoh definisi TargetServer yang salah:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >
      

5. Gambaran definisi TargetServer adalah contoh untuk salah satu definisi kesalahan konfigurasi yang dijelaskan sebagai berikut:

   Anggaplah server target mocktarget.apigee.net telah dikonfigurasi untuk menerima koneksi aman (HTTPS) pada port 443. Namun, jika Anda melihat definisi server target, tidak ada atribut/tanda lain yang menunjukkan bahwa yang ditujukan untuk koneksi aman. Hal ini menyebabkan Edge memperlakukan permintaan API yang menuju ke server target tertentu sebagai permintaan HTTP (tidak aman). Jadi Edge tidak akan memulai proses berjabatan SSL dengan server target.

   Karena server target dikonfigurasi untuk hanya menerima permintaan HTTPS (SSL) di 443, server tersebut akan menolak permintaan dari Edge atau menutup koneksi. Hasilnya, Anda mendapatkan Error UnexpectedEOFAtTarget pada Pemroses Pesan. Pemroses Pesan akan mengirim 502 Bad Gateway sebagai respons terhadap klien.

Resolusi

Selalu pastikan bahwa server target dikonfigurasi dengan benar sesuai dengan kebutuhan Anda.

Untuk contoh ilustrasi di atas, jika Anda ingin membuat permintaan ke target (HTTPS/SSL) yang aman server, Anda harus menyertakan atribut SSLInfo dengan tanda enabled yang disetel ke true. Meskipun diizinkan untuk menambahkan atribut SSLInfo untuk server target di target definisi endpoint itu sendiri, sebaiknya tambahkan atribut SSLInfo sebagai bagian dari target definisi server untuk menghindari kebingungan.

1. Jika layanan backend memerlukan komunikasi SSL satu arah, maka:
   1. Anda harus mengaktifkan TLS/SSL di definisi TargetServer dengan menyertakan SSLInfo tempat tanda enabled ditetapkan ke benar (true) seperti yang ditunjukkan di bawah ini:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
      

   2. Jika Anda ingin memvalidasi sertifikat server target di Edge, kita juga perlu sertakan truststore (berisi sertifikat server target) seperti yang ditunjukkan di bawah:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>
      

2. Jika layanan backend memerlukan komunikasi SSL dua arah, maka:
   1. Anda harus memiliki atribut SSLInfo dengan ClientAuthEnabled, Keystore, KeyAlias, dan Tanda Truststore disetel dengan benar, seperti yang ditunjukkan di bawah ini:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >
      

Referensi

Load balancing di seluruh server backend

Penyebab: EOFException dari server backend

Server backend dapat mengirim EOF (End of File) secara tiba-tiba.

Diagnosis

1. Gunakan Pemantauan API, alat Trace, atau Log akses NGINX untuk menentukan ID pesan, kode kesalahan, dan sumber kesalahan untuk error 502.
2. Memeriksa log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log) dan telusuri untuk mengetahui apakah Anda memiliki eof unexpected untuk API tertentu atau jika Anda memiliki messageid unik untuk API maka Anda dapat mencarinya.

   Contoh stack trace pengecualian dari log Pemroses Pesan

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
   

   Pada contoh di atas, Anda dapat melihat bahwa error java.io.EOFException: eof unexpected terjadi saat Pemroses Pesan mencoba membaca respons dari server backend. Pengecualian ini menunjukkan akhir file (EOF), atau akhir {i>stream<i} memiliki tercapai secara tidak terduga.

   Artinya, Pemroses Pesan mengirim permintaan API ke server backend dan sedang menunggu atau membaca responsnya. Namun, server backend menghentikan koneksi secara tiba-tiba sebelum Pemroses Pesan mendapat respons atau dapat membaca respons lengkap.

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/informasi, lalu buka Resolusi 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 Pemroses Pesan:
   1. Jika host server backend Anda memiliki satu alamat IP, gunakan perintah berikut:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
      

   2. Jika host server backend Anda memiliki beberapa alamat IP, gunakan perintah berikut:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
      

      Biasanya, kesalahan ini disebabkan karena server backend merespons kembali dengan [FIN,ACK] segera setelah Pemroses Pesan mengirimkan permintaan ke server backend.

5. Perhatikan contoh tcpdump berikut.

   Contoh tcpdump diambil saat 502 Bad Gateway Error (UnexpectedEOFAtTarget) terjadi

   

6. Dari output TCPDump, Anda akan melihat urutan peristiwa berikut:
   1. Dalam paket 985, Pemroses Pesan mengirimkan permintaan API ke server backend.
   2. Dalam paket 986, server backend segera merespons kembali dengan [FIN,ACK].
   3. Dalam paket 987, Pemroses Pesan merespons dengan [FIN,ACK] ke backend server tertentu.
   4. Pada akhirnya, koneksi ditutup dengan [ACK] dan [RST] dari kedua sisi.
   5. Anda akan mendapatkan pengecualian karena server backend mengirim [FIN,ACK] Pengecualian java.io.EOFException: eof unexpected pada Pesan Pemroses.
7. Hal ini dapat terjadi jika ada masalah jaringan di server backend. Bangun interaksi dengan jaringan Anda tim operasional untuk menyelidiki masalah ini lebih lanjut.

Resolusi

Perbaiki masalah di server backend dengan tepat.

Jika masalah berlanjut dan Anda memerlukan bantuan pemecahan masalah 502 Bad Gateway Error menduga bahwa ini adalah masalah pada Edge, hubungi Dukungan Apigee Edge.

Penyebab: Waktu tunggu tetap aktif tidak dikonfigurasi dengan benar

Sebelum Anda mendiagnosis apakah ini merupakan penyebab error 502, baca seluruh konsep berikut.

Koneksi persisten di Apigee

Apigee secara default (dan selanjutnya dengan standar HTTP/1.1) menggunakan koneksi persisten saat berkomunikasi dengan server backend target. Koneksi persisten dapat meningkatkan performa dengan mengizinkan koneksi TCP dan (jika berlaku) TLS/SSL yang telah digunakan untuk digunakan kembali, mengurangi overhead latensi. Durasi koneksi yang perlu dipertahankan dikontrol melalui properti waktu tunggu keep alive (keepalive.timeout.millis).

Baik server backend maupun Pemroses Pesan Apigee menggunakan waktu tunggu tetap aktif untuk menjaga koneksi terbuka satu sama lain. Setelah tidak ada data yang diterima dalam waktu tunggu keep alive durasi, server backend atau Pemroses Pesan dapat menutup koneksi dengan yang lain.

Proxy API yang di-deploy ke Pemroses Pesan di Apigee, secara default, memiliki waktu tunggu tetap aktif ke 60s kecuali jika diganti. Setelah tidak ada data yang diterima untuk 60s, Apigee akan menutup koneksi dengan server backend. Server backend juga akan mempertahankan waktu tunggu yang tetap aktif, dan setelah ini berakhir, server backend akan menutup koneksi dengan Pemroses Pesan.

Implikasi konfigurasi waktu tunggu keep alive yang salah

Jika Apigee atau server backend dikonfigurasi dengan waktu tunggu keep alive yang salah, menghasilkan kondisi race yang menyebabkan server backend mengirim End Of File (FIN) tidak terduga sebagai respons terhadap permintaan resource.

Misalnya, jika waktu tunggu keep alive dikonfigurasi dalam Proxy API atau Pemroses dengan nilai lebih besar dari atau sama dengan waktu tunggu server backend upstream, lalu kondisi race berikut dapat terjadi. Artinya, jika Pemroses Pesan tidak menerima data hingga mendekati ambang batas server backend, membuat waktu tunggu tetap aktif, lalu permintaan datang dan dikirim ke server {i> backend <i}menggunakan koneksi yang ada. Hal ini dapat menyebabkan 502 Bad Gateway karena error EOF yang tidak terduga seperti yang dijelaskan di bawah:

1. Misalkan waktu tunggu tetap aktif disetel pada Pemroses Pesan dan server backend adalah 60 detik dan tidak ada yang baru datang hingga 59 detik setelah permintaan sebelumnya dilayani oleh Pemroses Pesan.
2. Pemroses Pesan melanjutkan dan memproses permintaan yang masuk pada detik ke-59 menggunakan koneksi yang ada (karena waktu tunggu keep alive belum berlalu) dan mengirimkan permintaan ke server backend.
3. Namun, sebelum permintaan tiba di server backend, waktu tunggu keep alive batas tersebut telah terlampaui di server backend.
4. Permintaan Pemroses Pesan untuk resource sedang berlangsung, tetapi server backend mencoba menutup koneksi dengan mengirimkan paket FIN ke Pesan Pemroses.
5. Sementara Pemroses Pesan menunggu data diterima, Pemroses menerima FIN yang tidak terduga, dan koneksinya dihentikan.
6. Hal ini menghasilkan Unexpected EOF, lalu 502 akan yang ditampilkan ke klien oleh Pemroses Pesan.

Dalam kasus ini, kita mengamati bahwa error 502 terjadi karena waktu tunggu keep alive yang sama 60 detik telah dikonfigurasi di Pemroses Pesan dan server backend. Demikian pula, masalah ini juga dapat terjadi jika nilai yang lebih tinggi dikonfigurasi untuk waktu tunggu tetap aktif di Pesan Prosesor daripada di server backend.

Diagnosis

1. Jika Anda adalah pengguna Cloud Publik:
   1. Menggunakan alat Monitoring atau Trace API (seperti yang dijelaskan dalam Langkah-langkah diagnosis umum) dan pastikan Anda memiliki kedua hal berikut pengaturan:
      • Kode error: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Sumber error: target
   2. Buka Menggunakan tcpdump untuk penyelidikan lebih lanjut.
2. Jika Anda adalah pengguna Private Cloud:
   1. Gunakan alat Trace atau Log akses NGINX untuk menentukan ID pesan, kode kesalahan, dan sumber kesalahan untuk error 502.
   2. Menelusuri ID pesan di log Pemroses Pesan
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Anda akan melihat java.io.EOFEXception: eof unexpected seperti yang ditunjukkan di bawah ini:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
      

   4. Error java.io.EOFException: eof unexpected menunjukkan bahwa Pemroses Pesan menerima EOF saat masih menunggu untuk membaca respons dari server backend.
   5. Atribut useCount=7 dalam pesan error di atas menunjukkan bahwa Pemroses Pesan telah menggunakan kembali koneksi ini sekitar tujuh kali dan atribut bytesWritten=159 menunjukkan bahwa Pemroses Pesan telah mengirim permintaan payload 159 byte ke server backend. Namun, server tersebut menerima nol byte saat EOF yang tidak terduga terjadi.

   6. Ini menunjukkan bahwa {i>Message Processor<i} telah menggunakan koneksi yang sama beberapa kali, dan pada kesempatan ini mengirim data, tetapi tidak lama kemudian menerima EOF sebelum data apa pun diterima. Ini berarti ada probabilitas tinggi bahwa backend waktu tunggu keep-alive server lebih pendek atau sama dengan yang disetel di proxy API.

      Anda dapat menyelidiki lebih lanjut dengan bantuan tcpdump seperti yang dijelaskan di bawah.

Menggunakan tcpdump

1. Ambil tcpdump di server backend dengan perintah berikut:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name
   

2. Menganalisis tcpdump yang diambil:

   Berikut adalah contoh output tcpdump:

   

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

   1. Dalam paket 5992,, server backend menerima permintaan GET.
   2. Dalam paket 6064, respons ini direspons dengan 200 OK.
   3. Dalam paket 6084, server backend menerima permintaan GET lainnya.
   4. Dalam paket 6154, kode ini merespons dengan 200 OK.
   5. Dalam paket 6228, server backend menerima permintaan GET ketiga.
   6. Kali ini, server backend menampilkan FIN, ACK ke Pemroses Pesan (paket 6285) yang memulai penutupan koneksi.

   Koneksi yang sama berhasil digunakan kembali dua kali dengan sukses, tetapi pada permintaan ketiga, server backend memulai penutupan koneksi, sementara Pemroses Pesan menunggu data dari server backend. Ini menunjukkan bahwa server backend menyimpan waktu tunggu aktif kemungkinan besar lebih pendek atau sama dengan nilai yang disetel di proxy API. Untuk memvalidasi ini, lihat Membandingkan waktu tunggu keep alive di Apigee dan server backend.

Membandingkan waktu tunggu keep alive di Apigee dan server backend

1. Secara default, Apigee menggunakan nilai 60 detik untuk properti waktu tunggu keep alive.

2. Namun, Anda mungkin telah mengganti nilai default di Proxy API. Anda dapat memverifikasinya dengan memeriksa definisi TargetEndpoint spesifik di Proxy API gagal yang memberikan error 502.

   Contoh konfigurasi TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>
   

   Dalam contoh di atas, properti waktu tunggu keep alive diganti dengan nilai 30 detik (30000 milidetik).

3. Selanjutnya, periksa properti waktu tunggu tetap aktif yang dikonfigurasi di server backend Anda. Katakanlah server backend Anda dikonfigurasi dengan nilai 25 seconds.
4. Jika Anda menentukan bahwa nilai properti waktu tunggu keep alive di Apigee lebih tinggi daripada nilai properti waktu tunggu keep alive di server backend seperti di atas contoh, maka itulah penyebab error 502.

Resolusi

Pastikan properti waktu tunggu keep alive selalu lebih rendah di Apigee (di Proxy API dan Pemroses Pesan) dibandingkan dengan yang ada di server backend.

1. Tentukan nilai yang ditetapkan untuk waktu tunggu keep alive di server backend.
2. Mengonfigurasi nilai yang sesuai untuk properti waktu tunggu tetap aktif di Proxy API atau Pemroses Pesan, sehingga properti waktu tunggu tetap aktif lebih rendah dari nilai yang ditetapkan pada server backend, menggunakan langkah-langkah yang dijelaskan dalam Mengonfigurasi waktu tunggu tetap aktif di Pemroses Pesan.

Jika masalah masih berlanjut, buka Harus mengumpulkan informasi diagnostik.

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 Apigee Edge, sebaiknya gunakan panduan berikut:

1. Waktu tunggu tetap aktif klien harus kurang dari waktu tunggu keep alive Router Edge.
2. Waktu tunggu tetap aktif Router Edge harus kurang dari waktu tunggu tetap aktif Pemroses Pesan.
3. Waktu tunggu tetap aktif Pemroses Pesan harus kurang dari waktu tunggu tetap aktif server target.
4. Jika Anda memiliki hop lain di depan atau di belakang Apigee, aturan yang sama harus diterapkan. Anda harus selalu membiarkannya sebagai tanggung jawab klien downstream untuk menutup dengan upstream.

Harus mengumpulkan informasi diagnostik

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

Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:

• Nama organisasi
• Nama lingkungan
• Nama Proxy API
• Selesaikan perintah curl untuk mereproduksi error 502
• File rekaman aktivitas yang berisi permintaan dengan 502 Bad Gateway - Unexpected EOF error
• Jika error 502 tidak terjadi saat ini, berikan jangka waktu dengan informasi zona waktu saat terjadi error 502 di masa lalu.

Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:

• Pesan error lengkap yang diamati untuk permintaan yang gagal
• Nama Proxy Organisasi, Lingkungan, dan Nama Proxy API yang Anda amati 502 error
• Paket Proxy API
• File rekaman aktivitas yang berisi permintaan dengan 502 Bad Gateway - Unexpected EOF error
• Log akses NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Log Pemroses Pesan
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Jangka waktu dengan informasi zona waktu saat terjadi error 502
• Tcpdumps yang dikumpulkan di Pemroses Pesan atau server backend, atau keduanya saat error terjadi