Halaman ini diterjemahkan oleh Cloud Translation API.

502 Gateway Buruk - TooBigBody

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

Gejala

Aplikasi klien mendapatkan kode status HTTP 502 Bad Gateway dengan kode error protocol.http.TooBigBody sebagai respons untuk panggilan API.

Pesan error

Aplikasi klien mendapatkan kode respons berikut:

HTTP/1.1 502 Bad Gateway

Selain itu, Anda mungkin melihat pesan error berikut:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Kemungkinan penyebab

Error ini terjadi jika ukuran payload yang dikirim oleh server target/backend ke Apigee Edge sebagai bagian respons HTTP lebih besar dari batas yang diizinkan di Apigee Edge.

Berikut adalah kemungkinan penyebab error:

Penyebab	Deskripsi	Petunjuk pemecahan masalah berlaku untuk
Ukuran payload respons melebihi batas yang diizinkan	Ukuran payload yang dikirim oleh server target/backend sebagai bagian dari respons HTTP ke Apigee adalah melebihi batas yang diizinkan di Apigee.	Pengguna Edge Public dan Private Cloud
Ukuran payload respons melebihi batas yang diizinkan setelah dekompresi	Ukuran payload yang dikirim dalam format terkompresi oleh server target/backend sebagai bagian dari HTTP respons terhadap Apigee lebih dari batas yang diizinkan jika didekompresi oleh Apigee.	Pengguna Edge Public dan Private Cloud

Langkah-langkah diagnosis umum

Gunakan salah satu alat/teknik berikut untuk mendiagnosis error ini:

Pemantauan API

Untuk mendiagnosis error menggunakan Pemantauan API:

Login ke UI Apigee Edge sebagai pengguna dengan peran yang sesuai.
Beralihlah ke organisasi tempat Anda ingin menyelidiki masalah tersebut.
Buka Analyze > Pemantauan API > Investigasi.
Pilih jangka waktu tertentu saat Anda melihat error.
Anda dapat memilih filter Proxy untuk mempersempit kode kesalahan.
Gambarkan Kode Kesalahan terhadap Waktu.
Pilih sel yang memiliki kode kesalahan protocol.http.TooBigBody sebagai yang ditampilkan di bawah ini:
Anda akan melihat informasi tentang kode kesalahan protocol.http.TooBigBody seperti yang ditunjukkan di bawah ini:
Klik View logs, lalu luaskan baris untuk permintaan yang gagal.
Dari jendela Logs, perhatikan detail berikut:
- Kode Status: 502
- Sumber Kesalahan: target
- Kode Kesalahan: protocol.http.TooBigBody.
Jika Sumber Kesalahan memiliki nilai target dan Kode Kesalahan memiliki nilai protocol.http.TooBigBody, maka itu menunjukkan bahwa permintaan respons dari server target/ backend memiliki ukuran payload respons lebih besar dari batas yang diizinkan di Apigee Edge.

Trace

Untuk mendiagnosis error menggunakan alat Trace:

Aktifkan sesi rekaman aktivitas dan:
- Tunggu hingga error 502 Bad Gateway terjadi, atau
- Jika Anda dapat mereproduksi masalah, lakukan panggilan API dan rekonstruksi 502 Bad Gateway error.
Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitasnya.
Menavigasi melalui berbagai fase pelacakan dan menemukan tempat terjadinya kegagalan.
Buka fase Error tepat setelah Respons diterima dari target server seperti yang ditunjukkan di bawah ini:

Perhatikan nilai error dari rekaman aktivitas:
- error: Body buffer overflow
- error.class: com.apigee.errors.http.server.BadGateway
Hal ini menunjukkan bahwa Apigee Edge (komponen Prosesor Pesan) menampilkan error segera setelah server menerima respons dari server backend karena ukuran payload yang melebihi batas batas tersebut.
Anda akan melihat kegagalan dalam fase Respons Dikirim ke Klien seperti yang ditunjukkan di bawah ini:
Perhatikan nilai error dari rekaman aktivitas. Contoh rekaman aktivitas di atas menunjukkan:
- error: 502 Bad Gateway
- Konten Error: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
Buka fase Respons Diterima dari server target seperti yang ditunjukkan di bawah untuk berbagai skenario:
Tidak terkompresi

Skenario #1: Payload Respons yang dikirim dalam bentuk tidak terkompresi

Perhatikan nilai error dari rekaman aktivitas:
- Respons diterima dari server target: 200 OK
- Durasi Konten (dari bagian Header Respons): ~11 MB
Terkompresi

Skenario #2: Meminta Payload yang dikirim dalam bentuk terkompresi

Perhatikan nilai error dari rekaman aktivitas:
- Respons diterima dari server target: 200 OK
- Content-Encoding: Jika Anda melihat header ini di Header Respons perhatikan nilainya. Misalnya, dalam contoh ini nilainya adalah gzip.
Catat Isi di bagian Konten Respons:
```
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
```
Catatan: Meskipun server target/backend mengirim 200, respons yang dikirim ke klien adalah 502 bersama dengan pesan error di atas dengan Apigee Edge.
Buka Fase AX (Data Analytics Dicatat) di trace, lalu klik Fase tersebut untuk melihat detail terkait.

Scroll ke bawah di Detail Fase ke bagian Pembacaan Variabel, lalu tentukan nilai target.received.content.length yang menunjukkan:

Ukuran sebenarnya dari payload respons saat dikirim dalam format yang tidak terkompresi dan
Ukuran payload respons setelah dekompresi oleh Apigee, saat payload dikirim dalam format terkompresi. Ini akan selalu sama dengan nilai parameter yang diizinkan maksimum (10 MB) dalam skenario ini.

Tidak terkompresi

Skenario #1: Payload Respons yang dikirim dalam bentuk tidak terkompresi

Perhatikan nilai target.received.content.length:

Header permintaan	Nilai
target.received.content.length	~11 MB

Terkompresi

Skenario #2: Meminta Payload yang dikirim dalam bentuk terkompresi

Perhatikan nilai target.received.content.length:

Header Permintaan	Nilai
target.received.content.length	~10 MB

Tabel berikut menjelaskan mengapa error 502 ditampilkan oleh Apigee dalam dua skenario berdasarkan nilai target.received.content.length:

Skenario	Nilai target.received.content.length	Alasan kegagalan
Payload Respons dalam format tidak terkompresi	~11 MB	Ukuran > batas yang diizinkan sebesar 10 MB
Payload Respons dalam format terkompresi	~10 MB	Batas ukuran terlampaui setelah dekompresi Catatan: Ukuran payload sebenarnya setelah dekompresi bisa lebih dari 10 MB. Namun, Apigee akan berhenti melakukan dekompresi segera setelah ukuran file data melebihi batas 10 MB (batas default) dan merespons dengan error.

NGINX

Untuk mendiagnosis error menggunakan log akses NGINX:

Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log akses NGINX untuk menentukan informasi penting tentang error 502 HTTP.
Periksa log akses NGINX:
```
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
```
Di mana: ORG, ENV, dan PORT# diganti dengan nilai sebenarnya.
Telusuri apakah terdapat Error 502 selama durasi tertentu (jika ada) masalah terjadi di masa lalu) atau jika ada permintaan yang masih gagal dengan 502.

Jika Anda menemukan error 502 dengan pencocokan X-Apigee-fault-code nilai protocol.http.TooBigBody, lalu tentukan nilai X-Apigee-fault-source.

Contoh error 502 dari log akses NGINX:

Contoh entri di atas dari log akses NGINX memiliki nilai berikut untuk X-Apigee- fault-code dan X-Apigee-fault-source:

Header Respons	Nilai
X-Apigee-fault-code	`protocol.http.TooBigBody`
X-Apigee-fault-source	`target`

Penyebab: Ukuran Payload Respons lebih besar dari batas yang diizinkan

Diagnosis

Tentukan Fault Code, Fault Source, dan Response Payload Size untuk error yang diamati menggunakan Pemantauan API, alat Trace, atau log akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #1.
Jika Fault Source memiliki nilai target, ini menunjukkan bahwa respons ukuran payload yang dikirim server target/backend ke Apigee lebih besar dari batas yang diizinkan di Apigee Edge.
Periksa Respons Payload Size seperti yang ditentukan di langkah 1.
- Jika ukuran payload > Batas maksimum 10 MB, maka itulah penyebab error ini.
- Jika ukuran payload ~10 MB diperbolehkan berada, maka mungkin saja respons payload diteruskan dalam format terkompresi. Buka Penyebab: Ukuran payload respons melebihi batas yang diizinkan setelah dekompresi.
Validasi bahwa ukuran payload respons memang > Batas maksimum 10 MB dengan memeriksa respons aktual menggunakan langkah-langkah berikut:
1. Jika Anda tidak memiliki akses ke permintaan sebenarnya yang dibuat ke server target/backend, lalu buka Resolution.
2. Jika Anda memiliki akses ke permintaan sebenarnya yang dilakukan ke server target/backend, maka lakukan langkah-langkah berikut:
  1. Jika Anda adalah pengguna Public Cloud/Private Cloud, buat permintaan langsung ke server backend dari server backend itu sendiri atau komputer lain dari tempat Anda diizinkan membuat permintaan ke server backend.
  2. Jika Anda adalah pengguna Private Cloud, Anda juga dapat membuat permintaan ke server backend dari salah satu Pemroses Pesan.
  3. Verifikasi ukuran payload yang diteruskan dalam respons dengan memeriksa Header Content-Length.
  4. Jika Anda menemukan bahwa ukuran payload lebih besar dari batas yang diizinkan di Apigee Edge, maka itulah penyebab masalah performa.
Contoh Respons dari server backend:
```
curl -v https://BACKENDSERVER-HOSTNAME/testfile
```
```
* About to connect() to 10.14.0.10 port 9000 (#0)
*   Trying 10.14.0.10...
* Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
> GET /testfile HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.14.0.10:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 11534336
< Content-Type: application/octet-stream
< Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
< Date: Wed, 30 Jun 2021 09:22:41 GMT
<
----snipped----
<Response Body>
```
Dalam contoh di atas, Anda dapat melihat bahwa Content-Length: 11534336 (which is ~11 MB) yang merupakan penyebab error ini karena melebihi batas yang diizinkan di Apigee Edge.

Resolusi

Lihat Resolusi.

Penyebab: Ukuran Payload Respons melebihi batas yang diizinkan setelah dekompresi

Jika payload respons dikirim dalam format terkompresi dan header respons Content-Encoding disetel ke gzip, Apigee mendekompresi respons payload. Selama proses dekompresi, jika Apigee mendapati ukuran payload lebih besar daripada batas yang diizinkan di Apigee Edge., maka akan berhenti lebih jauh dekompresi dan segera merespons kembali dengan 502 Bad Gateway dan kode error protocol.http.TooBigBody.

Diagnosis

Tentukan Kode Kesalahan, Sumber Kesalahan, dan Ukuran Payload Respons untuk error yang diamati menggunakan log Pemantauan API, Alat Pelacak, atau Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #2.
Jika Fault Source memiliki nilai target, ini menunjukkan bahwa ukuran payload respons yang dikirim aplikasi target/backend ke Apigee lebih besar dari batas yang diizinkan di Apigee Edge.
Periksa Respons Payload Size seperti yang ditentukan di langkah 1.
- Jika ukuran payload > Batas 10 MB yang diizinkan, maka itulah penyebab error.
- Jika ukuran {i>payload<i} ~ 10 MB merupakan batas yang diizinkan, maka ada kemungkinan bahwa payload respons diteruskan dalam format terkompresi. Dalam hal ini, periksa ukuran file yang tidak dikompresi payload respons.
Anda dapat memvalidasi apakah respons dari target/backend dikirim dalam format terkompresi dan ukuran yang tidak dikompresi lebih besar dari batas yang diizinkan menggunakan salah satu metode:
Trace

Menggunakan alat Trace:
1. Jika Anda telah merekam pelacakan permintaan yang gagal, lihat langkah-langkah yang dijelaskan dalam Trace dan
  1. Tentukan nilai target.received.content.length
  2. Verifikasi apakah permintaan dari klien berisi Header Content-Encoding: gzip
2. Jika nilai target.received.content.length sekitar 10 MB yang diizinkan dan header respons Content-Encoding: gzip, maka akan menjadi penyebab kesalahan ini.
Permintaan sebenarnya

Menggunakan permintaan yang sebenarnya:
1. Jika Anda tidak memiliki akses ke permintaan sebenarnya yang dibuat ke server target/backend, lalu buka Resolution.
2. Jika Anda memiliki akses ke permintaan sebenarnya yang dilakukan ke server target/backend, maka lakukan langkah-langkah berikut:
  1. Verifikasi ukuran payload yang diteruskan dalam respons beserta Header Content-Encoding yang dikirim dalam respons.
  2. Jika Anda mendapati bahwa header respons Content-Encoding disetel ke gzip dan ukuran payload yang tidak dikompresi lebih dari batas yang diizinkan di Apigee Edge, maka itulah penyebab {i>error<i} ini.
    Contoh respons yang diterima dari server backend:
    
    curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
    
    * About to connect() to 10.1.0.10 port 9000 (#0) * Trying 10.1.0.10... * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0) > GET /testzippedfile.gz HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 10.1.0.10:9000 > Accept: */* > < HTTP/1.1 200 OK < Accept-Ranges: bytes < Content-Encoding: gzip < Content-Type: application/x-gzip < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT < Testheader: test < Date: Wed, 07 Jul 2021 10:14:16 GMT < Transfer-Encoding: chunked < ----snipped---- <Response Body>
    
    Dalam kasus di atas, header Content-Encoding: gzip dikirim dan ukuran file testzippedfile.gz dalam respons kurang dari batasnya, namun ukuran file testzippedfile yang tidak dikompresi ~15 MB.
Catatan: Jika Anda tidak memiliki akses ke permintaan dan respons yang sebenarnya dari server backend, Anda dapat memeriksa log server backend, oleh server backend, dan memverifikasi ukuran file yang dikompresi.
Log Pemroses Pesan

Menggunakan log Pemroses Pesan:

Catatan: Petunjuk di bagian ini hanya untuk pengguna Edge Private Cloud.
1. Jika Anda pengguna Private Cloud, Anda dapat menggunakan log Pemroses Pesan untuk menentukan informasi penting tentang error 502 HTTP.
2. Memeriksa log Pemroses Pesan
  
  /opt/apigee/var/log/edge-message-processor/logs/system.log
3. Telusuri untuk mengetahui apakah terdapat error 502 selama durasi tertentu atau tidak (jika masalah terjadi di masa lalu) atau jika ada permintaan yang masih gagal dengan 502. Anda dapat menggunakan string penelusuran berikut:
```
grep -ri "chunkCount"
```
```
grep -ri "BadGateway: Body buffer overflow"
```
4. Anda akan menemukan baris dari system.log yang mirip seperti yang ditunjukkan di bawah ini (TotalRead dan chunkCount dapat berbeda dalam kasus Anda):
```
2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
TotalRead 10489856 chunkCount 2571

2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
HTTPClient$Context.onInputException() :
ClientInputChannel(ClientChannel[Connected:
Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
isOpen=true).onExceptionRead exception: {}
com.apigee.errors.http.server.BadGateway: Body buffer overflow

2021-07-07 09:40:47,012  NIOThread@7 ERROR
ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
Body buffer overflow)
```
5. Selama proses dekompresi, segera setelah Pemroses Pesan menentukan total byte baca adalah > 10 MB, akan menghentikan dan mencetak baris berikut:
  
  Message is too large. TotalRead 10489856 chunkCount 2571
  
  Ini menyiratkan bahwa Response Payload Size lebih dari 10 MB dan Apigee menampilkan error saat ukuran mulai melebihi batas 10 MB dengan kode kesalahan sebagai protocol.http.TooBigBody
  
  Catatan: Anda akan melihat baris di atas dalam log Pemroses Pesan, meskipun Anda mengirim payload respons dalam format yang tidak dikompresi. Satu-satunya perbedaan adalah TotalRead akan berisi ukuran sebenarnya dari payload permintaan yang yang lebih besar.

Resolusi

Perbaiki ukuran

Opsi #1 [Direkomendasikan]: Perbaiki aplikasi server target agar tidak mengirim ukuran payload yang melebihi batas Apigee

Menganalisis alasan server target tertentu mengirim ukuran respons / payload melebihi batas yang diizinkan sebagaimana ditetapkan dalam Batas.
Jika tidak diinginkan, modifikasi aplikasi server target Anda agar mengirim ukuran respons / payload kurang dari batas yang diizinkan.
Jika Anda menginginkannya dan Anda ingin mengirimkan respons/payload lebih dari yang diizinkan membatasi, lanjutkan ke opsi berikutnya.

Pola URL yang ditandatangani

Opsi #2 [Direkomendasikan]: Gunakan pola URL yang ditandatangani dalam JavaInfo Apigee

Untuk payload yang lebih besar dari 10 MB, Apigee merekomendasikan penggunaan pola URL yang ditandatangani dalam Info Java Apigee, yang diilustrasikan oleh Edge Keterangan: Contoh Generator URL Bertanda Tangan di GitHub.

Streaming

Opsi no. 3: Gunakan Streaming

Jika proxy API perlu menangani permintaan dan/atau respons yang sangat besar, Anda dapat aktifkan streaming di Apigee.

CwC

Opsi #4: Gunakan properti CwC untuk meningkatkan batas buffer

Opsi ini harus digunakan hanya ketika Anda tidak dapat menggunakan opsi yang direkomendasikan sebagai mungkin ada masalah performa jika ukuran default diperbesar.

Apigee menyediakan CwC yang memungkinkannya meningkatkan ukuran payload permintaan dan respons batas tersebut. Untuk mengetahui detailnya, lihat Menetapkan batas ukuran pesan di Router atau Pemroses Pesan.

Batas

Apigee mengharapkan aplikasi klien dan server backend tidak mengirim ukuran payload lebih besar dari batas yang diizinkan seperti yang didokumentasikan untuk Request/response size di Batas Edge Apigee.

Jika Anda adalah pengguna Cloud Publik, batas maksimum untuk permintaan dan respons ukuran payload seperti yang didokumentasikan untuk Request/response size di Batasan Edge Apigee.
Jika Anda adalah pengguna Private Cloud , Anda mungkin telah mengubah ukuran maksimum default batas ukuran payload permintaan dan respons (meskipun bukan praktik yang direkomendasikan). Anda dapat menentukan batas ukuran payload permintaan maksimum dengan mengikuti petunjuk di Cara memeriksa batas saat ini.

Bagaimana cara memeriksa batas saat ini?

Bagian ini menjelaskan cara memverifikasi bahwa properti HTTPResponse.body.buffer.limit telah diperbarui dengan nilai baru di Pesan Prosesor.

Di mesin Pemroses Pesan, telusuri properti HTTPResponse.body.buffer.limit di direktori /opt/apigee/edge-message- processor/conf dan periksa untuk melihat nilai yang telah ditetapkan seperti yang ditunjukkan di bawah ini:
```
grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
```

Contoh hasil dari perintah di atas adalah sebagai berikut:

/opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

Pada contoh {i>output<i} di atas, perhatikan bahwa properti HTTPResponse.body.buffer.limit telah ditetapkan dengan nilai 10m di http.properties.

Hal ini menunjukkan bahwa batas ukuran payload permintaan yang dikonfigurasi di Apigee untuk Private Cloud berukuran 10 MB.

Jika Anda masih memerlukan bantuan dari Dukungan Apigee, buka Harus mengumpulkan informasi diagnostik.

Harus mengumpulkan informasi diagnostik

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
Menyelesaikan perintah curl yang digunakan untuk mereproduksi error 502
File rekaman aktivitas untuk permintaan API
Lengkapi output respons dari server target/backend beserta ukuran payload

Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:

Pesan error lengkap yang diamati untuk permintaan yang gagal
Nama organisasi
Nama lingkungan
Paket Proxy API
File pelacakan untuk permintaan API yang gagal
Menyelesaikan perintah curl yang digunakan untuk mereproduksi error 502
Lengkapi output respons dari server target/backend beserta ukuran payload
Log akses NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

Di mana: ORG, ENV, dan PORT# diganti dengan nilai aktual.
Log sistem Pemroses Pesan /opt/apigee/var/log/edge-message-processor/logs/system.log

502 Gateway Buruk - TooBigBody

Gejala

Pesan error

Kemungkinan penyebab

Langkah-langkah diagnosis umum

Pemantauan API

Trace

Tidak terkompresi

Terkompresi

Tidak terkompresi

Terkompresi

NGINX

Penyebab: Ukuran Payload Respons lebih besar dari batas yang diizinkan

Diagnosis

Resolusi

Penyebab: Ukuran Payload Respons melebihi batas yang diizinkan setelah dekompresi

Diagnosis

Trace

Permintaan sebenarnya

Log Pemroses Pesan

Resolusi

Perbaiki ukuran

Pola URL yang ditandatangani

Streaming

CwC

Batas

Bagaimana cara memeriksa batas saat ini?

Harus mengumpulkan informasi diagnostik