400 คําขอไม่ถูกต้อง - DecompressionFailureAtRequest

คุณกำลังดูเอกสารประกอบ Apigee Edge
ไปที่ เอกสารประกอบเกี่ยวกับ Apigee X. ข้อมูล

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับรหัสสถานะ HTTP 400 Bad Request พร้อมรหัสข้อผิดพลาด messaging.adaptors.http.flow.DecompressionFailureAtRequest เป็นการตอบกลับ API

ข้อความแสดงข้อผิดพลาด

แอปพลิเคชันไคลเอ็นต์ได้รับโค้ดตอบกลับต่อไปนี้ 

HTTP/1.1 400 Bad Request

นอกจากนี้ คุณอาจสังเกตเห็นข้อความแสดงข้อผิดพลาดที่คล้ายกับข้อความด้านล่าง: 

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

สาเหตุที่เป็นไปได้

ข้อผิดพลาดนี้จะเกิดขึ้นเฉพาะในกรณีที่

  • การเข้ารหัสที่ระบุในส่วนหัวของคำขอ HTTP Content-Encoding ถูกต้องและ รองรับโดย Apigee Edge

    • แต่

  • รูปแบบเพย์โหลดที่ไคลเอ็นต์ส่งโดยเป็นส่วนหนึ่งของคำขอ HTTP ไม่ ตรงกับรูปแบบการเข้ารหัสที่ระบุไว้ในส่วนหัวContent-Encoding

เนื่องจาก Apigee Edge ไม่สามารถถอดรหัสเพย์โหลดโดยใช้การเข้ารหัสที่ระบุตั้งแต่ ของเพย์โหลดไม่ได้อยู่ในรูปแบบเดียวกับการเข้ารหัสที่ระบุไว้ใน ส่วนหัว Content-Encoding

ต่อไปนี้คือตัวอย่างค่า Content-Encodingที่รองรับและวิธีที่ Apigee Edge ต้องการรูปแบบเพย์โหลดในกรณีเหล่านี้

สถานการณ์ Content-Encoding รูปแบบเพย์โหลดที่คาดไว้
การเข้ารหัสเดี่ยว Gzip

รูปแบบ Unix gzip

โปรดดู รูปแบบ RFC1952 GZIP

การเข้ารหัสเดี่ยว เสื่อม

รูปแบบนี้ใช้โครงสร้าง zlib ที่มีอัลกอริทึมการบีบอัดแบบ Deflate

โปรดดู RFC1950 และ RFC1951.
การเข้ารหัสหลายรายการ

การเข้ารหัสหลายรายการ

เช่น ในกรณีที่มีการเข้ารหัส 2 ครั้ง อาจเกิดเหตุการณ์ต่อไปนี้

  • gzip, deflate
  • gzip, gzip
  • deflate, gzip
  • ลดละ, ลดละ
 ใช้การเข้ารหัสหลายรายการกับเพย์โหลดตามลำดับที่ระบุตามที่ปรากฏในส่วนหัว

สาเหตุที่เป็นไปได้สำหรับข้อผิดพลาดนี้มีดังนี้

สาเหตุ คำอธิบาย วิธีการแก้ปัญหาสำหรับ
รูปแบบเพย์โหลดคำขอไม่ตรงกับการเข้ารหัสที่ระบุไว้ในส่วนหัวการเข้ารหัสเนื้อหา รูปแบบของเพย์โหลดคำขอที่ไคลเอ็นต์ส่งไม่ได้เข้ารหัสหรือไม่ได้เข้ารหัส ตรงกับการเข้ารหัสที่ระบุไว้ในส่วนหัว Content-Encoding ผู้ใช้ Edge สาธารณะและ Private Cloud

ขั้นตอนการวินิจฉัยทั่วไป

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

การตรวจสอบ API

วิธีวินิจฉัยข้อผิดพลาดโดยใช้การตรวจสอบ API

  1. ลงชื่อเข้าใช้ Apigee Edge UI ในฐานะผู้ใช้ที่มี บทบาทที่เหมาะสม

  2. เปลี่ยนเป็นองค์กรที่ต้องการตรวจสอบปัญหา

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

  7. เลือกเซลล์ที่มีรหัสข้อผิดพลาด messaging.adaptors.http.flow.DecompressionFailureAtRequest เป็น แสดงอยู่ด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  8. ข้อมูลเกี่ยวกับรหัสข้อผิดพลาด messaging.adaptors.http.flow.DecompressionFailureAtRequest แสดงดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  9. คลิกดูบันทึกและขยายแถวที่ล้มเหลวโดยมีข้อผิดพลาด 400

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  10. จากหน้าต่าง Logs ให้จดรายละเอียดต่อไปนี้
    • รหัสสถานะ: 400
    • แหล่งที่มาของข้อผิดพลาด: proxy
    • รหัสข้อผิดพลาด: messaging.adaptors.http.flow.DecompressionFailureAtRequest
  11. หากซอร์สข้อผิดพลาดมีค่า proxy นั่นหมายถึง รูปแบบเพย์โหลดคำขอไม่ตรงกับ การเข้ารหัสที่รองรับที่ระบุไว้ในส่วนหัว Content-Encoding

เครื่องมือการติดตาม

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

  1. เปิดใช้เซสชันการติดตาม และเลือกระหว่าง
    1. รอให้ข้อผิดพลาด 400 Bad Request เกิดขึ้น หรือ
    2. หากคุณทำให้เกิดปัญหาซ้ำได้ ให้เรียกใช้ API และทำซ้ำ 400 Bad Request

  2. ตรวจสอบว่าเปิดใช้แสดง FlowInfo ทั้งหมด แล้ว

  3. เลือกคำขอที่ไม่สำเร็จรายการหนึ่งและตรวจสอบการติดตาม
  4. ไปยังส่วนต่างๆ ของการติดตามและค้นหาตำแหน่งที่ล้มเหลว เกิดขึ้น

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

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  6. สังเกตค่าของพร็อพเพอร์ตี้จากการติดตาม ดังนี้

    • ข้อผิดพลาด: Decompression failure at request
    • error.class: com.apigee.rest.framework.BadRequestException
    • error.cause: Not in GZIP format

    error.cause ระบุว่าเพย์โหลดคำขอไม่ได้อยู่ในรูปแบบ GZIP ซึ่งหมายความว่า Apigee Edge คาดว่าเพย์โหลดคำขอจะอยู่ในรูปแบบ GZIP ตามที่ระบุไว้ในส่วนหัว Content-Encoding

  7. ระบุค่าของส่วนหัวของคำขอ Content-Encoding โดยให้ไปยังขั้นคำขอที่ได้รับจากไคลเอ็นต์ดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

    โปรดทราบว่าค่าของส่วนหัวของคำขอ Content-Encoding แท้จริงแล้ว gzip

    การติดตามตัวอย่างข้างต้นแสดงให้เห็นว่าการเข้ารหัสที่ระบุในส่วนหัวของคำขอ Content-Encodinggzip แต่เพย์โหลดคำขอ ไม่ได้อยู่ในรูปแบบ GZIP ดังนั้น Apigee จึงไม่สามารถขยายเพย์โหลดโดยใช้ gzip และแสดงผลข้อผิดพลาด Decompression failure at request

  8. จดบันทึกรหัสสถานะและข้อความแสดงข้อผิดพลาดที่ Apigee Edge แสดงขึ้นมาด้วยการไปยังส่วนต่างๆ

    ไปยังระยะ Response Sent to Client ในการติดตามดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

    โปรดทราบรายละเอียดต่อไปนี้จากการติดตาม

    • รหัสสถานะ: 400 Bad Request
    • เนื้อหาข้อผิดพลาด: {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}

  9. ไปยังช่วง AX (Analytics Data Recorded) ในการติดตาม แล้วคลิกที่ตัวเลือก

  10. เลื่อนลงไปที่ส่วนรายละเอียดระยะ ส่วนหัวของข้อผิดพลาด และ ระบุค่าของ X-Apigee-fault-code และ X-Apigee-fault-source ดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  11. คุณจะเห็นค่าของ X-Apigee-fault-code และ X-Apigee-fault-source ด้วยชื่อ messaging.adaptors.http.flow.DecompressionFailureAtRequest และ policy ซึ่งแสดงว่ารูปแบบเพย์โหลดคำขอไม่ตรงกับ ที่ระบุในส่วนหัว Content-Encoding
    ส่วนหัวการตอบกลับ ค่า
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

NGINX

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

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

  2. ตรวจสอบบันทึกการเข้าถึง NGINX ดังต่อไปนี้

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

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

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

  4. หากคุณพบข้อผิดพลาด 400 ที่มี X-Apigee-fault-code ตรงกับค่าของ messaging.adaptors.http.flow.DecompressionFailureAtRequest แล้วกำหนดค่าของ X-Apigee-fault-source.

    ตัวอย่างข้อผิดพลาด 400 จากบันทึกการเข้าถึง NGINX

    ตัวอย่างรายการข้างต้นจากบันทึกการเข้าถึง NGINX มีค่าต่อไปนี้สำหรับ X-Apigee-fault-code และ X-Apigee-fault-code

    ส่วนหัวการตอบกลับ ค่า
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

สาเหตุ: รูปแบบเพย์โหลดคำขอไม่ตรงกับการเข้ารหัสที่ระบุ ในส่วนหัวการเข้ารหัสเนื้อหา

โดยค่าเริ่มต้น Apigee Edge จะยกเลิกการบีบอัดเพย์โหลดเสมอหากส่วนหัวของคำขอ Content-Encoding มีแอตทริบิวต์ที่ถูกต้องและ การเข้ารหัสที่รองรับ ดังนั้นจึงคาดว่ารูปแบบของเพย์โหลดคำขอ ควรตรงกับการเข้ารหัสที่ระบุในส่วนหัวของคำขอ Content-Encoding หากมีข้อมูลที่ไม่ตรงกัน คุณจะได้รับข้อผิดพลาดนี้

การวินิจฉัย

  1. กำหนดรหัสข้อผิดพลาดและแหล่งที่มาของข้อผิดพลาดสำหรับข้อผิดพลาดที่พบโดยใช้ API การตรวจสอบ เครื่องมือการติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไป
  2. หาก Fault Code คือ messaging.adaptors.http.flow.DecompressionFailureAtRequest และ Fault Source มีค่า policy หรือ proxy จากนั้นจะเป็น ระบุว่าคำขอที่ส่งโดยแอปพลิเคชันไคลเอ็นต์มีเพย์โหลดที่ไม่ตรงกับ การเข้ารหัสที่รองรับที่ระบุในส่วนหัวของคำขอ Content-Encoding

  3. คุณระบุการจับคู่ที่ไม่ตรงกันเป็นส่วนหนึ่งของคำขอ HTTP ได้โดยใช้ข้อใดข้อหนึ่งต่อไปนี้ วิธีการ:

    ข้อความแสดงข้อผิดพลาด

    หากต้องการตรวจสอบโดยใช้ข้อความแสดงข้อผิดพลาด ให้ทำดังนี้

    1. หากคุณมีสิทธิ์เข้าถึงข้อความแสดงข้อผิดพลาดทั้งหมดที่ได้รับจาก Apigee Edge โปรดดูที่ faultstring

      ตัวอย่างข้อความแสดงข้อผิดพลาด

      "faultstring":"Decompression failure at request"
    2. ในข้อความแสดงข้อผิดพลาดข้างต้น "Decompression failure at request" ซึ่งบอกเป็นนัยว่าคำขอ ไม่สามารถบีบอัดโดยใช้การเข้ารหัสที่ระบุใน ส่วนหัว Content-Encoding

    Trace

    วิธีตรวจสอบโดยใช้การติดตาม

    1. ระบุค่าของส่วนหัวของคำขอ Content-Encoding และ พร็อพเพอร์ตี้ error.cause โดยใช้Trace ตามที่อธิบายไว้ในขั้นตอนการวิเคราะห์ทั่วไป

    2. ค่าจากการติดตามตัวอย่างมีดังนี้

      • การเข้ารหัสเนื้อหา: gzip
      • error.cause: Not in GZIP format

      ค่าในส่วนหัวของคำขอ Content-Encoding คือ gzip แต่เพย์โหลดคำขอไม่ได้อยู่ในรูปแบบ GZIP (ตามที่ระบุไว้โดย error.cause) ดังนั้น Apigee Edge จะตอบสนองด้วย 400 Bad Request และรหัสข้อผิดพลาด messaging.adaptors.http.flow.DecompressionFailureAtRequest

    คำขอจริง

    วิธีตรวจสอบโดยใช้คำขอจริงมีดังนี้

    หากคุณมีสิทธิ์เข้าถึงคำขอจริงที่ลูกค้าสร้าง ให้ทำตามขั้นตอนต่อไปนี้

    1. ระบุค่าที่ส่งไปยังส่วนหัวของคำขอ Content-Encoding
    2. กำหนดรูปแบบของเพย์โหลดที่ส่งเป็นส่วนหนึ่งของคำขอ

    3. หากค่าของส่วนหัว Content-Encoding อยู่ในรายการ การเข้ารหัสที่รองรับแต่รูปแบบของเพย์โหลดคำขอไม่รองรับ ตรงกับการเข้ารหัสที่ระบุในส่วนหัว Content-Encoding นั่นก็คือสาเหตุของปัญหา

      ตัวอย่างคำขอ

      curl -v "http://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.zip

      คำขอตัวอย่างข้างต้นจะส่งค่า gzip ไปยัง Content-Encoding ซึ่งเป็นส่วนหัว การเข้ารหัสที่รองรับใน Apigee Edge อย่างไรก็ตาม เพย์โหลดคำขอ request_payload.zip อยู่ในรูปแบบ ZIP ดังนั้น คำขอนี้ ล้มเหลวโดยมีรหัสสถานะ 400 Bad Request และรหัสข้อผิดพลาด: messaging.adaptors.http.flow.DecompressionFailureAtRequest

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

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

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

    1. กำหนดรหัสข้อความของคำขอที่ล้มเหลวโดยใช้การตรวจสอบ API, เครื่องมือการติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไป

    2. ค้นหารหัสข้อความในบันทึกตัวประมวลผลข้อความโดยใช้คำสั่งต่อไปนี้

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

    3. คุณจะเห็นข้อยกเว้นข้อใดข้อหนึ่งต่อไปนี้

      สถานการณ์ที่ 1

      สถานการณ์ที่ 1: เมื่อคำขอ API มีส่วนหัว Content-Encoding: gzip

      2021-07-28 10:21:16,861  NIOThread@0 ERROR HTTP.SERVER -
HTTPServer$Context.onInputException() : Message id:rt-57-1
SSLClientChannel[Accepted: Remote:192.168.199.8:8443
Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0
bytesWritten=28764 age=2739893ms  lastIO=0ms
isOpen=true.onExceptionRead exception: {}
java.util.zip.ZipException: Not in GZIP format

2021-07-28 10:21:16,862  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW -
AbstractRequestListener.onException() : Request:POST, uri:/test,
message Id:rt-57-1, exception:java.util.zip.ZipException: Not in GZIP format,
context:Context@71ea5ac input=ClientInputChannel(SSLClientChannel[Accepted:
Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1
bytesRead=0 bytesWritten=28764 age=2739894ms  lastIO=0ms  isOpen=true)
2021-07-28 10:21:16,862  NIOThread@0 INFO  HTTP.SERVICE -
ExceptionHandler.handleException() :
Exception java.util.zip.ZipException: Not in GZIP format occurred while writing
to channel null
2021-07-28 10:21:16,863  NIOThread@0 INFO  HTTP.SERVICE -
ExceptionHandler.handleException() : Exception trace:
java.util.zip.ZipException: Not in GZIP format

      บรรทัด java.util.zip.ZipException: Not in GZIP format ในข้อความแสดงข้อผิดพลาดข้างต้นระบุว่าคำขอ ระบบไม่ได้ส่งเพย์โหลดในรูปแบบ GZIP แม้ว่า Content-Encoding ระบุเป็น gzip ดังนั้น Apigee Edge จึงจะมีการส่งข้อยกเว้นและ แสดงรหัสสถานะ 400 ที่มีรหัสข้อผิดพลาด วันที่ messaging.adaptors.http.flow.DecompressionFailureAtRequest ในแอปพลิเคชันไคลเอ็นต์

      สถานการณ์ที่ 2

      สถานการณ์ที่ 2: เมื่อคำขอ API มีส่วนหัว Content-Encoding: deflate

      2021-07-28 15:26:31,893  NIOThread@1 ERROR HTTP.SERVER -
HTTPServer$Context.onInputException() : Message id:rt-47875-1
SSLClientChannel[Accepted: Remote:192.168.199.8:8443
Local:192.168.81.72:45954]@29276 useCount=1 bytesRead=0
bytesWritten=37230 age=3498856ms  lastIO=1ms
isOpen=true.onExceptionRead exception: {}
java.util.zip.ZipException: incorrect header check
                  ….
Caused by: java.util.zip.DataFormatException: incorrect header check
       ..
2021-07-28 15:26:31,894  NIOThread@1 ERROR ADAPTORS.HTTP.FLOW -
AbstractRequestListener.onException() : Request:POST, uri:/test,
message Id:rrt-47875-1, exception:java.util.zip.ZipException:
incorrect header check, context:Context@69b3ac45
input=ClientInputChannel(SSLClientChannel[Accepted:
Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276
useCount=1 byt	esRead=0 bytesWritten=37230 age=3498856ms
lastIO=1ms  isOpen=true)

      เส้น java.util.zip.ZipException: incorrect header check และ วันที่ Caused by: java.util.zip.DataFormatException: incorrect header check ในข้อความแสดงข้อผิดพลาดข้างต้นระบุว่าไม่มีการส่งเพย์โหลดคำขอใน deflate และไม่ตรงกับการเข้ารหัสที่ระบุใน ส่วนหัว Content-Encoding ของ deflate ดังนั้น Apigee Edge จะแสดงข้อยกเว้นและส่งคืนรหัสสถานะ 400 ด้วย รหัสข้อผิดพลาด messaging.adaptors.http.flow.DecompressionFailureAtRequest ในแอปพลิเคชันไคลเอ็นต์

ความละเอียด

  1. หากไม่จำเป็นต้องใช้เพย์โหลดคำขอที่บีบอัดในขั้นตอนพร็อกซี API ใน Apigee Edge และในเซิร์ฟเวอร์แบ็กเอนด์ ให้ไม่ต้องส่งส่วนหัว Content-Encoding หากจำเป็นต้องบีบอัดเพย์โหลดคำขอ ให้ไปยังขั้นตอนที่ 2
  2. ตรวจสอบว่าแอปพลิเคชันไคลเอ็นต์ส่งข้อมูลต่อไปนี้เสมอ
    • ใดๆ ก็ได้ การเข้ารหัสที่รองรับเป็นค่าสำหรับส่วนหัว Content-Encoding ใน คำขอ
    • เพย์โหลดคำขอในรูปแบบที่รองรับไปยัง Apigee Edge ตรงกับการเข้ารหัส รูปแบบที่ระบุในส่วนหัว Content-Encoding
  3. ในตัวอย่างที่พูดถึงข้างต้น เพย์โหลดคำขอจะอยู่ในรูปแบบ ZIP แต่ส่วนหัวของคำขอ ระบุ Content-Encoding: gzip คุณจะแก้ไขปัญหาได้โดยการส่งคำขอ ส่วนหัวเป็น Content-Encoding: gzip และเพย์โหลดคำขออยู่ใน gzip ด้วย รูปแบบ: 
    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz

ข้อมูลจำเพาะ

Apigee Edge ตอบกลับด้วยรหัสสถานะ 400 Bad Request ด้วยรหัสข้อผิดพลาด messaging.adaptors.http.flow.DecompressionFailureAtRequest ตาม RFC ต่อไปนี้ ข้อมูลจำเพาะ:

ข้อมูลจำเพาะ
RFC 7231 ส่วน 6.5.1
RFC 7231 ส่วน 3.1.2.2

หากยังต้องการความช่วยเหลือจากทีมสนับสนุนของ Apigee ให้ไปที่ ต้องรวบรวมข้อมูลการวินิจฉัย

ต้องรวบรวมข้อมูลการวินิจฉัย

รวบรวมข้อมูลการวินิจฉัยต่อไปนี้ จากนั้นให้ติดต่อทีมสนับสนุนของ Apigee Edge

หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ โปรดระบุข้อมูลต่อไปนี้

  • ชื่อองค์กร
  • ชื่อสภาพแวดล้อม
  • ชื่อพร็อกซี API
  • ทำตามคำสั่ง curl ในการสร้างข้อผิดพลาด 400 ซ้ำ
  • ไฟล์การติดตามสำหรับคำขอ API

หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้

  • พบข้อความแสดงข้อผิดพลาดทั้งหมดสำหรับคำขอที่ล้มเหลว
  • ชื่อสภาพแวดล้อม
  • แพ็กเกจพร็อกซี API
  • ไฟล์การติดตามสำหรับคำขอ API

  • บันทึกการเข้าถึง 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