502 เกตเวย์ไม่ถูกต้อง - TooBigBody

คุณกำลังดูเอกสารประกอบ 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

  1. ลงชื่อเข้าใช้ Apigee Edge UI ในฐานะผู้ใช้ที่มี บทบาทที่เหมาะสม
  2. เปลี่ยนเป็นองค์กรที่ต้องการตรวจสอบปัญหา

  3. ไปที่ วิเคราะห์ > การตรวจสอบ API > หน้าตรวจสอบ
  4. เลือกกรอบเวลาที่คุณพบข้อผิดพลาด
  5. คุณอาจเลือกตัวกรองพร็อกซีเพื่อจำกัดรหัสข้อผิดพลาดให้แคบลง
  6. พล็อตรหัสข้อผิดพลาดเทียบกับเวลา
  7. เลือกเซลล์ที่มีรหัสข้อผิดพลาด protocol.http.TooBigBody เป็น แสดงอยู่ด้านล่าง

  8. คุณจะเห็นข้อมูลเกี่ยวกับรหัสข้อผิดพลาด protocol.http.TooBigBody ตามที่แสดงด้านล่าง:

  9. คลิก ดูบันทึก และขยายแถวสำหรับคำขอที่ล้มเหลว

  10. จากหน้าต่างบันทึก โปรดสังเกตรายละเอียดต่อไปนี้
    • รหัสสถานะ: 502
    • แหล่งที่มาของข้อผิดพลาด: target
    • รหัสข้อผิดพลาด: protocol.http.TooBigBody
  11. หากแหล่งที่มาของข้อผิดพลาดมีค่า target และรหัสข้อผิดพลาด มีค่า protocol.http.TooBigBody ซึ่งแสดงว่า HTTP การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย/ แบ็กเอนด์มีขนาดเพย์โหลดการตอบกลับใหญ่กว่า อนุญาตขีดจำกัดใน Apigee Edge แล้ว

Trace

วิธีวินิจฉัยข้อผิดพลาดโดยใช้เครื่องมือติดตาม

  1. เปิดใช้เซสชันการติดตาม และดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้
    • รอให้ข้อผิดพลาด 502 Bad Gateway เกิดขึ้น หรือ
    • หากคุณทำให้เกิดปัญหาซ้ำได้ ให้เรียกใช้ API และทำซ้ำ ข้อผิดพลาด 502 Bad Gateway รายการ
  2. เลือกคำขอที่ไม่สำเร็จรายการหนึ่งและตรวจสอบการติดตาม
  3. ดำเนินการตามขั้นตอนต่างๆ ของการติดตามและค้นหาตำแหน่งที่เกิดข้อผิดพลาด
  4. ไปที่ระยะข้อผิดพลาดหลังจากการตอบสนองที่ได้รับจากเป้าหมาย เซิร์ฟเวอร์ตามที่แสดงด้านล่าง

    บันทึกค่าของข้อผิดพลาดจากการติดตามดังนี้

    • ข้อผิดพลาด: Body buffer overflow
    • error.class: com.apigee.errors.http.server.BadGateway

    ซึ่งหมายความว่า Apigee Edge (คอมโพเนนต์ตัวประมวลผลข้อความ) แสดงข้อผิดพลาดในทันที จะได้รับการตอบสนองจากเซิร์ฟเวอร์แบ็กเอนด์เนื่องจากขนาดเพย์โหลดเกินขีดจำกัดที่อนุญาต ขีดจำกัด

  5. คุณจะเห็นความล้มเหลวในช่วงตอบกลับไปยังไคลเอ็นต์ดังที่แสดงด้านล่าง

  6. จดค่าของข้อผิดพลาดจากการติดตาม การติดตามตัวอย่างข้างต้นแสดงสิ่งต่อไปนี้
    • ข้อผิดพลาด: 502 Bad Gateway
    • เนื้อหาข้อผิดพลาด: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  7. ไปยังระยะการตอบกลับที่ได้รับจากเซิร์ฟเวอร์เป้าหมายดังที่แสดงด้านล่างสำหรับสถานการณ์ต่างๆ

    ไม่บีบอัด

    สถานการณ์ที่ 1: ส่งเพย์โหลดการตอบกลับในรูปแบบที่ไม่ได้บีบอัด

    บันทึกค่าของข้อผิดพลาดจากการติดตามดังนี้

    • การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย: 200 OK
    • ความยาวของเนื้อหา (จากส่วนส่วนหัวการตอบกลับ): ~11 MB

    ขนาดไฟล์ที่บีบอัด

    สถานการณ์ที่ 2: ส่งเพย์โหลดคำขอในรูปแบบที่บีบอัด

    บันทึกค่าของข้อผิดพลาดจากการติดตามดังนี้

    • การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย: 200 OK
    • Content-Encoding: หากคุณเห็นส่วนหัวนี้ในContent-Encoding ให้สังเกตค่า ตัวอย่างเช่น ในตัวอย่างนี้ค่าคือ gzip
  8. จดบันทึกเนื้อหาในส่วนเนื้อหาการตอบกลับดังนี้

    {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
    
  9. ไปที่ระยะ AX (บันทึกข้อมูลของ Analytics) ในการติดตามและคลิก เพื่อดูรายละเอียดที่เกี่ยวข้อง

  10. เลื่อนลงในรายละเอียดระยะในส่วนการอ่านตัวแปร และระบุ ของ 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
  11. ตารางต่อไปนี้อธิบายสาเหตุที่ Apigee แสดงข้อผิดพลาด 502 ทั้ง 2 กรณีขึ้นอยู่กับค่าของ target.received.content.length ดังนี้

    สถานการณ์ ค่าของ target.received.content.length เหตุผลที่ล้มเหลว
    เพย์โหลดการตอบกลับในรูปแบบที่ไม่บีบอัด ~11 MB ขนาด > ขีดจำกัด 10 MB ที่อนุญาต
    เพย์โหลดการตอบกลับในรูปแบบที่บีบอัด ~10 MB

    เกินขนาดที่จำกัดเมื่อคลายการบีบอัด

NGINX

วิธีวินิจฉัยข้อผิดพลาดโดยใช้บันทึกการเข้าถึง NGINX

  1. หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถใช้บันทึกการเข้าถึง NGINX ในการระบุ ข้อมูลคีย์เกี่ยวกับข้อผิดพลาด HTTP 502
  2. ตรวจสอบบันทึกการเข้าถึง NGINX ดังต่อไปนี้

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    ที่ไหน: ระบบจะแทนที่ ORG, ENV และ PORT# ด้วยค่าจริง

  3. ค้นหาเพื่อดูว่ามีข้อผิดพลาด 502 รายการเกิดขึ้นในช่วงระยะเวลาหนึ่งๆ หรือไม่ (หาก เกิดขึ้นในอดีต) หรือหากมีคำขอที่ยังคงล้มเหลว 502
  4. หากคุณพบข้อผิดพลาด 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

สาเหตุ: ขนาดเพย์โหลดการตอบกลับเกินขีดจำกัดที่อนุญาต

การวินิจฉัย

  1. กำหนดรหัสข้อผิดพลาด แหล่งที่มาของข้อผิดพลาด และขนาดของเพย์โหลดการตอบกลับสำหรับ ข้อผิดพลาดที่พบเมื่อใช้การตรวจสอบ API, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไปจากสถานการณ์ที่ 1
  2. หากแหล่งที่มาของข้อผิดพลาดมีค่า target แสดงว่าการตอบสนอง ขนาดเพย์โหลดที่ส่งโดยเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ไปยัง Apigee ใหญ่กว่า ขีดจำกัดที่อนุญาตใน Apigee Edge
  3. ตรวจสอบขนาดเพย์โหลดการตอบกลับตามที่ระบุจากขั้นตอนที่ 1
  4. ตรวจสอบว่าขนาดเพย์โหลดการตอบกลับจริง > ไม่เกิน 10 MB โดยตรวจสอบ คำตอบจริงตามขั้นตอนต่อไปนี้
    1. หากคุณไม่มีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ ให้ไปที่ความละเอียด
    2. หากคุณมีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ ให้ทำตามขั้นตอนต่อไปนี้
      1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ/Private Cloud ให้ส่งคำขอโดยตรงไปยัง เซิร์ฟเวอร์แบ็กเอนด์จากเซิร์ฟเวอร์แบ็กเอนด์เองหรือเครื่องอื่นๆ ที่คุณ ได้รับอนุญาตให้ส่งคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์
      2. หากคุณเป็นผู้ใช้ Private Cloud คุณยังสามารถส่งคำขอไปยัง เซิร์ฟเวอร์ส่วนหลังจากตัวประมวลผลข้อความ
      3. ยืนยันขนาดของเพย์โหลดที่ส่งผ่านในการตอบกลับโดยตรวจสอบ ส่วนหัวความยาวของเนื้อหา
      4. หากคุณพบว่าเพย์โหลดมีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาตใน 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

การวินิจฉัย

  1. กำหนดรหัสข้อผิดพลาด แหล่งที่มาของข้อผิดพลาด และขนาดเพย์โหลดการตอบกลับสำหรับ ข้อผิดพลาดที่พบเมื่อใช้การตรวจสอบ API, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไปจากสถานการณ์ที่ 2
  2. หาก Fault Source มีค่า target ก็จะแสดงค่าว่า ขนาดเพย์โหลดการตอบกลับที่ส่งโดยแอปพลิเคชันเป้าหมาย/แบ็กเอนด์ไปยัง Apigee มีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาตใน Apigee Edge
  3. ตรวจสอบขนาดเพย์โหลดการตอบกลับตามที่ระบุจากขั้นตอนที่ 1
    • หากขนาดเพย์โหลด > ขนาดที่จำกัดไว้ 10 MB นั้นจึงเป็นสาเหตุของข้อผิดพลาด
    • หากเพย์โหลดขนาดไม่เกิน 10 MB ที่อนุญาต อาจเป็นไปได้ว่าเพย์โหลดการตอบกลับ ในรูปแบบที่บีบอัด ในกรณีนี้ ให้ตรวจสอบขนาดที่ไม่มีการบีบอัดของ เพย์โหลดการตอบกลับ
  4. คุณตรวจสอบได้ว่ามีการส่งการตอบสนองจากเป้าหมาย/แบ็กเอนด์ในรูปแบบที่บีบอัดหรือไม่ และ ขนาดที่ไม่ได้บีบอัดมีค่าเกินขีดจำกัดที่อนุญาตโดยใช้ค่าใดค่าหนึ่งต่อไปนี้ วิธีการ:

    Trace

    เมื่อใช้เครื่องมือติดตาม ให้ทำดังนี้

    1. หากคุณได้บันทึกการติดตามสำหรับคำขอที่ล้มเหลว โปรดดูขั้นตอนโดยละเอียดใน Traceและ
      1. ระบุค่า target.received.content.length
      2. ตรวจสอบว่าคำขอจากลูกค้ามี การเข้ารหัสเนื้อหา: gzip ส่วนหัว
    2. หากค่าของ target.received.content.length ประมาณ 10 MB ตามที่ได้รับอนุญาต และส่วนหัวการตอบกลับ Content-Encoding: gzip จากนั้นก็จะ สาเหตุของข้อผิดพลาดนี้

    คำขอจริง

    เมื่อใช้คำขอจริง

    1. หากคุณไม่มีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ ให้ไปที่ความละเอียด
    2. หากคุณมีสิทธิ์เข้าถึงคำขอจริงที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์ ให้ทำตามขั้นตอนต่อไปนี้
      1. ตรวจสอบขนาดของเพย์โหลดที่ส่งผ่านในการตอบกลับพร้อมกับ ส่งส่วนหัว Content-Encoding ในการตอบกลับแล้ว
      2. ถ้าคุณพบว่ามีการตั้งค่าส่วนหัวการตอบกลับ 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

    บันทึกของผู้ประมวลผลข้อความ

    การใช้บันทึกโปรแกรมประมวลผลข้อความมีดังนี้

    1. หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถใช้บันทึกสำหรับตัวประมวลผลข้อความเพื่อ ระบุข้อมูลสำคัญเกี่ยวกับข้อผิดพลาด HTTP 502
    2. ตรวจสอบบันทึกสำหรับโปรแกรมประมวลผลข้อความ

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. ค้นหาเพื่อดูว่ามีข้อผิดพลาด 502 รายการเกิดขึ้นในช่วงระยะเวลาหนึ่งๆ หรือไม่ (หากเคยมีปัญหาเกิดขึ้นในอดีต) หรือหากมีคำขอที่ยังคงดำเนินการไม่สำเร็จ 502 คุณใช้สตริงการค้นหาต่อไปนี้ได้

      grep -ri "chunkCount"
      
      grep -ri "BadGateway: Body buffer overflow"
      
    4. คุณจะเห็นเส้นทางจาก 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)
      
    5. ในระหว่างขั้นตอนการยกเลิกการบีบอัด ทันทีที่เครื่องมือประมวลผลข้อความระบุ ไบต์ที่อ่านทั้งหมดคือ > ขนาด 10 MB กล้องจะหยุดและพิมพ์บรรทัดต่อไปนี้

      Message is too large. TotalRead 10489856 chunkCount 2571

      แสดงว่าขนาดเพย์โหลดการตอบกลับมากกว่า 10 MB และ Apigee แสดงข้อผิดพลาดเมื่อขนาดเริ่มเกินขีดจำกัด 10 MB โดยมีรหัสข้อผิดพลาดเป็น protocol.http.TooBigBody

ความละเอียด

แก้ไขขนาด

ตัวเลือกที่ 1 [แนะนำ]: แก้ไขแอปพลิเคชันเซิร์ฟเวอร์เป้าหมายไม่ให้ส่งขนาดเพย์โหลดเกินขีดจำกัด Apigee

  1. วิเคราะห์สาเหตุที่เซิร์ฟเวอร์เป้าหมายบางรายการส่งขนาดการตอบกลับ / เพย์โหลด มากกว่าขีดจำกัดที่อนุญาตตามที่ระบุไว้ใน ขีดจำกัด
  2. หากไม่พึงประสงค์ ให้แก้ไขแอปพลิเคชันเซิร์ฟเวอร์เป้าหมายเพื่อให้ส่ง ขนาดการตอบกลับ / เพย์โหลดน้อยกว่าขีดจำกัดที่อนุญาต
  3. หากมีความจำเป็น และคุณต้องการส่งการตอบกลับ/เพย์โหลดมากกว่าที่อนุญาต ให้ไปที่ตัวเลือกถัดไป

รูปแบบ 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

  1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ขีดจำกัดสูงสุดสำหรับคำขอและการตอบกลับ ขนาดเพย์โหลดที่บันทึกไว้สำหรับ Request/response size ใน ขีดจำกัด Apigee Edge
  2. หากคุณเป็นผู้ใช้ Private Cloud คุณอาจได้แก้ไขขีดจำกัดสูงสุดเริ่มต้น ขีดจำกัดสำหรับขนาดเพย์โหลดคำขอและการตอบกลับ (แม้ว่าจะไม่ใช่แนวทางปฏิบัติที่แนะนำก็ตาม) คุณกำหนดขีดจำกัดขนาดเพย์โหลดคำขอสูงสุดได้โดยทำตามวิธีการใน วิธีตรวจสอบขีดจำกัดปัจจุบัน

วิธีตรวจสอบขีดจำกัดปัจจุบัน

ส่วนนี้อธิบายวิธียืนยันพร็อพเพอร์ตี้ อัปเดต HTTPResponse.body.buffer.limit ด้วยค่าใหม่ในข้อความแล้ว ผู้ประมวลผลข้อมูล

  1. ค้นหาคุณสมบัติในเครื่องประมวลผลข้อความ HTTPResponse.body.buffer.limit ในไดเรกทอรี /opt/apigee/edge-message- processor/conf แล้วตรวจสอบว่าได้ตั้งค่าให้กับค่าใดบ้างดังที่แสดงด้านล่าง

    grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
    
  2. ตัวอย่างผลลัพธ์จากคำสั่งด้านบนมีดังนี้

    /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m
    
  3. ในตัวอย่างเอาต์พุตด้านบน จะเห็นว่าพร็อพเพอร์ตี้ มีการตั้งค่า 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