504 เกตเวย์หมดเวลาจากเซิร์ฟเวอร์แบ็กเอนด์

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์จะได้รับรหัสสถานะ HTTP 504 พร้อมข้อความ "ระยะหมดเวลาของเกตเวย์" ในการตอบกลับการเรียก API

การตอบกลับข้อผิดพลาดนี้บ่งบอกว่าไคลเอ็นต์ไม่ได้รับการตอบกลับอย่างทันท่วงทีจาก Apigee Edge หรือเซิร์ฟเวอร์แบ็กเอนด์ขณะดำเนินการเรียก API

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

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

HTTP/1.1 504 Gateway Timeout

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

<html>
<head><title>504 Gateway Timeout</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Timeout</h1></center>
</body>
</html>

การหมดเวลาของเกตเวย์เกิดจากอะไร

เส้นทางทั่วไปสำหรับคำขอ API ที่สร้างผ่าน Apigee Edge คือไคลเอ็นต์ -> เราเตอร์ -> ผู้ประมวลผลข้อความ -> เซิร์ฟเวอร์แบ็กเอนด์ ดังที่แสดงในรูปภาพด้านล่าง

เส้นทางคำขอ API

แอปพลิเคชันไคลเอ็นต์ เราเตอร์ และเครื่องมือประมวลผลข้อความจะได้รับการกำหนดค่าด้วยค่าระยะหมดเวลาที่เหมาะสม Apigee Edge ต้องการการตอบกลับสำหรับคำขอ API ทุกรายการภายในระยะเวลาตามค่าระยะหมดเวลา ถ้าไม่ได้รับการตอบสนองภายในระยะเวลาที่กำหนด ระบบจะแสดงการตอบกลับการหมดเวลาของเกตเวย์ 504

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

ใน Apigee Edge สาเหตุทั่วไปของการตอบกลับระยะหมดเวลาของเกตเวย์ 504 จากเซิร์ฟเวอร์แบ็กเอนด์คือ

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

เซิร์ฟเวอร์แบ็กเอนด์ตอบกลับด้วยระยะหมดเวลาของเกตเวย์ 504

เซิร์ฟเวอร์แบ็กเอนด์อาจตอบกลับด้วยรหัสตอบกลับ HTTP เป็น 504 Gateway Timeout

การวินิจฉัย

ส่วนนี้จะอธิบายวิธีวิเคราะห์การหมดเวลาของเกตเวย์ 504 อย่างถูกต้อง ระบบจะแสดงขั้นตอนสำหรับทั้งผู้ใช้ Private และ Cloud Cloud สาธารณะ

ขั้นตอนที่ 1: การใช้การติดตาม (ผู้ใช้ระบบคลาวด์ส่วนตัวและสาธารณะ)

  1. เปิดใช้การติดตามใน UI ของ Apigee สำหรับ API ที่ได้รับผลกระทบ
  2. ส่งคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์
  3. หากคำขอ API ที่ล้มเหลวแสดงการตอบกลับ 504 จากเซิร์ฟเวอร์แบ็กเอนด์ใน Trace สาเหตุของระยะหมดเวลาของเกตเวย์ 504 จะเป็นเซิร์ฟเวอร์แบ็กเอนด์
  4. หากต้องการระบุเวลาในการตอบกลับ ให้คลิกเฟสการตอบกลับที่ได้รับจากเซิร์ฟเวอร์เป้าหมายใน Trace ในตัวอย่างที่แสดง เวลาที่ผ่านไปคือ 60, 004 มิลลิวินาที

    รายละเอียดระยะจาก UI

    ส่วนรายละเอียดระยะมีข้อมูลเพิ่มเติมต่อไปนี้

    • ซึ่งไฮไลต์การตอบกลับ 504 Gateway Timeout ที่ได้รับจากเซิร์ฟเวอร์แบ็กเอนด์
    • ส่วนเนื้อหาการตอบกลับจะแสดงเนื้อหาการตอบกลับทั้งหมดจากเซิร์ฟเวอร์แบ็กเอนด์ ตามที่ได้กล่าวไว้ก่อนหน้านี้ รูปแบบและเนื้อหาของเพย์โหลดการตอบกลับอาจแตกต่างกันไปโดยขึ้นอยู่กับการใช้งานเซิร์ฟเวอร์แบ็กเอนด์
    • ส่วนส่วนหัวการตอบกลับ > เซิร์ฟเวอร์ อาจระบุตำแหน่งของการตอบกลับ
  5. หากต้องการดูข้อมูล Analytics และยืนยันการวิเคราะห์ ให้คลิกเฟสข้อมูล Analytics ที่บันทึกใน Trace ดังที่แสดงในรูปภาพด้านล่าง

    รายละเอียด Analytics จากการติดตาม

    ส่วนส่วนหัวการตอบกลับในรายละเอียดเฟสจะแสดงค่าของ X-Apigee-fault-code และ X-Apigee-fault-source ดังที่แสดงในรูปด้านล่าง

    รายละเอียดระยะการวิเคราะห์จาก UI

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

    ส่วนหัวการตอบกลับ ค่า
    X-Apigee-fault-source เป้าหมาย
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  6. ตรวจสอบ เชนพร็อกซี ทำตามขั้นตอนต่อไปนี้เพื่อดูว่าเซิร์ฟเวอร์แบ็กเอนด์เรียกใช้พร็อกซีอื่นใน Apigee หรือไม่
    1. กลับไปที่เฟสคำขอที่ส่งไปยังเซิร์ฟเวอร์เป้าหมาย แล้วคลิกปุ่มแสดง Curl เพื่อดูชื่อแทนโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์
    2. หากชื่อแทนโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ชี้ไปยังชื่อแทนโฮสต์เสมือน แสดงว่าใช้เชนพร็อกซีอยู่แล้ว ทำขั้นตอนข้างต้นซ้ำกับพร็อกซีที่เชื่อมโยงแต่ละรายการเพื่อวิเคราะห์สาเหตุของการตอบกลับข้อผิดพลาดการหมดเวลาของเกตเวย์ 504 คุณวินิจฉัยการหมดเวลาของเกตเวย์ 504 ที่เกิดขึ้นในพร็อกซีแบบเชนในระยะอื่นๆ ของรอบคำขอ/การตอบกลับได้โดยใช้ Playbook นี้
    3. หากชื่อแทนโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ชี้ไปยังเซิร์ฟเวอร์แบ็กเอนด์ ให้ดําเนินการต่อด้วยการแก้ปัญหา

ขั้นตอนที่ 2: เรียกใช้ API ของเซิร์ฟเวอร์แบ็กเอนด์โดยตรง (ผู้ใช้แบบสาธารณะและ Private Cloud)

เรียกใช้เซิร์ฟเวอร์แบ็กเอนด์โดยตรงเพื่อยืนยันลักษณะการตอบกลับของระยะหมดเวลาเกตเวย์ 504 เดียวกันกับที่พบเมื่อส่งคำขอผ่าน Apigee Edge

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

ขั้นตอนที่ 3: ตรวจสอบบันทึกการเข้าถึง NGINX (เฉพาะผู้ใช้ Private Cloud)

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

  1. ดูบันทึกการเข้าถึง NGINX โดยใช้คำสั่งนี้ 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  2. ตรวจสอบการตอบกลับข้อผิดพลาด 504 ของพร็อกซี API ที่ได้รับผลกระทบ คุณจะตรวจสอบระยะเวลาที่เจาะจง ปัญหานี้เกิดขึ้นในอดีตหรือไม่ หรือระบุว่าคำขอยังคงล้มเหลวโดยมีการตอบกลับเป็นข้อผิดพลาด 504 หรือไม่
  3. หากมีการตอบกลับข้อผิดพลาด 504 ให้พิจารณาว่าการตอบกลับข้อผิดพลาดนั้นมาจากเซิร์ฟเวอร์แบ็กเอนด์หรือไม่

    4. รูปด้านล่างคือตัวอย่างของรายการบันทึก NGINX ที่แสดงการตอบสนองข้อผิดพลาด 504 ซึ่งเกิดจากเซิร์ฟเวอร์เป้าหมาย

    ตัวอย่างบันทึก nginx

    หากช่อง X-Apigee-fault-source และ X-Apigee-fault-code มีค่าที่แสดงในตารางด้านล่าง แสดงว่าการตอบกลับด้วย 504 จะมาจากเซิร์ฟเวอร์แบ็กเอนด์

    ส่วนหัวการตอบกลับ ค่า
    X-Apigee-fault-source เป้าหมาย
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  4. ตรวจสอบพร็อกซี API ที่ได้รับผลกระทบเพื่อตรวจหาเชนพร็อกซี เช่น เซิร์ฟเวอร์แบ็กเอนด์/ปลายทางปลายทางเรียกใช้พร็อกซีอื่นใน Apigee หากพร็อกซี API ใช้ห่วงโซ่พร็อกซี ให้ทำขั้นตอนด้านบนซ้ำสำหรับพร็อกซีที่เชนแต่ละรายการเพื่อวิเคราะห์สาเหตุของการตอบกลับข้อผิดพลาด 504 การหมดเวลาของเกตเวย์ 504 การหมดเวลาของเกตเวย์ที่เกิดขึ้นในพร็อกซีแบบเชนในระยะอื่นๆ สามารถวิเคราะห์ได้โดยใช้ Playbook นี้
  5. หากไม่มี เชนพร็อกซีและการตอบสนองข้อผิดพลาด 504 มาจากเซิร์ฟเวอร์แบ็กเอนด์ ให้ไปที่การแก้ปัญหา

ขั้นตอนที่ 4: การใช้ API Monitoring (ผู้ใช้ระบบคลาวด์สาธารณะเท่านั้น)

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

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

ความละเอียด

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

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

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

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

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

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

  • สังเกตข้อความแสดงข้อผิดพลาดสำหรับคำขอที่ไม่สำเร็จ
  • ชื่อสภาพแวดล้อม
  • แพ็กเกจพร็อกซี API
  • ไฟล์การติดตามที่มีคำขอ API ได้รับการตอบกลับแสดงข้อผิดพลาดระยะหมดเวลาของเกตเวย์ 504
  • บันทึกการเข้าถึง NGINX 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  • บันทึกตัวประมวลผลข้อความ 
    /opt/apigee/var/log/edge-message-processor/logs/system.log