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

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

ลักษณะปัญหา

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

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

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

HTTP/1.1 502 Bad Gateway

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

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

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

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

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

สาเหตุ: TLS/SSL Handshake หมดเวลา

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

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

การวินิจฉัย

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

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

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

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

    1. ตรวจสอบว่าข้อผิดพลาด 502 เกตเวย์ไม่ถูกต้อง เกิดขึ้นหลังจากผ่านไป 55 วินาที ซึ่ง เป็นระยะหมดเวลาเริ่มต้นที่ตั้งค่าไว้ใน Message Processor หรือไม่ หากเห็นว่าข้อผิดพลาดเกิดขึ้นหลังจากผ่านไป 55 วินาที แสดงว่าการหมดเวลาเป็นสาเหตุที่เป็นไปได้ของปัญหา
    2. ตรวจสอบว่าข้อผิดพลาดแสดงข้อผิดพลาด messaging.adaptors.http.BadGateway หรือไม่ ข้อผิดพลาดนี้มักบ่งบอกว่าเกิดการหมดเวลา
    3. หากคุณใช้ Edge Private Cloud ให้จดค่าของ X-Apigee.Message-ID ในเอาต์พุตการติดตามดังที่แสดงด้านล่าง ผู้ใช้ Private Cloud สามารถใช้ค่ารหัสนี้เพื่อแก้ปัญหาเพิ่มเติมได้ตามที่อธิบายไว้ในภายหลัง

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

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

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

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

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

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

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

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

      telnet BackendServer-HostName 443

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

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

  2. ตรวจสอบไฟล์บันทึกของ Message Processor เพื่อดูหลักฐานการล้มเหลวของ Handshake เปิดไฟล์

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

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

    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
    

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

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

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

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

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

    tcpdump -i any -s 0 host <IP address> -w <File name>
    
    • หากคุณบันทึกแพ็กเก็ต TCP/IP ในเซิร์ฟเวอร์แบ็กเอนด์ ให้ใช้ที่อยู่ IP สาธารณะของ Message Processor ในคำสั่ง tcpdump ดูวิธีใช้ คำสั่งเพื่อตรวจสอบการเข้าชมเซิร์ฟเวอร์แบ็กเอนด์ได้ที่ tcpdump

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

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

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

  5. สังเกตในเอาต์พุตของ Wireshark ว่า TCP Handshake แบบ 3 ทางเสร็จสมบูรณ์ใน 3 แพ็กเก็ตแรก

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

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

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

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

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

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

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

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

ความละเอียด

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

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

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

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

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

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