EOF Gateway Buruk 502 Tidak Terduga

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

Gejala

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

Kode status HTTP 502 berarti klien tidak menerima respons yang valid dari server backend yang seharusnya 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 502 Bad Gateway Error adalah error Unexpected EOF yang dapat disebabkan oleh alasan berikut:

Langkah-langkah diagnosis umum

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

• Pemantauan API
• Alat pelacakan
• Log akses NGINX

Penyebab: Server target yang dikonfigurasi dengan tidak benar

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

Diagnosis

1. Gunakan Pemantauan API, alat Pelacakan, 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 untuk 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.

      Maka, kemungkinan besar masalah ini disebabkan oleh konfigurasi server target yang salah.

4. Dapatkan definisi server target menggunakan panggilan Edge Management API:
   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. Definisi TargetServer yang diilustrasikan adalah contoh untuk salah satu kesalahan konfigurasi umum yang dijelaskan sebagai berikut:

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

   Karena server target dikonfigurasi untuk hanya menerima permintaan HTTPS (SSL) di 443, server tersebut akan menolak permintaan dari Edge atau menutup koneksi. Akibatnya, Anda akan mendapatkan error UnexpectedEOFAtTarget di Pemroses Pesan. Prosesor Pesan akan mengirimkan 502 Bad Gateway sebagai respons kepada klien.

Resolusi

Selalu pastikan server target dikonfigurasi dengan benar sesuai dengan persyaratan Anda.

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

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

      <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 menyertakan truststore (yang berisi sertifikat server target) seperti yang ditunjukkan di bawah ini:

      <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 flag Truststore yang ditetapkan dengan tepat, 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 Pelacakan, atau log akses NGINX untuk menentukan ID pesan, kode kesalahan, dan sumber kesalahan untuk error 502.
2. Periksa log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) dan telusuri untuk melihat apakah Anda memiliki eof unexpected untuk API tertentu atau apakah Anda memiliki messageid unik untuk permintaan API, lalu Anda dapat menelusurinya.

   Contoh pelacakan tumpukan 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]"

   Dalam contoh di atas, Anda dapat melihat bahwa error java.io.EOFException: eof unexpected terjadi saat Message Processor mencoba membaca respons dari server backend. Pengecualian ini menunjukkan akhir file (EOF), atau akhir streaming telah tercapai secara tidak terduga.

   Artinya, Message Processor mengirim permintaan API ke server backend dan sedang menunggu atau membaca respons. Namun, server backend menghentikan koneksi secara tiba-tiba sebelum Message Processor mendapatkan 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, 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 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, error ini disebabkan karena server backend merespons kembali dengan [FIN,ACK] segera setelah Message Processor mengirimkan permintaan ke server backend.

5. Perhatikan contoh tcpdump berikut.

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

   

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

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 masalahnya ada di dalam Edge, hubungi Dukungan Apigee Edge.

Penyebab: Waktu tunggu tetap aktif yang salah dikonfigurasi

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

Koneksi persisten di Apigee

Apigee secara default (dan sesuai dengan standar HTTP/1.1) menggunakan koneksi persisten saat berkomunikasi dengan server backend target. Koneksi persisten dapat meningkatkan performa dengan memungkinkan koneksi TCP dan (jika berlaku) TLS/SSL yang sudah dibuat digunakan kembali, yang mengurangi overhead latensi. Durasi koneksi yang harus dipertahankan dikontrol melalui properti waktu tunggu tetap aktif (keepalive.timeout.millis).

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

Proxy API yang di-deploy ke Message Processor di Apigee, secara default, memiliki waktu tunggu tetap aktif yang ditetapkan 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 tetap aktif, dan setelah waktu ini berakhir, server backend akan menutup koneksi dengan Pemroses Pesan.

Implikasi konfigurasi waktu tunggu tetap aktif yang salah

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

Misalnya, jika waktu tunggu keep-alive dikonfigurasi dalam Proxy API atau Message Processor dengan nilai yang lebih besar dari atau sama dengan waktu tunggu server backend upstream, maka kondisi race berikut dapat terjadi. Artinya, jika Pemroses Pesan tidak menerima data apa pun hingga sangat mendekati batas waktu tunggu tetap aktif server backend, maka permintaan akan masuk dan dikirim ke server backend 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 yang ditetapkan di Message Processor dan server backend adalah 60 detik dan tidak ada permintaan baru hingga 59 detik setelah permintaan sebelumnya ditayangkan oleh Message Processor tertentu.
2. Proses Pesan akan melanjutkan dan memproses permintaan yang masuk pada detik ke-59 menggunakan koneksi yang ada (karena waktu tunggu tetap aktif belum berlalu) dan mengirimkan permintaan ke server backend.
3. Namun, sebelum permintaan tiba di server backend, nilai batas waktu keep-alive di server backend telah terlampaui.
4. Permintaan resource dari Message Processor sedang dalam proses, tetapi server backend berupaya menutup koneksi dengan mengirimkan paket FIN ke Message Processor.
5. Saat menunggu data diterima, Message Processor malah menerima FIN yang tidak terduga, dan koneksi dihentikan.
6. Hal ini akan menghasilkan Unexpected EOF dan selanjutnya 502 akan ditampilkan ke klien oleh Pemroses Pesan.

Dalam hal ini, kami mengamati bahwa error 502 terjadi karena nilai waktu tunggu tetap aktif yang sama, yaitu 60 detik, dikonfigurasi di Message Processor dan server backend. Demikian pula, masalah ini juga dapat terjadi jika nilai yang lebih tinggi dikonfigurasi untuk waktu tunggu tetap aktif di Message Processor daripada di server backend.

Diagnosis

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

      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 Message Processor 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 payload permintaan sebesar 159 byte ke server backend. Namun, ia menerima nol byte kembali saat EOF yang tidak terduga terjadi.

   6. Hal ini menunjukkan bahwa Message Processor telah menggunakan kembali koneksi yang sama beberapa kali, dan pada kesempatan ini, Message Processor mengirim data, tetapi segera setelah itu menerima EOF sebelum data diterima. Artinya, ada kemungkinan besar bahwa waktu tunggu tetap aktif server backend lebih singkat atau sama dengan yang ditetapkan 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. Analisis tcpdump yang diambil:

   Berikut 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, ia merespons dengan 200 OK.
   3. Dalam paket 6084, server backend menerima permintaan GET lainnya.
   4. Dalam paket 6154, sistem akan 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 dalam contoh ini, tetapi pada permintaan ketiga, server backend memulai penutupan koneksi, sementara Pemroses Pesan menunggu data dari server backend. Hal ini menunjukkan bahwa waktu tunggu keep-alive server backend kemungkinan lebih singkat atau sama dengan nilai yang ditetapkan di proxy API. Untuk memvalidasi hal ini, lihat Membandingkan waktu tunggu tetap aktif 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 tetap aktif.

2. Namun, Anda mungkin telah mengganti nilai default di Proxy API. Anda dapat memverifikasinya dengan memeriksa definisi TargetEndpoint tertentu di Proxy API yang gagal dan 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>

   Pada contoh di atas, properti waktu tunggu tetap aktif diganti dengan nilai 30 detik (30000 milidetik).

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

Resolusi

Pastikan properti waktu tunggu tetap aktif selalu lebih rendah di Apigee (dalam komponen Proxy API dan Message Processor) dibandingkan dengan yang ada di server backend.

1. Tentukan nilai yang ditetapkan untuk waktu tunggu tetap aktif di server backend.
2. Konfigurasi nilai yang sesuai untuk properti waktu tunggu tetap aktif di Proxy API atau Message Processor, sehingga properti waktu tunggu tetap aktif lebih rendah daripada nilai yang ditetapkan di server backend, menggunakan langkah-langkah yang dijelaskan dalam Mengonfigurasi waktu tunggu tetap aktif di Message Processor.

Jika masalah masih berlanjut, buka Informasi diagnostik yang harus dikumpulkan.

Praktik Terbaik

Sangat disarankan agar komponen hilir selalu memiliki nilai batas waktu tetap aktif yang lebih kecil daripada yang dikonfigurasi di server hulu untuk menghindari kondisi persaingan dan error 502 semacam ini. Setiap hop hilir harus lebih rendah daripada setiap hop hulu. Di Apigee Edge, sebaiknya gunakan panduan berikut:

1. Waktu tunggu tetap aktif klien harus kurang dari waktu tunggu tetap aktif Edge Router.
2. Waktu tunggu tetap aktif Edge Router harus kurang dari waktu tunggu tetap aktif Message Processor.
3. Waktu tunggu tetap aktif Message Processor harus lebih kecil daripada 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 menyerahkan tanggung jawab untuk menutup koneksi dengan upstream kepada klien downstream.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut, 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 error 502 Bad Gateway - Unexpected EOF
• Jika error 502 tidak terjadi saat ini, berikan jangka waktu dengan informasi zona waktu saat error 502 terjadi di masa lalu.

Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:

• Pesan error lengkap yang diamati untuk permintaan yang gagal
• Nama Organisasi, Lingkungan, dan Proxy API yang Anda amati 502 errornya
• Paket Proxy API
• File rekaman aktivitas yang berisi permintaan dengan error 502 Bad Gateway - Unexpected EOF
• Log akses NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Log Message Processor
  /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