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 ส่วนตัวและระบบคลาวด์สาธารณะ

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

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

การตรวจสอบ API

ขั้นตอนที่ 1: การใช้ API Monitoring

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

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

  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. ตรวจสอบว่าเปิดใช้ Show FlowInfos ทั้งหมดแล้ว โดยทำดังนี้

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

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

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

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

  7. เลื่อนลงไปที่ส่วน Phase Details Response Headers และระบุค่าของ 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. ระบุ Fault Code, Fault Source สำหรับข้อผิดพลาดที่พบโดยใช้ API Monitoring, เครื่องมือ Trace หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ในขั้นตอนการวินิจฉัยทั่วไป
  2. หากแหล่งที่มาของข้อผิดพลาดคือ target และรหัสข้อผิดพลาดคือ messaging.adaptors.http.flow.ErrorResponseCode แสดงว่าเซิร์ฟเวอร์แบ็กเอนด์แสดงข้อผิดพลาด
  3. คุณสามารถทำตามขั้นตอนใดขั้นตอนหนึ่งต่อไปนี้เพื่อวิเคราะห์สาเหตุของปัญหา

    Trace

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

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

    1. ใน Trace ให้เลือกคำขอ 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. หากเข้าถึงเซิร์ฟเวอร์แบ็กเอนด์ได้จาก Message Processor เท่านั้น คุณจะใช้คําสั่ง curl, Postman หรือไคลเอ็นต์ REST อื่นๆ และเรียกใช้ API เซิร์ฟเวอร์แบ็กเอนด์โดยตรงจาก Message Processor ได้

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

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

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

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

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

    1. หากคุณมีการติดตามสำหรับคำขอที่ล้มเหลว ให้ไปที่เฟสคำขอที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย แล้วคลิกแสดง 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