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

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

ลักษณะปัญหา

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

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

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

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

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

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

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

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

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

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

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

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

การวินิจฉัย

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

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

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

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

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

ในการติดตามด้านบน โปรแกรมประมวลผลข้อความหมดเวลาหลังจาก 55002 มิลลิวินาทีเนื่องจากเซิร์ฟเวอร์แบ็กเอนด์ไม่ตอบกลับ

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

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

  2. หากพบข้อผิดพลาด Gateway Timeout และ onTimeoutRead สําหรับคําขอพร็อกซี API ที่เจาะจง ณ เวลาหนึ่งๆ แสดงว่าตัวประมวลผลข้อความหมดเวลา

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

    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 อย่างไร"

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

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

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

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

    หมดเวลาในเราเตอร์ หมดเวลาใน 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>

    จากนั้น ตัวประมวลผลข้อความจะไม่หมดเวลาหลังจากผ่านไป 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, รหัสข้อความจาก Message Processor คือ - และเวลาทั้งหมดที่ใช้ไปคือ 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 ใน Message Processor

  • เซิร์ฟเวอร์แบ็กเอนด์ 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. ค่าระยะหมดเวลาที่กำหนดไว้ในแอปพลิเคชันไคลเอ็นต์ต่ำกว่าค่าระยะหมดเวลาที่กำหนดไว้บนเราเตอร์และ Message Processor ดังนี้

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

    หมดเวลาในไคลเอ็นต์ หมดเวลาในเราเตอร์ หมดเวลาใน Message Processor
    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 ในเครื่องของโปรแกรมประมวลผลข้อความ หากยังไม่มี
  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 ทั้งหมด

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

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

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

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

การวินิจฉัย

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

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

ความละเอียด

  1. ตรวจสอบว่านโยบายใช้เวลานานในการตอบกลับหรือไม่ และมีโค้ดที่กำหนดเองที่อาจใช้เวลานานในการประมวลผลหรือไม่ หากมีโค้ดดังกล่าว ให้ตรวจสอบว่าคุณสามารถแก้ไข/เพิ่มประสิทธิภาพโค้ดที่ระบุได้หรือไม่
  2. หากไม่มีโค้ดที่กำหนดเองที่อาจทำให้เวลาในการประมวลผลสูง ให้ตรวจสอบว่า Message Processor กำลังใช้ 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 และส่งไฟล์บันทึกการหยุดทำงานของเธรด ไฟล์บันทึกการหยุดทำงานของฮีป และบันทึกของ Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)เพื่อช่วยทีมสนับสนุนตรวจสอบสาเหตุของการใช้งาน CPU/หน่วยความจำที่สูง

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

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

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