Kesalahan Server Internal 500 - Streaming diaktifkan

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

Gejala

Aplikasi klien menerima kode status respons HTTP 500 dengan pesan Internal Server Error untuk panggilan API.

Pesan error

Aplikasi klien dapat menerima respons error seperti yang ditunjukkan di bawah:

HTTP/1.1 500 Internal Server Error

Hal ini mungkin diikuti dengan pesan error seperti berikut:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Kemungkinan penyebab

Error Server Internal 500 dapat terjadi karena sejumlah penyebab yang berbeda. Playbook ini berfokus pada Error Server Internal 500 yang disebabkan karena mengakses payload permintaan/respons saat streaming diaktifkan.

Penyebab: Mengakses Payload dengan Streaming yang Diaktifkan

Diagnosis

Prosedur #1: Menggunakan Trace

1. Aktifkan sesi trace, lalu lakukan panggilan API untuk mereproduksi masalah - 500 Internal Server Error.
2. Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitas.
3. Telusuri berbagai fase rekaman aktivitas dan temukan tempat terjadinya kegagalan.
4. Error ini mungkin terjadi saat kebijakan mengurai payload permintaan/respons.
5. Berikut adalah screenshot rekaman aktivitas contoh yang menunjukkan kegagalan kebijakan JSONThreatProtection dengan error "Expecting } at line 1":

   

   Catat informasi berikut dari output rekaman aktivitas, seperti yang ditunjukkan pada screenshot di atas:
   

   Kebijakan yang Gagal: JSONThreatProtection

   Alur: Permintaan Proxy

6. Periksa definisi kebijakan yang gagal dan periksa payload yang sedang diuraikan.

   Dalam contoh skenario, periksa kebijakan JSONThreatProtection bernama JSON-Threat-Protection yang gagal dan periksa elemen <Source>.

   <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
      <DisplayName>JSON Threat Protection</DisplayName>
      <ArrayElementCount>20</ArrayElementCount>
      <ContainerDepth>10</ContainerDepth>
      <ObjectEntryCount>15</ObjectEntryCount>
      <ObjectEntryNameLength>50</ObjectEntryNameLength>
      <Source>request</Source>
      <StringValueLength>1000</StringValueLength>
   </JSONThreatProtection>

   Perhatikan bahwa elemen <Source> mengarah ke request.. Artinya, error terjadi saat mengurai payload permintaan.

7. Tentukan jenis payload yang diuraikan dengan memeriksa permintaan API.

Anda dapat memeriksa konten payload permintaan dan header Content-Type dalam permintaan API. Dalam contoh perintah curl berikut, payload JSON digunakan.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Anda juga dapat memeriksa kebijakan yang gagal dan menentukan jenis payload yang sedang diuraikan. Dalam contoh skenario di atas, kebijakan JSON-Threat-Protection gagal. Ini menunjukkan bahwa payload harus dalam format JSON.

8. Validasi apakah payload dalam format yang benar. Jika payload tidak valid, Anda akan mendapatkan error ini.

9. Jika payload valid, tetapi Anda masih mendapatkan error seperti yang tercantum di bagian Pesan Error, maka penyebab error ini adalah payload diakses saat streaming diaktifkan.

   Bergantung pada payload yang diuraikan oleh kebijakan (seperti yang ditentukan pada langkah #6), periksa konten payload di alat Perekaman Aktivitas pada fase yang sesuai.

   Dalam contoh skenario, payload permintaan sedang diuraikan, jadi periksa fase "Request Received from Client" dalam rekaman aktivitas dan periksa Request Content.

   

   Jika Konten Permintaan ditemukan kosong seperti yang ditunjukkan pada screenshot di atas, meskipun Anda telah mengirim payload yang valid, maka hal ini menunjukkan bahwa kemungkinan penyebab masalah ini adalah streaming permintaan diaktifkan.

   Hal ini karena saat streaming diaktifkan, payload permintaan tidak akan muncul di rekaman aktivitas.

   Demikian pula, jika payload respons sedang diuraikan saat terjadi error, periksa konten respons pada fase "Respons diterima dari server target".

10. Selanjutnya, periksa definisi Proxy dan Endpoint Target, bergantung pada tempat kebijakan yang gagal digunakan dalam alur Proxy API. Verifikasi apakah streaming telah diaktifkan.

    Dalam contoh skenario, kebijakan yang gagal dieksekusi dalam alur permintaan Proxy (seperti yang ditentukan pada langkah #5 di atas); oleh karena itu, periksa Endpoint Proxy:

    <ProxyEndpoint name="default">
    ...
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <VirtualHost>secure</VirtualHost>
        <Properties>
          <Property name="response.streaming.enabled">true</Property>
          <Property name="request.streaming.enabled">true</Property>
        </Properties>
      </HTTPProxyConnection>
    </ProxyEndpoint>

    Seperti yang terlihat dalam contoh di atas, streaming permintaan telah diaktifkan seperti yang ditunjukkan oleh properti "request.streaming.enabled" yang ditetapkan ke benar (true).

    Oleh karena itu, penyebab error adalah penggunaan kebijakan JSONThreatProtection di Proxy API yang mengakses payload permintaan saat streaming diaktifkan. Hal ini menyebabkan error karena memicu buffering di Proxy API dan mengalahkan tujuan penggunaan streaming di Apigee Edge.

    Error ini mungkin tidak terlihat dengan payload yang lebih kecil, tetapi saat Anda menggunakan payload yang lebih besar, Anda dapat melihat error ini.

11. Anda dapat memverifikasi bahwa error 500 disebabkan oleh kebijakan dengan memeriksa nilai "X-Apigee-fault-source" dalam Fase "AX" (Data Analytics Dicatat) dalam rekaman aktivitas menggunakan langkah-langkah yang diberikan di bawah:
    1. Klik "AX" (Data Analytics Direkam) seperti yang ditunjukkan pada screenshot di bawah:

       

    2. Scroll ke bawah Detail Fase ke bagian "Header Error" dan tentukan nilai "X-Apigee-fault-code", "X-Apigee-fault-source" dan "X-Apigee-fault-policy" seperti yang ditunjukkan di bawah:

       

    3. Jika nilai "X-Apigee-fault-source" adalah "policy" seperti yang ditunjukkan pada gambar di atas, berarti error disebabkan karena kebijakan mengakses payload saat streaming diaktifkan.

Resolusi

Mengakses payload dengan streaming yang diaktifkan adalah antipola seperti yang dijelaskan dalam Antipola: Mengakses payload permintaan/respons saat streaming diaktifkan.

1. Jika Anda ingin memproses payload, Anda harus menonaktifkan streaming di Endpoint Proxy/Target dengan menghapus properti "request.streaming.enabled" and "response.streaming.enabled" seperti yang ditunjukkan dalam contoh ProxyEndpoint di bawah:

   <ProxyEndpoint name="default">
   ...
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <VirtualHost>secure</VirtualHost>
     </HTTPProxyConnection>
   </ProxyEndpoint>

   ATAU

2. Jika Anda ingin menggunakan streaming untuk Proxy API, jangan gunakan kebijakan apa pun di Proxy API yang mengakses payload permintaan/respons.

Catatan:

• Dalam playbook ini, kebijakan JSONThreatProtection digunakan untuk memproses payload permintaan dengan streaming yang diaktifkan dalam contoh skenario. Hal ini menyebabkan Error Server Internal 500 dengan error yang berbeda-beda.
• Error ini juga dapat terlihat dengan kebijakan seperti JSONToXML dan XMLToJSON, yang memproses payload permintaan atau respons saat streaming diaktifkan.
• Sebaiknya jangan gunakan kebijakan semacam itu di proxy yang memerlukan akses ke payload saat streaming diaktifkan.
• Tindakan ini merupakan antipola, seperti yang didokumentasikan dalam Antipola: Mengakses payload permintaan/respons saat streaming diaktifkan.

Mendiagnosis Masalah menggunakan Pemantauan API

Jika Anda adalah pengguna Private Cloud, lewati prosedur ini.

Pemantauan API memungkinkan Anda mengisolasi area masalah dengan cepat untuk mendiagnosis error, performa, dan masalah latensi serta sumbernya, seperti aplikasi developer, proxy API, target backend, atau platform API.

Ikuti skenario contoh yang menunjukkan cara memecahkan masalah 5xx dengan API Anda menggunakan Pemantauan API. Misalnya, Anda dapat menyiapkan pemberitahuan untuk menerima notifikasi saat jumlah Error 500 melebihi batas tertentu.

Jika Anda ingin mendapatkan notifikasi saat respons error 500 ditampilkan dari kebijakan, Anda harus menyiapkan pemberitahuan untuk kode status 500 dengan sumber kesalahan sebagai Proxy.

Mengumpulkan Informasi Diagnostik yang Wajib

Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut. Hubungi dan bagikan ke Dukungan Apigee.

Jika Anda adalah pengguna Public Cloud, berikan informasi berikut:

• Nama Organisasi
• Nama Lingkungan
• Nama Proxy API
• Lengkapi perintah curl beserta payload permintaan (jika ada) untuk mereproduksi error 500
• File rekaman aktivitas yang berisi permintaan dengan Error Server Internal 500
• Jika error 500 tidak terjadi saat ini, berikan jangka waktu dengan informasi zona waktu saat error 500 terjadi di masa lalu.

Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:

• Pesan error lengkap yang diamati untuk permintaan yang gagal
• Nama Organisasi, Nama Lingkungan, dan Nama Proxy API yang mengalami error 500
• Paket Proxy API
• Payload yang digunakan dalam permintaan (jika ada)
• File rekaman aktivitas yang berisi permintaan dengan Error Server Internal 500
• 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 500.