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

รูปแบบ gzip ของ Unix

ดู รูปแบบ RFC1952 GZIP

การเข้ารหัสรายการเดียว หดตัว

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

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

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

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

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

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

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

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

ใช้เครื่องมือ/เทคนิคอย่างใดอย่างหนึ่งต่อไปนี้เพื่อวิเคราะห์ข้อผิดพลาดนี้

การตรวจสอบ API

วิธีวินิจฉัยข้อผิดพลาดโดยใช้ API Monitoring

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

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

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

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

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

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

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

  9. คลิกดูบันทึกแล้วขยายแถวที่ดำเนินการไม่สำเร็จโดยมีข้อผิดพลาด 400

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

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

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

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

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

  2. ตรวจสอบว่าเปิดใช้ Show FlowInfos ทั้งหมดแล้ว โดยทำดังนี้

  3. เลือกคำขอที่ล้มเหลว 1 รายการและตรวจสอบการติดตาม
  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-Encoding คือ gzip แต่เพย์โหลดคำขอไม่ได้อยู่ในรูปแบบ GZIP ดังนั้น Apigee จึงไม่สามารถขยายเพย์โหลดโดยใช้ gzip และแสดงผลข้อผิดพลาด Decompression failure at request

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

    ไปยังส่วนการตอบกลับที่ส่งไปยังไคลเอ็นต์ในการติดตามดังที่แสดงด้านล่าง

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

    สังเกตรายละเอียดต่อไปนี้จากการติดตาม

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

  9. ไปยังเฟส AX (บันทึกข้อมูล Analytics) ในการติดตาม แล้วคลิกตัวเลือกนั้น

  10. เลื่อนลงไปที่ส่วน Phase Details, Error Headers และระบุค่าของ 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. กำหนด Fault Code และ Fault Source สำหรับข้อผิดพลาดที่สังเกตโดยใช้ API Monitoring, เครื่องมือ Trace หรือบันทึกการเข้าถึง 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-Encrypting คือ 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-Encrypting: 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-Encrypting: 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