503 ไม่พร้อมให้บริการ - NoActiveTargets - Health CheckFailures

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

วิดีโอ

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

วิดีโอ คำอธิบาย
แก้ปัญหาและแก้ปัญหาบริการ 503 ไม่พร้อมใช้งาน - NoActiveTargets โปรดดูข้อมูลเกี่ยวกับสิ่งต่อไปนี้
  • ความสำคัญของเซิร์ฟเวอร์เป้าหมายและการตรวจสอบประสิทธิภาพการทำงาน
  • การแก้ปัญหาและการแก้ไขบริการ 503 แบบเรียลไทม์ไม่พร้อมใช้งาน - NoActiveTargets ข้อผิดพลาดที่เกิดจากการตรวจสอบประสิทธิภาพการทำงานล้มเหลว

ลักษณะปัญหา

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

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

คุณจะเห็นการตอบกลับข้อผิดพลาดต่อไปนี้

HTTP/1.1 503 Service Unavailable
  

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

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

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

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

Playbook นี้มีเนื้อหาเกี่ยวกับรหัสข้อผิดพลาด 503 Service Unavailable NoActiveTargets เกิดขึ้นเนื่องจากการตรวจสอบประสิทธิภาพการทำงานล้มเหลว โปรดดูที่ Playbook นี้เพื่อดูข้อมูลเกี่ยวกับสาเหตุอื่นๆ ของข้อผิดพลาดนี้

การตรวจสอบประสิทธิภาพการทำงานล้มเหลว

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

เมื่อเซิร์ฟเวอร์เป้าหมายไม่ผ่านการตรวจสอบประสิทธิภาพการทำงาน Edge จะเพิ่มจำนวนความล้มเหลวของเซิร์ฟเวอร์นั้น หากจำนวนความล้มเหลวในการตรวจสอบประสิทธิภาพการทำงานของเซิร์ฟเวอร์นั้นถึงเกณฑ์ที่กำหนดไว้ล่วงหน้า (<MaxFailures>) ตัวประมวลผลข้อความจะบันทึกข้อความเตือนดังที่แสดงด้านล่างในไฟล์บันทึก

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

ข้อความเตือนจะให้ข้อมูลต่อไปนี้ ซึ่งจะช่วยให้คุณทราบว่าเซิร์ฟเวอร์เป้าหมายใดที่มีจํานวน MaxFailure ครบ:

  • ชื่อเซิร์ฟเวอร์เป้าหมาย
  • ชื่อองค์กรและสภาพแวดล้อม
  • ชื่อพร็อกซี API
  • ชื่อปลายทางเป้าหมาย

หลังจากนั้น Edge จะหยุดส่งคำขอเพิ่มเติมไปยังเซิร์ฟเวอร์ที่เฉพาะเจาะจงนั้น เมื่อเป้าหมายทั้งหมด เซิร์ฟเวอร์ที่กำหนดค่าไว้ในการกำหนดค่า LoadBalancer จะมีจำนวน MaxFailure ตาม ระบบจะตอบกลับคำขอ API ด้วย 503 Service Unavailable ด้วยรหัสข้อผิดพลาด NoActiveTargets

การใช้ Health Monitor ช่วยให้ Apigee Edge รวมเซิร์ฟเวอร์เป้าหมายกลับเข้าไปใน การหมุนเวียนเมื่อได้รับอนุมัติโดยไม่ต้องทำให้พร็อกซี API ใช้งานได้อีกครั้ง

สาเหตุที่อาจทำให้การตรวจสอบประสิทธิภาพการทำงานล้มเหลวมีดังนี้

สาเหตุ คำอธิบาย ใครสามารถทำขั้นตอนการแก้ปัญหา
ข้อผิดพลาดหมดเวลาการเชื่อมต่อ ตัวประมวลผลข้อความไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์เป้าหมายภายในระยะหมดเวลาที่ระบุไว้ได้ ในการกำหนดค่า LoadBalancer ผู้ใช้ Edge Private Cloud
คำขอที่ปลอดภัยในพอร์ตที่ไม่ปลอดภัย
  1. หากเซิร์ฟเวอร์เป้าหมายได้รับการกำหนดให้เป็นเซิร์ฟเวอร์ที่ปลอดภัย แต่กำหนดค่าไม่ถูกต้องด้วย พอร์ตที่ไม่ปลอดภัย
  2. หากมีการกำหนดเซิร์ฟเวอร์เป้าหมายเป็นเซิร์ฟเวอร์ที่ปลอดภัย แต่การตรวจสอบประสิทธิภาพการทำงานกลับ มีการกำหนดค่าให้ดำเนินการตรวจสอบประสิทธิภาพการทำงานในพอร์ตที่ไม่ปลอดภัย
ผู้ใช้ Edge Private Cloud
คำขอที่ไม่ปลอดภัยในพอร์ตที่ปลอดภัย
  1. หากมีการกำหนดเซิร์ฟเวอร์เป้าหมายเป็นเซิร์ฟเวอร์ที่ไม่ปลอดภัย แต่กำหนดค่าไม่ถูกต้อง ด้วยพอร์ตที่ปลอดภัย
  2. หากมีการกำหนดเซิร์ฟเวอร์เป้าหมายเป็นเซิร์ฟเวอร์ที่ไม่ปลอดภัย แต่การตรวจสอบประสิทธิภาพการทำงานกลับ มีการกำหนดค่าให้ดำเนินการตรวจสอบประสิทธิภาพการทำงานบนพอร์ตที่ปลอดภัย
ผู้ใช้ Edge Private Cloud
Health Check API ตอบกลับพร้อมข้อผิดพลาด หาก API การตรวจสอบประสิทธิภาพการทำงานตอบกลับพร้อมข้อผิดพลาดหรือรหัสการตอบกลับ การดำเนินการอื่นใดนอกเหนือจาก ที่ระบุในองค์ประกอบ SuccessResponse ของ Health Monitor ผู้ใช้ Edge Private Cloud

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

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

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

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

  1. เปิดใช้เซสชันการติดตาม เรียก API และสร้างปัญหาซ้ำ - 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets
  2. เลือกคำขอที่ไม่สำเร็จ 1 รายการ
  3. ไปที่ระยะ 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. ค้นหาว่าพร็อกซี API ที่ระบุในช่วงระยะเวลาหนึ่งมีข้อผิดพลาด 503 หรือไม่ (หากเคยมีปัญหาเกิดขึ้นในอดีต) หรือหากมีคำขอที่ยังคงดำเนินการไม่สำเร็จด้วย 503
  3. หากมีข้อผิดพลาด 503 ใน X-Apigee-fault-codeการรับส่งข้อความ.adaptors.http.flow.NoActiveTargets จดรหัสข้อความสําหรับคําขอดังกล่าวไว้อย่างน้อย 1 รายการ ดังที่แสดงในตัวอย่างต่อไปนี้

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

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

ข้อความแสดงข้อผิดพลาดที่พบบ่อย

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

ข้อความแสดงข้อผิดพลาดที่พบบ่อยในบันทึก Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) สำหรับ 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets ดังนี้

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

ข้อความแสดงข้อผิดพลาดเหล่านี้ระบุว่าระบบไม่สามารถส่งคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์ได้เนื่องจาก ล้มเหลว ดังนั้น Message Processor จะส่ง 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets เป็นการตอบสนองไคลเอ็นต์

สาเหตุ: การเชื่อมต่อหมดเวลา

การวินิจฉัย

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

    ตัวอย่างเช่น ข้อความแสดงข้อผิดพลาด HEALTH MONITOR ต่อไปนี้แสดงว่าโปรแกรมประมวลผลข้อความล้มเหลว มีข้อผิดพลาดการเชื่อมต่อหมดเวลาเมื่อส่งคำขอ API การตรวจสอบประสิทธิภาพการทำงาน:

    Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
    java.net.ConnectException: Connection timed out (Connection timed out)
    	at java.net.PlainSocketImpl.socketConnect(Native Method)
    	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
    	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
    …<snipped>
            

    หากข้อผิดพลาดนี้เกิดซ้ำถึง MaxFailure ครั้งที่กำหนดค่าไว้ใน Health Monitor คุณจะเห็นข้อความเตือนดังนี้

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

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

  4. ในตัวอย่างด้านบน การตรวจสอบประสิทธิภาพการทำงานล้มเหลวโดยมีข้อผิดพลาด connection timed out ตรวจสอบว่าคุณสามารถเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ที่เจาะจงจาก ตัวประมวลผลข้อความที่ใช้คำสั่ง telnet:
  5. telnet <BackendServer-HostName> 443
          
  6. หากคุณเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ได้ คุณอาจเห็นข้อความอย่างเช่น เชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์แล้ว ปัญหานี้อาจเป็นปัญหาชั่วคราวและ ปัญหาอาจได้รับการแก้ไขแล้ว หรือเป็นปัญหาเป็นระยะๆ ทำขั้นตอนที่ 4 ซ้ำ 2-3 ครั้ง (มากกว่า 10 ครั้ง) แล้วตรวจสอบเอาต์พุต
    1. หากไม่มีข้อผิดพลาดเกิดขึ้นกับคําสั่ง telnet อย่างต่อเนื่อง แสดงว่าปัญหาคือ แก้ปัญหาแล้ว ตรวจสอบอีกครั้งว่าการทำงานล้มเหลวของการตรวจสอบประสิทธิภาพการทำงานหยุดลงแล้วหรือไม่ หากใช่ คุณก็ไม่จำเป็นต้องดำเนินการ สิ่งอื่นๆ ได้อีกมากมาย
    2. หากเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ด้วยคำสั่ง telnet ไม่ได้ในบางครั้ง แสดงว่าเครือข่ายอาจมีปัญหาหรือเซิร์ฟเวอร์แบ็กเอนด์ของคุณอาจไม่ว่าง
  7. หากเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ด้วยคําสั่ง telnet อย่างต่อเนื่องไม่ได้ ซึ่งอาจเป็นเพราะไม่ได้รับอนุญาตจาก Message Processor ในเซิร์ฟเวอร์แบ็กเอนด์เฉพาะ

ความละเอียด

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

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

สาเหตุ: คำขอที่ปลอดภัยในพอร์ตที่ไม่ปลอดภัย

การวินิจฉัย

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

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

    Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
            at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
            at sun.security.ssl.InputRecord.read(InputRecord.java:527)
            at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
            at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
    …<snipped>
            

    หากข้อผิดพลาดนี้เกิดซ้ำเป็นเวลา MaxFailure ครั้งที่กำหนดค่าไว้ใน Health Monitor คุณจะเห็นข้อความเตือนดังนี้

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

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

  4. การตรวจสอบประสิทธิภาพการทำงานล้มเหลวโดยมีข้อผิดพลาด:
    Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
          

    ข้อความแสดงข้อผิดพลาดและ URL จะระบุสาเหตุของปัญหานี้คือ การเรียกที่ปลอดภัย (HTTPS) ในพอร์ตที่ไม่ปลอดภัย 80

    ข้อผิดพลาดนี้อาจเกิดขึ้นใน 2 สถานการณ์ต่อไปนี้

    • เซิร์ฟเวอร์เป้าหมายที่ปลอดภัยกำหนดด้วยพอร์ตที่ไม่ปลอดภัย
    • กำหนดเซิร์ฟเวอร์เป้าหมายที่ปลอดภัยแล้ว แต่ Health Monitor กำหนดค่าด้วยพอร์ตที่ไม่ปลอดภัย

    พอร์ตที่ไม่ปลอดภัยของเป้าหมายที่ปลอดภัย

    สถานการณ์ 1: เซิร์ฟเวอร์เป้าหมายที่ปลอดภัยกำหนดด้วยพอร์ตที่ไม่ปลอดภัย

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

    1. ตรวจสอบคำจำกัดความของเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย
    2. ใช้เมนู รับ TargetServer API เพื่อรับการกำหนดเซิร์ฟเวอร์เป้าหมาย

      ผลลัพธ์ตามคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย

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

      ในตัวอย่างด้านบน คําจํากัดความแสดงให้เห็นว่าเซิร์ฟเวอร์เป้าหมาย mocktarget เป็น ตามที่ระบุไว้โดยบล็อก SSLInfo แต่มีการกำหนดค่าด้วยพอร์ต 80 ที่ไม่ปลอดภัย

    3. จากนั้นตรวจสอบการกำหนดค่า Health Monitor สำหรับเซิร์ฟเวอร์เป้าหมายในการกำหนดค่าปลายทางเป้าหมาย

      การกำหนดค่าการตรวจวัดสุขภาพ

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      โปรดสังเกตว่าไม่ได้ระบุองค์ประกอบ <Port> ใน การกำหนดค่า Health Monitor ด้านบน ในกรณีนี้ โปรเซสเซอร์ข้อความของ Edge จะใช้พอร์ตนั้น ที่ระบุในคำจำกัดความเซิร์ฟเวอร์เป้าหมาย (ซึ่งก็คือ 80) สำหรับการเรียก API การตรวจสอบประสิทธิภาพการทำงาน

    4. จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือเซิร์ฟเวอร์เป้าหมายคือ กำหนดเป็นเซิร์ฟเวอร์ที่ปลอดภัย (เนื่องจากเปิดใช้การบล็อก SSLInfo อยู่) แต่มีพอร์ต 80 ที่ไม่ปลอดภัย

    พอร์ต HM ที่ไม่ปลอดภัยของเป้าหมายที่ปลอดภัย

    สถานการณ์ที่ 2: กำหนดเซิร์ฟเวอร์เป้าหมายที่ปลอดภัยแต่กำหนดค่า Health Monitor ด้วยพอร์ตที่ไม่ปลอดภัย

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

    1. ตรวจสอบการกำหนดเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย

      ใช้ รับ TargetServer API เพื่อรับคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย

      ผลลัพธ์ตามคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย

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

      ในตัวอย่างด้านบน คําจํากัดความแสดงให้เห็นว่าเซิร์ฟเวอร์เป้าหมาย mocktarget เป็นเซิร์ฟเวอร์ที่ปลอดภัยตามที่บล็อก SSLInfo ระบุไว้

    2. ถัดไป ให้ตรวจสอบการกำหนดค่า Health Monitor สำหรับเซิร์ฟเวอร์เป้าหมายในการกำหนดค่าปลายทางเป้าหมาย

      การกำหนดค่าการตรวจสอบประสิทธิภาพการทำงาน

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      ในตัวอย่างข้างต้น Health Monitor ได้รับการกำหนดค่าด้วยพอร์ต 80 ที่ไม่ปลอดภัยตามที่ระบุโดยองค์ประกอบ <Port>

    3. จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือมีการกำหนดเซิร์ฟเวอร์เป้าหมาย เป็นเซิร์ฟเวอร์ที่ปลอดภัย (เนื่องจากเปิดใช้การบล็อก SSLInfo อยู่) และใช้พอร์ต 443 ที่ปลอดภัย แต่ Health Monitor มีการกำหนดค่าให้ดำเนินการตรวจสอบประสิทธิภาพการทำงานด้วยพอร์ต 80 ที่ไม่ปลอดภัย (ระบุไว้ในองค์ประกอบ <Port>)

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

ความละเอียด

พอร์ตที่ไม่ปลอดภัยของเป้าหมายที่ปลอดภัย

สถานการณ์ 1: เซิร์ฟเวอร์เป้าหมายที่ปลอดภัยกำหนดด้วยพอร์ตที่ไม่ปลอดภัย

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

ใช้ อัปเดต TargetServer API เพื่ออัปเดตคำจำกัดความของเซิร์ฟเวอร์เป้าหมายและตรวจสอบว่า ระบบใช้พอร์ตที่ปลอดภัย (เช่น 443) ดังที่แสดงในตัวอย่างด้านล่าง

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

พอร์ต HM ที่ไม่ปลอดภัยของเป้าหมายที่ปลอดภัย

สถานการณ์ที่ 2: กำหนดเซิร์ฟเวอร์เป้าหมายที่ปลอดภัยแต่กำหนดค่า Health Monitor ด้วยพอร์ตที่ไม่ปลอดภัย

หากต้องการแก้ไขข้อผิดพลาดนี้ โปรดทำตามวิธีการด้านล่าง

  1. แก้ไขการกำหนดค่า Health Monitor เพื่อใช้พอร์ตที่ปลอดภัย (เช่น 443) เพื่อดำเนินการเป้าหมาย ตรวจสอบประสิทธิภาพการทำงานของเซิร์ฟเวอร์ในการกำหนดค่าปลายทางเป้าหมายของพร็อกซี API ที่ล้มเหลวดังที่แสดงด้านล่าง
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
        <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>443</Port>
          <Verb>GET</Verb>
          <Path>/statuscode/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            
  2. บันทึกการเปลี่ยนแปลงลงในพร็อกซี API

สาเหตุ: คำขอที่ไม่ปลอดภัยในพอร์ตที่ปลอดภัย

การวินิจฉัย

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

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

    Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
    java.net.SocketException: Unexpected end of file from server
    	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
    	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
    	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
    …<snipped>
              

    หากข้อผิดพลาดนี้เกิดซ้ำเป็นเวลา MaxFailure ครั้งที่กำหนดค่าไว้ใน Health Monitor คุณจะเห็นข้อความเตือนดังนี้

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
              

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

  4. การตรวจสอบประสิทธิภาพการทำงานล้มเหลวโดยมีข้อผิดพลาด:
    Error sending request Request URL : http://mocktarget.apigee.net:443/status
    java.net.SocketException: Unexpected end of file from server
          

    ข้อความแสดงข้อผิดพลาดและ URL จะระบุสาเหตุของปัญหานี้คือ การเรียกที่ไม่ปลอดภัย (HTTP) ในพอร์ตที่ปลอดภัย 443

    ข้อผิดพลาดนี้อาจเกิดขึ้นใน 2 สถานการณ์ต่อไปนี้

    • เซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัยซึ่งกำหนดด้วยพอร์ตที่ปลอดภัย
    • กำหนดเซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัย แต่ Health Monitor กำหนดค่าด้วยพอร์ตที่ปลอดภัย

    พอร์ตที่ปลอดภัยสำหรับเป้าหมายที่ไม่ปลอดภัย

    สถานการณ์ 1: เซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัยซึ่งกำหนดด้วยพอร์ตที่ปลอดภัย

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

    1. ตรวจสอบการกำหนดเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย

      ใช้ รับ TargetServer API เพื่อรับคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย

      ผลลัพธ์ตามคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย

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

      ในตัวอย่างด้านบน คําจํากัดความแสดงให้เห็นว่าเซิร์ฟเวอร์เป้าหมาย mocktarget เป็นเซิร์ฟเวอร์ที่ไม่ปลอดภัยเนื่องจากไม่มีการบล็อก SSLInfo อย่างไรก็ตาม ข้อมูลนี้ไม่ถูกต้อง กำหนดค่าด้วยพอร์ต 443 ที่ปลอดภัยแล้ว

    2. จากนั้นตรวจสอบการกำหนดค่า Health Monitor สำหรับเซิร์ฟเวอร์เป้าหมายในการกำหนดค่าปลายทางเป้าหมาย

      การกำหนดค่าการตรวจสอบประสิทธิภาพการทำงาน

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      โปรดสังเกตว่าไม่ได้ระบุองค์ประกอบ <Port> ใน Health Monitor การกำหนดค่าข้างต้น ในกรณีนี้ ตัวประมวลผลข้อความของ Edge จะใช้พอร์ตที่ระบุไว้ใน คำจำกัดความของเซิร์ฟเวอร์เป้าหมายคือ 443

    3. จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือมีการกำหนดเซิร์ฟเวอร์เป้าหมาย เป็นเซิร์ฟเวอร์ที่ไม่ปลอดภัย (เนื่องจากไม่มีการกำหนดการบล็อก SSLInfo ไว้) แต่มีพอร์ต 443 ที่ปลอดภัย

      กล่าวคือ Edge ทำให้การตรวจสอบประสิทธิภาพการทำงานเป็นการโทรที่ไม่ปลอดภัยด้วยพอร์ตที่ปลอดภัย 443 และไม่ผ่าน ที่มีข้อผิดพลาดที่กล่าวถึงข้างต้น

    พอร์ต HM ที่ปลอดภัยสำหรับเป้าหมายที่ไม่ปลอดภัย

    สถานการณ์ที่ 2: กำหนดเซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัย แต่ Health Monitor กำหนดค่าด้วยพอร์ตที่ปลอดภัย

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

    1. ตรวจสอบการกำหนดเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย

      ใช้ รับ TargetServer API เพื่อรับคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย

      ผลลัพธ์ตามคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย

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

      ในตัวอย่างด้านบน คำจำกัดความแสดงให้เห็นว่าเซิร์ฟเวอร์เป้าหมาย mocktarget ไม่ปลอดภัย เซิร์ฟเวอร์ (เนื่องจากไม่มีการบล็อก SSLInfo) กำหนดค่าด้วยพอร์ต 80 ที่ไม่ปลอดภัยอย่างถูกต้อง

    2. ถัดไป ให้ตรวจสอบการกำหนดค่า Health Monitor สำหรับเซิร์ฟเวอร์เป้าหมายในการกำหนดค่าปลายทางเป้าหมาย

      การกำหนดค่าการตรวจสอบประสิทธิภาพการทำงาน

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      ในตัวอย่างข้างต้น Health Monitor ได้รับการกำหนดค่าด้วยพอร์ต 443 ที่ปลอดภัยซึ่งระบุโดยองค์ประกอบ <Port>

    3. จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือเซิร์ฟเวอร์เป้าหมายได้รับการกำหนดเป็น เซิร์ฟเวอร์ที่ไม่ปลอดภัย (เนื่องจากไม่มีการกำหนดการบล็อก SSLInfo ไว้) ที่มีพอร์ต 80 ที่ไม่ปลอดภัยอย่างถูกต้อง แต่กำหนดค่า Health Monitor ให้ดำเนินการตรวจสอบประสิทธิภาพการทำงานด้วยพอร์ตที่ปลอดภัย 443 (ระบุไว้ในเอลิเมนต์ <Port>)

      กล่าวคือ ในกรณีนี้ Edge จะตรวจสอบประสิทธิภาพการทำงานเป็นการเรียกที่ไม่ปลอดภัยด้วยพอร์ตที่ปลอดภัย 443 และจะดำเนินการไม่สำเร็จเนื่องจากข้อผิดพลาดที่กล่าวถึงข้างต้น

ความละเอียด

พอร์ตที่ปลอดภัยสำหรับเป้าหมายที่ไม่ปลอดภัย

สถานการณ์ 1: เซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัยซึ่งกำหนดด้วยพอร์ตที่ปลอดภัย

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

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

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

พอร์ต HM ที่ปลอดภัยสำหรับเป้าหมายที่ไม่ปลอดภัย

สถานการณ์ที่ 2: กำหนดเซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัย แต่ Health Monitor กำหนดค่าด้วยพอร์ตที่ปลอดภัย

หากต้องการแก้ไขข้อผิดพลาดนี้ โปรดทำตามวิธีการด้านล่าง

  1. นำองค์ประกอบ <Port> ออกจากการกำหนดค่า Health Monitor หรือแก้ไขการกำหนดค่า Health Monitor เพื่อใช้พอร์ตที่ไม่ปลอดภัย (เช่น 80) เพื่อตรวจสอบประสิทธิภาพการทำงานของเซิร์ฟเวอร์เป้าหมายในการกำหนดค่าปลายทางเป้าหมายของพร็อกซี API ที่ล้มเหลวดังที่แสดงด้านล่าง
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
       	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/statuscode/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            
  2. บันทึกการเปลี่ยนแปลงลงในพร็อกซี API

สาเหตุ: API การตรวจสอบประสิทธิภาพตอบสนองพร้อมข้อผิดพลาด

การวินิจฉัย

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

    เช่น คุณอาจเห็นคำเตือนด้านสุขภาพดังที่แสดงด้านล่างนี้

    Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
    Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
            

    หากข้อผิดพลาดนี้เกิดซ้ำเป็นเวลา MaxFailure ครั้งที่กำหนดค่าไว้ใน Health Monitor คุณจะเห็นข้อความเตือนดังนี้

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

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

  4. การตรวจสอบประสิทธิภาพการทำงานจะแสดงข้อความเตือน:
    HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
          

    ข้อความเตือนด้านบนระบุว่าโค้ดตอบกลับที่คาดไว้สำหรับ API การตรวจสอบประสิทธิภาพการทำงานคือ 200 แต่การตอบสนองจริงที่ได้รับคือ 404 ดังนั้น กรณีนี้จะถือว่าเป็นความล้มเหลว

  5. ก่อนที่จะตรวจสอบสาเหตุของการตอบกลับข้อผิดพลาดจาก API การตรวจสอบประสิทธิภาพการทำงาน ให้หาสาเหตุที่ Edge ต้องการโค้ดตอบกลับเป็น 200 สำหรับ API การตรวจสอบประสิทธิภาพการทำงาน โดยตรวจสอบสุขภาพด้วย การกำหนดค่าสำหรับเซิร์ฟเวอร์เป้าหมายในการกำหนดค่าปลายทางเป้าหมาย:

    การกำหนดค่าการตรวจสอบประสิทธิภาพการทำงาน

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
       	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>443</Port>
          <Verb>GET</Verb>
          <Path>/status/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            

    โปรดสังเกตว่าการกำหนดค่า Health Monitor ได้รับการกำหนดค่าด้วยโค้ดตอบกลับ 200 ในองค์ประกอบ <SuccessResponse> ซึ่งหมายความว่าหาก Edge ได้รับโค้ดตอบกลับ (เช่น 400, 401, 404, 500) นอกเหนือจาก 200 จาก API การตรวจสอบประสิทธิภาพการทำงาน ระบบจะถือว่าเป็นข้อผิดพลาดและเพิ่มจำนวนความล้มเหลว

  6. ในการตรวจสอบสาเหตุของการตอบกลับข้อผิดพลาดจาก API การตรวจสอบประสิทธิภาพการทำงาน ให้ทำตามขั้นตอนต่อไปนี้
    1. ดูที่ข้อความก่อนข้อความเตือนในบันทึก Message Processor
      Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
                

      จด URL การตรวจสอบประสิทธิภาพการทำงานจากข้อความนี้ไว้

    2. คุณสามารถเรียก URL นี้โดยตรงจากโปรแกรมประมวลผลข้อความ และตรวจสอบการตอบกลับจริง
      curl -i https://mocktarget.apigee.net:443/status/200
                

      การตอบกลับจากการเรียกใช้ด้านบนแสดง 404 ตามที่เห็นในบันทึกของตัวประมวลผลข้อความ ดังนี้

      < HTTP/2 404
                
    3. ซึ่งแสดงให้เห็นว่า แม้แต่การเรียกใช้ URL การตรวจสอบประสิทธิภาพการทำงานโดยตรงก็ไม่สำเร็จด้วยรหัสการตอบกลับ 404 เดียวกัน ซึ่งหมายความว่า URL การตรวจสอบประสิทธิภาพการทำงานอาจไม่ถูกต้องหรือทรัพยากรที่มีการเข้าถึงซึ่งเป็นส่วนหนึ่งของ URL ไม่พร้อมใช้งานอีกต่อไป
    4. ในตัวอย่าง API การตรวจสอบประสิทธิภาพการทำงานที่ระบุข้างต้น ปัญหาเกิดขึ้นเนื่องจากมีการใช้ URL ที่ไม่ถูกต้องในการกำหนดค่า Health Monitor พบว่า URL ที่ถูกต้องเป็น https://mocktarget.apigee.net:443/statuscode/200 จาก จำลอง API เป้าหมาย
  7. ถ้าได้รับการตอบกลับข้อผิดพลาดอื่นๆ ก็ให้หาสาเหตุของข้อผิดพลาดดังกล่าวโดยทำตามขั้นตอนต่อไปนี้ ขั้นตอนข้างต้น หากจำเป็น ให้ทำงานร่วมกับทีมแบ็กเอนด์ของคุณ

ความละเอียด

  1. แก้ไขปัญหาเกี่ยวกับ API การตรวจสอบประสิทธิภาพการทำงานในเซิร์ฟเวอร์แบ็กเอนด์
  2. วิธีแก้ไขปัญหาในตัวอย่างที่พูดถึงข้างต้น
    1. แก้ไของค์ประกอบ <Path> ในการกำหนดค่า Health Monitor เป็น /statuscode/200 ดังที่แสดงด้านล่าง
      <Path>/statuscode/200</Path>
              
    2. บันทึกการเปลี่ยนแปลงในพร็อกซี API

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

วิเคราะห์ปัญหาโดยใช้การตรวจสอบ API

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

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

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

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

  1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ โปรดระบุข้อมูลต่อไปนี้
    1. ชื่อองค์กร
    2. ชื่อสภาพแวดล้อม
    3. ชื่อพร็อกซี API
    4. ทำตามคำสั่ง curl ให้เสร็จเพื่อทำให้เกิดข้อผิดพลาดซ้ำ
    5. ไฟล์การย้ายข้อมูลที่มีคำขอที่มี 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets
  2. หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้
    1. พบข้อความแสดงข้อผิดพลาดฉบับสมบูรณ์
    2. ชื่อสภาพแวดล้อม
    3. แพ็กเกจพร็อกซี API
    4. ไฟล์การย้ายข้อมูลที่มีคำขอที่มี 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets
    5. บันทึกการเข้าถึง NGINX

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

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

      (/opt/apigee/var/log/edge-message-processor/logs/system.log)