502 EOF เกตเวย์ไม่ถูกต้อง

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

ลักษณะปัญหา

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

รหัสสถานะ HTTP 502 หมายความว่าไคลเอ็นต์ไม่ได้รับการตอบสนองที่ถูกต้องจาก เซิร์ฟเวอร์แบ็กเอนด์ที่ ควรดำเนินการตามคำขอจริงๆ

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

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

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

สาเหตุทั่วไปอย่างหนึ่งของ502 Bad Gateway ErrorคือUnexpected EOF ซึ่งอาจเกิดจากสาเหตุต่อไปนี้

สาเหตุ	รายละเอียด	ขั้นตอนที่ให้สำหรับ
เซิร์ฟเวอร์เป้าหมายมีการกำหนดค่าไม่ถูกต้อง	เซิร์ฟเวอร์เป้าหมายไม่ได้รับการกำหนดค่าอย่างถูกต้องให้รองรับการเชื่อมต่อ TLS/SSL	ผู้ใช้ Edge สาธารณะและ Private Cloud
EOFException จากเซิร์ฟเวอร์แบ็กเอนด์	เซิร์ฟเวอร์แบ็กเอนด์อาจส่ง EOF กะทันหัน	เฉพาะผู้ใช้ Edge Private Cloud
การกำหนดค่าระยะหมดเวลาของ Keep-alive ไม่ถูกต้อง	กำหนดค่าระยะหมดเวลาตลอดอายุการใช้งานอย่างไม่ถูกต้องใน Apigee และเซิร์ฟเวอร์แบ็กเอนด์	ผู้ใช้ Edge สาธารณะและ Private Cloud

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

หากต้องการวินิจฉัยข้อผิดพลาด คุณสามารถใช้วิธีการใดก็ได้ต่อไปนี้

• การตรวจสอบ API
• เครื่องมือการติดตาม
• บันทึกการเข้าถึง NGINX

สาเหตุ: เซิร์ฟเวอร์เป้าหมายมีการกำหนดค่าไม่ถูกต้อง

เซิร์ฟเวอร์เป้าหมายไม่ได้รับการกำหนดค่าอย่างถูกต้องให้รองรับการเชื่อมต่อ TLS/SSL

การวินิจฉัย

1. ใช้การตรวจสอบ API, เครื่องมือการติดตาม หรือ บันทึกการเข้าถึง NGINX เพื่อระบุรหัสข้อความ รหัสข้อผิดพลาด และแหล่งที่มาของข้อผิดพลาดสำหรับข้อผิดพลาด 502
2. เปิดใช้การติดตามใน UI สำหรับ API ที่ได้รับผลกระทบ
3. หากการติดตามสำหรับคำขอ API ที่ล้มเหลวแสดงข้อมูลต่อไปนี้
   1. ระบบพบข้อผิดพลาด 502 Bad Gateway ทันทีที่คำขอโฟลว์เป้าหมายเริ่มต้น
   2. error.class จะแสดง messaging.adaptors.http.UnexpectedEOF.

      แสดงว่าปัญหานี้น่าจะเกิดจากเซิร์ฟเวอร์เป้าหมายไม่ถูกต้อง การกำหนดค่า

4. รับคำจำกัดความของเซิร์ฟเวอร์เป้าหมายโดยใช้การเรียก Edge Management API ดังนี้
   1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ใช้ API นี้

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

   2. หากคุณเป็นผู้ใช้ Private Cloud ให้ใช้ API นี้

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

      ตัวอย่างคำจำกัดความของ TargetServer ที่มีข้อผิดพลาด:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >
      

5. ตัวอย่างคำจำกัดความของ TargetServer เป็นตัวอย่างสำหรับ การกำหนดค่าที่ไม่ถูกต้อง ซึ่งมีคำอธิบายดังต่อไปนี้

   สมมติว่ามีการกำหนดค่าเซิร์ฟเวอร์เป้าหมาย mocktarget.apigee.net เพื่อยอมรับการเชื่อมต่อที่ปลอดภัย (HTTPS) บนพอร์ต 443 แต่หากพิจารณา หรือการกำหนดเซิร์ฟเวอร์เป้าหมาย จะไม่มีแอตทริบิวต์/แฟล็กอื่นๆ ที่ระบุว่าเป็น เพื่อการเชื่อมต่อที่ปลอดภัย ซึ่งจะทำให้ Edge ดำเนินการกับคำขอ API ที่ส่งไปยัง เซิร์ฟเวอร์เป้าหมายที่เฉพาะเจาะจงเป็นคำขอ HTTP (ไม่ปลอดภัย) ดังนั้น Edge จะไม่ เริ่มต้นกระบวนการแฮนด์เชค SSL กับเซิร์ฟเวอร์เป้าหมายนี้

   เนื่องจากเซิร์ฟเวอร์เป้าหมายมีการกำหนดค่าให้ยอมรับเฉพาะคำขอ HTTPS (SSL) ใน 443 เซิร์ฟเวอร์จะ ปฏิเสธคำขอจาก Edge หรือปิดการเชื่อมต่อ ดังนั้นคุณจะได้รับ เกิดข้อผิดพลาด UnexpectedEOFAtTarget ใน Message Processor จากนั้นโปรแกรมประมวลผลข้อความจะส่ง 502 Bad Gateway เป็นการตอบกลับไปยังไคลเอ็นต์

ความละเอียด

โปรดตรวจสอบทุกครั้งว่าเซิร์ฟเวอร์เป้าหมายได้รับการกำหนดค่าอย่างถูกต้องตามข้อกำหนดของคุณ

จากตัวอย่างด้านบน หากคุณต้องการส่งคำขอไปยังเป้าหมาย (HTTPS/SSL) ที่ปลอดภัย คุณต้องรวมแอตทริบิวต์ SSLInfo ด้วยชุดแฟล็ก enabled ไปยัง true แม้ว่าจะสามารถเพิ่มแอตทริบิวต์ SSLInfo สำหรับเซิร์ฟเวอร์เป้าหมายในเป้าหมายได้ ของคำจำกัดความปลายทาง ขอแนะนำให้เพิ่มแอตทริบิวต์ SSLInfo เป็นส่วนหนึ่งของเป้าหมาย เพื่อป้องกันความสับสน

1. หากบริการแบ็กเอนด์ต้องใช้การสื่อสาร SSL แบบทางเดียว ให้ดำเนินการต่อไปนี้
   1. คุณต้องเปิดใช้ TLS/SSL ในคำจำกัดความ TargetServer โดยรวม SSLInfo ที่มีการตั้งค่าแฟล็ก enabled เป็น "จริง" ดังที่แสดงด้านล่าง

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
      

   2. หากต้องการตรวจสอบใบรับรองของเซิร์ฟเวอร์เป้าหมายใน Edge เราจำเป็นต้องดำเนินการต่อไปนี้ด้วย รวม Truststore (ที่มีใบรับรองของเซิร์ฟเวอร์เป้าหมาย) ดังที่แสดงด้านล่าง

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>
      

2. หากบริการแบ็กเอนด์ต้องใช้การสื่อสาร SSL แบบ 2 ทาง ให้ทำดังนี้
   1. คุณต้องมีแอตทริบิวต์ SSLInfo ที่มี ClientAuthEnabled Keystore, KeyAlias และ มีการตั้งค่าแฟล็ก Truststore อย่างเหมาะสมดังที่แสดงด้านล่าง

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >
      

ข้อมูลอ้างอิง

การจัดสรรภาระงาน ในเซิร์ฟเวอร์แบ็กเอนด์

สาเหตุ: EOFException จากเซิร์ฟเวอร์แบ็กเอนด์

เซิร์ฟเวอร์แบ็กเอนด์อาจส่ง EOF (สิ้นสุดไฟล์) กะทันหัน

การวินิจฉัย

1. ใช้การตรวจสอบ API, เครื่องมือการติดตาม หรือ บันทึกการเข้าถึง NGINX เพื่อระบุรหัสข้อความ รหัสข้อผิดพลาด และแหล่งที่มาของข้อผิดพลาดสำหรับข้อผิดพลาด 502
2. ตรวจสอบบันทึกสำหรับโปรแกรมประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log) แล้วค้นหาเพื่อดูว่าคุณ มี eof unexpected สำหรับ API เฉพาะ หรือหากคุณมี messageid ที่ไม่ซ้ำกันสำหรับ API จากนั้นคุณจะสามารถค้นหาได้

   ตัวอย่างสแต็กเทรซข้อยกเว้นจากบันทึก Message Processor

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
   

   ในตัวอย่างข้างต้น คุณจะเห็นว่าข้อผิดพลาด java.io.EOFException: eof unexpected เกิดขึ้นขณะที่ระบบประมวลผลข้อความกำลังพยายามอ่านการตอบกลับจาก เซิร์ฟเวอร์แบ็กเอนด์ ข้อยกเว้นนี้ระบุว่าจุดสิ้นสุดของไฟล์ (EOF) หรือจุดสิ้นสุดของสตรีม โดยไม่คาดคิด

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

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

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
      

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

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
      

      โดยทั่วไป ข้อผิดพลาดนี้เกิดขึ้นเนื่องจากเซิร์ฟเวอร์แบ็กเอนด์จะตอบสนองด้วย [FIN,ACK] ทันทีที่เครื่องมือประมวลผลข้อความส่งคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์

5. ลองดูตัวอย่าง tcpdump ต่อไปนี้

   ตัวอย่าง tcpdump ถ่ายเมื่อ 502 Bad Gateway Error (UnexpectedEOFAtTarget) เกิดขึ้น

   

6. จากเอาต์พุต TCPDump คุณจะเห็นลำดับเหตุการณ์ต่อไปนี้
   1. ในแพ็กเก็ต 985 ตัวประมวลผลข้อความจะส่งคำขอ API ไปยังเซิร์ฟเวอร์แบ็กเอนด์
   2. ในแพ็กเก็ต 986 เซิร์ฟเวอร์แบ็กเอนด์จะตอบกลับด้วย [FIN,ACK] ทันที
   3. ในแพ็กเก็ต 987 ตัวประมวลผลข้อความจะตอบสนองด้วย [FIN,ACK] ไปยังแบ็กเอนด์ เซิร์ฟเวอร์
   4. ในที่สุดระบบก็ปิดการเชื่อมต่อโดยมี [ACK] และ [RST] จากทั้ง 2 ฝั่ง
   5. เนื่องจากเซิร์ฟเวอร์แบ็กเอนด์จะส่ง [FIN,ACK] คุณจึงได้รับข้อยกเว้น ข้อยกเว้น java.io.EOFException: eof unexpected ในข้อความ ผู้ประมวลผลข้อมูล
7. ซึ่งอาจเกิดขึ้นได้หากเซิร์ฟเวอร์แบ็กเอนด์มีปัญหา สร้างการมีส่วนร่วมในเครือข่าย ทีมปฏิบัติการเพื่อตรวจสอบปัญหานี้เพิ่มเติม

ความละเอียด

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

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

สาเหตุ: กำหนดค่าไม่ถูกต้องสำหรับการหมดเวลาของ Keep-alive

ก่อนที่จะวินิจฉัยว่านี่เป็นสาเหตุของข้อผิดพลาด 502 หรือไม่ โปรดอ่าน แนวคิดต่อไปนี้

การเชื่อมต่อแบบถาวรใน Apigee

โดยค่าเริ่มต้น Apigee (และต่อท้ายด้วยมาตรฐาน HTTP/1.1) จะใช้การเชื่อมต่อแบบถาวร เมื่อสื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์เป้าหมาย การเชื่อมต่ออย่างต่อเนื่องช่วยเพิ่มประสิทธิภาพได้ ด้วยการอนุญาตให้ระบบ TCP และการเชื่อมต่อ TLS/SSL ที่มีอยู่แล้ว (หากมี) ถูกใช้ซ้ำ ช่วยลดค่าใช้จ่ายของเวลาในการตอบสนอง ระยะเวลาที่ต้องคงการเชื่อมต่อได้รับการควบคุม ผ่านพร็อพเพอร์ตี้ รักษาระยะหมดเวลาไว้ (keepalive.timeout.millis)

ทั้งเซิร์ฟเวอร์แบ็กเอนด์และ Apigee Message Processor จะใช้ระยะหมดเวลาแบบ Keep-alive เพื่อรักษาไว้ การเชื่อมต่อจะเปิดขึ้นพร้อมกัน เมื่อไม่มีการส่งข้อมูลภายในระยะหมดเวลาของ Keep alive เซิร์ฟเวอร์ส่วนหลังหรือตัวประมวลผลข้อความสามารถปิดการเชื่อมต่อกับเซิร์ฟเวอร์อื่นๆ ได้

โดยค่าเริ่มต้น พร็อกซี API ที่ทำให้ใช้งานได้กับตัวประมวลผลข้อความใน Apigee จะตั้งค่าระยะหมดเวลา Keep ทำงานเป็น 60s เว้นแต่จะมีการลบล้าง เมื่อได้รับข้อมูลสำหรับ 60s แล้ว Apigee จะ ปิดการเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ เซิร์ฟเวอร์แบ็กเอนด์จะคงระยะหมดเวลา Keep-alive ไว้ และเมื่อขั้นตอนนี้หมดอายุ เซิร์ฟเวอร์แบ็กเอนด์จะปิดการเชื่อมต่อกับ Message Processor

ผลกระทบจากการกำหนดค่าระยะหมดเวลาของ Keep-alive ที่ไม่ถูกต้อง

หากมีการกำหนดค่า Apigee หรือเซิร์ฟเวอร์แบ็กเอนด์ด้วยระยะหมดเวลาของ Keep-alive ที่ไม่ถูกต้อง ส่งผลให้เกิดเงื่อนไขการแข่งขันซึ่งทำให้เซิร์ฟเวอร์แบ็กเอนด์ส่ง End Of File (FIN) ที่ไม่คาดคิดเพื่อตอบกลับคำขอทรัพยากร

ตัวอย่างเช่น หากมีการกำหนดค่าระยะหมดเวลาของ Keep-alive ภายในพร็อกซี API หรือข้อความ โปรเซสเซอร์ที่มีค่ามากกว่าหรือเท่ากับระยะหมดเวลาของเซิร์ฟเวอร์แบ็กเอนด์อัปสตรีม จากนั้น อาจมีอาการดังต่อไปนี้ กล่าวคือ หากตัวประมวลผลข้อความไม่ได้รับ ข้อมูลจนถึงเกณฑ์ที่ใกล้เกณฑ์ของเซิร์ฟเวอร์แบ็กเอนด์จะทำให้หมดเวลาใช้งาน จากนั้นจะมีคำขอ เข้ามาและส่งไปยังเซิร์ฟเวอร์แบ็กเอนด์โดยใช้การเชื่อมต่อที่มีอยู่ ซึ่งอาจส่งผลถึง 502 Bad Gateway เนื่องจากเกิดข้อผิดพลาด EOF ที่ไม่คาดคิดตามที่อธิบายไว้ด้านล่าง:

1. สมมติว่าระยะหมดเวลา Keep-alive ถูกตั้งค่าไว้ทั้งในตัวประมวลผลข้อความและเซิร์ฟเวอร์แบ็กเอนด์ คือ 60 วินาทีและไม่มีรายการใหม่ มาจนกระทั่ง 59 วินาทีหลังจากที่คำขอก่อนหน้าได้ส่งโดย ตัวประมวลผลข้อความ
2. โปรแกรมประมวลผลข้อความจะดำเนินการตามคำขอที่เข้ามาในวินาทีที่ 59 โดยใช้การเชื่อมต่อที่มีอยู่ (เนื่องจากระยะหมดเวลา Keep-alive ยังไม่ผ่าน) แล้วส่ง ไปยังเซิร์ฟเวอร์แบ็กเอนด์
3. อย่างไรก็ตาม ก่อนที่คำขอจะส่งมาที่เซิร์ฟเวอร์แบ็กเอนด์ ระบบจะหมดเวลา "ปล่อยให้ทำงาน" ก่อน เกินเกณฑ์ในเซิร์ฟเวอร์แบ็กเอนด์
4. คำขอทรัพยากรของผู้ประมวลผลข้อมูลข้อความอยู่ระหว่างดำเนินการ แต่เซิร์ฟเวอร์แบ็กเอนด์ พยายามปิดการเชื่อมต่อด้วยการส่งแพ็กเก็ต FIN ไปยังข้อความ ผู้ประมวลผลข้อมูล
5. ขณะที่ตัวประมวลผลข้อความกำลังรอรับข้อมูล แต่จะได้รับข้อมูล FIN ที่ไม่คาดคิด และการเชื่อมต่อจะสิ้นสุดลง
6. การดำเนินการนี้จะส่งผลให้เกิด Unexpected EOF และต่อมาเป็น 502 ตัวประมวลผลข้อความจะส่งกลับไปยังไคลเอ็นต์

ในกรณีนี้ เราพบว่าเกิดข้อผิดพลาด 502 ขึ้นเนื่องจากมีการหมดเวลาของ Keep-alive เดียวกัน กำหนดค่า 60 วินาทีแล้วทั้งในเซิร์ฟเวอร์ตัวประมวลผลข้อความและเซิร์ฟเวอร์แบ็กเอนด์ ในทำนองเดียวกัน ปัญหานี้อาจเกิดขึ้นได้เช่นกันหากมีการกำหนดค่าที่สูงกว่าสำหรับระยะหมดเวลาของ Keep-alive ในข้อความ ผู้ประมวลผลข้อมูลมากกว่าในเซิร์ฟเวอร์แบ็กเอนด์

การวินิจฉัย

1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ทำดังนี้
   1. ใช้เครื่องมือตรวจสอบหรือติดตาม API (ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไป) และตรวจสอบว่าคุณมีคุณสมบัติตรงตามทั้ง 2 ข้อต่อไปนี้ การตั้งค่าต่อไปนี้
      • รหัสข้อผิดพลาด: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • แหล่งที่มาของข้อผิดพลาด: target
   2. ไปที่การใช้ tcpdump เพื่อตรวจสอบเพิ่มเติม
2. หากคุณเป็นผู้ใช้ Private Cloud ให้ทำดังนี้
   1. ใช้เครื่องมือติดตามหรือ บันทึกการเข้าถึง NGINX เพื่อระบุรหัสข้อความ รหัสข้อผิดพลาด และแหล่งที่มาของข้อผิดพลาดสำหรับข้อผิดพลาด 502
   2. ค้นหารหัสข้อความในบันทึกตัวประมวลผลข้อความ
      (/opt/apigee/var/log/edge-message-processor/logs/system.log)
   3. คุณจะเห็น java.io.EOFEXception: eof unexpected ตามที่แสดงด้านล่าง วันที่

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
      

   4. ข้อผิดพลาด java.io.EOFException: eof unexpected บ่งชี้ว่า ผู้ประมวลผลข้อความได้รับ EOF ขณะที่รออ่าน การตอบกลับจากเซิร์ฟเวอร์แบ็กเอนด์
   5. แอตทริบิวต์ useCount=7 ในข้อความแสดงข้อผิดพลาดข้างต้นระบุว่า ตัวประมวลผลข้อความได้ใช้การเชื่อมต่อนี้ซ้ำประมาณ 7 ครั้งและแอตทริบิวต์ bytesWritten=159 ระบุว่าเครื่องมือประมวลผลข้อความได้ส่งคำขอแล้ว เพย์โหลด 159 ไบต์ไปยังเซิร์ฟเวอร์แบ็กเอนด์ แต่คุณได้รับ 0 ไบต์ เมื่อเกิดEOFที่ไม่คาดคิด

   6. ซึ่งแสดงว่าระบบประมวลผลข้อความได้ใช้การเชื่อมต่อเดิมซ้ำหลายครั้ง และในกรณีนี้ มีการส่งข้อมูล แต่หลังจากนั้นไม่นานก็ได้รับ EOF ก่อนที่จะมีการรับข้อมูล ซึ่งหมายความว่า มีโอกาสสูงที่แบ็กเอนด์ ระยะหมดเวลา Keep-alive ของเซิร์ฟเวอร์นั้นสั้นกว่าหรือเท่ากับค่าที่ตั้งไว้ในพร็อกซี API

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

การใช้ tcpdump

1. บันทึก tcpdump ในเซิร์ฟเวอร์แบ็กเอนด์ด้วยคำสั่งต่อไปนี้ วันที่

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name
   

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

   ต่อไปนี้คือตัวอย่างเอาต์พุต tcpdump

   

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

   1. ในแพ็กเก็ต 5992, เซิร์ฟเวอร์แบ็กเอนด์ได้รับคำขอ GET
   2. ในแพ็กเก็ต 6064 ตอบสนองด้วย 200 OK.
   3. ในแพ็กเก็ต 6084 เซิร์ฟเวอร์แบ็กเอนด์ได้รับคำขอ GET อีกรายการ
   4. ในแพ็กเก็ต 6154 จะตอบสนองด้วย 200 OK
   5. ในแพ็กเก็ต 6228 เซิร์ฟเวอร์แบ็กเอนด์ได้รับคำขอ GET รายการที่ 3
   6. ในขณะนี้ เซิร์ฟเวอร์แบ็กเอนด์จะส่ง FIN, ACK กลับไปยังตัวประมวลผลข้อความ (แพ็กเก็ต 6285) ที่เริ่มปิดการเชื่อมต่อ

   ในตัวอย่างนี้มีการใช้การเชื่อมต่อเดียวกันซ้ำ 2 ครั้งแล้ว แต่ในคำขอที่สาม เซิร์ฟเวอร์ส่วนหลังจะเริ่มปิดการเชื่อมต่อ ขณะที่ตัวประมวลผลข้อความ กำลังรอข้อมูลจากเซิร์ฟเวอร์แบ็กเอนด์ แสดงว่าเซิร์ฟเวอร์แบ็กเอนด์จะเก็บ การหมดเวลาตลอดอายุการใช้งานมักจะสั้นกว่าหรือเท่ากับค่าที่ตั้งไว้ในพร็อกซี API วิธีตรวจสอบ ที่หัวข้อเปรียบเทียบระยะหมดเวลา Keep-alive บน Apigee และเซิร์ฟเวอร์แบ็กเอนด์

เปรียบเทียบการหมดเวลาของ Keep alive บน Apigee และเซิร์ฟเวอร์แบ็กเอนด์

1. โดยค่าเริ่มต้น Apigee จะใช้ค่า 60 วินาทีสำหรับพร็อพเพอร์ตี้ระยะหมดเวลาของ Keep-alive

2. อย่างไรก็ตาม คุณอาจลบล้างค่าเริ่มต้นในพร็อกซี API ไปแล้ว คุณยืนยันได้โดยตรวจสอบคําจํากัดความ TargetEndpoint ที่เจาะจงใน พร็อกซี API ที่ไม่ผ่านการตรวจสอบซึ่งแสดงข้อผิดพลาด 502 รายการ

   ตัวอย่างการกำหนดค่า TargetEndpoint

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>
   

   ในตัวอย่างข้างต้น มีการลบล้างพร็อพเพอร์ตี้การหมดเวลาของ Keep alive ด้วยค่า 30 วินาที (30000 มิลลิวินาที)

3. ถัดไป ให้ตรวจสอบพร็อพเพอร์ตี้การหมดเวลา Keep alive ที่กำหนดค่าไว้ในเซิร์ฟเวอร์แบ็กเอนด์ สมมติว่า เซิร์ฟเวอร์แบ็กเอนด์ของคุณได้รับการกำหนดค่าด้วยค่า 25 seconds
4. หากคุณเห็นว่าค่าของพร็อพเพอร์ตี้ระยะหมดเวลา Keep alive ใน Apigee สูงกว่า มากกว่าค่าของพร็อพเพอร์ตี้การหมดเวลา Keep alive บนเซิร์ฟเวอร์แบ็กเอนด์ตามข้างต้น นั่นคือสาเหตุของข้อผิดพลาด 502

ความละเอียด

ตรวจสอบว่าพร็อพเพอร์ตี้ Keep-alive หมดเวลาใน Apigee ต่ำกว่าเสมอ (ในพร็อกซี API และ คอมโพเนนต์ตัวประมวลผลข้อความ) เทียบกับในเซิร์ฟเวอร์แบ็กเอนด์

1. ระบุค่าที่ตั้งไว้สำหรับระยะหมดเวลา Keep alive บนเซิร์ฟเวอร์แบ็กเอนด์
2. กำหนดค่าที่เหมาะสมสำหรับพร็อพเพอร์ตี้การหมดเวลาของ Keep alive ในพร็อกซี API หรือ ตัวประมวลผลข้อความ ซึ่งทำให้พร็อพเพอร์ตี้ Keep-alive หมดเวลาต่ำกว่าค่าที่ตั้งไว้ใน เซิร์ฟเวอร์ส่วนหลัง โดยใช้ขั้นตอนที่อธิบายไว้ใน การกำหนดค่าระยะหมดเวลา Keep alive ใน Message Processor

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

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

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

1. ระยะหมดเวลาของ Keep-alive ของไคลเอ็นต์ควรน้อยกว่าระยะหมดเวลาของ Edge Router ที่จะคงอยู่
2. การหมดเวลาของ Edge Router จะคงการทำงานต้องน้อยกว่าค่าการหมดเวลาของ Message Processor ที่ยังคงทำงานอยู่
3. การหมดเวลาของ Keep-alive ของโปรแกรมประมวลผลข้อความควรน้อยกว่าการหมดเวลาแบบ Keep-alive ของเซิร์ฟเวอร์เป้าหมาย
4. หากคุณมีการ Hop อื่นๆ ที่อยู่ด้านหน้าหรือหลัง Apigee ก็ควรใช้กฎเดียวกันนี้ด้วย คุณควรปล่อยให้ลูกค้าเป็นผู้รับผิดชอบปลายทางในการปิด การเชื่อมต่อกับอัปสตรีม

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

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

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

• ชื่อองค์กร
• ชื่อสภาพแวดล้อม
• ชื่อพร็อกซี API
• ทำตามคำสั่ง curl เพื่อทำให้เกิดข้อผิดพลาด 502 ซ้ำ
• ไฟล์การติดตามที่มีคำขอที่มีข้อผิดพลาด 502 Bad Gateway - Unexpected EOF รายการ
• หากไม่มีข้อผิดพลาด 502 ในปัจจุบัน โปรดระบุระยะเวลาด้วย ข้อมูลเขตเวลาเมื่อเกิดข้อผิดพลาด 502 รายการในอดีต

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

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