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

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

วิดีโอ

วิดีโอ คำอธิบาย
500 ข้อผิดพลาดภายในเซิร์ฟเวอร์ - เกิดจากแบ็กเอนด์ แสดง 500 Internal Server Error แบบเรียลไทม์ที่เกิดจากเซิร์ฟเวอร์แบ็กเอนด์พร้อมกับขั้นตอนในการแก้ปัญหาและแก้ไขข้อผิดพลาด

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับรหัสสถานะ HTTP 500 พร้อมข้อความ Internal Server Error เป็นการตอบกลับสำหรับการเรียก API

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

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

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

HTTP/1.1 500 Internal Server Error

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

ตัวอย่าง #1

ตัวอย่างการตอบกลับของเซิร์ฟเวอร์แบ็กเอนด์ที่ 1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

ตัวอย่าง #2

ตัวอย่างการตอบกลับของเซิร์ฟเวอร์แบ็กเอนด์ที่ 2

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

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

500 Internal Server Error อาจส่งคืนโดยเซิร์ฟเวอร์แบ็กเอนด์เนื่องจาก สาเหตุต่างๆ ได้ Playbook นี้อธิบายวิธีแก้ปัญหาโดยใช้ขั้นตอนทั่วไปและแก้ปัญหานี้ ไม่ว่าจะเกิดจากสาเหตุใด

สาเหตุที่เป็นไปได้สำหรับปัญหานี้มีดังนี้

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

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

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

การตรวจสอบ API

ขั้นตอนที่ 1: การใช้การตรวจสอบ API

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

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

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

  3. ไปที่ วิเคราะห์ > การตรวจสอบ API > หน้าตรวจสอบ
  4. เลือกกรอบเวลาที่คุณพบข้อผิดพลาด

  5. พล็อตรหัสข้อผิดพลาดเทียบกับเวลา

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

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

  7. ข้อมูลเกี่ยวกับรหัสข้อผิดพลาด messaging.adaptors.http.flow.ErrorResponseCode จะแสดงเป็น แสดงอยู่ด้านล่าง

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

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

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

  9. จากหน้าต่าง Logs ให้จดรายละเอียดต่อไปนี้
    • รหัสข้อความคำขอ
    • รหัสสถานะ: 500
    • แหล่งที่มาของข้อผิดพลาด: target
    • รหัสข้อผิดพลาด: messaging.adaptors.http.flow.ErrorResponseCode

Trace

ขั้นตอนที่ 2: การใช้เครื่องมือติดตาม

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

  1. เปิดใช้เซสชันการติดตาม และ
    • รอข้อผิดพลาด 500 Internal Server Error ที่มีรหัสข้อผิดพลาด messaging.adaptors.http.flow.ErrorResponseCodeจะเกิดขึ้น หรือ
    • หากคุณทำให้เกิดปัญหาซ้ำได้ ให้เรียกใช้ API เพื่อจำลองปัญหา 500 Internal Server Error

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

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

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

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

  6. ไปที่ระยะ AX (Analytics Data Recorded) ในการติดตามและคลิก

  7. เลื่อนลงไปที่ส่วนส่วนหัวการตอบกลับรายละเอียดระยะ และมองหา ของ X-Apigee-fault-code และ X-Apigee-fault-source และ X-Apigee-Message-ID ดังที่แสดงด้านล่าง

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

  8. โปรดสังเกตค่าของ X-Apigee-fault-code, X-Apigee-fault-source, และ X-Apigee-Message-ID
    9. ส่วนหัวการตอบกลับ ค่า
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

ขั้นตอนที่ 3: การใช้บันทึกการเข้าถึง NGINX

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

  1. หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถใช้บันทึกการเข้าถึง NGINX ในการระบุ ข้อมูลคีย์เกี่ยวกับ HTTP 500 Internal Server Error

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

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

  3. ค้นหาว่ามีข้อผิดพลาด 500 ที่มีรหัสข้อผิดพลาดไหม messaging.adaptors.http.flow.ErrorResponseCode ในช่วงระยะเวลาหนึ่ง (หากปัญหาเกิดขึ้นใน ที่ผ่านมา) หรือมีคำขอใดที่ยังคงดำเนินการไม่สำเร็จกับ 500

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

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

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

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

    ส่วนหัว ค่า
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

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

การวินิจฉัย

500 Internal Server Error ที่ตอบกลับโดยเซิร์ฟเวอร์แบ็กเอนด์สามารถ เกิดจากหลายสาเหตุ คุณจะต้องวิเคราะห์แต่ละสถานการณ์แยกกัน

  1. กำหนดรหัสข้อผิดพลาด แหล่งที่มาของข้อผิดพลาดสำหรับข้อผิดพลาดที่พบโดยใช้การตรวจสอบ API เครื่องมือติดตามหรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ในขั้นตอนการวิเคราะห์ทั่วไป
  2. หากแหล่งที่มาของข้อผิดพลาดคือ target และโค้ดความผิดพลาดคือ messaging.adaptors.http.flow.ErrorResponseCode นั่นหมายถึงว่า จะส่งกลับข้อผิดพลาดโดยเซิร์ฟเวอร์แบ็กเอนด์
  3. ใช้ขั้นตอนใดขั้นตอนหนึ่งต่อไปนี้เพื่อวิเคราะห์สาเหตุของปัญหา

    Trace

    เมื่อใช้ Trace

    ถ้าคุณมีเซสชันการติดตามสำหรับความล้มเหลว โปรดทำตามขั้นตอนต่อไปนี้

    1. ในการติดตาม ให้เลือกคำขอ API ที่ดำเนินการไม่สำเร็จด้วย 500 Internal Server Error

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

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

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

      ตัวอย่างเนื้อหาคำตอบ

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

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

    เรียกใช้เซิร์ฟเวอร์แบ็กเอนด์

    การเรียกไปยังเซิร์ฟเวอร์แบ็กเอนด์โดยตรง:

    คุณเรียกไปยังเซิร์ฟเวอร์แบ็กเอนด์โดยตรงได้โดยทำดังนี้

    • ตรวจสอบว่าคุณได้รับ 500 Internal Server Error เดียวกันหรือไม่ การตอบกลับตามที่ได้รับเมื่อส่งคำขอผ่าน Apigee Edge
    • ตรวจสอบข้อความแสดงข้อผิดพลาด (การตอบกลับ) ที่ได้รับจากเซิร์ฟเวอร์แบ็กเอนด์

    ทำตามขั้นตอนต่อไปนี้เพื่อเรียกโดยตรงไปยังเซิร์ฟเวอร์แบ็กเอนด์

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

    3. หากเซิร์ฟเวอร์ส่วนหลังสามารถเข้าถึงได้จากโปรแกรมประมวลผลข้อความเท่านั้น คุณสามารถ ใช้คำสั่ง curl, Postman หรือไคลเอ็นต์ REST อื่นๆ และเรียกใช้ API เซิร์ฟเวอร์แบ็กเอนด์โดยตรงจาก Message Processor

    4. ตรวจสอบว่าบริการแบ็กเอนด์กำลังส่งคืน 500 Internal Server Error จริงหรือไม่ และตรวจสอบข้อความแสดงข้อผิดพลาด (การตอบกลับ) ที่เซิร์ฟเวอร์แบ็กเอนด์แสดง และ ระบุสาเหตุของข้อผิดพลาดนี้

    บันทึกของเซิร์ฟเวอร์แบ็กเอนด์

    การใช้บันทึกเซิร์ฟเวอร์แบ็กเอนด์

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

  4. ตรวจสอบว่าคุณกำลังใช้ การเชื่อมโยงพร็อกซีในปลายทางเป้าหมายที่เจาะจงของพร็อกซี API ที่ล้มเหลว กล่าวคือ หากเซิร์ฟเวอร์/ปลายทางเป้าหมายเรียกใช้พร็อกซีอื่นใน Apigee Edge ในการพิจารณาในเรื่องนี้:

    1. หากคุณมีการติดตามสำหรับคำขอที่ล้มเหลว ให้ไปที่คำขอที่ส่งแล้ว ไปยังเฟสเซิร์ฟเวอร์เป้าหมาย แล้วคลิก Show Curl

    2. หน้าต่าง Curl for Request Sent to Target Server จะเปิดขึ้นเพื่อให้คุณ กำหนดชื่อแทนของโฮสต์เซิร์ฟเวอร์เป้าหมายได้
    3. ตรวจสอบปลายทางเป้าหมายของพร็อกซี API และดูว่าเซิร์ฟเวอร์แบ็กเอนด์ URL หรือชื่อโฮสต์ในเซิร์ฟเวอร์เป้าหมายชี้ไปที่พร็อกซีอื่นหรือของคุณเอง เซิร์ฟเวอร์แบ็กเอนด์
    4. ถ้าชื่อแทนโฮสต์ของเซิร์ฟเวอร์เป้าหมายชี้ไปยังชื่อแทนโฮสต์เสมือน คือการทำพร็อกซี ในกรณีนี้ คุณต้องทำขั้นตอนด้านบนซ้ำทั้งหมด พร็อกซีแบบเครือข่ายเดียวกันจนกว่าคุณจะทราบว่าอะไรคือสาเหตุที่แท้จริงของ 500 Internal Server Error ในกรณีนี้ 500 Internal Server Error อาจ เกิดขึ้นในพร็อกซีเครือข่ายอื่นๆ ที่ขั้นตอนอื่นๆ ได้เช่นกัน ซึ่งสามารถวินิจฉัยและ แก้ไขปัญหาได้โดยใช้คำแนะนำใน Playbook นี้หรือใน Playbook 500 ข้อผิดพลาดภายในเซิร์ฟเวอร์
    5. หากชื่อแทนโฮสต์ของเซิร์ฟเวอร์เป้าหมายชี้ไปที่เซิร์ฟเวอร์แบ็กเอนด์ ให้ไปที่ การแก้ปัญหา

ความละเอียด

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

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

สิ่งสำคัญที่ควรทราบ

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

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

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

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

  • ชื่อองค์กร
  • ชื่อสภาพแวดล้อม
  • ชื่อพร็อกซี API
  • ทำตามคำสั่ง curl เพื่อทำให้เกิดข้อผิดพลาด 500 ซ้ำ
  • ไฟล์การติดตามที่มีคำขอที่มี 500 Internal Server Error
  • หากไม่มีข้อผิดพลาด 500 ในปัจจุบัน โปรดระบุเวลา ช่วงเวลาที่มีข้อมูลเขตเวลาเมื่อเกิดข้อผิดพลาด 500 รายการในอดีต

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

  • พบข้อความแสดงข้อผิดพลาดทั้งหมดสำหรับคำขอที่ล้มเหลว
  • องค์กร ชื่อสภาพแวดล้อม และชื่อพร็อกซี API ที่คุณสังเกตการณ์ ข้อผิดพลาด 500 รายการ
  • แพ็กเกจพร็อกซี API
  • ไฟล์การติดตามที่มีคำขอที่มี 500 Internal Server Error
  • บันทึกการเข้าถึง 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
  • ช่วงเวลาที่มีข้อมูลเขตเวลาเมื่อเกิดข้อผิดพลาด 500 รายการ