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

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

ลักษณะปัญหา

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

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

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

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

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

การหมดเวลาของไคลเอ็นต์เกิดจากอะไร

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

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

หมดเวลาเมื่อไคลเอ็นต์

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

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

หมดเวลาบนเราเตอร์

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

หมดเวลาสำหรับตัวประมวลผลข้อความ

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

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

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

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

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

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

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

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

การตรวจสอบ API

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

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

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

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

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

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

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

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

    For example : 

    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 Monitoring หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ในขั้นตอนการวิเคราะห์ทั่วไป

ความละเอียด

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

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

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

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

สาเหตุ: แอปพลิเคชันไคลเอ็นต์หมดเวลา

ซึ่งอาจเกิดขึ้นได้ในบางกรณี

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

การวินิจฉัย

API Monitoring หรือบันทึกการเข้าถึง NGINX

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

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

Trace

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

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

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

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

ความละเอียด

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

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

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

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

หากคุณเป็นผู้ใช้ ระบบคลาวด์สาธารณะ โปรดระบุข้อมูลต่อไปนี้

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

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

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