504 เกตเวย์หมดเวลา

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

ลักษณะปัญหา

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

รหัสสถานะ HTTP - ข้อผิดพลาด 504 Gateway Timeout บ่งชี้ว่าไคลเอ็นต์ ไม่ได้รับการตอบสนองจาก Edge Gateway หรือเซิร์ฟเวอร์แบ็กเอนด์อย่างทันท่วงทีในระหว่างการดําเนินการ API

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

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

HTTP/1.1 504 Gateway Timeout

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

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

สาเหตุของระยะหมดเวลาของเกตเวย์คืออะไร

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

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

ตารางต่อไปนี้แสดงรายละเอียดเพิ่มเติมเกี่ยวกับระยะหมดเวลาใน Edge

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

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

ใน Edge สาเหตุทั่วไปของข้อผิดพลาด 504 Gateway Timeout คือ

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

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

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

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

ส่วนต่อไปนี้อธิบายวิธีการวินิจฉัยและแก้ไขปัญหาในแต่ละหัวข้อ สถานการณ์

สถานการณ์ที่ 1 ตัวประมวลผลข้อความหมดเวลาก่อนที่เซิร์ฟเวอร์แบ็กเอนด์จะตอบสนอง

การวินิจฉัย

คุณใช้กระบวนการต่อไปนี้เพื่อวินิจฉัยได้หากเกิดข้อผิดพลาด 504 Gateway Timeout เนื่องจากเซิร์ฟเวอร์แบ็กเอนด์ที่ทำงานช้า

ขั้นตอนที่ 1 การใช้การติดตาม

หากปัญหายังคงอยู่ (ยังคงมีข้อผิดพลาด 504 รายการ) โปรดทำตามขั้นตอนด้านล่าง ขั้นตอน:

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

รายการต่อไปนี้แสดงตัวอย่างการติดตามที่แสดงให้เห็นว่าเซิร์ฟเวอร์แบ็กเอนด์ไม่ตอบสนอง หลังผ่านไป 55 วินาที ซึ่งจะทำให้เกิดข้อผิดพลาด 504 Gateway Timeout รายการ:

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

ขั้นตอนที่ 2 การใช้บันทึกของตัวประมวลผลข้อความ

  1. ตรวจสอบบันทึกของโปรแกรมประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log)

  2. หากพบข้อผิดพลาด Gateway Timeout และ onTimeoutRead สำหรับคำขอพร็อกซี API ที่เจาะจง ที่เวลาที่ระบุ ระบบจะระบุว่าเครื่องมือประมวลผลข้อความหมดเวลาแล้ว

    ตัวอย่างบันทึกโปรแกรมประมวลผลข้อความแสดงข้อผิดพลาดการหมดเวลาของเกตเวย์

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

    ในบันทึกของตัวประมวลผลข้อความข้างต้น คุณจะสังเกตเห็นว่าเซิร์ฟเวอร์แบ็กเอนด์จะแสดงด้วย IP ที่อยู่ XX.XX.XX.XX ไม่ตอบสนองแม้ว่าจะผ่านไป 55 วินาทีแล้ว (lastIO=55000ms) ตัวประมวลผลข้อความจึงหมดเวลาและแสดงข้อผิดพลาด 504 Gateway Timeout รายการ

    ตรวจสอบ: มีการควบคุมระยะหมดเวลาบน Message Processor อย่างไร

    • มีการควบคุมระยะหมดเวลาบน Message Processor อย่างไร ผู้ประมวลผลข้อความมักจะ ตั้งค่าด้วยค่าระยะหมดเวลาเริ่มต้นที่ 55 วินาที) ผ่านพร็อพเพอร์ตี้ HTTPTransport.io.timeout.millis ค่าระยะหมดเวลานี้คือ ใช้ได้สำหรับพร็อกซี API ทั้งหมดที่เป็นขององค์กรที่ให้บริการโดย ตัวประมวลผลข้อความ
      • ถ้าเซิร์ฟเวอร์ส่วนหลังไม่ตอบกลับภายใน 55 วินาที ระบบ ตัวประมวลผลหมดเวลาและส่งข้อผิดพลาด 504 Gateway Timeout รายการไปยังไคลเอ็นต์
    • ค่าการหมดเวลาที่ระบุในตัวประมวลผลข้อความสามารถ ถูกแทนที่โดยพร็อพเพอร์ตี้ io.timeout.millis ที่ระบุภายในพร็อกซี API ค่าการหมดเวลานี้ใช้ได้กับ API ที่เฉพาะเจาะจง พร็อกซีที่ระบุพร็อพเพอร์ตี้ที่กล่าวถึงข้างต้น ตัวอย่างเช่น หาก io.timeout.millis ได้รับการตั้งค่าเป็น 10 วินาทีในพร็อกซี API จากนั้น ระบบจะใช้ค่าการหมดเวลา 10 วินาทีสำหรับพร็อกซี API นี้
      • หากเซิร์ฟเวอร์แบ็กเอนด์ไม่ตอบสนองภายใน 10 วินาทีสําหรับ พร็อกซี API จากนั้นตัวประมวลผลข้อความจะหมดเวลาและส่ง 504 Gateway Timeout ไปยังไคลเอ็นต์

ความละเอียด

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

สถานการณ์ #2 - เราเตอร์หมดเวลาก่อนที่เครื่องมือประมวลผลข้อความ/เซิร์ฟเวอร์แบ็กเอนด์จะตอบสนอง

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

  • ค่าระยะหมดเวลาที่กำหนดไว้บนเราเตอร์สั้นกว่าค่าการหมดเวลาที่ตั้งไว้ใน Message ผู้ประมวลผลข้อมูล ตัวอย่างเช่น สมมติว่าระยะหมดเวลาบนเราเตอร์คือ 50 วินาที ขณะที่ข้อความ โปรเซสเซอร์ยาว 55 วินาที
    ระยะหมดเวลาบนเราเตอร์ หมดเวลาในตัวประมวลผลข้อความ
    50 วินาที 55 วินาที
  • ค่าการหมดเวลาในตัวประมวลผลข้อความจะถูกลบล้างด้วยค่าการหมดเวลาที่สูงกว่าโดยใช้ พร็อพเพอร์ตี้ io.timeout.millis ที่ตั้งค่าไว้ภายในการกำหนดค่าปลายทางเป้าหมาย ของพร็อกซี API

    ตัวอย่างเช่น หากมีการกำหนดค่าระยะหมดเวลาต่อไปนี้

    ระยะหมดเวลาบนเราเตอร์ หมดเวลาในตัวประมวลผลข้อความ หมดเวลาภายในพร็อกซี API
    57 วินาที 55 วินาที 120 วินาที

    แต่ตั้งค่า io.timeout.millis เป็น 120 วินาทีในพร็อกซี API

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    จากนั้น โปรแกรมประมวลผลข้อความจะไม่หมดเวลาหลังจาก 55 วินาที แม้ว่าจะหมดเวลาแล้วก็ตาม (55 วินาที) น้อยกว่าค่าระยะหมดเวลาในเราเตอร์ (57 วินาที) นั่นเป็นเพราะ ค่าการหมดเวลา 55 วินาทีในข้อความประมวลผลข้อความถูกลบล้างด้วยค่า 120 วินาทีที่ตั้งค่าไว้ภายในพร็อกซี API ดังนั้นค่าระยะหมดเวลาของ Message Processor สำหรับพร็อกซี API เฉพาะนี้ จะเป็น 120 วินาที

    เนื่องจากเราเตอร์มีค่าการหมดเวลาต่ำกว่า (57 วินาที) เมื่อเทียบกับการตั้งค่าเวลา 120 วินาทีภายใน พร็อกซี API เราเตอร์จะหมดเวลาหากเซิร์ฟเวอร์แบ็กเอนด์ไม่ตอบสนองหลังจาก 57 วินาที

การวินิจฉัย

  1. ตรวจสอบบันทึกการเข้าถึง NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

  2. หากเราเตอร์หมดเวลาก่อนตัวประมวลผลข้อความ คุณจะเห็นสถานะ 504 ในบันทึกการเข้าถึง NGINX สำหรับคำขอ API ที่เฉพาะเจาะจงและ message id จาก โปรแกรมประมวลผลข้อความจะถูกตั้งค่าเป็น - เนื่องจากเราเตอร์ไม่ได้รับการตอบสนอง จาก Message Processor ภายในระยะหมดเวลาที่กำหนดไว้ในเราเตอร์

    ตัวอย่างรายการบันทึก NGINX ที่แสดง 504 เนื่องจากเราเตอร์หมดเวลา

  3. ในตัวอย่างข้างต้น ให้สังเกตสถานะของ 504 บน NGINX ซึ่งเป็นรหัสข้อความจากข้อความ โปรเซสเซอร์อยู่ที่ - และเวลาทั้งหมดที่ผ่านไปคือ 57.001 วินาที เนื่องจากเราเตอร์หมดเวลา หลังผ่านไป 57.001 วินาที และเราไม่ได้รับการตอบสนองใดๆ จากโปรแกรมประมวลผลข้อความ
  4. ในกรณีนี้ คุณจะเห็นข้อยกเว้น Broken Pipe รายการในข้อความ บันทึกของผู้ประมวลผลข้อมูล (/opt/apigee/var/log/edge-message-processor/logs/system.log). 
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

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

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

ความละเอียด

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

      แนวคิด: ตั้งค่าระยะหมดเวลาสำหรับคอมโพเนนต์ต่างๆ ดังต่อไปนี้ คำสั่งซื้อ:

      ระยะหมดเวลาในไคลเอ็นต์ > ระยะหมดเวลาบนเราเตอร์ > หมดเวลาสำหรับข้อความ โปรเซสเซอร์ > ระยะหมดเวลาภายในพร็อกซี API
  2. หากเป็นเซิร์ฟเวอร์แบ็กเอนด์ NodeJS ให้ทำดังนี้
    1. ตรวจสอบว่าโค้ด NodeJS เรียกใช้เซิร์ฟเวอร์แบ็กเอนด์อื่นๆ หรือไม่ และโค้ดนั้นใช้ ใช้เวลานานในการตอบสนอง ตรวจสอบสาเหตุที่เซิร์ฟเวอร์แบ็กเอนด์ใช้เวลานานขึ้น และ แก้ไขปัญหาตามความเหมาะสม
    2. ตรวจสอบว่าระบบประมวลผลข้อความมีการใช้ CPU หรือหน่วยความจำสูงหรือไม่ ดังนี้
      1. หากตัวประมวลผลข้อความมีการใช้งาน CPU สูง ให้สร้างขึ้นมา 3 อัน ชุดข้อความ dumps ทุก 30 วินาทีโดยใช้คำสั่งต่อไปนี้ 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. หากตัวประมวลผลข้อความมีการใช้หน่วยความจำสูง ให้สร้าง ฮีป dump โดยใช้คำสั่งต่อไปนี้ 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. รีสตาร์ทโปรแกรมประมวลผลข้อความโดยใช้คำสั่งด้านล่าง จะทำให้ CPU ลดลง และหน่วยความจำ: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. ตรวจสอบการเรียก API เพื่อยืนยันว่าปัญหายังคงอยู่หรือไม่
      5. ติดต่อทีมสนับสนุนของ Apigee Edge เพื่อแจ้ง เทรดดัมพ์ ฮีปดัมป์ และบันทึกของโปรแกรมประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log)เพื่อช่วยเหลือ ตรวจสอบหาสาเหตุของการใช้ CPU/หน่วยความจำสูง

ตรวจสอบ: มีการควบคุมระยะหมดเวลาของเซิร์ฟเวอร์แบ็กเอนด์ NodeJS ใน Messages อย่างไร ผู้ประมวลผลข้อมูล

  • เซิร์ฟเวอร์แบ็กเอนด์ NodeJS จะทำงานภายในกระบวนการ JVM ของ Message Processor ค่าระยะหมดเวลาสำหรับเซิร์ฟเวอร์แบ็กเอนด์ NodeJS จะควบคุมผ่านพร็อพเพอร์ตี้ http.request.timeout.seconds ในไฟล์ nodejs.properties ช่วงเวลานี้ คุณสมบัติจะถูกตั้งค่าเป็น 0 โดยค่าเริ่มต้น กล่าวคือ ระยะหมดเวลาจะปิดใช้งานโดยค่าเริ่มต้นสำหรับ พร็อกซี API ที่เป็นขององค์กรที่ให้บริการโดยตัวประมวลผลข้อความนี้ ดังนั้นแม้ว่า เซิร์ฟเวอร์แบ็กเอนด์ NodeJS ใช้เวลานาน โดยโปรแกรมประมวลผลข้อความจะไม่หมดเวลา
  • อย่างไรก็ตาม หากเซิร์ฟเวอร์แบ็กเอนด์ NodeJS ใช้เวลานาน และหาก API ใช้เวลา คำขอคือ > 57 วินาที เราเตอร์จะหมดเวลาและส่ง 504 Gateway Timeout ไปยังไคลเอ็นต์

สถานการณ์ที่ 3 - แอปพลิเคชันไคลเอ็นต์หมดเวลาก่อนเราเตอร์/ตัวประมวลผลข้อความ/เซิร์ฟเวอร์แบ็กเอนด์ ตอบสนอง

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

  1. ค่าการหมดเวลาที่ตั้งไว้ในแอปพลิเคชันไคลเอ็นต์ต่ำกว่าค่าระยะหมดเวลาที่กำหนดไว้ใน เราเตอร์และตัวประมวลผลข้อความ:

    ตัวอย่างเช่น หากมีการกำหนดค่าระยะหมดเวลาต่อไปนี้

    หมดเวลาในไคลเอ็นต์ ระยะหมดเวลาบนเราเตอร์ หมดเวลาในตัวประมวลผลข้อความ
    50 วินาที 57 วินาที 55 วินาที

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

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

    ซึ่งจะทำให้ NGINX ตั้งรหัสสถานะ 499 ซึ่งบ่งชี้ว่าไคลเอ็นต์ได้ปิด การเชื่อมต่อ

การวินิจฉัย

  1. หากแอปพลิเคชันไคลเอ็นต์หมดเวลาก่อนที่จะได้รับการตอบสนองจากเราเตอร์ ก็จะ ปิดการเชื่อมต่อกับเราเตอร์ ในกรณีนี้ คุณจะเห็นรหัสสถานะ 499 ใน บันทึกการเข้าถึง NGINX สำหรับคำขอ API ที่เฉพาะเจาะจง

    ตัวอย่างรายการบันทึก NGINX ที่แสดงรหัสสถานะ 499

  2. ในตัวอย่างข้างต้น โปรดทราบว่าสถานะของ 499 บน NGINX และเวลาทั้งหมดที่ผ่านไปคือ 50.001 วินาที เหตุการณ์นี้แสดงว่าไคลเอ็นต์หมดเวลาหลังจากผ่านไป 50.001 วินาที
  3. ในกรณีนี้ คุณจะเห็นข้อยกเว้น Broken Pipe ในข้อความ บันทึกของผู้ประมวลผลข้อมูล (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
  4. หลังจากที่เราเตอร์หมดเวลา ระบบจะปิดการเชื่อมต่อกับตัวประมวลผลข้อความ เมื่อ โปรแกรมประมวลผลข้อความดำเนินการประมวลผลเสร็จเรียบร้อยแล้ว ระบบจะพยายามเขียนการตอบกลับไปยังเราเตอร์ เนื่องจากการเชื่อมต่อกับเราเตอร์ถูกปิดแล้ว คุณจะได้รับ Broken Pipe exception ใน Message Processor
  5. ข้อยกเว้นนี้เป็นไปตามกรณีที่อธิบายไว้ข้างต้น สาเหตุที่แท้จริงของ ข้อผิดพลาด 504 Gateway Timeout ยังคงเป็นว่าเซิร์ฟเวอร์แบ็กเอนด์ใช้เวลานานในการตอบสนองและ คุณต้องแก้ไขปัญหานั้น

ความละเอียด

  1. หากเป็นเซิร์ฟเวอร์แบ็กเอนด์ที่กำหนดเอง ให้ทำดังนี้
    1. ตรวจสอบเซิร์ฟเวอร์แบ็กเอนด์เพื่อหาสาเหตุที่ใช้เวลานานกว่า 57 วินาที และดูว่า สามารถแก้ไข/เพิ่มประสิทธิภาพเพื่อให้ตอบสนองได้เร็วขึ้น
    2. หากไม่สามารถแก้ไข/เพิ่มประสิทธิภาพเซิร์ฟเวอร์แบ็กเอนด์ หรือถ้าคุณทราบว่า เซิร์ฟเวอร์ส่วนหลังจะใช้เวลานาน จากนั้นเพิ่มค่าการหมดเวลาใน เราเตอร์ และ Message Processor

      แนวคิด: ตั้งค่าระยะหมดเวลาสำหรับคอมโพเนนต์ต่างๆ ดังต่อไปนี้ คำสั่งซื้อ:

      ระยะหมดเวลาในไคลเอ็นต์ > ระยะหมดเวลาบนเราเตอร์ > หมดเวลาสำหรับข้อความ โปรเซสเซอร์ > ระยะหมดเวลาภายในพร็อกซี API
  2. หากเป็นแบ็กเอนด์ NodeJS ให้ทำดังนี้
    1. ตรวจสอบว่าโค้ด NodeJS เรียกใช้เซิร์ฟเวอร์แบ็กเอนด์อื่นๆ หรือไม่ และโค้ดดังกล่าว ใช้เวลานานในการกลับมา ตรวจสอบว่าทำไมเซิร์ฟเวอร์แบ็กเอนด์จึงใช้เวลานานขึ้น
    2. ตรวจสอบว่าโปรแกรมประมวลผลข้อความมีการใช้ CPU หรือหน่วยความจำสูงหรือไม่ ดังนี้
      1. หากโปรแกรมประมวลผลข้อความมีการใช้งาน CPU สูง ให้สร้าง ชุดข้อความ dumps ทุก 30 วินาทีโดยใช้คำสั่งต่อไปนี้ 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. หากตัวประมวลผลข้อความมีการใช้หน่วยความจำสูง ให้สร้าง ฮีปดัมป์ โดยใช้คำสั่งต่อไปนี้ 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. รีสตาร์ทโปรแกรมประมวลผลข้อความโดยใช้คำสั่งด้านล่าง ซึ่งจะช่วยลด CPU และหน่วยความจำ: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. ตรวจสอบการเรียก API เพื่อยืนยันว่าปัญหายังคงอยู่หรือไม่
      5. ติดต่อทีมสนับสนุนของ Apigee Edge เพื่อแจ้ง เทรดดัมพ์ ฮีปดัมป์ และบันทึกของโปรแกรมประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log)เพื่อช่วยผู้ใช้ ตรวจสอบหาสาเหตุของการใช้ CPU/หน่วยความจำสูง

เพิ่มค่าระยะหมดเวลาใน เราเตอร์และโปรแกรมประมวลผลข้อความ

เลือกค่าการหมดเวลาที่จะตั้งค่าบนเราเตอร์และตัวประมวลผลข้อความอย่างรอบคอบ ข้อกำหนดของคุณ อย่ากำหนดค่าระยะหมดเวลาขนาดใหญ่โดยไม่มีกฎเกณฑ์ หากต้องการความช่วยเหลือ โปรดติดต่อ การสนับสนุน Apigee Edge

เราเตอร์

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. สร้างไฟล์ /opt/apigee/customer/application/router.properties ใน เครื่องเราเตอร์หากยังไม่มี
  2. เพิ่มบรรทัดต่อไปนี้ลงในไฟล์นี้: 
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    เช่น ถ้าต้องการกำหนดค่าระยะหมดเวลาเป็น 120 วินาที ให้กำหนดเป็น ดังต่อไปนี้:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. ตรวจสอบว่า Apigee เป็นเจ้าของไฟล์นี้:
  4. รีสตาร์ทเราเตอร์ดังนี้ 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. หากคุณมีเราเตอร์มากกว่า 1 เครื่อง ให้ทำขั้นตอนข้างต้นซ้ำกับเราเตอร์ทุกตัว

Message Processor

  1. สร้างไฟล์ /opt/apigee/customer/application/message-processor.properties ใน เครื่องประมวลผลข้อความหากยังไม่มีอยู่
  2. เพิ่มบรรทัดต่อไปนี้ลงในไฟล์นี้: 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    เช่น ถ้าต้องการกำหนดค่าระยะหมดเวลาเป็น 120 วินาที ให้กำหนดเป็น ดังต่อไปนี้:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. ตรวจสอบว่า Apigee เป็นเจ้าของไฟล์นี้: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. รีสตาร์ทโปรแกรมประมวลผลข้อความ 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. หากคุณมีโปรแกรมประมวลผลข้อความมากกว่า 1 ระบบ ให้ทำขั้นตอนข้างต้นซ้ำในส่วน "ข้อความ" ทั้งหมด ผู้ประมวลผลข้อมูล

แนวคิด: ตั้งค่าระยะหมดเวลาสำหรับคอมโพเนนต์ต่างๆ ตามลำดับต่อไปนี้

ระยะหมดเวลาในไคลเอ็นต์ > ระยะหมดเวลาบนเราเตอร์ > หมดเวลาในตัวประมวลผลข้อความ ระยะหมดเวลาภายในพร็อกซี API

Edge การดำเนินการตามคำขอ API ที่ช้า

หาก Edge ทำงานช้ามากและ/หรือใช้เวลานานในการประมวลผลคำขอ API คุณจะได้รับ ข้อผิดพลาด 504 Gateway Timeout รายการ

การวินิจฉัย

  1. ติดตาม API ที่ได้รับผลกระทบใน Edge UI
  2. โปรดรอให้เกิดข้อผิดพลาดขึ้น หรือหากคุณมีการเรียก API แล้ว ก็ให้เรียกใช้ API บางรายการ และทำให้เกิดข้อผิดพลาด 504 Gateway Timeout ซ้ำ
  3. โปรดทราบว่าในกรณีนี้ คุณอาจเห็นการตอบกลับที่สำเร็จในการติดตาม
    1. เราเตอร์/ไคลเอ็นต์หมดเวลาเนื่องจากตัวประมวลผลข้อความไม่ตอบกลับภายใน ระยะหมดเวลาที่กำหนดบนเราเตอร์/ไคลเอ็นต์ (แล้วแต่ว่าระยะเวลาใดจะหมดเวลาน้อยที่สุด) อย่างไรก็ตาม ผู้ประมวลผลข้อความจะดำเนินการคำขอต่อไป และอาจเสร็จสมบูรณ์ สำเร็จ
    2. นอกจากนี้ ค่า HTTPTransport.io.timeout.millis ที่กำหนดไว้ใน ตัวประมวลผลข้อความจะทริกเกอร์ก็ต่อเมื่อตัวประมวลผลข้อความสื่อสารกับ HTTP/HTTPS เซิร์ฟเวอร์แบ็กเอนด์ กล่าวคือ ระบบจะไม่เรียกใช้ระยะหมดเวลานี้เมื่อนโยบายใดๆ (อื่นๆ นโยบาย Serviceข้อความไฮไลต์) ภายในพร็อกซี API ใช้เวลานาน
  4. หลังจากเกิดข้อผิดพลาด ให้ตรวจสอบคำขอเฉพาะที่มีความยาว เวลาที่ใช้ไป
  5. ตรวจสอบเวลาที่ผ่านไปในแต่ละเฟส และจดช่วงที่ใช้เวลามากที่สุด ที่ใช้ไป
  6. หากคุณสังเกตเห็นเวลาที่ผ่านไปนานที่สุดในนโยบายอื่นๆ นอกเหนือจากบริการ นโยบายการเรียกซึ่งบ่งชี้ว่า Edge ใช้เวลานานในการประมวลผล อีกครั้ง
  7. ตัวอย่างการติดตาม UI ที่แสดงเวลาที่ผ่านไปสูงมากในนโยบาย JavaScript มีดังนี้

  8. ในตัวอย่างข้างต้น คุณสังเกตเห็นว่านโยบาย JavaScript ใช้เวลานานผิดปกติ ประมาณ 245 วินาที

ความละเอียด

  1. ตรวจสอบว่านโยบายที่ใช้เวลานานในการตอบสนองหรือไม่ และมีโค้ดที่กำหนดเองซึ่ง อาจใช้เวลานานในการประมวลผล ถ้ามีรหัสดังกล่าว ลองดูว่าคุณสามารถ แก้ไข/เพิ่มประสิทธิภาพโค้ดที่ระบุ
  2. หากไม่มีโค้ดที่กำหนดเองซึ่งอาจทำให้ใช้เวลาในการประมวลผลสูง ให้ตรวจสอบว่า โปรเซสเซอร์มีการใช้งาน CPU หรือหน่วยความจำสูง ดังนี้
    1. หากตัวประมวลผลข้อความมีการใช้งาน CPU สูง ให้สร้างขึ้นมา 3 อัน ชุดข้อความ dumps ทุก 30 วินาทีโดยใช้คำสั่งต่อไปนี้ 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. หากตัวประมวลผลข้อความมีการใช้งานหน่วยความจำสูง ให้สร้าง ฮีปดัมป์ โดยใช้คำสั่งต่อไปนี้ 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. รีสตาร์ทโปรแกรมประมวลผลข้อความโดยใช้คำสั่งด้านล่าง ซึ่งจะทําให้ CPU ลดลง และความทรงจำ 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. ตรวจสอบการเรียก API และตรวจสอบว่ายังมีปัญหาอยู่หรือไม่
    5. ติดต่อทีมสนับสนุนของ Apigee Edge และระบุชุดข้อความ ดัมพ์ ฮีปดัมป์ และบันทึกของโปรแกรมประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log)เพื่อช่วยผู้ใช้ ตรวจสอบหาสาเหตุของการใช้ CPU/หน่วยความจำสูง

วิเคราะห์ปัญหาโดยใช้การตรวจสอบ API

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

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