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

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

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

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

สาเหตุ รายละเอียด ขั้นตอนที่ให้สำหรับ
เซิร์ฟเวอร์แบ็กเอนด์ที่ทำงานช้า เซิร์ฟเวอร์แบ็กเอนด์ที่ประมวลผลคำขอ API ช้าเกินไปเนื่องจากมีภาระงานสูงหรือประสิทธิภาพไม่ดี ผู้ใช้ Public และ Private Cloud
Edge กำลังประมวลผลคำขอ API ที่ช้า 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. หากคุณสังเกตเห็นข้อผิดพลาดพร้อมกับเวลาที่ผ่านไปนานที่สุดทันทีหลังจากขั้นตอนใดเฟสต่อไปนี้ ก็แสดงว่าเซิร์ฟเวอร์แบ็กเอนด์ทำงานช้าหรือใช้เวลานานในการดำเนินการตามคำขอ
    • ส่งคำขอไปยังเซิร์ฟเวอร์เป้าหมายแล้ว
    • นโยบาย Serviceส่วนขยายไฮไลต์

ต่อไปนี้เป็นตัวอย่างการติดตามที่แสดงว่าเซิร์ฟเวอร์แบ็กเอนด์ไม่ตอบสนองแม้ผ่านไป 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 รายการ

    เลือก: เครื่องมือประมวลผลข้อความมีการควบคุมการหมดเวลาอย่างไร

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

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

    ตัวอย่างรายการบันทึก 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. หากแก้ไข/เพิ่มประสิทธิภาพเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้ หรือเป็นข้อเท็จจริงที่ทราบกันว่าเซิร์ฟเวอร์แบ็กเอนด์ใช้เวลานาน ให้เพิ่มค่าระยะหมดเวลาในเราเตอร์และผู้ประมวลผลข้อความ

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

      ระยะหมดเวลาสำหรับไคลเอ็นต์ > หมดเวลาบนเราเตอร์ > ระยะหมดเวลาสำหรับตัวประมวลผลข้อความ > ระยะหมดเวลาภายในพร็อกซี API
  2. หากเป็นเซิร์ฟเวอร์แบ็กเอนด์ของ NodeJS ให้ทำดังนี้
    1. ตรวจสอบว่าโค้ด NodeJS ทำการเรียกไปยังเซิร์ฟเวอร์แบ็กเอนด์อื่นๆ หรือไม่ และใช้เวลานานในการส่งการตอบกลับหรือไม่ ให้ตรวจสอบสาเหตุที่เซิร์ฟเวอร์แบ็กเอนด์ใช้เวลานานกว่าปกติ และแก้ไขปัญหาตามความเหมาะสม
    2. ตรวจสอบว่าตัวประมวลผลข้อความมีการใช้งาน CPU หรือหน่วยความจำสูงหรือไม่
      1. หากตัวประมวลผลข้อความมีการใช้งาน CPU สูง ให้สร้างดัมพ์ชุดข้อความ 3 รายการทุก 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/หน่วยความจำสูง

ตรวจสอบ: วิธีควบคุมการหมดเวลาสำหรับเซิร์ฟเวอร์แบ็กเอนด์ของ NodeJS ในโปรแกรมประมวลผลข้อความ

  • เซิร์ฟเวอร์แบ็กเอนด์ของ NodeJS ทำงานภายในกระบวนการ JVM ของโปรแกรมประมวลผลข้อความ ค่าระยะหมดเวลาสำหรับเซิร์ฟเวอร์แบ็กเอนด์ของ 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 (เราเตอร์, ผู้ประมวลผลข้อความ), คำขอที่ส่งไปยังเซิร์ฟเวอร์แบ็กเอนด์ (หากมี), การประมวลผลแบ็กเอนด์คำขอและการตอบกลับ, 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 อยู่ในเครื่องมือประมวลผลข้อความ
  5. ข้อยกเว้นนี้เป็นไปตามเงื่อนไขที่อธิบายข้างต้น ดังนั้น สาเหตุที่แท้จริงของข้อผิดพลาด 504 Gateway Timeout ยังคงเป็นเพราะเซิร์ฟเวอร์แบ็กเอนด์ใช้เวลานานในการตอบสนองและคุณจะต้องแก้ไขปัญหาดังกล่าว

ความละเอียด

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

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

      ระยะหมดเวลาสำหรับไคลเอ็นต์ > หมดเวลาบนเราเตอร์ > ระยะหมดเวลาสำหรับตัวประมวลผลข้อความ > ระยะหมดเวลาภายในพร็อกซี API
  2. หากเป็นแบ็กเอนด์ของ NodeJS ให้ทำดังนี้
    1. ตรวจสอบว่าโค้ด NodeJS ทำการเรียกไปยังเซิร์ฟเวอร์แบ็กเอนด์อื่นๆ หรือไม่ และใช้เวลานานในการส่งคืนไหม ตรวจสอบว่าเหตุใดเซิร์ฟเวอร์แบ็กเอนด์เหล่านั้นจึงใช้เวลานานกว่า
    2. ตรวจสอบว่าตัวประมวลผลข้อความมีการใช้งาน CPU หรือหน่วยความจำสูงหรือไม่
      1. หากตัวประมวลผลข้อความมีการใช้งาน CPU สูง ให้สร้างดัมพ์ชุดข้อความ 3 รายการทุก 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 บนเครื่อง 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. หากมีเครื่องมือประมวลผลข้อความมากกว่า 1 เครื่อง ให้ทำตามขั้นตอนข้างต้นซ้ำในตัวประมวลผลข้อความทั้งหมด

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

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

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

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

การวินิจฉัย

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

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

ความละเอียด

  1. ตรวจสอบว่านโยบายที่ใช้การตอบกลับใช้เวลานานหรือไม่ มีโค้ดที่กำหนดเองที่อาจใช้เวลานานในการประมวลผลหรือไม่ หากมีโค้ดดังกล่าว ให้ดูว่าคุณสามารถแก้ไข/เพิ่มประสิทธิภาพโค้ดที่ระบุได้หรือไม่
  2. หากไม่มีโค้ดที่กำหนดเองซึ่งอาจทำให้ใช้เวลาในการประมวลผลสูง ให้ตรวจสอบว่าตัวประมวลผลข้อความมีการใช้งาน CPU หรือหน่วยความจำสูงหรือไม่ ดังนี้
    1. หากตัวประมวลผลข้อความมีการใช้งาน CPU สูง ให้สร้างดัมพ์ชุดข้อความ 3 รายการทุก 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 Monitoring

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

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