499 ไคลเอ็นต์ปิดการเชื่อมต่อ

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับข้อผิดพลาด Timeout สำหรับคำขอ API หรือคำขอถูกยกเลิก อย่างกะทันหันขณะที่คำขอ API ยังคงดำเนินการอยู่บน Apigee

คุณจะเห็นรหัสสถานะ 499 สำหรับคำขอ API ดังกล่าวในการตรวจสอบ API และ บันทึกการเข้าถึง NGINX บางครั้งคุณจะเห็นรหัสสถานะที่แตกต่างกันใน API Analytics เนื่องจาก แสดงรหัสสถานะที่ Message Processor ส่งคืน

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

แอปพลิเคชันไคลเอ็นต์อาจเห็นข้อผิดพลาดต่างๆ เช่น 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

สาเหตุที่ทำให้ไคลเอ็นต์หมดเวลา

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

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

Timeout ในไคลเอ็นต์

คุณสามารถกำหนดค่าแอปพลิเคชันไคลเอ็นต์ด้วยค่า Timeout ที่เหมาะสมตามความต้องการ

ไคลเอ็นต์ เช่น เว็บเบราว์เซอร์และแอปบนอุปกรณ์เคลื่อนที่ มีค่า Timeout ที่กำหนดโดยระบบปฏิบัติการ

Timeout ในเราเตอร์

ค่า Timeout เริ่มต้นที่กำหนดค่าในเราเตอร์คือ 57 วินาที ซึ่งเป็นเวลาสูงสุดที่พร็อกซี API สามารถดำเนินการได้นับตั้งแต่เวลาที่ได้รับคำขอ API ใน Edge จนถึงเวลาที่ส่งการตอบกลับกลับ รวมถึงการตอบกลับจากแบ็กเอนด์และนโยบายทั้งหมดที่ดำเนินการ คุณสามารถลบล้างค่า Timeout เริ่มต้นในเราเตอร์และโฮสต์เสมือนได้ตามที่อธิบายไว้ในหัวข้อ การกำหนดค่า Timeout ของ I/O ในเราเตอร์

Timeout ใน Message Processor

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

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

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

ใน Edge สาเหตุทั่วไปของข้อผิดพลาด 499 Client Closed Connection มีดังนี้

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

ขั้นตอนการวินิจฉัยทั่วไป

ใช้เครื่องมือ/เทคนิคใดเทคนิคหนึ่งต่อไปนี้เพื่อวินิจฉัยข้อผิดพลาดนี้

  • การตรวจสอบ API
  • บันทึกการเข้าถึง NGINX

การตรวจสอบ API

วิธีวินิจฉัยข้อผิดพลาดโดยใช้การตรวจสอบ API

  1. ไปที่หน้าวิเคราะห์ > การตรวจสอบ API > ตรวจสอบ
  2. กรองข้อผิดพลาด 4xx แล้วเลือกกรอบเวลา
  3. พล็อตรหัสสถานะ เทียบกับเวลา
  4. เลือกเซลล์ที่มีข้อผิดพลาด 499 ดังที่แสดงด้านล่าง

  5. คุณจะเห็นข้อมูลเกี่ยวกับข้อผิดพลาด 499 ในบานหน้าต่างด้านขวา ดังที่แสดงด้านล่าง

  6. คลิกดูบันทึก ในบานหน้าต่างด้านขวา

    จากหน้าต่างบันทึกการเข้าชม ให้จดรายละเอียดต่อไปนี้สำหรับข้อผิดพลาด 499 บางรายการ

    • คำขอ:แสดงเมธอดคำขอและ URI ที่ใช้ในการเรียก
    • เวลา ตอบสนอง:แสดงเวลาทั้งหมดที่ผ่านไปสำหรับคำขอ

    นอกจากนี้ คุณยังรับบันทึกทั้งหมดได้โดยใช้ API การตรวจสอบ การรับบันทึก API เช่น การค้นหาบันทึกสำหรับ org, env, timeRange, และ status จะช่วยให้คุณดาวน์โหลดบันทึกทั้งหมดสำหรับการทำธุรกรรมที่ไคลเอ็นต์หมดเวลาได้

    เนื่องจากการตรวจสอบ API ตั้งค่าพร็อกซีเป็น - สำหรับข้อผิดพลาด HTTP 499 คุณจึงใช้ API (Logs API) เพื่อรับพร็อกซีที่เชื่อมโยงสำหรับโฮสต์เสมือนและเส้นทางได้

    ตัวอย่างเช่น 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. ตรวจสอบเวลาตอบสนอง สำหรับข้อผิดพลาด 499 เพิ่มเติม และดูว่า เวลาตอบสนอง สอดคล้องกันหรือไม่ (เช่น 30 วินาที) ในข้อผิดพลาด 499 ทั้งหมด

บันทึกการเข้าถึง NGINX

วิธีวินิจฉัยข้อผิดพลาดโดยใช้บันทึกการเข้าถึง NGINX

  1. หากเป็นผู้ใช้ Private Cloud คุณสามารถใช้บันทึกการเข้าถึง NGINX เพื่อดูข้อมูลสำคัญเกี่ยวกับข้อผิดพลาด HTTP 499 ได้
  2. ตรวจสอบบันทึกการเข้าถึง NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. ค้นหาเพื่อดูว่ามีข้อผิดพลาด 499 เกิดขึ้นในช่วงเวลาที่เฉพาะเจาะจงหรือไม่ (หากปัญหาเกิดขึ้นในอดีต) หรือมีคำขอที่ยังคงล้มเหลวด้วยข้อผิดพลาด 499 หรือไม่
  4. จดข้อมูลต่อไปนี้สำหรับข้อผิดพลาด 499 บางรายการ
    • เวลาตอบสนองทั้งหมด
    • URI คำขอ
    • User Agent

    ตัวอย่างข้อผิดพลาด 499 จากบันทึกการเข้าถึง NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    ในตัวอย่างนี้ เราจะเห็นข้อมูลต่อไปนี้

    • เวลาตอบสนองทั้งหมด: 10.001 วินาที ซึ่งบ่งชี้ว่า ไคลเอ็นต์หมดเวลาหลังจากผ่านไป 10.001 วินาที
    • คำขอ: GET /v1/products
    • โฮสต์:api.acme.org
    • User Agent:okhttp/3.9.1
  5. ตรวจสอบว่าเวลาตอบสนองทั้งหมด และ User Agent สอดคล้องกัน ในข้อผิดพลาด 499 ทั้งหมดหรือไม่

สาเหตุ: ไคลเอ็นต์ปิดการเชื่อมต่ออย่างกะทันหัน

การวินิจฉัย

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

ความละเอียด

  1. เหตุการณ์นี้ถือเป็นเรื่องปกติและโดยปกติแล้วไม่น่ากังวลหากข้อผิดพลาด HTTP 499 เกิดขึ้นในปริมาณเล็กน้อย

  2. หากข้อผิดพลาดเกิดขึ้นบ่อยครั้งสำหรับเส้นทาง URL เดียวกัน อาจเป็นเพราะพร็อกซีที่เฉพาะเจาะจง ซึ่งเชื่อมโยงกับเส้นทางนั้นทำงานช้ามากและผู้ใช้ไม่ต้องการรอ

    เมื่อทราบแล้วว่าพร็อกซีใดอาจได้รับผลกระทบ ให้ใช้ แดชบอร์ดการวิเคราะห์ เวลาในการตอบสนองเพื่อตรวจสอบเพิ่มเติมว่าสาเหตุที่ทำให้พร็อกซีมีเวลาในการตอบสนองนานคืออะไร

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

สาเหตุ: Timeout ของแอปพลิเคชันไคลเอ็นต์

เหตุการณ์นี้อาจเกิดขึ้นได้ในหลายสถานการณ์

  1. คาดว่าคำขอจะใช้เวลาดำเนินการให้เสร็จสมบูรณ์ตามที่กำหนด (เช่น 10 วินาที) ภายใต้สภาวะการทำงานปกติ อย่างไรก็ตาม แอปพลิเคชันไคลเอ็นต์ได้รับการตั้งค่าด้วยค่า Timeout ที่ไม่ถูกต้อง ซึ่งทำให้แอปพลิเคชันไคลเอ็นต์หมดเวลาก่อนที่คำขอ API จะเสร็จสมบูรณ์ ซึ่งนำไปสู่ข้อผิดพลาด 499 ในกรณีนี้ เราต้องตั้งค่า Timeout ของไคลเอ็นต์เป็นค่าที่เหมาะสม
  2. เซิร์ฟเวอร์เป้าหมายหรือ Callout ใช้เวลานานกว่าที่คาดไว้ ในกรณีนี้ คุณต้องแก้ไขคอมโพเนนต์ที่เหมาะสม และปรับค่า Timeout ให้เหมาะสมด้วย
  3. ไคลเอ็นต์ไม่ต้องการการตอบกลับอีกต่อไปจึงยกเลิก เหตุการณ์นี้อาจเกิดขึ้นกับ API ที่มีความถี่สูง เช่น การเติมข้อความอัตโนมัติหรือการโพลแบบสั้น

การวินิจฉัย

การตรวจสอบ API หรือบันทึกการเข้าถึง NGINX

วิธีวินิจฉัยข้อผิดพลาดโดยใช้การตรวจสอบ API หรือบันทึกการเข้าถึง NGINX

  1. ตรวจสอบบันทึกการตรวจสอบ API หรือบันทึกการเข้าถึง NGINX สำหรับธุรกรรม HTTP 499 ตามที่อธิบายไว้ใน ขั้นตอนการวินิจฉัยทั่วไป
  2. ตรวจสอบว่าเวลาตอบสนอง สอดคล้องกันสำหรับข้อผิดพลาด 499 ทั้งหมดหรือไม่
  3. หากสอดคล้องกัน แสดงว่าแอปพลิเคชันไคลเอ็นต์ที่เฉพาะเจาะจงอาจกำหนดค่า Timeout คงที่ไว้ หากพร็อกซี API หรือเซิร์ฟเวอร์เป้าหมายตอบกลับช้า ไคลเอ็นต์จะหมดเวลา ก่อนที่พร็อกซีจะหมดเวลา ซึ่งส่งผลให้เกิดข้อผิดพลาด HTTP 499s จำนวนมากสำหรับเส้นทาง URI เดียวกัน ในกรณีนี้ ให้ระบุ User Agent จากบันทึกการเข้าถึง NGINX ซึ่ง ช่วยให้คุณระบุแอปพลิเคชันไคลเอ็นต์ที่เฉพาะเจาะจงได้
  4. นอกจากนี้ ยังอาจมีตัวจัดสรรภาระงานอยู่หน้า Apigee เช่น Akamai, F5, AWS ELB และอื่นๆ หาก Apigee ทำงานอยู่เบื้องหลังตัวจัดสรรภาระงานที่กำหนดเอง คุณต้องกำหนดค่า Timeout ของคำขอ ของตัวจัดสรรภาระงานให้มากกว่า Timeout ของ Apigee API โดย ค่าเริ่มต้น เราเตอร์ Apigee จะหมดเวลาหลังจากผ่านไป 57 วินาที ดังนั้นจึงเหมาะที่จะกำหนดค่า Timeout ของคำขอ เป็น 60 วินาทีในตัวจัดสรรภาระงาน

Trace

วิธีวินิจฉัยข้อผิดพลาดโดยใช้ Trace

หากปัญหายังคงเกิดขึ้นอยู่ (499 ยังคงเกิดขึ้น) ให้ทำตามขั้นตอนต่อไปนี้

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

    ตัวอย่าง Trace ใน UI ที่แสดงเกตเวย์หมดเวลา หลังจากส่งคำขอ ถูก ส่งไปยังเซิร์ฟเวอร์เป้าหมาย:

ความละเอียด

  1. โปรดดู แนวทางปฏิบัติแนะนำสำหรับการกำหนดค่า Timeout ของ I/O เพื่อทำความเข้าใจค่า Timeout ที่ควรตั้งค่า ในคอมโพเนนต์ต่างๆ ที่เกี่ยวข้องกับขั้นตอนการทำงานของคำขอ API ผ่าน Apigee Edge
  2. ตรวจสอบว่าคุณได้ตั้งค่า Timeout ที่เหมาะสมในแอปพลิเคชันไคลเอ็นต์ตาม แนวทางปฏิบัติแนะนำ

หากปัญหายังคงอยู่ ให้ไปที่ ข้อมูลการวินิจฉัยที่ต้องรวบรวม

ข้อมูลการวินิจฉัยที่ต้องรวบรวม

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

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

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

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

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