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

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

ลักษณะปัญหา

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

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

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

HTTP/1.1 502 Bad Gateway

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

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

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

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

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

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

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

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

การวินิจฉัย

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

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

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

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

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

   1. พิจารณาว่าข้อผิดพลาดเกตเวย์ 502 ไม่ถูกต้องจะเกิดขึ้นหลังจาก 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 เป็นสาเหตุของข้อผิดพลาด โปรดทำตามขั้นตอนในส่วนต่อไปนี้โดยขึ้นอยู่กับว่าคุณใช้ Public Cloud หรือ Private Cloud

ขั้นตอนการวินิจฉัยเพิ่มเติมสำหรับผู้ใช้ 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 ส่วนตัวและระบบคลาวด์สาธารณะ

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

ขั้นตอนการวินิจฉัยเพิ่มเติมสําหรับผู้ใช้ Edge ส่วนตัวและระบบคลาวด์สาธารณะ

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

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

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

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

   

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

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

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

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

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

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

การใช้ API Monitoring เพื่อระบุปัญหา

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

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

ความละเอียด

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

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

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

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

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

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