Halaman ini diterjemahkan oleh Cloud Translation API.

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 mungkin menerima respons error seperti yang ditunjukkan di bawah ini:

HTTP/1.1 500 Internal Server Error

Pesan ini mungkin diikuti dengan pesan {i>error<i} seperti ini:

{
   "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

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

Cause	Deskripsi	Siapa yang dapat melakukan langkah-langkah pemecahan masalah
Mengakses Payload dengan Streaming Diaktifkan	Terjadi error karena payload permintaan/respons diakses saat streaming diaktifkan.	Pengguna Cloud Pribadi dan Publik Edge

Penyebab: Mengakses Payload dengan Streaming Diaktifkan

Diagnosis

Prosedur #1: Menggunakan Trace

Aktifkan sesi pelacakan, dan buat panggilan API untuk memunculkan kembali masalah - 500 Internal Server Error.
Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitas.
Jelajahi berbagai fase rekaman aktivitas dan temukan lokasi terjadinya kegagalan.
Error ini mungkin terjadi saat kebijakan mengurai payload permintaan/respons.
Berikut adalah contoh screenshot trace yang menampilkan kebijakan JSONThreatProtection yang gagal dengan error "Expecting } pada baris 1":

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

Kebijakan yang Gagal: JSONThreatProtection

Alur: Permintaan Proxy

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

Pada contoh skenario, periksa kebijakan JSONThreatProtection bernama JSON-Threat-Protection yang telah gagal, lalu 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.

Tentukan jenis payload yang diurai dengan memeriksa permintaan API.

Anda dapat memeriksa konten payload permintaan dan header Content-Type di 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 diurai. Dalam contoh skenario di atas, kebijakan JSON-Threat-Protection gagal. Hal ini menunjukkan bahwa payload harus dalam format JSON.

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

Catatan: Jika payload-nya besar, Anda dapat menggunakan pemformat online apa pun untuk memvalidasi format payload.
Jika payload valid, tetapi Anda masih mendapatkan error seperti yang tercantum di bagian Pesan Error, penyebab error ini adalah payload sedang diakses saat streaming diaktifkan.

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

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

Jika Konten Permintaan ternyata kosong seperti yang ditampilkan pada screenshot di atas, meskipun Anda telah mengirim payload yang valid, berarti 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 diuraikan saat error terjadi, periksa konten respons pada fase "Respons diterima dari server target".
Selanjutnya, periksa definisi Proxy dan Target Endpoint bergantung pada tempat kebijakan yang gagal digunakan dalam alur Proxy API. Verifikasi apakah streaming telah diaktifkan.

Dalam contoh skenario, kebijakan yang gagal dijalankan di alur permintaan Proxy (seperti yang ditentukan di 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 pada contoh di atas, streaming permintaan telah diaktifkan seperti yang ditunjukkan oleh properti "request.streaming.enabled" yang ditetapkan ke true.

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

Error ini mungkin tidak terlihat pada payload yang lebih kecil, tetapi saat Anda menggunakan payload yang lebih besar, Anda dapat melihat error ini.
Anda dapat memverifikasi bahwa error 500 disebabkan oleh kebijakan ini dengan memeriksa nilai "X-Apigee-fault-source" di Fase "AX" (Data Analytics Dicatat) dalam pelacakan menggunakan langkah-langkah yang diberikan di bawah ini:
1. Klik Fase "AX" (Data Analytics Dicatat) seperti yang ditunjukkan pada screenshot di bawah:
2. Scroll ke bawah Detail Fase ke bagian "Error Headers" dan tentukan nilai "X-Apigee-fault-code", "X-Apigee-fault-source" dan "X-Apigee-fault-policy" seperti yang ditunjukkan di bawah ini:
3. Jika nilai "X-Apigee-fault-source" adalah "policy" seperti yang ditunjukkan pada gambar di atas, hal ini menunjukkan bahwa error disebabkan oleh kebijakan yang mengakses payload saat streaming diaktifkan.

Resolusi

Mengakses payload dengan streaming yang diaktifkan adalah antipola seperti yang dijelaskan dalam Antipattern: Access the request/response payload when streaming is enabled.

Jika ingin memproses payload, Anda harus menonaktifkan streaming di Proxy/Target Endpoint dengan menghapus properti "request.streaming.enabled" and "response.streaming.enabled"seperti yang ditunjukkan pada contoh ProxyEndpoint di bawah ini:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
ATAU
Jika Anda ingin menggunakan streaming untuk Proxy API Anda, 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 500 Internal Server Error dengan error yang berbeda-beda.
Error ini juga dapat dilihat pada kebijakan seperti JSONToXML dan XMLToJSON, yang memproses payload permintaan atau respons saat streaming diaktifkan.
Kami sangat menyarankan untuk tidak menggunakan kebijakan semacam itu di proxy yang memerlukan akses ke payload saat streaming diaktifkan.
Melakukannya adalah anti-pola, seperti yang didokumentasikan dalam Antipattern: 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 masalah error, performa, dan latensi beserta sumbernya, seperti aplikasi developer, proxy API, target backend, atau platform API.

Ikuti contoh skenario yang menunjukkan cara memecahkan masalah 5xx pada API Anda menggunakan API Monitoring. Misalnya, Anda mungkin ingin menyiapkan pemberitahuan yang akan dikirimkan saat jumlah 500 Error 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.

Harus Mengumpulkan Informasi Diagnostik

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

Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:

Nama Organisasi
Nama Lingkungan
Nama Proxy API
Menyelesaikan perintah curl beserta payload permintaan (jika ada) untuk mereproduksi error 500
File detail migrasi yang berisi permintaan dengan Error Server Internal 500
Jika error 500 tidak terjadi saat ini, maka 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
Organisasi, Nama Lingkungan, dan Nama Proxy API yang error 500-nya Anda amati
Paket Proxy API
Payload yang digunakan dalam permintaan (jika ada)
File detail migrasi yang berisi permintaan dengan Error Server Internal 500
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 500 terjadi.