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

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

ลักษณะปัญหา

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

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

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

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

HTTP/1.1 504 Gateway Timeout

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

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

อะไรเป็นสาเหตุของข้อผิดพลาด Gateway Timeout

เส้นทางทั่วไปสำหรับคำขอ API ผ่านแพลตฟอร์ม Edge คือ Client -> Router -> Message Processor -> Backend Server ดังที่แสดงในรูปด้านล่าง

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

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

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

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

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

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

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

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

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

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

สถานการณ์ #1 Message Processor หมดเวลาตอบสนองก่อนที่เซิร์ฟเวอร์แบ็กเอนด์จะตอบกลับ

การวินิจฉัย

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

ขั้นตอนที่ 1 การใช้ Trace

หากปัญหายังคงเกิดขึ้น (ยังคงมีข้อผิดพลาด 504) ให้ทำตามขั้นตอนด้านล่าง

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

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

ในการติดตามด้านบน Message Processor จะหมดเวลาหลังจาก 55002 มิลลิวินาทีเนื่องจากเซิร์ฟเวอร์แบ็กเอนด์ไม่ตอบสนอง

ขั้นตอนที่ 2: ใช้บันทึกของ Message Processor

  1. ตรวจสอบบันทึกของ Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)

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

    ตัวอย่างบันทึกของ Message Processor ที่แสดงข้อผิดพลาด Gateway Timeout

    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

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

    โปรดดูที่หัวข้อ "การควบคุมการหมดเวลาใน Message Processor"

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

ความละเอียด

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

สถานการณ์ #2 - เราเตอร์หมดเวลาไปก่อนที่ Message Processor/เซิร์ฟเวอร์แบ็กเอนด์จะตอบกลับ

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

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

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

    หมดเวลาในเราเตอร์ หมดเวลาใน Message Processor การหมดเวลาภายในพร็อกซี 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>

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

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

การวินิจฉัย

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

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

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

  3. ในตัวอย่างข้างต้น ให้สังเกตสถานะของ 504 ใน NGINX, รหัสข้อความจาก Message Processor คือ - และเวลาที่ผ่านไปทั้งหมดคือ 57.001 วินาที เนื่องจากเราเตอร์หมดเวลา หลังจากผ่านไป 57.001 วินาที และเราไม่ได้รับการตอบกลับจาก Message Processor
  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>

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

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

ความละเอียด

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

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

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

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

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

สถานการณ์ #3 - แอปพลิเคชันไคลเอ็นต์หมดเวลาก่อนที่ Router/Message Processor/เซิร์ฟเวอร์แบ็กเอนด์จะตอบกลับ

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

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

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

    การหมดเวลาในไคลเอ็นต์ หมดเวลาในเราเตอร์ หมดเวลาใน Message Processor
    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 ในบันทึกของ Message Processor (/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. หลังจากเราเตอร์หมดเวลา ระบบจะปิดการเชื่อมต่อกับ Message Processor เมื่อ Message Processor ประมวลผลเสร็จแล้ว จะพยายามเขียนการตอบกลับไปยังเราเตอร์ เนื่องจากระบบปิดการเชื่อมต่อกับเราเตอร์แล้ว คุณจึงได้รับ Broken Pipe exception ใน Message Processor
  5. ข้อยกเว้นนี้คาดว่าจะเกิดขึ้นภายใต้สถานการณ์ที่อธิบายไว้ข้างต้น ดังนั้นสาเหตุที่แท้จริงของข้อผิดพลาด 504 Gateway Timeout ยังคงเป็นเพราะเซิร์ฟเวอร์แบ็กเอนด์ใช้เวลานานในการตอบสนอง และคุณต้องแก้ไขปัญหานี้

ความละเอียด

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

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

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

เพิ่มค่าการหมดเวลาใน เราเตอร์และ Message Processor

โปรดเลือกค่าการหมดเวลาที่จะตั้งค่าในเราเตอร์และ Message Processor อย่างระมัดระวังตามข้อกำหนดของคุณ อย่าตั้งค่าระยะหมดเวลาให้ใหญ่เกินไปโดยไม่มีเหตุผล หากต้องการความช่วยเหลือ โปรดติดต่อ ทีมสนับสนุนของ 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ในเครื่อง Message Processor หากยังไม่มี
  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. หากมี Message Processor มากกว่า 1 รายการ ให้ทำตามขั้นตอนข้างต้นใน Message Processor ทั้งหมด

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

หมดเวลาในไคลเอ็นต์ > หมดเวลาในเราเตอร์ > หมดเวลาใน Message Processor > หมดเวลาภายใน API Proxy

Edge ประมวลผลคำขอ API ช้า

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

การวินิจฉัย

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

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

ความละเอียด

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

วินิจฉัยปัญหาโดยใช้การตรวจสอบ API

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

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