502 ข้อผิดพลาดระยะหมดเวลาของเกตเวย์ไม่ถูกต้อง

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับข้อผิดพลาดเกตเวย์ไม่ถูกต้อง 502 ตัวประมวลผลข้อความจะแสดงข้อผิดพลาดนี้ไปยังแอปพลิเคชันไคลเอ็นต์เมื่อไม่ได้รับการตอบกลับจากเซิร์ฟเวอร์แบ็กเอนด์

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

แอปพลิเคชันไคลเอ็นต์จะได้รับโค้ดตอบกลับต่อไปนี้

HTTP/1.1 502 Bad Gateway

นอกจากนี้ คุณอาจสังเกตเห็นข้อความแสดงข้อผิดพลาดต่อไปนี้

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

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

สาเหตุที่เป็นไปได้ของปัญหานี้แสดงอยู่ในตารางต่อไปนี้

สาเหตุ	คำอธิบาย	คุณสามารถทำตามขั้นตอนการแก้ปัญหาได้โดย
การหมดเวลาของ handshake TLS/SSL	เกิดข้อจำกัดเวลาระหว่างการแฮนด์เชค TLS/SSL ระหว่างโปรแกรมประมวลผลข้อความกับเซิร์ฟเวอร์แบ็กเอนด์	ผู้ใช้ Edge Private และ Public Cloud

สาเหตุ: หมดเวลาแฮนด์เชค TLS/SSL

ใน Apigee Edge คุณสามารถตั้งค่าการเชื่อมต่อ TLS/SSL กับเซิร์ฟเวอร์แบ็กเอนด์เพื่อเปิดใช้การสื่อสาร TLS ระหว่าง Edge Message Processor กับเซิร์ฟเวอร์แบ็กเอนด์

การทำ Handshake ของ TLS/SSL มีหลายขั้นตอน ข้อผิดพลาดนี้มักเกิดขึ้นเมื่อจับมือ TLS/SSL ระหว่างโปรแกรมประมวลผลข้อความกับเซิร์ฟเวอร์แบ็กเอนด์หมดเวลา

การวินิจฉัย

ส่วนนี้จะอธิบายวิธีการวินิจฉัยระยะหมดเวลาของแฮนด์เชค TLS/SSL อย่างถูกต้อง แสดงวิธีการสำหรับ Edge Private Cloud และ Public Cloud

ตรวจสอบผลลัพธ์เซสชันการติดตาม

ขั้นตอนต่อไปนี้จะอธิบายวิธีวินิจฉัยปัญหาเบื้องต้นโดยใช้เครื่องมือ Apigee Edge Trace

1. ใน UI ของ Edge ให้เปิดใช้เซสชันการติดตามสําหรับพร็อกซี API ที่ได้รับผลกระทบ

2. หากการติดตามคำขอ API ที่ไม่สำเร็จแสดงข้อมูลต่อไปนี้ แสดงว่าอาจเกิดข้อผิดพลาดในการจับคู่ TLS/SSL หมดเวลา สาเหตุที่เป็นไปได้ของข้อผิดพลาดคือไฟร์วอลล์ของเซิร์ฟเวอร์แบ็กเอนด์บล็อกการรับส่งข้อมูลจาก Apigee

   1. ตรวจสอบว่าข้อผิดพลาด 502 Bad Gateway เกิดขึ้นหลังจากผ่านไป 55 วินาทีหรือไม่ ซึ่งเป็นระยะเวลาหมดเวลาเริ่มต้นที่ตั้งค่าไว้ในโปรแกรมประมวลผลข้อความ หากคุณเห็นว่าข้อผิดพลาดเกิดขึ้นหลังจากผ่านไป 55 วินาที แสดงว่าเวลาหมดอาจเป็นสาเหตุของปัญหา
   2. ตรวจสอบว่าข้อผิดพลาดแสดงข้อผิดพลาดหรือไม่: messaging.adaptors.http.BadGateway อีกครั้ง ข้อผิดพลาดนี้มักบ่งบอกว่าเกิดปัญหาการหมดเวลา

   3. หากคุณใช้ Edge Private Cloud ให้สังเกตค่าของช่อง X-Apigee.Message-ID ในเอาต์พุตการติดตามดังที่แสดงด้านล่าง ผู้ใช้ Private Cloud สามารถใช้ค่ารหัสนี้เพื่อแก้ปัญหาเพิ่มเติมได้ ตามที่อธิบายไว้ภายหลัง

      1. คลิกไอคอนบันทึกข้อมูล Analytics ในเส้นทางการติดตาม ดังนี้

         

      2. เลื่อนลงและจดค่าของช่องชื่อ X-Apigee.Message-ID

หากต้องการยืนยันว่าการหมดเวลาของ TLS/SSL Handshake เป็นสาเหตุของข้อผิดพลาด ให้ทำตามขั้นตอนในส่วนต่อไปนี้โดยขึ้นอยู่กับว่าคุณใช้ระบบคลาวด์สาธารณะหรือระบบคลาวด์ส่วนตัว

ขั้นตอนการวินิจฉัยเพิ่มเติมสำหรับผู้ใช้ Edge Private Cloud เท่านั้น

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

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

   1. หากเซิร์ฟเวอร์แบ็กเอนด์แสดงผลเป็นที่อยู่ IP เดียว ให้ใช้คำสั่งนี้

      telnet BackendServer-IPaddress 443

   2. หากเซิร์ฟเวอร์แบ็กเอนด์แก้ไขเป็นที่อยู่ IP หลายรายการ ให้ใช้ชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ในคำสั่ง telnet ดังที่แสดงด้านล่าง

      telnet BackendServer-HostName 443

   หากเชื่อมต่อเซิร์ฟเวอร์แบ็กเอนด์ได้โดยไม่มีข้อผิดพลาด ให้ไปยังขั้นตอนถัดไป

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

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

   /opt/apigee/var/log/edge-message-processor/system.log

   และค้นหารหัสข้อความที่ไม่ซ้ำกัน (ค่าของ X-Apigee.Message-ID ที่คุณพบในไฟล์ติดตาม) ตรวจสอบว่าคุณเห็นข้อความแสดงข้อผิดพลาดในการจับมือที่เชื่อมโยงกับรหัสข้อความดังที่แสดงด้านล่างหรือไม่

   org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
   HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
   isOpen=true handshake timeout
   

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

หากไม่เห็นข้อความจับมือในไฟล์บันทึก ให้ไปที่ต้องรวบรวมข้อมูลการวินิจฉัย

ขั้นตอนการวินิจฉัยเพิ่มเติมสำหรับผู้ใช้ Edge Private และ Public Cloud

หากต้องการระบุปัญหาเพิ่มเติม คุณสามารถใช้เครื่องมือ tcpdump เพื่อวิเคราะห์แพ็กเก็ต TCP/IP เพื่อยืนยันว่าเกิดเวลาหมดอายุระหว่างแฮนด์เชค TLS/SSL หรือไม่

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

3. หลังจากตัดสินใจว่าจะบันทึกแพ็กเก็ต TCP/IP ที่ใด ให้ใช้คำสั่ง tcpdump ต่อไปนี้เพื่อบันทึกแพ็กเก็ต TCP/IP

   tcpdump -i any -s 0 host <IP address> -w <File name>
   

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

   • หากคุณจะรับแพ็กเก็ต TCP/IP บน Message Processor ให้ใช้ที่อยู่ IP สาธารณะของเซิร์ฟเวอร์แบ็กเอนด์ในคำสั่ง tcpdump สำหรับความช่วยเหลือในการใช้คำสั่ง เพื่อตรวจสอบการรับส่งข้อมูลของตัวประมวลผลข้อความ โปรดดูที่ tcpdump

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

4. วิเคราะห์แพ็กเก็ต TCP/IP โดยใช้เครื่องมือ Wireshark หรือเครื่องมือที่คล้ายกัน ภาพหน้าจอต่อไปนี้แสดงแพ็กเก็ต TCP/IP ใน Wireshark

   

5. โปรดสังเกตในเอาต์พุต Wireshark ว่าแฮนด์เชค TCP 3 ทางเสร็จสมบูรณ์ใน 3 แพ็กเก็ตแรก

6. จากนั้นตัวประมวลผลข้อความจะส่งข้อความ "Client Hello" ในแพ็กเก็ต #4

7. เนื่องจากไม่มีการรับทราบจากเซิร์ฟเวอร์แบ็กเอนด์ ตัวประมวลผลข้อความจะส่งข้อความ "Client Hello" ซ้ำหลายครั้งในแพ็กเก็ตที่ 5, 6 และ 7 หลังจากที่รอช่วงเวลาที่กำหนดไว้ล่วงหน้า

8. เมื่อตัวประมวลผลข้อความไม่ได้รับการตอบรับใดๆ หลังจากลองใหม่ 3 ครั้ง ระบบจะส่งข้อความ FIN, ACK ไปยังเซิร์ฟเวอร์แบ็กเอนด์เพื่อระบุว่ากำลังจะปิดการเชื่อมต่อ

9. ดังที่คุณแสดงในตัวอย่างเซสชัน Wireshark การเชื่อมต่อกับแบ็กเอนด์สำเร็จ (ขั้นตอนที่ 1) แต่การจับมือ SSL หมดเวลาเนื่องจากเซิร์ฟเวอร์แบ็กเอนด์ไม่ตอบกลับ

หากคุณทำตามขั้นตอนการแก้ปัญหาใน Playbook นี้แล้ว และพิจารณาแล้วว่าการหมดเวลาทำให้เกิดข้อผิดพลาดในการจับมือ TLS/SSL ให้ไปที่ส่วนการแก้ปัญหา

การใช้การตรวจสอบ API เพื่อระบุปัญหา

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

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

ความละเอียด

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

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

หากไม่มีข้อจำกัดของไฟร์วอลล์และ/หรือปัญหายังคงอยู่ ให้ไปที่ต้องรวบรวมข้อมูลการวินิจฉัย

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

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

1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ระบุข้อมูลต่อไปนี้
   1. ชื่อองค์กร
   2. ชื่อสภาพแวดล้อม
   3. ชื่อพร็อกซี API
   4. พิมพ์คำสั่ง curl ให้เสร็จสมบูรณ์เพื่อทําให้ข้อผิดพลาดเกิดขึ้นอีกครั้ง
   5. ไฟล์การย้ายข้อมูลแสดงข้อผิดพลาด
   6. แพ็กเก็ต TCP/IP ที่บันทึกบนเซิร์ฟเวอร์แบ็กเอนด์
2. หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้
   1. พบข้อความแสดงข้อผิดพลาดที่สมบูรณ์
   2. แพ็กเกจพร็อกซี API
   3. ไฟล์การติดตามที่แสดงข้อผิดพลาด
   4. บันทึกของ Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log
   5. แพ็กเก็ต TCP/IP ที่บันทึกไว้ในเซิร์ฟเวอร์แบ็กเอนด์หรือโปรแกรมประมวลผลข้อความ
3. รายละเอียดเกี่ยวกับส่วนที่คุณลองทำใน Playbook นี้และข้อมูลเชิงลึกอื่นๆ ที่จะเร่งให้เราแก้ปัญหานี้ได้