คุณกำลังดูเอกสารประกอบ Apigee Edge
ไปที่
เอกสารประกอบเกี่ยวกับ Apigee X. ข้อมูล
ลักษณะปัญหา
แอปพลิเคชันไคลเอ็นต์ได้รับรหัสสถานะ HTTP 502 Bad Gateway
พร้อมรหัสข้อผิดพลาด
protocol.http.TooBigBody
เป็นการตอบกลับสำหรับการเรียก API
ข้อความแสดงข้อผิดพลาด
แอปพลิเคชันไคลเอ็นต์ได้รับโค้ดตอบกลับต่อไปนี้
HTTP/1.1 502 Bad Gateway
นอกจากนี้ คุณอาจสังเกตเห็นข้อความแสดงข้อผิดพลาดต่อไปนี้
{ "fault":{ "faultstring":"Body buffer overflow", "detail":{ "errorcode":"protocol.http.TooBigBody" } } }
สาเหตุที่เป็นไปได้
ข้อผิดพลาดนี้เกิดขึ้นหากขนาดเพย์โหลดที่ส่งโดยเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ไปยัง Apigee Edge เป็นส่วนหนึ่ง ของการตอบสนอง HTTP มากกว่าขีดจำกัดที่อนุญาตใน Apigee Edge
สาเหตุที่เป็นไปได้ของข้อผิดพลาดมีดังนี้
สาเหตุ | คำอธิบาย | วิธีการแก้ปัญหาสำหรับ |
---|---|---|
ขนาดเพย์โหลดการตอบกลับเกินขีดจำกัดที่อนุญาต | ขนาดเพย์โหลดที่ส่งโดยเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์เพื่อเป็นส่วนหนึ่งของการตอบสนอง HTTP ไปยัง Apigee คือ เกินขีดจำกัดที่อนุญาตใน Apigee | ผู้ใช้ Edge สาธารณะและ Private Cloud |
ขนาดเพย์โหลดการตอบกลับเกินขีดจำกัดที่อนุญาตหลังจาก การยกเลิกการบีบอัด | ขนาดเพย์โหลดที่ส่งในรูปแบบที่บีบอัดโดยเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์โดยเป็นส่วนหนึ่งของ HTTP การตอบสนองต่อ Apigee เกินขีดจำกัดที่อนุญาตเมื่อยกเลิกการบีบอัดโดย Apigee | ผู้ใช้ Edge สาธารณะและ Private Cloud |
ขั้นตอนการวินิจฉัยทั่วไป
ใช้เครื่องมือ/เทคนิคต่อไปนี้เพื่อวินิจฉัยข้อผิดพลาดนี้
การตรวจสอบ API
วิธีวินิจฉัยข้อผิดพลาดโดยใช้การตรวจสอบ API
- ลงชื่อเข้าใช้ Apigee Edge UI ในฐานะผู้ใช้ที่มี บทบาทที่เหมาะสม
เปลี่ยนเป็นองค์กรที่ต้องการตรวจสอบปัญหา
- ไปที่ วิเคราะห์ > การตรวจสอบ API > หน้าตรวจสอบ
- เลือกกรอบเวลาที่คุณพบข้อผิดพลาด
- คุณอาจเลือกตัวกรองพร็อกซีเพื่อจำกัดรหัสข้อผิดพลาดให้แคบลง
- พล็อตรหัสข้อผิดพลาดเทียบกับเวลา
เลือกเซลล์ที่มีรหัสข้อผิดพลาด
protocol.http.TooBigBody
เป็น แสดงอยู่ด้านล่างคุณจะเห็นข้อมูลเกี่ยวกับรหัสข้อผิดพลาด
protocol.http.TooBigBody
ตามที่แสดงด้านล่าง:คลิก ดูบันทึก และขยายแถวสำหรับคำขอที่ล้มเหลว
- จากหน้าต่างบันทึก โปรดสังเกตรายละเอียดต่อไปนี้
- รหัสสถานะ:
502
- แหล่งที่มาของข้อผิดพลาด:
target
- รหัสข้อผิดพลาด:
protocol.http.TooBigBody
- รหัสสถานะ:
- หากแหล่งที่มาของข้อผิดพลาดมีค่า
target
และรหัสข้อผิดพลาด มีค่าprotocol.http.TooBigBody
ซึ่งแสดงว่า HTTP การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย/ แบ็กเอนด์มีขนาดเพย์โหลดการตอบกลับใหญ่กว่า อนุญาตขีดจำกัดใน Apigee Edge แล้ว
Trace
วิธีวินิจฉัยข้อผิดพลาดโดยใช้เครื่องมือติดตาม
- เปิดใช้เซสชันการติดตาม และดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้
- รอให้ข้อผิดพลาด
502 Bad Gateway
เกิดขึ้น หรือ - หากคุณทำให้เกิดปัญหาซ้ำได้ ให้เรียกใช้ API และทำซ้ำ
ข้อผิดพลาด
502 Bad Gateway
รายการ
- รอให้ข้อผิดพลาด
- เลือกคำขอที่ไม่สำเร็จรายการหนึ่งและตรวจสอบการติดตาม
- ดำเนินการตามขั้นตอนต่างๆ ของการติดตามและค้นหาตำแหน่งที่เกิดข้อผิดพลาด
ไปที่ระยะข้อผิดพลาดหลังจากการตอบสนองที่ได้รับจากเป้าหมาย เซิร์ฟเวอร์ตามที่แสดงด้านล่าง
บันทึกค่าของข้อผิดพลาดจากการติดตามดังนี้
- ข้อผิดพลาด:
Body buffer overflow
- error.class:
com.apigee.errors.http.server.BadGateway
ซึ่งหมายความว่า Apigee Edge (คอมโพเนนต์ตัวประมวลผลข้อความ) แสดงข้อผิดพลาดในทันที จะได้รับการตอบสนองจากเซิร์ฟเวอร์แบ็กเอนด์เนื่องจากขนาดเพย์โหลดเกินขีดจำกัดที่อนุญาต ขีดจำกัด
- ข้อผิดพลาด:
คุณจะเห็นความล้มเหลวในช่วงตอบกลับไปยังไคลเอ็นต์ดังที่แสดงด้านล่าง
- จดค่าของข้อผิดพลาดจากการติดตาม การติดตามตัวอย่างข้างต้นแสดงสิ่งต่อไปนี้
- ข้อผิดพลาด:
502 Bad Gateway
- เนื้อหาข้อผิดพลาด:
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
- ข้อผิดพลาด:
ไปยังระยะการตอบกลับที่ได้รับจากเซิร์ฟเวอร์เป้าหมายดังที่แสดงด้านล่างสำหรับสถานการณ์ต่างๆ
ไม่บีบอัด
สถานการณ์ที่ 1: ส่งเพย์โหลดการตอบกลับในรูปแบบที่ไม่ได้บีบอัด
บันทึกค่าของข้อผิดพลาดจากการติดตามดังนี้
- การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย:
200 OK
- ความยาวของเนื้อหา (จากส่วนส่วนหัวการตอบกลับ): ~11 MB
ขนาดไฟล์ที่บีบอัด
สถานการณ์ที่ 2: ส่งเพย์โหลดคำขอในรูปแบบที่บีบอัด
บันทึกค่าของข้อผิดพลาดจากการติดตามดังนี้
- การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย:
200 OK
- Content-Encoding: หากคุณเห็นส่วนหัวนี้ในContent-Encoding
ให้สังเกตค่า ตัวอย่างเช่น ในตัวอย่างนี้ค่าคือ
gzip
- การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย:
จดบันทึกเนื้อหาในส่วนเนื้อหาการตอบกลับดังนี้
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
ไปที่ระยะ AX (บันทึกข้อมูลของ Analytics) ในการติดตามและคลิก เพื่อดูรายละเอียดที่เกี่ยวข้อง
- เลื่อนลงในรายละเอียดระยะในส่วนการอ่านตัวแปร และระบุ
ของ
target.received.content.length
ซึ่งระบุข้อมูลต่อไปนี้- ขนาดจริงของเพย์โหลดการตอบกลับเมื่อส่งในรูปแบบที่ไม่ได้บีบอัด และ
- ขนาดของเพย์โหลดการตอบสนองเมื่อยกเลิกการบีบอัดโดย Apigee เมื่อเพย์โหลดคือ ที่ส่งในรูปแบบที่บีบอัด ซึ่งจะเป็นค่าเดียวกันกับค่าของรายการที่อนุญาตเสมอ (10 MB) ในสถานการณ์นี้
ไม่บีบอัด
สถานการณ์ที่ 1: ส่งเพย์โหลดการตอบกลับในรูปแบบที่ไม่ได้บีบอัด
ดูค่าของ target.received.content.length ดังนี้
ส่วนหัวของคำขอ ค่า target.received.content.length ~11 MB ขนาดไฟล์ที่บีบอัด
สถานการณ์ที่ 2: ส่งเพย์โหลดคำขอในรูปแบบที่บีบอัด
ดูค่าของ target.received.content.length ดังนี้
ส่วนหัวของคำขอ ค่า target.received.content.length ~10 MB ตารางต่อไปนี้อธิบายสาเหตุที่ Apigee แสดงข้อผิดพลาด
502
ทั้ง 2 กรณีขึ้นอยู่กับค่าของ target.received.content.length ดังนี้สถานการณ์ ค่าของ target.received.content.length เหตุผลที่ล้มเหลว เพย์โหลดการตอบกลับในรูปแบบที่ไม่บีบอัด ~11 MB ขนาด > ขีดจำกัด 10 MB ที่อนุญาต เพย์โหลดการตอบกลับในรูปแบบที่บีบอัด ~10 MB เกินขนาดที่จำกัดเมื่อคลายการบีบอัด
NGINX
วิธีวินิจฉัยข้อผิดพลาดโดยใช้บันทึกการเข้าถึง NGINX
- หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถใช้บันทึกการเข้าถึง NGINX ในการระบุ
ข้อมูลคีย์เกี่ยวกับข้อผิดพลาด HTTP
502
ตรวจสอบบันทึกการเข้าถึง NGINX ดังต่อไปนี้
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
ที่ไหน: ระบบจะแทนที่ ORG, ENV และ PORT# ด้วยค่าจริง
- ค้นหาเพื่อดูว่ามีข้อผิดพลาด
502
รายการเกิดขึ้นในช่วงระยะเวลาหนึ่งๆ หรือไม่ (หาก เกิดขึ้นในอดีต) หรือหากมีคำขอที่ยังคงล้มเหลว502
- หากคุณพบข้อผิดพลาด
502
ที่มีการจับคู่ X-Apigee-fault-code ค่าของprotocol.http.TooBigBody
แล้วระบุค่าของ X-Apigee-fault-source.ตัวอย่างข้อผิดพลาด 502 จากบันทึกการเข้าถึง NGINX
ตัวอย่างรายการข้างต้นจากบันทึกการเข้าถึง NGINX มีค่าต่อไปนี้สำหรับ X-Apigee- fault-code และ X-Apigee-fault-source:
ส่วนหัวการตอบกลับ ค่า X-Apigee-fault-code protocol.http.TooBigBody
X-Apigee-fault-source target
สาเหตุ: ขนาดเพย์โหลดการตอบกลับเกินขีดจำกัดที่อนุญาต
การวินิจฉัย
- กำหนดรหัสข้อผิดพลาด แหล่งที่มาของข้อผิดพลาด และขนาดของเพย์โหลดการตอบกลับสำหรับ ข้อผิดพลาดที่พบเมื่อใช้การตรวจสอบ API, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไปจากสถานการณ์ที่ 1
- หากแหล่งที่มาของข้อผิดพลาดมีค่า
target
แสดงว่าการตอบสนอง ขนาดเพย์โหลดที่ส่งโดยเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ไปยัง Apigee ใหญ่กว่า ขีดจำกัดที่อนุญาตใน Apigee Edge - ตรวจสอบขนาดเพย์โหลดการตอบกลับตามที่ระบุจากขั้นตอนที่ 1
- หากขนาดเพย์โหลด > ไฟล์ต้องมีขนาดไม่เกิน 10 MB ดังนี้
- หากเพย์โหลดมีขนาดไม่เกิน 10 MB ที่อนุญาต ก็เป็นไปได้ว่าการตอบสนอง ระบบจะส่งเพย์โหลดในรูปแบบที่บีบอัด ไปที่ สาเหตุ: ขนาดเพย์โหลดการตอบกลับเกินขีดจำกัดที่อนุญาตหลังจากการยกเลิกการบีบอัด
- ตรวจสอบว่าขนาดเพย์โหลดการตอบกลับจริง > ไม่เกิน 10 MB โดยตรวจสอบ
คำตอบจริงตามขั้นตอนต่อไปนี้
- หากคุณไม่มีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ ให้ไปที่ความละเอียด
- หากคุณมีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์
ให้ทำตามขั้นตอนต่อไปนี้
- หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ/Private Cloud ให้ส่งคำขอโดยตรงไปยัง เซิร์ฟเวอร์แบ็กเอนด์จากเซิร์ฟเวอร์แบ็กเอนด์เองหรือเครื่องอื่นๆ ที่คุณ ได้รับอนุญาตให้ส่งคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์
- หากคุณเป็นผู้ใช้ Private Cloud คุณยังสามารถส่งคำขอไปยัง เซิร์ฟเวอร์ส่วนหลังจากตัวประมวลผลข้อความ
- ยืนยันขนาดของเพย์โหลดที่ส่งผ่านในการตอบกลับโดยตรวจสอบ ส่วนหัวความยาวของเนื้อหา
- หากคุณพบว่าเพย์โหลดมีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาตใน Apigee Edge นั่นเป็นสาเหตุของ ปัญหา
ตัวอย่างการตอบกลับจากเซิร์ฟเวอร์แบ็กเอนด์
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>
ในตัวอย่างด้านบน คุณจะเห็นว่า
Content-Length: 11534336 (which is ~11 MB)
ซึ่งเป็นสาเหตุของข้อผิดพลาดนี้เพราะเกิน ขีดจำกัดที่อนุญาตใน Apigee Edge
ความละเอียด
โปรดดูความละเอียด
สาเหตุ: ขนาดเพย์โหลดการตอบกลับเกินขีดจำกัดที่อนุญาตหลังจาก การยกเลิกการบีบอัด
หากส่งเพย์โหลดการตอบกลับในรูปแบบที่บีบอัดและส่วนหัวการตอบกลับ
มีการตั้งค่า Content-Encoding
เป็น gzip,
Apigee จะขยายการตอบสนอง
เพย์โหลด ในระหว่างขั้นตอนการยกเลิกการบีบอัด หาก Apigee พบว่าเพย์โหลดมีขนาดใหญ่กว่า
เกินขีดจำกัดที่ อนุญาตใน Apigee Edge และจะหยุดต่อไปอีก
การยกเลิกการบีบอัด
และตอบกลับทันที
ด้วย 502 Bad Gateway
และรหัสข้อผิดพลาด protocol.http.TooBigBody
การวินิจฉัย
- กำหนดรหัสข้อผิดพลาด แหล่งที่มาของข้อผิดพลาด และขนาดเพย์โหลดการตอบกลับสำหรับ ข้อผิดพลาดที่พบเมื่อใช้การตรวจสอบ API, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไปจากสถานการณ์ที่ 2
- หาก Fault Source มีค่า
target
ก็จะแสดงค่าว่า ขนาดเพย์โหลดการตอบกลับที่ส่งโดยแอปพลิเคชันเป้าหมาย/แบ็กเอนด์ไปยัง Apigee มีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาตใน Apigee Edge - ตรวจสอบขนาดเพย์โหลดการตอบกลับตามที่ระบุจากขั้นตอนที่ 1
- หากขนาดเพย์โหลด > ขนาดที่จำกัดไว้ 10 MB นั้นจึงเป็นสาเหตุของข้อผิดพลาด
- หากเพย์โหลดขนาดไม่เกิน 10 MB ที่อนุญาต อาจเป็นไปได้ว่าเพย์โหลดการตอบกลับ ในรูปแบบที่บีบอัด ในกรณีนี้ ให้ตรวจสอบขนาดที่ไม่มีการบีบอัดของ เพย์โหลดการตอบกลับ
- คุณตรวจสอบได้ว่ามีการส่งการตอบสนองจากเป้าหมาย/แบ็กเอนด์ในรูปแบบที่บีบอัดหรือไม่ และ
ขนาดที่ไม่ได้บีบอัดมีค่าเกินขีดจำกัดที่อนุญาตโดยใช้ค่าใดค่าหนึ่งต่อไปนี้
วิธีการ:
Trace
เมื่อใช้เครื่องมือติดตาม ให้ทำดังนี้
- หากคุณได้บันทึกการติดตามสำหรับคำขอที่ล้มเหลว โปรดดูขั้นตอนโดยละเอียดใน
Traceและ
- ระบุค่า target.received.content.length
- ตรวจสอบว่าคำขอจากลูกค้ามี
การเข้ารหัสเนื้อหา:
gzip
ส่วนหัว
- หากค่าของ target.received.content.length ประมาณ 10 MB ตามที่ได้รับอนุญาต
และส่วนหัวการตอบกลับ Content-Encoding:
gzip
จากนั้นก็จะ สาเหตุของข้อผิดพลาดนี้
คำขอจริง
เมื่อใช้คำขอจริง
- หากคุณไม่มีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ ให้ไปที่ความละเอียด
- หากคุณมีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์
ให้ทำตามขั้นตอนต่อไปนี้
- ตรวจสอบขนาดของเพย์โหลดที่ส่งผ่านในการตอบกลับพร้อมกับ
ส่งส่วนหัว
Content-Encoding
ในการตอบกลับแล้ว - ถ้าคุณพบว่ามีการตั้งค่าส่วนหัวการตอบกลับ
Content-Encoding
เป็นgzip
และเพย์โหลดขนาดที่ไม่ได้บีบอัดมีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาตใน Apigee Edge นี่จึงเป็นสาเหตุของ ข้อผิดพลาดนี้ตัวอย่างการตอบกลับที่ได้รับจากเซิร์ฟเวอร์แบ็กเอนด์
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>
ในกรณีข้างต้น ส่วนหัว
Content-Encoding: gzip
จะถูกส่งและ ไฟล์testzippedfile.gz
ในการตอบกลับมีขนาดไฟล์น้อยกว่า ขนาดสูงสุด แต่ขนาดของไฟล์testzippedfile
ที่ไม่ได้บีบอัดคือ ~15 MB
- ตรวจสอบขนาดของเพย์โหลดที่ส่งผ่านในการตอบกลับพร้อมกับ
ส่งส่วนหัว
บันทึกของผู้ประมวลผลข้อความ
การใช้บันทึกโปรแกรมประมวลผลข้อความมีดังนี้
- หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถใช้บันทึกสำหรับตัวประมวลผลข้อความเพื่อ
ระบุข้อมูลสำคัญเกี่ยวกับข้อผิดพลาด HTTP
502
ตรวจสอบบันทึกสำหรับโปรแกรมประมวลผลข้อความ
/opt/apigee/var/log/edge-message-processor/logs/system.log
ค้นหาเพื่อดูว่ามีข้อผิดพลาด
502
รายการเกิดขึ้นในช่วงระยะเวลาหนึ่งๆ หรือไม่ (หากเคยมีปัญหาเกิดขึ้นในอดีต) หรือหากมีคำขอที่ยังคงดำเนินการไม่สำเร็จ502
คุณใช้สตริงการค้นหาต่อไปนี้ได้grep -ri "chunkCount"
grep -ri "BadGateway: Body buffer overflow"
- คุณจะเห็นเส้นทางจาก
system.log
ที่คล้ายกับดังที่แสดงด้านล่าง (TotalRead
และchunkCount
อาจแตกต่างกันไปในกรณีของคุณ):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)
ในระหว่างขั้นตอนการยกเลิกการบีบอัด ทันทีที่เครื่องมือประมวลผลข้อความระบุ ไบต์ที่อ่านทั้งหมดคือ > ขนาด 10 MB กล้องจะหยุดและพิมพ์บรรทัดต่อไปนี้
Message is too large. TotalRead 10489856 chunkCount 2571
แสดงว่าขนาดเพย์โหลดการตอบกลับมากกว่า 10 MB และ Apigee แสดงข้อผิดพลาดเมื่อขนาดเริ่มเกินขีดจำกัด 10 MB โดยมีรหัสข้อผิดพลาดเป็น
protocol.http.TooBigBody
- หากคุณได้บันทึกการติดตามสำหรับคำขอที่ล้มเหลว โปรดดูขั้นตอนโดยละเอียดใน
Traceและ
ความละเอียด
แก้ไขขนาด
ตัวเลือกที่ 1 [แนะนำ]: แก้ไขแอปพลิเคชันเซิร์ฟเวอร์เป้าหมายไม่ให้ส่งขนาดเพย์โหลดเกินขีดจำกัด Apigee
- วิเคราะห์สาเหตุที่เซิร์ฟเวอร์เป้าหมายบางรายการส่งขนาดการตอบกลับ / เพย์โหลด มากกว่าขีดจำกัดที่อนุญาตตามที่ระบุไว้ใน ขีดจำกัด
- หากไม่พึงประสงค์ ให้แก้ไขแอปพลิเคชันเซิร์ฟเวอร์เป้าหมายเพื่อให้ส่ง ขนาดการตอบกลับ / เพย์โหลดน้อยกว่าขีดจำกัดที่อนุญาต
- หากมีความจำเป็น และคุณต้องการส่งการตอบกลับ/เพย์โหลดมากกว่าที่อนุญาต ให้ไปที่ตัวเลือกถัดไป
รูปแบบ URL ที่ลงนาม
ตัวเลือกที่ 2 [แนะนำ]: ใช้รูปแบบ URL ที่มีการรับรองภายใน Apigee Javacallout
สำหรับเพย์โหลดที่มีขนาดใหญ่กว่า 10 MB Apigee แนะนำให้ใช้รูปแบบ URL ที่มีการรับรองภายใน Apigee Javacallout ที่แสดงโดย ข้อความไฮไลต์ Edge: ตัวอย่างเครื่องมือสร้าง URL ที่ลงนามใน GitHub
สตรีมมิง
ตัวเลือกที่ 3: ใช้สตรีมมิง
หากพร็อกซี API ของคุณจำเป็นต้องจัดการคำขอและ/หรือการตอบกลับขนาดใหญ่มาก คุณสามารถ เปิดใช้สตรีมมิงใน Apigee
CwC
ตัวเลือกที่ 4: ใช้พร็อพเพอร์ตี้ CwC เพื่อเพิ่มขีดจำกัดบัฟเฟอร์
ควรใช้ตัวเลือกนี้เฉพาะเมื่อคุณไม่สามารถใช้ตัวเลือกที่แนะนำเป็น อาจมีปัญหาด้านประสิทธิภาพหากเพิ่มขนาดเริ่มต้น
Apigee มอบสิทธิประโยชน์ พร็อพเพอร์ตี้ CwC ที่ช่วยให้เพิ่มขนาดเพย์โหลดคำขอและการตอบกลับได้ ขีดจำกัด โปรดดูรายละเอียดที่ ตั้งค่าขนาดสูงสุดของข้อความบนเราเตอร์หรือ Message Processor
จำกัดสูงสุด
Apigee คาดว่าแอปพลิเคชันไคลเอ็นต์และเซิร์ฟเวอร์แบ็กเอนด์จะไม่ส่งเพย์โหลดที่มีขนาดใหญ่กว่า
ขีดจำกัดที่อนุญาตสำหรับ
Request/response size
ใน
ขีดจำกัด Apigee Edge
- หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ขีดจำกัดสูงสุดสำหรับคำขอและการตอบกลับ
ขนาดเพย์โหลดที่บันทึกไว้สำหรับ
Request/response size
ใน ขีดจำกัด Apigee Edge - หากคุณเป็นผู้ใช้ Private Cloud คุณอาจได้แก้ไขขีดจำกัดสูงสุดเริ่มต้น ขีดจำกัดสำหรับขนาดเพย์โหลดคำขอและการตอบกลับ (แม้ว่าจะไม่ใช่แนวทางปฏิบัติที่แนะนำก็ตาม) คุณกำหนดขีดจำกัดขนาดเพย์โหลดคำขอสูงสุดได้โดยทำตามวิธีการใน วิธีตรวจสอบขีดจำกัดปัจจุบัน
วิธีตรวจสอบขีดจำกัดปัจจุบัน
ส่วนนี้อธิบายวิธียืนยันพร็อพเพอร์ตี้
อัปเดต HTTPResponse.body.buffer.limit
ด้วยค่าใหม่ในข้อความแล้ว
ผู้ประมวลผลข้อมูล
ค้นหาคุณสมบัติในเครื่องประมวลผลข้อความ
HTTPResponse.body.buffer.limit
ในไดเรกทอรี/opt/apigee/edge-message- processor/conf
แล้วตรวจสอบว่าได้ตั้งค่าให้กับค่าใดบ้างดังที่แสดงด้านล่างgrep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
ตัวอย่างผลลัพธ์จากคำสั่งด้านบนมีดังนี้
/opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m
ในตัวอย่างเอาต์พุตด้านบน จะเห็นว่าพร็อพเพอร์ตี้ มีการตั้งค่า
HTTPResponse.body.buffer.limit
ด้วยค่า10m
ในhttp.properties
ค่านี้ระบุว่าขีดจำกัดสำหรับขนาดเพย์โหลดคำขอที่กำหนดค่าใน Apigee สำหรับ Private Cloud มีขนาด 10 MB
หากยังต้องการความช่วยเหลือจากทีมสนับสนุนของ Apigee ให้ไปที่ ต้องรวบรวมข้อมูลการวินิจฉัย
ต้องรวบรวมข้อมูลการวินิจฉัย
รวบรวมข้อมูลการวินิจฉัยต่อไปนี้ จากนั้นให้ติดต่อทีมสนับสนุนของ Apigee Edge
หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ โปรดระบุข้อมูลต่อไปนี้
- ชื่อองค์กร
- ชื่อสภาพแวดล้อม
- ชื่อพร็อกซี API
- ใช้คำสั่ง curl เพื่อสร้างข้อผิดพลาด
502
ซ้ำ - ไฟล์การติดตามสำหรับคำขอ API
- เอาต์พุตที่สมบูรณ์ของการตอบกลับจากเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ พร้อมด้วยขนาดของเพย์โหลด
หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้
- พบข้อความแสดงข้อผิดพลาดทั้งหมดสำหรับคำขอที่ล้มเหลว
- ชื่อองค์กร
- ชื่อสภาพแวดล้อม
- แพ็กเกจพร็อกซี API
- ไฟล์การติดตามสำหรับคำขอ API ที่ล้มเหลว
- ใช้คำสั่ง curl เพื่อสร้างข้อผิดพลาด
502
ซ้ำ - เอาต์พุตที่สมบูรณ์ของการตอบกลับจากเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ พร้อมด้วยขนาดของเพย์โหลด
บันทึกการเข้าถึง NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
ที่ไหน: ORG, ENV และ PORT# จะถูกแทนที่ด้วย มูลค่าจริง
- บันทึกระบบของผู้ประมวลผลข้อความ
/opt/apigee/var/log/edge-message-processor/logs/system.log