500 ข้อผิดพลาดภายในเซิร์ฟเวอร์

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

วิดีโอ

ดูวิดีโอต่อไปนี้เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ปัญหาข้อผิดพลาดภายในเซิร์ฟเวอร์ 500

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับรหัสสถานะ HTTP เป็น 500 พร้อมข้อความ "ข้อผิดพลาดภายในเซิร์ฟเวอร์" เป็นการตอบกลับสำหรับการเรียก API ข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 อาจเกิดจากข้อผิดพลาดระหว่างการดำเนินการนโยบายใดๆ ภายใน Edge หรือเกิดจากข้อผิดพลาด ในเซิร์ฟเวอร์เป้าหมาย/แบ็กเอนด์

รหัสสถานะ HTTP 500 คือการตอบกลับข้อผิดพลาดทั่วไป ซึ่งหมายความว่าเซิร์ฟเวอร์พบเงื่อนไขที่ไม่คาดคิดซึ่งทำให้ไม่สามารถดำเนินการตามคำขอได้ โดยปกติแล้วเซิร์ฟเวอร์จะแสดงข้อผิดพลาดนี้เมื่อไม่มีรหัสข้อผิดพลาดอื่นที่เหมาะสม

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

คุณอาจได้รับข้อความแสดงข้อผิดพลาดต่อไปนี้

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

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

ข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 อาจเกิดขึ้นได้จากสาเหตุหลายประการ ใน Edge, เราสามารถจัดประเภทสาเหตุออกเป็น 2 หมวดหมู่หลักๆ ตามตำแหน่งที่เกิดข้อผิดพลาดได้ดังนี้

ข้อผิดพลาดในการดำเนินการในนโยบาย Edge

นโยบาย Policy ภายใน พร็อกซี API อาจล้มเหลวด้วยเหตุผลบางประการ ส่วนนี้จะอธิบายวิธีแก้ปัญหาหาก เกิดข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 ระหว่างการดำเนินการนโยบาย

การวินิจฉัย

ขั้นตอนการวินิจฉัยสำหรับผู้ใช้ Private และ Public Cloud

หากคุณมีเซสชัน UI ของการติดตามข้อผิดพลาด ให้ทำดังนี้

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

ขั้นตอนการวินิจฉัยสำหรับผู้ใช้ Private Cloud เท่านั้น

หากคุณไม่มีเซสชัน UI ของการติดตาม ให้ทำดังนี้

1. ตรวจสอบว่าข้อผิดพลาดเกิดขึ้นระหว่างการดำเนินการนโยบาย ดูรายละเอียดได้ที่การระบุแหล่งที่มาของปัญหา
2. หากข้อผิดพลาดเกิดจากการดำเนินการนโยบาย ให้ดำเนินการต่อ หากข้อผิดพลาดเกิดขึ้นระหว่างการดำเนินการนโยบาย ให้ดำเนินการต่อ หากข้อผิดพลาดเกิดจากเซิร์ฟเวอร์แบ็กเอนด์ ให้ไปที่ ข้อผิดพลาดในเซิร์ฟเวอร์แบ็กเอนด์
3. ใช้บันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน Determining the source of the problem เพื่อระบุนโยบายที่ล้มเหลวในพร็อกซี API รวมถึง the unique request message id
4. ตรวจสอบบันทึกของ Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) และค้นหา รหัสข้อความคำขอที่ไม่ซ้ำกันในบันทึก
5. หากพบรหัสข้อความคำขอที่ไม่ซ้ำกัน ให้ดูว่าคุณจะได้รับข้อมูลเพิ่มเติมเกี่ยวกับ สาเหตุของความล้มเหลวหรือไม่

วิธีแก้ไข

หากคุณพิจารณาสาเหตุของปัญหาเกี่ยวกับนโยบายได้แล้ว ให้ลองแก้ไขปัญหาโดย แก้ไขนโยบายและติดตั้งใช้งานพร็อกซีอีกครั้ง

ตัวอย่างต่อไปนี้แสดงวิธีพิจารณาสาเหตุและวิธีแก้ไขปัญหาประเภทต่างๆ

หากต้องการความช่วยเหลือเพิ่มเติมในการแก้ปัญหาข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 หรือสงสัย ว่าปัญหาเกิดจาก Edge โปรดติดต่อ Apigee ทีมสนับสนุน

ตัวอย่างที่ 1: ความล้มเหลวในนโยบายการเรียกใช้บริการเนื่องจากข้อผิดพลาดในแบ็กเอนด์ เซิร์ฟเวอร์

หากการเรียกใช้เซิร์ฟเวอร์แบ็กเอนด์ล้มเหลวภายในนโยบายการเรียกใช้บริการโดยมีข้อผิดพลาดใดๆ เช่น 4XX หรือ 5XX ระบบจะถือว่าเป็นการเกิดข้อผิดพลาดภายในเซิร์ฟเวอร์ 500

1. นี่คือตัวอย่างที่บริการแบ็กเอนด์ล้มเหลวโดยมีข้อผิดพลาด 404 ภายในนโยบายการเรียกใช้บริการ ระบบจะส่งข้อความแสดงข้อผิดพลาดต่อไปนี้ไปยังผู้ใช้ปลายทาง

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. เซสชัน UI ของการติดตามต่อไปนี้แสดงรหัสสถานะ 500 ที่เกิดจากข้อผิดพลาดในนโยบายการเรียกใช้บริการ

   

3. ในตัวอย่างนี้ พร็อพเพอร์ตี้ "ข้อผิดพลาด" แสดงเหตุผลที่นโยบายการเรียกใช้บริการล้มเหลวเป็น "ResponseCode 404 is treated as error" ข้อผิดพลาดนี้อาจเกิดขึ้นหาก ทรัพยากรที่เข้าถึงผ่าน URL ของเซิร์ฟเวอร์แบ็กเอนด์ในนโยบายการเรียกใช้บริการไม่ พร้อมใช้งาน
4. ตรวจสอบความพร้อมใช้งานของทรัพยากรในเซิร์ฟเวอร์แบ็กเอนด์ ทรัพยากรอาจไม่พร้อมใช้งาน ชั่วคราว/ถาวร หรืออาจย้ายไปยังตำแหน่งอื่น

วิธีแก้ไขตัวอย่างที่ 1

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

ตัวอย่างที่ 2: ความล้มเหลวในนโยบายการแยกตัวแปร

ตอนนี้มาดูอีกตัวอย่างหนึ่งที่ข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 เกิดจากข้อผิดพลาด ในนโยบายการแยกตัวแปร และดูวิธีแก้ปัญหาและแก้ไขข้อผิดพลาด

1. การติดตามต่อไปนี้ในเซสชัน UI แสดงรหัสสถานะ 500 ที่เกิดจากข้อผิดพลาดในนโยบายการแยก ตัวแปร

   

2. เลือกนโยบายการแยกตัวแปรที่ล้มเหลว เลื่อนลงและดูส่วน "Error Content" เพื่อดูรายละเอียดเพิ่มเติม:
   
   
3. เนื้อหาข้อผิดพลาดระบุว่า ตัวแปร"serviceCallout.oamCookieValidationResponse" ไม่พร้อมใช้งานใน นโยบายการแยกตัวแปร ตามชื่อตัวแปร ตัวแปรนี้ควรเก็บการตอบกลับของนโยบายการเรียกใช้บริการก่อนหน้า
4. เลือกนโยบายการเรียกใช้บริการในการติดตาม แล้วคุณอาจพบว่าตัวแปร "serviceCallout.oamCookieValidationResponse" ไม่ได้ตั้งค่าไว้ ซึ่งหมายความว่าการเรียกใช้บริการแบ็กเอนด์ล้มเหลว ส่งผลให้ตัวแปรการตอบกลับว่างเปล่า
5. แม้ว่านโยบายการเรียกใช้บริการจะล้มเหลว แต่การดำเนินการนโยบายหลังจากนโยบายการเรียกใช้บริการจะดำเนินต่อไปเนื่องจากมีการตั้งค่าแฟล็ก "continueOnError" ในนโยบายการเรียกใช้บริการเป็น "จริง" ดังที่แสดงด้านล่าง
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. จดรหัสข้อความที่ไม่ซ้ำกัน "X-Apigee.Message-ID" สำหรับคำขอ API ที่เฉพาะเจาะจงนี้จากการติดตาม ดังนี้
   1. เลือกเฟส "บันทึกข้อมูล Analytics" จากคำขอ
   2. เลื่อนลงและจดค่าของ X-Apigee.Message-ID

   

7. ดูบันทึกของ Message Processor (/opt/apigee/var/log/edge-message-processor/system.log) และค้นหารหัสข้อความที่ไม่ซ้ำกัน ที่จดไว้ในขั้นตอนที่ 6 ข้อความแสดงข้อผิดพลาดต่อไปนี้ปรากฏขึ้นสำหรับคำขอ API ที่เฉพาะเจาะจง

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

   ข้อผิดพลาดข้างต้นระบุว่านโยบายการเรียกใช้บริการล้มเหลวเนื่องจากข้อผิดพลาดการเชื่อมต่อ หมดเวลาขณะเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์

8. หากต้องการพิจารณาสาเหตุของข้อผิดพลาดการเชื่อมต่อหมดเวลา ให้เรียกใช้คำสั่ง telnet ไปยังเซิร์ฟเวอร์แบ็กเอนด์จาก Message Processor คำสั่ง telnet แสดงข้อผิดพลาด "Connection timed out" ดังที่แสดงด้านล่าง

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

   โดยปกติแล้วข้อผิดพลาดนี้จะเกิดขึ้นในสถานการณ์ต่อไปนี้

   • เมื่อไม่ได้กำหนดค่าเซิร์ฟเวอร์แบ็กเอนด์ให้ยอมรับการรับส่งข้อมูลจาก Edge Message Processor
   • หากเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้ฟังพอร์ตที่เฉพาะเจาะจง

   ในตัวอย่างที่แสดงข้างต้น แม้ว่านโยบายการแยกตัวแปรจะล้มเหลว แต่สาเหตุที่แท้จริง คือ Edge ไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ในนโยบายการเรียกใช้บริการ และสาเหตุของความล้มเหลวนี้คือไม่ได้กำหนดค่าเซิร์ฟเวอร์แบ็กเอนด์ให้ยอมรับการรับส่งข้อมูลจาก Edge Message Processor

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

วิธีแก้ไขตัวอย่างที่ 2

1. แก้ไขสาเหตุของข้อผิดพลาดหรือความล้มเหลวในนโยบายการแยกตัวแปรอย่างเหมาะสม
2. ในตัวอย่างที่แสดงข้างต้น วิธีแก้ปัญหาคือการแก้ไขการกำหนดค่าเครือข่ายเพื่อให้ Edge Message Processor ส่งการรับส่งข้อมูลไปยังเซิร์ฟเวอร์แบ็กเอนด์ได้ โดยการเพิ่มที่อยู่ IP ของ Message Processor ลงในรายการที่อนุญาตในเซิร์ฟเวอร์แบ็กเอนด์ที่เฉพาะเจาะจง เช่น ใน Linux คุณสามารถใช้ iptables เพื่ออนุญาตการรับส่งข้อมูลจาก ที่อยู่ IP ของ Message Processor ในเซิร์ฟเวอร์แบ็กเอนด์

ตัวอย่างที่ 3: ความล้มเหลวในนโยบาย JavaCallout

ตอนนี้มาดูอีกตัวอย่างหนึ่งที่ข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 เกิดจากข้อผิดพลาด ในนโยบาย Java Callout และดูวิธีแก้ปัญหาและแก้ไขข้อผิดพลาด

1. การติดตาม UI ต่อไปนี้แสดงรหัสสถานะ 500 ที่เกิดจากข้อผิดพลาดในนโยบาย Java Callout

   

2. เลือกโฟลว์ที่ชื่อ "ข้อผิดพลาด" ตามด้วยนโยบาย Java Callout ที่ล้มเหลว เพื่อดูรายละเอียดข้อผิดพลาดดังที่แสดงในรูปภาพด้านล่าง

   

3. ในตัวอย่างนี้ พร็อพเพอร์ตี้ "ข้อผิดพลาด" ในส่วนพร็อพเพอร์ตี้เผยให้เห็น ว่าความล้มเหลวเกิดจากการใช้รหัสผ่านที่หมดอายุขณะเชื่อมต่อกับฐานข้อมูล Oracle จากภายในนโยบาย JavaCallout Java Callout ของคุณเองจะทำงานแตกต่างกันและจะ แสดงข้อความอื่นในพร็อพเพอร์ตี้ ข้อผิดพลาด
4. ตรวจสอบโค้ดนโยบาย JavaCallout และยืนยันการกำหนดค่าที่ถูกต้องที่จะใช้

วิธีแก้ไขตัวอย่างที่ 3

แก้ไขโค้ดหรือการกำหนดค่า Java Callout อย่างเหมาะสมเพื่อหลีกเลี่ยงข้อยกเว้นรันไทม์ ใน ตัวอย่างความล้มเหลวของ Java Callout ที่แสดงข้างต้น คุณจะต้องใช้รหัสผ่านที่ถูกต้อง เพื่อเชื่อมต่อกับฐานข้อมูล Oracle เพื่อแก้ไขปัญหา

ข้อผิดพลาดในเซิร์ฟเวอร์แบ็กเอนด์

ข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 อาจเกิดจากเซิร์ฟเวอร์แบ็กเอนด์ด้วย ส่วนนี้ จะอธิบายวิธีแก้ปัญหาหากข้อผิดพลาดมาจากเซิร์ฟเวอร์แบ็กเอนด์

การวินิจฉัย

ขั้นตอนการวินิจฉัยสำหรับผู้ใช้ทุกคน

สาเหตุของข้อผิดพลาดแบ็กเอนด์อื่นๆ อาจแตกต่างกันไปอย่างมาก คุณจะต้องวินิจฉัยแต่ละสถานการณ์ แยกกัน

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

หากคุณไม่มีเซสชันการติดตามสำหรับการเรียก API ที่ล้มเหลว ให้ทำดังนี้

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

หากคุณมีเซสชันการติดตามสำหรับการเรียก API ที่ล้มเหลว ให้ทำดังนี้

หากคุณมีเซสชันการติดตาม ขั้นตอนต่อไปนี้จะช่วยคุณวินิจฉัยปัญหา

1. ในเครื่องมือการติดตาม ให้เลือกคำขอ API ที่ล้มเหลวโดยมีข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 Error.
2. เลือกเฟส "การตอบกลับที่ได้รับจากเซิร์ฟเวอร์เป้าหมาย" จากคำขอ API ที่ล้มเหลว ดังที่แสดงในรูปภาพด้านล่าง:

   

3. ตรวจสอบส่วน "เนื้อหาการตอบกลับ" เพื่อดูรายละเอียดเกี่ยวกับข้อผิดพลาด

   

4. ในตัวอย่างนี้ เนื้อหาการตอบกลับซึ่งเป็น SOAP Envelope แสดงสตริงข้อผิดพลาดเป็น "Not Authorized" ข้อความ. สาเหตุที่เป็นไปได้มากที่สุดของปัญหานี้คือผู้ใช้ไม่ได้ส่งข้อมูลเข้าสู่ระบบที่เหมาะสม (ชื่อผู้ใช้/รหัสผ่าน, โทเค็นเพื่อการเข้าถึง ฯลฯ) ไปยังเซิร์ฟเวอร์แบ็กเอนด์ ปัญหานี้สามารถแก้ไขได้โดยส่งข้อมูลเข้าสู่ระบบที่ถูกต้องไปยัง เซิร์ฟเวอร์แบ็กเอนด์

หากแบ็กเอนด์เป็นเซิร์ฟเวอร์ Node.js ให้ทำดังนี้

1. หากแบ็กเอนด์เป็น เซิร์ฟเวอร์แบ็กเอนด์ Node.js ให้ตรวจสอบบันทึกของ Node.js สำหรับพร็อกซี API ที่เฉพาะเจาะจงใน UI ของ Edge (ทั้งผู้ใช้ Public และ Private Cloud สามารถ ตรวจสอบบันทึกของ Node.js ได้) หากคุณเป็นผู้ใช้ Edge Private Cloud คุณ ยังสามารถตรวจสอบบันทึกของ Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) เพื่อดูรายละเอียดเพิ่มเติม เกี่ยวกับข้อผิดพลาดได้ด้วย
   
   

   ตัวเลือกบันทึกของ NodeJS ใน UI ของ Edge - แท็บภาพรวมของพร็อกซี API

   

วิธีแก้ไข

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

หากต้องการความช่วยเหลือเพิ่มเติมในการแก้ปัญหาข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 หรือสงสัย ว่าปัญหาเกิดจาก Edge โปรดติดต่อ Apigee ทีมสนับสนุน

การระบุแหล่งที่มาของปัญหา

ใช้ขั้นตอนใดขั้นตอนหนึ่งต่อไปนี้เพื่อพิจารณาว่าข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 เกิดขึ้น ระหว่างการดำเนินการนโยบายภายในพร็อกซี API หรือเกิดจากเซิร์ฟเวอร์แบ็กเอนด์

การใช้การติดตามใน UI

หมายเหตุ: ทั้งผู้ใช้ Public และ Private Cloud สามารถทำตามขั้นตอนในส่วนนี้ได้

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

การใช้การตรวจสอบ API

หมายเหตุ: ผู้ใช้ Public Cloud เท่านั้นที่ทำตามขั้นตอนในส่วนนี้ได้

การตรวจสอบ API ช่วยให้คุณแยกพื้นที่ที่มีปัญหาได้อย่างรวดเร็วเพื่อวินิจฉัยข้อผิดพลาด ประสิทธิภาพ และปัญหาความหน่วง รวมถึงแหล่งที่มาของปัญหา เช่น แอปของนักพัฒนาแอป พร็อกซี API เป้าหมายแบ็กเอนด์ หรือแพลตฟอร์ม API

ดูสถานการณ์ตัวอย่าง ที่แสดงวิธีแก้ปัญหา 5xx กับ API โดยใช้การตรวจสอบ API เช่น คุณอาจต้องการตั้งค่าการแจ้งเตือนให้แจ้งเมื่อจำนวนรหัสสถานะ 500 หรือข้อผิดพลาด steps.servicecallout.ExecutionFailed เกินเกณฑ์ที่กำหนด

การใช้บันทึกการเข้าถึง NGINX

หมายเหตุ: ขั้นตอนในส่วนนี้มีไว้สำหรับผู้ใช้ Edge Private Cloud เท่านั้น

คุณยังดูบันทึกการเข้าถึง NGINX เพื่อพิจารณาว่ารหัสสถานะ 500 เกิดขึ้น ระหว่างการดำเนินการนโยบายภายในพร็อกซี API หรือเกิดจากเซิร์ฟเวอร์แบ็กเอนด์ ซึ่งจะมีประโยชน์อย่างยิ่งหากปัญหาเกิดขึ้นในอดีตหรือหากปัญหาเกิดขึ้นเป็นระยะๆ และคุณไม่สามารถบันทึกการติดตามใน UI ได้ ทำตามขั้นตอนต่อไปนี้เพื่อพิจารณาข้อมูลนี้จาก บันทึกการเข้าถึง NGINX

1. ตรวจสอบบันทึกการเข้าถึง NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log )
2. ค้นหาว่ามีข้อผิดพลาด 500 สำหรับพร็อกซี API ที่เฉพาะเจาะจงในช่วงเวลาที่เฉพาะเจาะจงหรือไม่
3. หากมีข้อผิดพลาด 500 ให้ตรวจสอบว่าข้อผิดพลาดเป็นข้อผิดพลาดของนโยบายหรือเซิร์ฟเวอร์เป้าหมาย ดังที่แสดงด้านล่าง

   ตัวอย่างรายการที่แสดงข้อผิดพลาดของนโยบาย

   

   ตัวอย่างรายการที่แสดงข้อผิดพลาดของเซิร์ฟเวอร์เป้าหมาย

   

4. เมื่อระบุได้แล้วว่าเป็นข้อผิดพลาดของนโยบายหรือเซิร์ฟเวอร์เป้าหมาย ให้ทำดังนี้
   1. ไปที่ ข้อผิดพลาดในการดำเนินการในนโยบาย Edge หาก เป็นข้อผิดพลาดของนโยบาย
   2. ไปที่ข้อผิดพลาดในเซิร์ฟเวอร์แบ็กเอนด์หากเป็นข้อผิดพลาดของเซิร์ฟเวอร์เป้าหมาย