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 Error Server Internal untuk panggilan API.

Pesan error

Aplikasi klien mungkin menerima respons error seperti yang ditunjukkan di bawah ini:

HTTP/1.1 500 Internal Server Error

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 sejumlah penyebab yang berbeda. Playbook ini berfokus pada 500 Internal Server Error yang disebabkan karena mengakses permintaan/respons payload 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 Edge Private dan Cloud Publik

Penyebab: Mengakses Payload dengan Streaming Aktif

Diagnosis

Prosedur #1: Menggunakan Rekaman Aktivitas

Mengaktifkan rekaman aktivitas , dan melakukan panggilan API untuk mereproduksi masalah - 500 Internal Server Error.
Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitasnya.
Menavigasi berbagai fase pelacakan dan menemukan tempat terjadinya kegagalan.
Error ini mungkin terjadi saat kebijakan mengurai payload permintaan/respons.
Berikut contoh screenshot rekaman aktivitas yang menampilkan JSONThreatProtection policy gagal dengan error "Expecting } at line 1":

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

Kebijakan yang Gagal: JSONThreatProtection

Alur: Permintaan Proxy

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

Dalam contoh skenario, periksa kebijakan JSONThreatProtection bernama JSON-Threat-Protection yang gagal dan memeriksa 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, terjadi error saat mengurai payload permintaan.

Tentukan jenis payload yang diuraikan dengan memeriksa permintaan API.

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

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

Catatan: Jika payload besar, Anda dapat menggunakan pemformat online mana pun untuk memvalidasi format payload.
Jika payload valid, tetapi Anda masih mendapatkan error seperti yang tercantum dalam Pesan Error, kemudian penyebab error ini adalah bahwa {i>payload<i} sedang diakses saat {i>streaming <i}diaktifkan.

Bergantung pada payload yang diuraikan oleh kebijakan (sebagaimana ditentukan di langkah #6), memeriksa isi {i>payload<i} di alat Trace dalam fase yang sesuai.

Dalam contoh skenario, payload permintaan sedang diuraikan, jadi periksa Fase "Permintaan Diterima dari Klien" dalam rekaman aktivitas dan memeriksa Minta Konten.

Jika Konten Permintaan kosong seperti yang ditampilkan dalam screenshot di atas, meskipun Anda telah mengirim payload yang valid, lalu yang menunjukkan bahwa kemungkinan penyebab masalah ini mengaktifkan permintaan streaming.

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

Demikian pula, jika payload respons diuraikan saat terjadi error, periksa konten respons dalam fase "Respons diterima dari server target".
Selanjutnya, periksa definisi Proxy dan Endpoint Target berdasarkan tempat kegagalan kebijakan ini digunakan dalam alur Proxy API. Verifikasi apakah streaming telah diaktifkan.

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

Oleh karena itu, penyebab error adalah menggunakan kebijakan JSONThreatProtection di Proxy API yang mengakses {i>payload <i}permintaan saat {i>streaming <i}diaktifkan. Hal ini menyebabkan kesalahan karena memicu buffering di Proxy API dan menggagalkan tujuan penggunaan streaming di Apigee Edge.

Kesalahan ini mungkin tidak terlihat dengan {i>payload<i} yang lebih kecil, tetapi ketika Anda menggunakan {i>payload<i} yang lebih besar, Anda dapat melihat error tersebut.
Anda dapat memverifikasi bahwa error 500 disebabkan oleh kebijakan dengan memeriksa nilainya "X-Apigee-fault-source" dalam "AX" (Data Analytics Direkam) Fase dalam rekaman aktivitas menggunakan langkah-langkah yang diberikan di bawah:
1. Klik Fase "KAK" (Data Analytics Dicatat) seperti yang ditampilkan dalam screenshot di bawah:
2. Scroll ke bawah Detail Fase ke "Header Error" dan menentukan 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, maka hal itu menunjukkan bahwa {i>error <i}disebabkan karena kebijakan yang mengakses payload ketika streaming diaktifkan.

Resolusi

Mengakses payload dengan streaming yang diaktifkan adalah anti-pola seperti yang dijelaskan di Antipola: Mengakses payload permintaan/respons saat streaming diaktifkan.

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:
```
<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 dalam contoh skenario. Hal ini menyebabkan 500 Error Server Internal dengan error yang berbeda.
Error ini juga dapat dilihat dengan 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 ketika streaming diaktifkan.
Melakukan hal tersebut adalah 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 masalah error, performa, dan latensi serta sumbernya, seperti aplikasi developer, proxy API, target backend, atau platform API.

Ikuti contoh skenario yang menunjukkan cara memecahkan masalah 5xx dengan API menggunakan Pemantauan API. Misalnya, Anda mungkin ingin menyiapkan sebuah pemberitahuan yang akan muncul saat jumlah 500 Error melebihi batas tertentu.

Jika Anda ingin mendapatkan notifikasi saat respons error 500 ditampilkan dari kebijakan, Anda harus menyiapkan pemberitahuan untuk 500 status code dengan fault source sebagai Proxy.

Harus Mengumpulkan Informasi Diagnostik

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

Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:

Nama Organisasi
Nama Lingkungan
Nama Proxy API
Selesaikan perintah curl beserta payload permintaan (jika ada) untuk mereproduksi error 500
File rekaman aktivitas yang berisi permintaan dengan 500 Error Server Internal
Jika error 500 saat ini tidak terjadi, berikan jangka waktu dengan informasi zona waktu saat terjadi error 500 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 lihat memiliki 500 error
Paket Proxy API
Payload yang digunakan dalam permintaan (jika ada)
File rekaman aktivitas yang berisi permintaan dengan 500 Error Server Internal
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 500.