502 Bad Gateway - ซ็อกเก็ตถูกวางสาย

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับรหัสสถานะ HTTP 502 Bad Gateway พร้อมรหัส ECONNRESET เป็นการตอบกลับสำหรับการเรียก API ใน Edge Microgateway

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

ไคลเอ็นต์จะเห็นโค้ดตอบกลับต่อไปนี้

HTTP/1.1 502 Bad Gateway

การตอบกลับจะมีข้อความแสดงข้อผิดพลาดต่อไปนี้

{"message":"socket hang up","code":"ECONNRESET"}

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

ขั้นตอนการวินิจฉัยที่พบบ่อย

1. ตรวจสอบบันทึกของ Edge Microgateway

   /var/tmp/edgemicro-`hostname`-*.log

2. ค้นหาเพื่อดูว่ามีข้อผิดพลาด 502 ที่มีรหัส ECONNRESET ในช่วงระยะเวลาหนึ่งๆ (หากปัญหาเกิดขึ้นในอดีต) หรือมีคำขอที่ยังคงล้มเหลวด้วยข้อผิดพลาด 502 หรือไม่

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]

3. หากคุณตั้งค่าระดับการบันทึกเป็น warn หรือ info ระบบจะแสดงข้อความ [warn] ซึ่งรวมถึงชื่อโฮสต์และพอร์ตของเซิร์ฟเวอร์ปลายทางในองค์ประกอบที่ 2 ด้วย ในตัวอย่างนี้คือ X.X.X.X:8080 และคุณสามารถใช้ค่านี้ในภายหลังเพื่อบันทึก tcpdump

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]

4. รหัสข้อผิดพลาด [socket hang up][ECONNRESET] แสดงว่าเซิร์ฟเวอร์ปลายทาง ปิดการเชื่อมต่อกับ Edge Microgateway คุณสามารถค้นหารหัสนี้ในบันทึกเพื่อดูว่าข้อผิดพลาดเกิดขึ้นบ่อยเพียงใด

สาเหตุ: กำหนดค่าระยะหมดเวลา Keep-Alive ไม่ถูกต้อง

การวินิจฉัย

1. ทำตามขั้นตอนใน ขั้นตอนการวินิจฉัยที่พบบ่อย และตรวจสอบว่าคุณได้รับข้อผิดพลาด [socket hang up][ECONNRESET] หรือไม่

2. หากได้รับ ให้ตรวจสอบเพิ่มเติมด้วยความช่วยเหลือจาก tcpdump ตามที่อธิบายไว้ด้านล่าง

การใช้ tcpdump

1. บันทึก tcpdump ระหว่าง Edge Microgateway กับเซิร์ฟเวอร์แบ็กเอนด์ใน ระบบปฏิบัติการโฮสต์ของ Edge Microgateway ด้วยคำสั่งต่อไปนี้

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. วิเคราะห์ tcpdump ที่บันทึกไว้

   ตัวอย่างเอาต์พุต tcpdump: ( ดูรูปภาพขนาดใหญ่ขึ้น)

   

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

   1. ในแพ็กเก็ต 250288 ไคลเอ็นต์จะส่งคำขอ POST
   2. ในแพ็กเก็ต 250371 เซิร์ฟเวอร์จะตอบกลับด้วย 200 OK
   3. ในแพ็กเก็ต 250559 ไคลเอ็นต์จะส่ง ACK.
   4. ในแพ็กเก็ต 250560 เซิร์ฟเวอร์จะส่งข้อความ Continuation
   5. ในแพ็กเก็ต 250561 ไคลเอ็นต์จะส่ง ACK.
   6. ในแพ็กเก็ต 262436 เซิร์ฟเวอร์จะส่ง FIN, ACK ไปยัง ไคลเอ็นต์เพื่อเริ่มการปิดการเชื่อมต่อ โปรดทราบว่าแพ็กเก็ตนี้เกิดขึ้นประมาณ 5 วินาทีหลังจากแพ็กเก็ตก่อนหน้า (250561)
   7. ในแพ็กเก็ต 262441 ไคลเอ็นต์จะส่งคำขอ POST อีกครั้ง อย่างไรก็ตาม คำขอนี้จะล้มเหลวเนื่องจากเซิร์ฟเวอร์เริ่มการปิดการเชื่อมต่อแล้ว เซิร์ฟเวอร์จะตอบกลับด้วย RST ในแพ็กเก็ต 262441

   ในตัวอย่างนี้ ระบบใช้การเชื่อมต่อเดิมซ้ำอย่างน้อย 1 ครั้งได้สำเร็จ แต่ใน คำขอสุดท้าย เซิร์ฟเวอร์จะเริ่มการปิดการเชื่อมต่อหลังจากไม่มีการใช้งานเป็นเวลา 5 วินาที ซึ่งเกิดขึ้นพร้อมกับที่ไคลเอ็นต์ส่งคำขอใหม่ ซึ่งแสดงว่าระยะหมดเวลา Keep-Alive ของเซิร์ฟเวอร์แบ็กเอนด์มีแนวโน้มที่จะสั้นกว่าหรือเท่ากับค่าที่ตั้งไว้ในไคลเอ็นต์ หากต้องการตรวจสอบ ให้ดู เปรียบเทียบระยะหมดเวลา Keep-Alive ใน Edge Microgateway กับเซิร์ฟเวอร์แบ็กเอนด์

เปรียบเทียบระยะหมดเวลา Keep-Alive

1. Edge Microgateway ไม่มีพร็อพเพอร์ตี้ระยะหมดเวลา Keep-Alive ที่เฉพาะเจาะจง ระยะหมดเวลาจะกำหนดโดยระบบปฏิบัติการที่ Edge Microgateway ทำงานอยู่ ตัวอย่างที่พบบ่อย ได้แก่ Windows, Linux และคอนเทนเนอร์ Docker
2. ระบบปฏิบัติการอาจมีการปรับแต่งระยะหมดเวลา Keep-Alive โปรดตรวจสอบกับ ผู้ดูแลระบบ โดยค่าเริ่มต้น ระบบปฏิบัติการ Linux จะมีระยะหมดเวลา Keep-Alive เริ่มต้น 2 ชั่วโมง
3. จากนั้นตรวจสอบพร็อพเพอร์ตี้ระยะหมดเวลา Keep-Alive ที่กำหนดค่าไว้ในเซิร์ฟเวอร์แบ็กเอนด์ สมมติว่าเซิร์ฟเวอร์แบ็กเอนด์กำหนดค่าไว้ที่ 10 วินาที
4. หากคุณพบว่าค่าระยะหมดเวลา Keep-Alive ในระบบปฏิบัติการสูงกว่าค่าพร็อพเพอร์ตี้ระยะหมดเวลา Keep-Alive ในเซิร์ฟเวอร์แบ็กเอนด์ ดังเช่นในตัวอย่างข้างต้น นั่นคือสาเหตุของข้อผิดพลาด 502

ความละเอียด

ตรวจสอบว่าพร็อพเพอร์ตี้ระยะหมดเวลา Keep-Alive ในระบบปฏิบัติการที่ Edge Microgateway ทำงานอยู่มีค่าต่ำกว่าค่าในเซิร์ฟเวอร์แบ็กเอนด์เสมอ

1. กำหนดค่าที่ตั้งไว้สำหรับระยะหมดเวลา Keep-Alive ในเซิร์ฟเวอร์แบ็กเอนด์
2. กำหนดค่าที่เหมาะสมสำหรับพร็อพเพอร์ตี้ระยะหมดเวลา Keep-Alive ในระบบปฏิบัติการ โดยให้พร็อพเพอร์ตี้ระยะหมดเวลา Keep-Alive มีค่าต่ำกว่าค่าที่ตั้งไว้ในเซิร์ฟเวอร์แบ็กเอนด์ โดยใช้ขั้นตอนที่ใช้ได้กับระบบปฏิบัติการของคุณ

แนวทางปฏิบัติแนะนำ

เราขอแนะนำอย่างยิ่งให้คอมโพเนนต์ปลายทางมีเกณฑ์ระยะหมดเวลา Keep-Alive ต่ำกว่าที่กำหนดค่าไว้ในเซิร์ฟเวอร์ต้นทางเสมอ เพื่อหลีกเลี่ยงสภาวะการแข่งขันและ 502 ข้อผิดพลาด การข้ามแต่ละครั้งที่ปลายทางควรต่ำกว่าการข้ามแต่ละครั้งที่ต้นทาง ใน Edge Microgateway เราขอแนะนำให้ใช้หลักเกณฑ์ต่อไปนี้

1. ระยะหมดเวลา Keep-Alive ในแอปพลิเคชันไคลเอ็นต์หรือ Load Balancer ควรน้อยกว่าระยะหมดเวลา Keep-Alive ของ Edge Microgateway

   หากต้องการกำหนดค่าระยะหมดเวลา Keep-Alive ใน Edge Microgateway ให้เพิ่มค่า keep_alive_timeout ลงในไฟล์ ~/.edgemicro/org-env-config.yaml

   edgemicro:
     keep_alive_timeout: 65000

2. ระยะหมดเวลา Keep-Alive ของระบบปฏิบัติการ Edge Microgateway ควรน้อยกว่าระยะหมดเวลา Keep-Alive ของเซิร์ฟเวอร์ปลายทาง
3. หากคุณมีการข้ามอื่นๆ ที่อยู่ด้านหน้าหรือด้านหลัง Edge Microgateway คุณควรใช้กฎเดียวกัน คุณควรปล่อยให้ไคลเอ็นต์ปลายทางเป็นผู้รับผิดชอบในการปิด การเชื่อมต่อกับต้นทางเสมอ

สาเหตุ: เซิร์ฟเวอร์ปลายทางปิดการเชื่อมต่อก่อนเวลา

การวินิจฉัย

1. ทำตามขั้นตอนที่อธิบายไว้ใน ขั้นตอนการวินิจฉัยที่พบบ่อย และตรวจสอบว่าคุณ ได้รับข้อผิดพลาด [socket hang up][ECONNRESET] หรือไม่
2. หากได้รับ ให้ตรวจสอบเพิ่มเติมด้วยความช่วยเหลือจาก tcpdump ตามที่อธิบายไว้ด้านล่าง

   ข้อความแสดงข้อผิดพลาด [targetRequest error][GET][][socket hang up][ECONNRESET] ในตัวอย่างข้างต้นแสดงว่าข้อผิดพลาดนี้เกิดขึ้นขณะที่ Edge Microgateway กำลังส่งคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์ (ปลายทาง) นั่นคือ Edge Microgateway ส่ง คำขอ API ไปยังเซิร์ฟเวอร์แบ็กเอนด์และรอการตอบกลับ อย่างไรก็ตาม เซิร์ฟเวอร์แบ็กเอนด์ ยกเลิกการเชื่อมต่ออย่างกะทันหันก่อนที่ Edge Microgateway จะได้รับการตอบกลับ

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

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. วิเคราะห์ tcpdump ที่บันทึกไว้

   ตัวอย่างเอาต์พุต tcpdump: ( ดูรูปภาพขนาดใหญ่ขึ้น)

   

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

   1. ในแพ็กเก็ต 4 Edge Microgateway ส่งคำขอ GET ไปยังเซิร์ฟเวอร์ปลายทาง
   2. ในแพ็กเก็ต 5 เซิร์ฟเวอร์ปลายทางตอบกลับด้วย ACK เพื่อรับทราบ คำขอ
   3. อย่างไรก็ตาม ในแพ็กเก็ต 6 เซิร์ฟเวอร์ปลายทาง จะส่ง FIN, ACK เพื่อเริ่มการปิดการเชื่อมแทนที่จะตอบกลับด้วยเพย์โหลดการตอบกลับ
   4. ในแพ็กเก็ต 7 เป็นต้นไป การเชื่อมต่อจะปิดลงร่วมกัน เนื่องจากระบบปิดการเชื่อมต่อก่อนที่จะส่งการตอบกลับ Edge Microgateway จะแสดงข้อผิดพลาด HTTP 502 กลับไปยังไคลเอ็นต์
   5. โปรดทราบว่าการประทับเวลาของแพ็กเก็ต 8 2021-06-23T03:52:24.110Z ตรงกับการประทับเวลาที่บันทึกข้อผิดพลาดในบันทึกของ Edge Microgateway บันทึก คุณมักจะใช้การประทับเวลาในไฟล์บันทึกและใน tcpdump เพื่อเชื่อมโยงข้อผิดพลาดกับแพ็กเก็ตจริงได้

   ความละเอียด

   แก้ไขปัญหาในเซิร์ฟเวอร์แบ็กเอนด์อย่างเหมาะสม

   หากยังพบปัญหาเดิมอยู่และต้องการความช่วยเหลือในการแก้ปัญหา 502 Bad Gateway Error หรือสงสัยว่าปัญหาเกิดจาก Edge Microgateway ให้ไปที่ ข้อมูลการวินิจฉัยที่ต้องรวบรวม

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

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

   • ไฟล์บันทึก: โฟลเดอร์เริ่มต้นคือ /var/tmp แต่คุณอาจลบล้างโฟลเดอร์นี้ ในไฟล์ config.yaml หลัก (logging > dir parameter) เราขอแนะนำให้ เปลี่ยน log > level เป็น info ก่อนส่ง ไฟล์บันทึกให้ทีมสนับสนุนของ Apigee
   • ไฟล์การกำหนดค่า: การกำหนดค่าหลักของ Edge Microgateway อยู่ใน ไฟล์ YAML ในโฟลเดอร์ Edge Microgateway เริ่มต้น $HOME/.edgemicro โดยจะมีไฟล์การกำหนดค่าเริ่มต้นชื่อ default.yaml และไฟล์การกำหนดค่าสำหรับแต่ละสภาพแวดล้อม ORG-ENV-config.yaml โปรดอัปโหลดไฟล์นี้ แบบเต็มสำหรับองค์กรและสภาพแวดล้อมที่ได้รับผลกระทบ