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 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 error Unexpected EOF, yang dapat disebabkan oleh alasan berikut:

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

Langkah-langkah diagnosis umum

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

• Pemantauan API
• Alat pelacakan
• Log akses NGINX

Penyebab: Server target tidak dikonfigurasi dengan benar

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

Diagnosis

1. Gunakan API Monitoring, Trace tool, atau Log akses NGINX untuk menentukan ID pesan, kode fault, dan sumber fault untuk error 502.
2. Mengaktifkan 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 akan terlihat segera setelah permintaan alur target dimulai.
   2. error.class menampilkan messaging.adaptors.http.UnexpectedEOF.

      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. Ilustrasi definisi TargetServer adalah contoh untuk salah satu kesalahan konfigurasi umum, yang dijelaskan sebagai berikut:

   Anggaplah server target mocktarget.apigee.net dikonfigurasi untuk menerima koneksi aman (HTTPS) pada port 443. Namun, jika Anda melihat definisi server target, tidak ada atribut/tanda lain yang menunjukkan bahwa server tersebut dimaksudkan untuk koneksi aman. Hal ini menyebabkan Edge memperlakukan permintaan API yang dikirim 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 pada Pemroses Pesan. Pemroses Pesan akan mengirimkan 502 Bad Gateway sebagai respons kepada klien.

Resolusi

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

Untuk contoh ilustrasi di atas, jika ingin membuat permintaan ke server target (HTTPS/SSL) yang aman, Anda harus menyertakan atribut SSLInfo dengan tanda enabled yang ditetapkan ke true. Meskipun Anda dapat menambahkan atribut SSLInfo 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 harus mengaktifkan TLS/SSL dalam definisi TargetServer dengan menyertakan atribut SSLInfo tempat tanda enabled ditetapkan 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, kami juga perlu menyertakan truststore (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 tanda ClientAuthEnabled, Keystore, KeyAlias, dan 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 (Akhir File) secara tiba-tiba.

Diagnosis

1. Gunakan API Monitoring, Trace tool, atau Log akses NGINX untuk menentukan ID pesan, kode fault, dan sumber fault untuk error 502.
2. Periksa 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 permintaan API, Anda dapat menelusurinya.

   Contoh pelacakan tumpukan pengecualian dari log Message Processor

   "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 Message Processor mencoba membaca respons dari server backend. Pengecualian ini menunjukkan akhir file (EOF), atau akhir streaming telah tercapai secara tidak terduga.

   Artinya, Pemroses Pesan mengirim permintaan API ke server backend dan sedang menunggu atau membaca respons. Namun, server backend menghentikan koneksi secara tiba-tiba sebelum Pemroses Pesan 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 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 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 Pemroses Pesan mengirim 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, Pemroses Pesan mengirimkan permintaan API ke server backend.
   2. Dalam paket 986, server backend langsung merespons kembali dengan [FIN,ACK].
   3. Dalam paket 987, Pemroses Pesan 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 mendapatkan pengecualian java.io.EOFException: eof unexpected di Pemroses Pesan.
7. Hal ini dapat terjadi jika ada masalah jaringan pada server backend. Minta agar tim operasi jaringan Anda menyelidiki masalah ini lebih lanjut.

Resolusi

Perbaiki masalah di server backend dengan tepat.

Jika masalah berlanjut dan Anda memerlukan bantuan untuk memecahkan 502 Bad Gateway Error atau Anda mencurigai bahwa ini adalah masalah dalam Edge, hubungi Dukungan Apigee Edge.

Penyebab: Waktu tunggu terus aktif tidak dikonfigurasi dengan benar

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

Koneksi persisten di Apigee

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

Server backend dan Apigee Message Processor menggunakan waktu tunggu tetap aktif agar koneksi tetap terbuka satu sama lain. Setelah tidak ada data yang diterima dalam durasi waktu tunggu keep alive, server backend atau Pemroses Pesan dapat menutup koneksi dengan server lainnya.

Proxy API yang di-deploy ke Pemroses Pesan 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 keep alive, dan setelah waktu 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, hal tersebut akan mengakibatkan kondisi race yang menyebabkan server backend mengirim End Of File (FIN) yang tidak terduga sebagai respons terhadap permintaan untuk resource.

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

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

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

Diagnosis

1. Jika Anda adalah pengguna Cloud Publik:
   1. Gunakan alat Pemantauan atau Pelacakan API (seperti yang dijelaskan dalam Langkah-langkah diagnosis umum) dan pastikan Anda memiliki kedua setelan berikut:
      • Kode error: 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 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 payload permintaan sebesar 159 byte ke server backend. Namun, metode ini menerima nol byte kembali saat EOF yang tidak terduga terjadi.

   6. Hal ini menunjukkan bahwa Pemroses Pesan telah menggunakan kembali koneksi yang sama beberapa kali, dan pada kesempatan ini mengirim data, tetapi sesaat setelahnya menerima EOF sebelum data apa pun diterima. Artinya, ada kemungkinan besar bahwa waktu tunggu keep alive server backend lebih pendek atau sama dengan yang disetel di proxy API.

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

Menggunakan {i>tcpdump<i}

1. Catat tcpdump di server backend dengan perintah berikut:

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

2. Analisis tcpdump yang ditangkap:

   Berikut contoh output tcpdump:

   

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

   1. Dalam paket 5992,, server backend menerima permintaan GET.
   2. Dalam paket 6064, kode ini merespons dengan 200 OK.
   3. Dalam paket 6084, server backend menerima permintaan GET lain.
   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 dalam contoh ini, tetapi pada permintaan ketiga, server backend memulai penutupan koneksi, saat Pemroses Pesan menunggu data dari server backend. Hal ini menunjukkan bahwa waktu tunggu keep alive server backend kemungkinan lebih pendek atau sama dengan nilai yang disetel di proxy API. Untuk memvalidasi hal 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, ada kemungkinan Anda telah mengganti nilai default di Proxy API. Anda dapat memverifikasi hal ini dengan memeriksa definisi TargetEndpoint spesifik di Proxy API yang 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>
   

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

3. Selanjutnya, periksa properti waktu tunggu keep alive yang dikonfigurasi di server backend. Misalnya, 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 dalam contoh di atas, maka itulah penyebab error 502.

Resolusi

Pastikan properti waktu tunggu keep alive selalu lebih rendah di Apigee (di komponen 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. Konfigurasikan nilai yang sesuai untuk properti waktu tunggu keep alive di Proxy API atau Pemroses Pesan, sehingga properti waktu tunggu terus aktif lebih rendah daripada nilai yang ditetapkan pada server backend, menggunakan langkah-langkah yang dijelaskan dalam Mengonfigurasi waktu tunggu keep alive di Pemroses Pesan.

Jika masalah masih berlanjut, buka Harus mengumpulkan informasi diagnostik.

Praktik Terbaik

Sangat disarankan agar komponen downstream selalu memiliki batas waktu tunggu aktif 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 Apigee Edge, sebaiknya ikuti panduan berikut:

1. Waktu tunggu klien untuk tetap aktif harus kurang dari waktu tunggu penyimpanan Edge Router.
2. Waktu tunggu masa aktif Router Edge harus kurang dari waktu tunggu aktif Pemroses Pesan.
3. Waktu tunggu keep-alive Pemroses Pesan harus kurang dari waktu tunggu keep alive 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 koneksi dengan upstream.

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
• Organisasi, Nama Lingkungan, dan nama Proxy API yang Anda amati error 502-nya
• 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 Pemroses Pesan
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Jangka waktu dengan informasi zona waktu saat error 502 terjadi
• Tcpdumps dikumpulkan di Pemroses Pesan atau server backend, atau keduanya saat error terjadi