503 ไม่พร้อมให้บริการ

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

วิดีโอ

ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อผิดพลาด 503 ได้ในวิดีโอต่อไปนี้

วิดีโอ คำอธิบาย
แก้ปัญหาและแก้ไขข้อผิดพลาดเกี่ยวกับบริการ 503 ไม่ได้เนื่องจากปัญหา DNS ดูข้อมูลเกี่ยวกับสิ่งต่อไปนี้
  • ข้อผิดพลาด 503 บริการไม่พร้อมใช้งาน ซึ่งเกิดจากการแปลง DNS และปัญหาเกี่ยวกับเครือข่ายใน Apigee Edge
  • การแก้ปัญหาและการแก้ไขข้อผิดพลาด 503 Service Unavailable แบบเรียลไทม์ซึ่งเกิดจากการแก้ปัญหา DNS
การแก้ปัญหาและแก้ไขข้อผิดพลาดเกี่ยวกับบริการ 503 ไม่ได้เนื่องจากปัญหาของเครือข่าย การแก้ปัญหาและการแก้ไขข้อผิดพลาด "บริการ 503 ไม่พร้อมใช้งานแบบเรียลไทม์" ซึ่งเกิดจากปัญหาของเครือข่ายใน Apigee Edge

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์จะได้รับสถานะการตอบกลับ HTTP 503 พร้อมด้วยข้อความ Service Unavailable หลังจากการเรียกพร็อกซี API

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

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

HTTP/1.1 503 Service Unavailable
      

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

ไม่พร้อมให้บริการ

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}
      

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

การตอบกลับ HTTP 503 Service Unavailable ที่มีรหัสข้อผิดพลาด messaging.adaptors.http.flow.ServiceUnavailable จะเกิดขึ้นหากตัวประมวลผลข้อความของ Apigee Edge พบข้อผิดพลาดเนื่องจากการเชื่อมต่อหมดเวลา ชื่อโฮสต์ไม่ถูกต้อง หรือแฮนด์เชค SSL ล้มเหลวขณะสื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์

สาเหตุที่เป็นไปได้ของการตอบกลับว่าบริการ 503 ไม่พร้อมใช้งานมีดังนี้

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

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

กำหนดรหัสข้อความของคำขอที่ล้มเหลว

เครื่องมือการติดตาม

หากต้องการระบุรหัสข้อความของคำขอที่ล้มเหลวโดยใช้เครื่องมือติดตาม ให้ทำดังนี้

  1. หากยังพบปัญหาอยู่ ให้เปิดใช้เซสชันการติดตามสำหรับ API ที่ได้รับผลกระทบ
  2. ทำการเรียก API และทำให้เกิดปัญหาซ้ำ - 503 บริการไม่พร้อมใช้งานโดยมีรหัสข้อผิดพลาด messaging.adaptors.http.flow.ServiceUnavailable.
  3. เลือกคำขอที่ล้มเหลว 1 รายการ
  4. ไปที่เฟส AX แล้วระบุรหัสข้อความ (X-Apigee.Message-ID) ของคำขอโดยเลื่อนลงในส่วนรายละเอียดเฟสดังที่แสดงในรูปต่อไปนี้

    รหัสข้อความในส่วนรายละเอียดเฟส

บันทึกการเข้าถึง NGINX

วิธีระบุรหัสข้อความของคำขอที่ไม่สำเร็จโดยใช้บันทึกการเข้าถึง NGINX

นอกจากนี้คุณยังสามารถดูบันทึกการเข้าถึง NGINX เพื่อระบุรหัสข้อความสำหรับข้อผิดพลาด 503 ซึ่งจะเป็นประโยชน์อย่างยิ่งหากปัญหาเกิดขึ้นในอดีต หรือเมื่อปัญหาเกิดขึ้นเป็นบางครั้งและคุณไม่สามารถจับภาพการติดตามใน UI ได้ ทำตามขั้นตอนต่อไปนี้เพื่อระบุข้อมูลนี้จากบันทึกการเข้าถึง NGINX

  1. ตรวจสอบบันทึกการเข้าถึง NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. ค้นหาว่ามีข้อผิดพลาด 503 สำหรับพร็อกซี API ที่ระบุในช่วงเวลาที่ระบุหรือไม่ (หากเกิดปัญหาในอดีต) หรือมีคำขอใดที่ยังคงล้มเหลวด้วย 503
  3. หากมีข้อผิดพลาด 503 กับ X-Apigee-fault-codeแอปรับส่งข้อความ.adaptors.http.flow.ServiceUnavailable โปรดจดรหัสข้อความสำหรับคำขออย่างน้อย 1 รายการดังที่แสดงในตัวอย่างต่อไปนี้

    รายการตัวอย่างที่แสดงข้อผิดพลาด 503

    รายการตัวอย่างที่แสดงรหัสสถานะ รหัสข้อความ แหล่งที่มาของข้อผิดพลาด และรหัสข้อผิดพลาด

ข้อผิดพลาดในการเชื่อมต่อเนื่องจากการแปลง DNS ไม่ถูกต้อง

การวินิจฉัย

  1. ระบุรหัสข้อความของคำขอที่ล้มเหลว
  2. ค้นหารหัสข้อความคำขอที่เฉพาะเจาะจงในบันทึกตัวประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log) คุณอาจพบข้อผิดพลาดต่อไปนี้

    ข้อผิดพลาด onConnectTimeout บ่งบอกว่าผู้ประมวลผลข้อความไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ภายในระยะหมดเวลาของการเชื่อมต่อที่กำหนดล่วงหน้า (ค่าเริ่มต้น: 3 วินาที)
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22
    
    2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
          
  3. จดบันทึกที่อยู่ IP ที่แก้ไขแล้วในข้อผิดพลาด onConnectTimeout และตรวจสอบว่าที่อยู่ IP ใช้ได้สำหรับเซิร์ฟเวอร์แบ็กเอนด์ของคุณ หากที่อยู่ IP ถูกต้อง ให้ไปที่ข้อผิดพลาดในการเชื่อมต่อ
  4. หากที่อยู่ IP ไม่ถูกต้อง อาจเป็นเพราะมีปัญหาเกี่ยวกับการแปลง DNS
  5. ทำขั้นตอนที่ 3 และ 4 ซ้ำสำหรับคำขอ API ที่ล้มเหลวอีก 2-3 รายการ และตรวจสอบว่าคุณเห็นที่อยู่ IP เดียวกันหรือที่อยู่อื่นๆ ที่ไม่ถูกต้อง
  6. ค้นหาผ่านบันทึกตัวประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log) สำหรับข้อความที่มีคีย์เวิร์ด DNS รีเฟรช ตรวจสอบว่ามีการเพิ่มที่อยู่ IP ที่ไม่ถูกต้องหรือไม่ถูกต้องไปยังแคช DNS ในเครื่องประมวลผลข้อมูลข้อความในช่วงเวลาหนึ่งหรือไม่
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
          
  7. ปัญหานี้อาจเกิดขึ้นหากมีปัญหากับเซิร์ฟเวอร์ DNS ที่เชื่อถือได้หรือเนมเซิร์ฟเวอร์ที่กำหนดค่าไว้ใน /etc/resolv.conf

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

ความละเอียด

โปรดติดต่อผู้ดูแลระบบระบบปฏิบัติการและแก้ไขปัญหาเกี่ยวกับเซิร์ฟเวอร์ DNS

  1. หากเกิดปัญหากับเซิร์ฟเวอร์ DNS หรือเนมเซิร์ฟเวอร์ที่เชื่อถือได้ที่ระบุไว้ใน /etc/resolv.conf ให้แก้ไขปัญหากับเซิร์ฟเวอร์ที่เหมาะสมเพื่อแก้ไขปัญหา
  2. หากมีปัญหาเกี่ยวกับการกำหนดค่าใน /etc/resolv.conf ในระบบที่มี Message Processor ให้แก้ไขปัญหาการกำหนดค่า

ข้อผิดพลาดในการเชื่อมต่อ

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

  • ตัวประมวลผลข้อความไม่สามารถเชื่อมต่อภายในระยะหมดเวลาของการเชื่อมต่อที่กำหนดล่วงหน้า (ค่าเริ่มต้น: 3 วินาที)
  • เซิร์ฟเวอร์แบ็กเอนด์ปฏิเสธการเชื่อมต่อ

การวินิจฉัย

  1. ระบุรหัสข้อความของคำขอที่ล้มเหลว
  2. ค้นหารหัสข้อความคำขอที่เฉพาะเจาะจงในบันทึกผู้ประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log) คุณอาจสังเกตเห็นข้อผิดพลาดต่อไปนี้
    1. ข้อผิดพลาด onConnectTimeout บ่งบอกว่าผู้ประมวลผลข้อความไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ภายในระยะหมดเวลาของการเชื่อมต่อที่กำหนดล่วงหน้าได้
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
      2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
      
    2. ข้อผิดพลาด java.net.ConnectException: การเชื่อมต่อถูกปฏิเสธ แสดงว่าเซิร์ฟเวอร์แบ็กเอนด์ปฏิเสธการเชื่อมต่อ
      14:40:16.531 +0530
      2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
      java.net.ConnectException: Connection refused
      at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
      at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
      at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
      
  3. ตรวจสอบว่าคุณเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ที่เจาะจงได้โดยตรงจากโปรแกรมประมวลผลข้อความแต่ละเครื่องโดยใช้คำสั่ง telnet ดังนี้
    1. หากเซิร์ฟเวอร์แบ็กเอนด์แก้ไขเป็นที่อยู่ IP เดียว ให้ใช้คำสั่งต่อไปนี้
      telnet BackendServer-IPaddress 443
                
    2. หากเซิร์ฟเวอร์แบ็กเอนด์แก้ไขเป็นที่อยู่ IP หลายรายการ ให้ใช้ชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ในคําสั่ง telnet ดังที่แสดงด้านล่าง
      telnet BackendServer-HostName 443
                
  4. หากคุณเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ได้ คุณอาจเห็นข้อความอย่างเช่น Connected to backend-server หากคุณเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้ อาจเป็นเพราะที่อยู่ IP ของผู้ประมวลผลข้อมูลข้อความไม่อยู่ในรายการที่อนุญาตในเซิร์ฟเวอร์แบ็กเอนด์ที่เจาะจง

ความละเอียด

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

หากปัญหายังคงอยู่ ให้ปรึกษากับผู้ดูแลระบบเครือข่ายเพื่อระบุและแก้ไขปัญหา หากต้องการความช่วยเหลือเพิ่มเติมจาก Apigee โปรดติดต่อทีมสนับสนุนของ Apigee

ชื่อโฮสต์ของเซิร์ฟเวอร์เป้าหมายไม่ถูกต้อง

การวินิจฉัย

หากชื่อโฮสต์ที่ระบุในเซิร์ฟเวอร์เป้าหมายไม่ถูกต้อง คุณอาจได้รับการตอบสนอง 503 Service Unavailable พร้อมรหัสข้อผิดพลาด messaging.adaptors.http.flow.ServiceUnavailable.

เครื่องมือการติดตาม

วิธีวินิจฉัยโดยใช้เครื่องมือติดตาม

  1. หากยังพบปัญหาอยู่ ให้เปิดใช้เซสชันการติดตามสำหรับ API ที่ได้รับผลกระทบ
  2. ทำการเรียก API และทำให้เกิดปัญหาซ้ำ - 503 บริการไม่พร้อมใช้งานโดยมีรหัสข้อผิดพลาด messaging.adaptors.http.flow.ServiceUnavailable.
  3. เลือกคำขอที่ล้มเหลว 1 รายการ
  4. ไปยังระยะต่างๆ ของการติดตามและค้นหาตำแหน่งที่เกิดข้อผิดพลาด
  5. เลือก FlowInfo ที่มีข้อผิดพลาด คุณสามารถค้นหาข้อมูลเพิ่มเติมได้ในช่อง error.cause ซึ่งสามารถบอกสาเหตุของความล้มเหลวตามที่ปรากฏในตัวอย่างต่อไปนี้

    คำขอตัวอย่างที่แสดง error.cause ในการติดตาม

    คำขอตัวอย่างที่แสดง error.cause ในการติดตาม
  6. หากเห็นว่า error.cause แสดงข้อความ Host ไม่ได้ สาเหตุที่เป็นไปได้ของข้อผิดพลาดอาจเกิดจากข้อใดข้อหนึ่งต่อไปนี้
    • ชื่อโฮสต์ที่ระบุในการกำหนดค่าเซิร์ฟเวอร์เป้าหมาย/ปลายทางเป้าหมายไม่ถูกต้องหรือมีพื้นที่หรือสัญลักษณ์พิเศษที่ไม่พึงประสงค์

      ตัวอย่างเช่น มีพื้นที่ว่างที่ไม่ต้องการในชื่อโฮสต์ดังที่แสดงด้านล่าง
      "demo-target.apigee.net "
                        
    • ชื่อโฮสต์ที่ถูกเขียนทับโดยตัวแปร target.url ในพร็อกซี API โดยใช้นโยบาย AssignMessage หรือ JavaScript ไม่ถูกต้องหรือมีการเว้นวรรคหรืออักขระพิเศษอื่นๆ ที่ไม่พึงประสงค์
  7. ตรวจสอบการกำหนดค่าปลายทางเป้าหมายและ/หรือคำจำกัดความเซิร์ฟเวอร์เป้าหมายเพื่อดูว่าชื่อโฮสต์ของเซิร์ฟเวอร์เป้าหมายไม่ถูกต้องหรือมีพื้นที่ที่ไม่ต้องการหรือสัญลักษณ์พิเศษหรือไม่
  8. หากโฮสต์เซิร์ฟเวอร์เป้าหมายสร้างขึ้นแบบไดนามิก ให้ตรวจสอบนโยบายที่เหมาะสม (เช่น นโยบาย AssignMessage/JavaScript) ที่ใช้ในการสร้างโฮสต์ดังกล่าว โปรดตรวจสอบว่าชื่อโฮสต์ของเซิร์ฟเวอร์เป้าหมายไม่ถูกต้องหรือมีพื้นที่ที่ไม่ต้องการหรือสัญลักษณ์พิเศษหรือไม่
  9. เมื่อระบุชื่อโฮสต์ของเซิร์ฟเวอร์เป้าหมายแล้ว ให้เรียกใช้คำสั่ง nslookup/dig ในชื่อโฮสต์เพื่อดูว่าจะแก้ไขได้หรือไม่

    ตัวอย่างเช่น การเรียกใช้คำสั่ง nslookup ในชื่อโฮสต์ที่มีช่องว่างที่ไม่ต้องการจะแสดงเอาต์พุตต่อไปนี้

    nslookup "demo-target.apigee.net "
    Server:	49.205.75.2
    Address:	49.205.75.2#53
    
    ** server can't find demo-target.apigee.net\032: NXDOMAIN
    
  10. หากคำสั่งระบบปฏิบัติการ nslookup ไม่สามารถแก้ไขชื่อโฮสต์ได้ สาเหตุของปัญหานี้คือชื่อโฮสต์ที่ใช้กับเซิร์ฟเวอร์เป้าหมายไม่ถูกต้อง

    ไปที่ความละเอียด

บันทึกตัวประมวลผลข้อความ

วิธีวินิจฉัยโดยใช้บันทึกตัวประมวลผลข้อความ

  1. ระบุรหัสข้อความของคำขอที่ล้มเหลว
  2. ค้นหา ID ข้อความในบันทึกเครื่องมือประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. ถ้าคุณเห็นข้อความเตือน/แสดงข้อผิดพลาดต่อไปนี้ ผู้ประมวลผลข้อความไม่สามารถแปลค่าชื่อโฮสต์ เนื่องจากระบบจะเลื่อนการแจ้งเตือนข้อความ คุณอาจไม่เห็นข้อความเตือนนี้สำหรับรหัส/คำขอทั้งหมด
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
        
  4. ตามด้วยข้อความเตือน ซึ่งผู้ประมวลผลข้อความจะนำที่อยู่ออกจากแคช DNS เนื่องจากเข้าถึงโฮสต์ของเซิร์ฟเวอร์เป้าหมายไม่ได้
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
        
  5. จากนั้นคุณอาจเห็นข้อความที่โปรแกรมประมวลผลข้อความทำงานล้มเหลวโดยมีข้อยกเว้น "เข้าถึงโฮสต์ไม่ได้" บางครั้งระบบจะแสดงชื่อโฮสต์เป็นส่วนหนึ่งของข้อความแสดงข้อผิดพลาด ดังนี้
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
    java.lang.RuntimeException: Host not reachable
    	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
    	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
    	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
    	…<snipped>
        
  6. บางครั้งอาจแสดงเป็น null เนื่องจากไม่สามารถจับคู่ชื่อโฮสต์หรือเข้าถึงชื่อโฮสต์ได้ดังที่แสดงด้านล่าง
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
    java.lang.RuntimeException: Host not reachable
    	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
    	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
    	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
    	…<snipped>
        
  7. ข้อผิดพลาด Host not reachable มักเกิดขึ้นในกรณีต่อไปนี้
    • ชื่อโฮสต์ที่ระบุในการกำหนดค่าเซิร์ฟเวอร์เป้าหมาย/ปลายทางเป้าหมายไม่ถูกต้องหรือมีพื้นที่หรือสัญลักษณ์พิเศษที่ไม่พึงประสงค์

      ตัวอย่างเช่น มีพื้นที่ว่างที่ไม่ต้องการในชื่อโฮสต์ "demo-target.apigee.net " ในข้อความแสดงข้อผิดพลาดต่อไปนี้
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
              
    • ชื่อโฮสต์ที่ถูกเขียนทับโดยตัวแปร target.url ในพร็อกซี API โดยใช้นโยบาย AssignMessage หรือ JavaScript ไม่ถูกต้องหรือมีการเว้นวรรคหรืออักขระพิเศษอื่นๆ ที่ไม่พึงประสงค์
  8. กำหนดชื่อโฮสต์ของเซิร์ฟเวอร์เป้าหมายที่ผู้ประมวลผลข้อความที่พยายามจะสื่อสาร โดยใช้ชื่อใดชื่อหนึ่งต่อไปนี้
    1. ตรวจสอบข้อความแสดงข้อผิดพลาดที่มีHost not reachable อย่างละเอียด
    2. หากข้อความแสดงข้อผิดพลาดแสดงชื่อโฮสต์ ให้คัดลอกชื่อโฮสต์รวมถึงการเว้นวรรคหรือสัญลักษณ์พิเศษ
    3. หากข้อความแสดงข้อผิดพลาดแสดงเป็น null สำหรับชื่อโฮสต์ตามที่แสดงในข้อความแสดงข้อผิดพลาดต่อไปนี้
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
              
      1. กำหนดชื่อโฮสต์โดยการตรวจสอบคำจำกัดความเซิร์ฟเวอร์เป้าหมายที่ใช้ในพร็อกซี API ที่ล้มเหลว
      2. หากโฮสต์เซิร์ฟเวอร์เป้าหมายสร้างขึ้นแบบไดนามิก ให้ตรวจสอบนโยบายที่เหมาะสม (เช่น นโยบาย AssignMessage/JavaScript) ที่ใช้ในการสร้างโฮสต์ดังกล่าว
  9. เมื่อคุณระบุชื่อโฮสต์ของเซิร์ฟเวอร์เป้าหมายแล้ว ให้เรียกใช้คำสั่ง nslookup/dig กับชื่อโฮสต์ และตรวจสอบว่าจะแก้ไขได้หรือไม่

    ตัวอย่างเช่น เรียกใช้คำสั่ง nslookup ในชื่อโฮสต์ที่มีช่องว่าง

    nslookup "demo-target.apigee.net "
    Server:	49.205.75.2
    Address:	49.205.75.2#53
    
    ** server can't find demo-target.apigee.net\032: NXDOMAIN
          
  10. หากคำสั่งระบบปฏิบัติการ nslookup แก้ไขชื่อโฮสต์ไม่ได้ สาเหตุของปัญหานี้คือชื่อโฮสต์ที่ใช้กับเซิร์ฟเวอร์เป้าหมายไม่ถูกต้อง

ความละเอียด

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

แฮนด์เชค SSL ล้มเหลว

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

การระบุที่มาของปัญหา

ข้อผิดพลาดบางประเภทอาจเกิดขึ้นจากการเชื่อมต่อขาเข้า (ทางเหนือ) หรือขาออก (ขาออก) เกิดข้อผิดพลาดขาเข้า (ทางเหนือ) ระหว่างแอปพลิเคชันไคลเอ็นต์และ Edge ข้อผิดพลาดขาออก (southbound) เกิดขึ้นระหว่าง Edge กับเซิร์ฟเวอร์เป้าหมายแบ็กเอนด์ ในการวินิจฉัยปัญหาประเภทนี้ งานแรกคือการตรวจสอบว่าข้อผิดพลาดเกิดขึ้นในการเชื่อมต่อทางทิศเหนือหรือทิศใต้หรือไม่

ทำความเข้าใจการเชื่อมต่อระหว่างทิศเหนือและใต้

ใน Edge คุณอาจพบข้อผิดพลาด 503 Service Unavailable ทั้งในการเชื่อมต่อขาเข้าหรือขาออก

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

หากคุณเป็นผู้ใช้ Edge Public Cloud ก็อาจไม่ทราบคอมโพเนนต์ภายใน เช่น เราเตอร์หรือผู้ประมวลผลข้อมูลข้อความ ผู้ใช้ Cloud Cloud สาธารณะจะไม่เห็นหรือเข้าถึงคอมโพเนนต์ภายในเหล่านี้ได้ เมื่อเป็นไปได้ เรามีวิธีอื่นๆ ในการตรวจสอบปัญหาซึ่งไม่จำเป็นต้องใช้การเข้าถึงคอมโพเนนต์เหล่านี้โดยตรง

ภาพต่อไปนี้แสดงการเชื่อมต่อไปทางเหนือและใต้สำหรับ Apigee Edge

ขั้นตอนของแอปพลิเคชันไคลเอ็นต์ (การเชื่อมต่อทางเหนือ) ผ่าน Edge ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (การเชื่อมต่อขาออก)

การหาตำแหน่งที่เกิดข้อผิดพลาด 503 บริการไม่พร้อมใช้งาน

ใช้ขั้นตอนใดขั้นตอนหนึ่งต่อไปนี้เพื่อดูว่าข้อผิดพลาด 503 Service Unavailable เกิดขึ้นที่การเชื่อมต่อทางเหนือหรือใต้หรือไม่

การติดตาม UI

วิธีค้นหาข้อผิดพลาดที่เกิดขึ้นโดยใช้การติดตาม UI

  1. หากยังพบปัญหาอยู่ ให้เปิดใช้การติดตาม UI สำหรับ API ที่ได้รับผลกระทบ
  2. หากการติดตาม UI สำหรับคำขอ API ที่ล้มเหลวแสดงว่าข้อผิดพลาด 503 Service Unavailable เกิดขึ้นระหว่างโฟลว์คำขอเป้าหมายหรือส่งโดยเซิร์ฟเวอร์แบ็กเอนด์ แสดงว่าปัญหาคือ southbound (ระหว่างผู้ประมวลผลข้อความกับเซิร์ฟเวอร์แบ็กเอนด์)
  3. หากคุณไม่ได้รับการติดตามสำหรับการเรียก API ที่เจาะจง แสดงว่าปัญหาเกิดขึ้นทางเหนือ ระหว่างแอปพลิเคชันไคลเอ็นต์และเราเตอร์

การตรวจสอบ API

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

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

บันทึกการเข้าถึง NGINX

วิธีค้นหาข้อผิดพลาดที่เกิดขึ้นโดยใช้การติดตาม UI

หากปัญหาเกิดขึ้นในอดีตหรือปัญหาเกิดขึ้นเป็นบางครั้งและคุณบันทึกการติดตามไม่ได้ ให้ทําตามขั้นตอนต่อไปนี้

  1. ตรวจสอบบันทึกการเข้าถึง NGINX (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log )
  2. ค้นหาหากมีข้อผิดพลาด 503 สำหรับพร็อกซี API ที่ระบุ
  3. หากคุณระบุข้อผิดพลาด 503 สำหรับ API ที่เฉพาะเจาะจงได้ ณ เวลาที่เจาะจง แสดงว่าปัญหาเกิดขึ้นที่การเชื่อมต่อ southbound (ระหว่างเครื่องมือประมวลผลข้อความและเซิร์ฟเวอร์แบ็กเอนด์)
  4. หากไม่ แสดงว่าปัญหาเกิดขึ้นที่การเชื่อมต่อ northbound (ระหว่างแอปพลิเคชันไคลเอ็นต์และเราเตอร์)