คุณกำลังดูเอกสารประกอบ Apigee Edge
ไปที่
เอกสารประกอบเกี่ยวกับ Apigee X. ข้อมูล
วิดีโอ
ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อผิดพลาด 503 ได้ในวิดีโอต่อไปนี้
วิดีโอ | คำอธิบาย |
---|---|
แก้ปัญหาและแก้ปัญหาบริการ 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 |
คำขอที่ปลอดภัยในพอร์ตที่ไม่ปลอดภัย |
|
ผู้ใช้ Edge Private Cloud |
คำขอที่ไม่ปลอดภัยในพอร์ตที่ปลอดภัย |
|
ผู้ใช้ Edge Private Cloud |
Health Check API ตอบกลับพร้อมข้อผิดพลาด | หาก API การตรวจสอบประสิทธิภาพการทำงานตอบกลับพร้อมข้อผิดพลาดหรือรหัสการตอบกลับ การดำเนินการอื่นใดนอกเหนือจาก ที่ระบุในองค์ประกอบ SuccessResponse ของ Health Monitor | ผู้ใช้ Edge Private Cloud |
ขั้นตอนการวินิจฉัยทั่วไป
กำหนดรหัสข้อความของคำขอที่ไม่สำเร็จ
เครื่องมือการติดตาม
วิธีระบุรหัสข้อความของคำขอที่ล้มเหลวโดยใช้เครื่องมือติดตาม
- เปิดใช้เซสชันการติดตาม เรียก API และสร้างปัญหาซ้ำ - 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets
- เลือกคำขอที่ไม่สำเร็จ 1 รายการ
- ไปที่ระยะ AX และกำหนดรหัสข้อความ (
X-Apigee.Message-ID
) ของคำขอโดยเลื่อนลงในส่วนรายละเอียดระยะดังที่ปรากฏในรูปต่อไปนี้
บันทึกการเข้าถึง NGINX
วิธีระบุรหัสข้อความของคำขอที่ล้มเหลวโดยใช้บันทึกการเข้าถึง NGINX
นอกจากนี้ คุณสามารถดูบันทึกการเข้าถึง NGINX เพื่อดูรหัสข้อความสำหรับข้อผิดพลาด 503 ซึ่งจะเป็นประโยชน์อย่างยิ่งหากเคยเกิดปัญหาในอดีตหรือเป็นปัญหาที่เกิดเป็นระยะๆ และคุณจะไม่สามารถจับภาพการติดตามใน UI ได้ ใช้ขั้นตอนต่อไปนี้เพื่อดูข้อมูลนี้จากบันทึกการเข้าถึง NGINX
- ตรวจสอบบันทึกการเข้าถึง NGINX (
/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log
) - ค้นหาว่าพร็อกซี API ที่ระบุในช่วงระยะเวลาหนึ่งมีข้อผิดพลาด 503 หรือไม่ (หากเคยมีปัญหาเกิดขึ้นในอดีต) หรือหากมีคำขอที่ยังคงดำเนินการไม่สำเร็จด้วย 503
- หากมีข้อผิดพลาด 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 เป็นการตอบสนองไคลเอ็นต์
สาเหตุ: การเชื่อมต่อหมดเวลา
การวินิจฉัย
- ระบุรหัสข้อความของคำขอที่ไม่สำเร็จ
- ค้นหารหัสข้อความในบันทึกตัวประมวลผลข้อความ (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) - คุณจะเห็น
ข้อความแสดงข้อผิดพลาดที่พบบ่อยที่สอดคล้องกับรหัสข้อความ อย่างไรก็ตาม
ถ้าต้องการดูสาเหตุที่แท้จริงของการตรวจสอบประสิทธิภาพการทำงานล้มเหลว ให้เลื่อนลงไปด้านบน
ข้อความแสดงข้อผิดพลาดที่พบบ่อยและตรวจหาข้อผิดพลาดด้านสุขภาพ
ตัวอย่างเช่น ข้อความแสดงข้อผิดพลาด 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 - ในตัวอย่างด้านบน การตรวจสอบประสิทธิภาพการทำงานล้มเหลวโดยมีข้อผิดพลาด
connection timed out
ตรวจสอบว่าคุณสามารถเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ที่เจาะจงจาก ตัวประมวลผลข้อความที่ใช้คำสั่งtelnet
: - หากคุณเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ได้ คุณอาจเห็นข้อความอย่างเช่น เชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์แล้ว ปัญหานี้อาจเป็นปัญหาชั่วคราวและ ปัญหาอาจได้รับการแก้ไขแล้ว หรือเป็นปัญหาเป็นระยะๆ ทำขั้นตอนที่ 4 ซ้ำ 2-3 ครั้ง (มากกว่า 10 ครั้ง) แล้วตรวจสอบเอาต์พุต
- หากไม่มีข้อผิดพลาดเกิดขึ้นกับคําสั่ง
telnet
อย่างต่อเนื่อง แสดงว่าปัญหาคือ แก้ปัญหาแล้ว ตรวจสอบอีกครั้งว่าการทำงานล้มเหลวของการตรวจสอบประสิทธิภาพการทำงานหยุดลงแล้วหรือไม่ หากใช่ คุณก็ไม่จำเป็นต้องดำเนินการ สิ่งอื่นๆ ได้อีกมากมาย - หากเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ด้วยคำสั่ง
telnet
ไม่ได้ในบางครั้ง แสดงว่าเครือข่ายอาจมีปัญหาหรือเซิร์ฟเวอร์แบ็กเอนด์ของคุณอาจไม่ว่าง - หากเชื่อมต่อกับเซิร์ฟเวอร์แบ็กเอนด์ด้วยคําสั่ง
telnet
อย่างต่อเนื่องไม่ได้ ซึ่งอาจเป็นเพราะไม่ได้รับอนุญาตจาก Message Processor ในเซิร์ฟเวอร์แบ็กเอนด์เฉพาะ
telnet <BackendServer-HostName> 443
ความละเอียด
หากระบบสังเกตข้อผิดพลาด connection timed out
อย่างสม่ำเสมอ ให้ตรวจสอบว่าแบ็กเอนด์
เซิร์ฟเวอร์ไม่มีข้อจำกัดไฟร์วอลล์และอนุญาตการรับส่งข้อมูลจาก Apigee Edge Message Processor
เช่น ใน Linux คุณสามารถใช้ iptables เพื่ออนุญาตการเข้าชมจาก
ที่อยู่ IP ของผู้ประมวลผลข้อมูลข้อความในเซิร์ฟเวอร์แบ็กเอนด์
หากยังคงพบปัญหาอยู่ ให้ปรึกษากับผู้ดูแลระบบเครือข่ายของคุณเพื่อพิจารณาและแก้ไขปัญหา หากต้องการความช่วยเหลือเพิ่มเติมจาก Apigee โปรดติดต่อทีมสนับสนุนของ Apigee
สาเหตุ: คำขอที่ปลอดภัยในพอร์ตที่ไม่ปลอดภัย
การวินิจฉัย
- ระบุรหัสข้อความของคำขอที่ไม่สำเร็จ
- ค้นหารหัสข้อความในบันทึกตัวประมวลผลข้อความ (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) - คุณจะเห็นข้อความแสดงข้อผิดพลาดทั่วไปตามรหัสข้อความ
แต่หากต้องการดูสาเหตุที่แท้จริงที่ทำให้ไม่ผ่านการตรวจสอบประสิทธิภาพการทำงาน ให้เลื่อนขึ้นไปด้านบน
ข้อความแสดงข้อผิดพลาดที่พบบ่อยและตรวจหาข้อผิดพลาดด้านสุขภาพ
เช่น คุณอาจเห็นข้อผิดพลาดการตรวจสุขภาพตามที่แสดงด้านล่าง
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 - การตรวจสอบประสิทธิภาพการทำงานล้มเหลวโดยมีข้อผิดพลาด:
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 คุณจะได้รับ ข้อผิดพลาดนี้ ทำตามขั้นตอนด้านล่างเพื่อยืนยันว่านี่เป็นสาเหตุของปัญหานี้หรือไม่
- ตรวจสอบคำจำกัดความของเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย
- จากนั้นตรวจสอบการกำหนดค่า 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 การตรวจสอบประสิทธิภาพการทำงาน - จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือเซิร์ฟเวอร์เป้าหมายคือ กำหนดเป็นเซิร์ฟเวอร์ที่ปลอดภัย (เนื่องจากเปิดใช้การบล็อก SSLInfo อยู่) แต่มีพอร์ต 80 ที่ไม่ปลอดภัย
ใช้เมนู รับ 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 ที่ไม่ปลอดภัยพอร์ต HM ที่ไม่ปลอดภัยของเป้าหมายที่ปลอดภัย
สถานการณ์ที่ 2: กำหนดเซิร์ฟเวอร์เป้าหมายที่ปลอดภัยแต่กำหนดค่า Health Monitor ด้วยพอร์ตที่ไม่ปลอดภัย
หากคุณกำหนดเซิร์ฟเวอร์เป้าหมายที่ปลอดภัยแล้ว แต่กำหนดค่า Health Monitor ด้วย พอร์ตที่ไม่ปลอดภัย เช่น 80 คุณจะได้รับข้อผิดพลาดนี้ ทำตามขั้นตอนด้านล่างเพื่อยืนยัน หากนี่คือสาเหตุของปัญหานี้
- ตรวจสอบการกำหนดเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย
ใช้ รับ TargetServer API เพื่อรับคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย
ผลลัพธ์ตามคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
ในตัวอย่างด้านบน คําจํากัดความแสดงให้เห็นว่าเซิร์ฟเวอร์เป้าหมาย
mocktarget
เป็นเซิร์ฟเวอร์ที่ปลอดภัยตามที่บล็อก SSLInfo ระบุไว้ - ถัดไป ให้ตรวจสอบการกำหนดค่า 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>
- จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือมีการกำหนดเซิร์ฟเวอร์เป้าหมาย
เป็นเซิร์ฟเวอร์ที่ปลอดภัย (เนื่องจากเปิดใช้การบล็อก 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 ด้วยพอร์ตที่ไม่ปลอดภัย
หากต้องการแก้ไขข้อผิดพลาดนี้ โปรดทำตามวิธีการด้านล่าง
- แก้ไขการกำหนดค่า 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>
- บันทึกการเปลี่ยนแปลงลงในพร็อกซี API
สาเหตุ: คำขอที่ไม่ปลอดภัยในพอร์ตที่ปลอดภัย
การวินิจฉัย
- ระบุรหัสข้อความของคำขอที่ไม่สำเร็จ
- ค้นหารหัสข้อความในบันทึกตัวประมวลผลข้อความ (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) - คุณจะเห็น
ข้อความแสดงข้อผิดพลาดที่พบบ่อยที่สอดคล้องกับรหัสข้อความ
แต่หากต้องการดูสาเหตุที่แท้จริงที่ทำให้ไม่ผ่านการตรวจสอบประสิทธิภาพการทำงาน ให้เลื่อนขึ้นไปด้านบน
ข้อความแสดงข้อผิดพลาดที่พบบ่อยและตรวจหาข้อผิดพลาดด้านสุขภาพ
เช่น คุณอาจเห็นข้อผิดพลาดการตรวจสุขภาพตามที่แสดงด้านล่าง
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 - การตรวจสอบประสิทธิภาพการทำงานล้มเหลวโดยมีข้อผิดพลาด:
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 คุณจะเห็นข้อผิดพลาดนี้ ทำตามขั้นตอนด้านล่างเพื่อยืนยันว่านี่เป็นสาเหตุของปัญหานี้หรือไม่
- ตรวจสอบการกำหนดเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย
ใช้ รับ TargetServer API เพื่อรับคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย
ผลลัพธ์ตามคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer>
ในตัวอย่างด้านบน คําจํากัดความแสดงให้เห็นว่าเซิร์ฟเวอร์เป้าหมาย
mocktarget
เป็นเซิร์ฟเวอร์ที่ไม่ปลอดภัยเนื่องจากไม่มีการบล็อก SSLInfo อย่างไรก็ตาม ข้อมูลนี้ไม่ถูกต้อง กำหนดค่าด้วยพอร์ต 443 ที่ปลอดภัยแล้ว - จากนั้นตรวจสอบการกำหนดค่า 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 - จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือมีการกำหนดเซิร์ฟเวอร์เป้าหมาย
เป็นเซิร์ฟเวอร์ที่ไม่ปลอดภัย (เนื่องจากไม่มีการกำหนดการบล็อก SSLInfo ไว้) แต่มีพอร์ต 443 ที่ปลอดภัย
กล่าวคือ Edge ทำให้การตรวจสอบประสิทธิภาพการทำงานเป็นการโทรที่ไม่ปลอดภัยด้วยพอร์ตที่ปลอดภัย 443 และไม่ผ่าน ที่มีข้อผิดพลาดที่กล่าวถึงข้างต้น
พอร์ต HM ที่ปลอดภัยสำหรับเป้าหมายที่ไม่ปลอดภัย
สถานการณ์ที่ 2: กำหนดเซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัย แต่ Health Monitor กำหนดค่าด้วยพอร์ตที่ปลอดภัย
หากคุณกำหนดเซิร์ฟเวอร์เป้าหมายที่ไม่ปลอดภัย แต่กำหนดค่า Health Monitor ด้วยพอร์ตที่ปลอดภัย เช่น 443 คุณจะเห็นข้อผิดพลาดนี้ ทำตามขั้นตอนด้านล่างเพื่อยืนยันว่านี่เป็นสาเหตุของปัญหานี้หรือไม่
- ตรวจสอบการกำหนดเซิร์ฟเวอร์เป้าหมายที่ใช้ในการกำหนดค่าปลายทางเป้าหมาย
ใช้ รับ TargetServer API เพื่อรับคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย
ผลลัพธ์ตามคำจำกัดความของเซิร์ฟเวอร์เป้าหมาย
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
ในตัวอย่างด้านบน คำจำกัดความแสดงให้เห็นว่าเซิร์ฟเวอร์เป้าหมาย
mocktarget
ไม่ปลอดภัย เซิร์ฟเวอร์ (เนื่องจากไม่มีการบล็อก SSLInfo) กำหนดค่าด้วยพอร์ต 80 ที่ไม่ปลอดภัยอย่างถูกต้อง - ถัดไป ให้ตรวจสอบการกำหนดค่า 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>
- จากข้อมูลข้างต้น สาเหตุของข้อผิดพลาดนี้คือเซิร์ฟเวอร์เป้าหมายได้รับการกำหนดเป็น
เซิร์ฟเวอร์ที่ไม่ปลอดภัย (เนื่องจากไม่มีการกำหนดการบล็อก 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 กำหนดค่าด้วยพอร์ตที่ปลอดภัย
หากต้องการแก้ไขข้อผิดพลาดนี้ โปรดทำตามวิธีการด้านล่าง
- นำองค์ประกอบ
<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>
- บันทึกการเปลี่ยนแปลงลงในพร็อกซี API
สาเหตุ: API การตรวจสอบประสิทธิภาพตอบสนองพร้อมข้อผิดพลาด
การวินิจฉัย
- ระบุรหัสข้อความของคำขอที่ไม่สำเร็จ
- ค้นหารหัสข้อความในบันทึกตัวประมวลผลข้อความ (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) - คุณจะเห็นข้อความแสดงข้อผิดพลาดทั่วไปตามรหัสข้อความ
แต่หากต้องการดูสาเหตุที่แท้จริงที่ทำให้ไม่ผ่านการตรวจสอบประสิทธิภาพการทำงาน ให้เลื่อนขึ้นไปด้านบน
ข้อความแสดงข้อผิดพลาดที่พบบ่อยและตรวจสอบข้อผิดพลาด/คำเตือนเกี่ยวกับสุขภาพ
เช่น คุณอาจเห็นคำเตือนด้านสุขภาพดังที่แสดงด้านล่างนี้
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 - การตรวจสอบประสิทธิภาพการทำงานจะแสดงข้อความเตือน:
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
ข้อความเตือนด้านบนระบุว่าโค้ดตอบกลับที่คาดไว้สำหรับ API การตรวจสอบประสิทธิภาพการทำงานคือ 200 แต่การตอบสนองจริงที่ได้รับคือ 404 ดังนั้น กรณีนี้จะถือว่าเป็นความล้มเหลว
- ก่อนที่จะตรวจสอบสาเหตุของการตอบกลับข้อผิดพลาดจาก 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 การตรวจสอบประสิทธิภาพการทำงาน ระบบจะถือว่าเป็นข้อผิดพลาดและเพิ่มจำนวนความล้มเหลว - ในการตรวจสอบสาเหตุของการตอบกลับข้อผิดพลาดจาก API การตรวจสอบประสิทธิภาพการทำงาน ให้ทำตามขั้นตอนต่อไปนี้
- ดูที่ข้อความก่อนข้อความเตือนในบันทึก Message Processor
Apigee-Timer-7 INFO SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
จด URL การตรวจสอบประสิทธิภาพการทำงานจากข้อความนี้ไว้
- คุณสามารถเรียก URL นี้โดยตรงจากโปรแกรมประมวลผลข้อความ และตรวจสอบการตอบกลับจริง
curl -i https://mocktarget.apigee.net:443/status/200
การตอบกลับจากการเรียกใช้ด้านบนแสดง 404 ตามที่เห็นในบันทึกของตัวประมวลผลข้อความ ดังนี้
< HTTP/2 404
- ซึ่งแสดงให้เห็นว่า แม้แต่การเรียกใช้ URL การตรวจสอบประสิทธิภาพการทำงานโดยตรงก็ไม่สำเร็จด้วยรหัสการตอบกลับ 404 เดียวกัน ซึ่งหมายความว่า URL การตรวจสอบประสิทธิภาพการทำงานอาจไม่ถูกต้องหรือทรัพยากรที่มีการเข้าถึงซึ่งเป็นส่วนหนึ่งของ URL ไม่พร้อมใช้งานอีกต่อไป
- ในตัวอย่าง API การตรวจสอบประสิทธิภาพการทำงานที่ระบุข้างต้น ปัญหาเกิดขึ้นเนื่องจากมีการใช้ URL ที่ไม่ถูกต้องในการกำหนดค่า Health Monitor
พบว่า URL ที่ถูกต้องเป็น
https://mocktarget.apigee.net:443/statuscode/200
จาก จำลอง API เป้าหมาย - ถ้าได้รับการตอบกลับข้อผิดพลาดอื่นๆ ก็ให้หาสาเหตุของข้อผิดพลาดดังกล่าวโดยทำตามขั้นตอนต่อไปนี้ ขั้นตอนข้างต้น หากจำเป็น ให้ทำงานร่วมกับทีมแบ็กเอนด์ของคุณ
ความละเอียด
- แก้ไขปัญหาเกี่ยวกับ API การตรวจสอบประสิทธิภาพการทำงานในเซิร์ฟเวอร์แบ็กเอนด์
- วิธีแก้ไขปัญหาในตัวอย่างที่พูดถึงข้างต้น
- แก้ไของค์ประกอบ
<Path>
ในการกำหนดค่า Health Monitor เป็น/statuscode/200
ดังที่แสดงด้านล่าง<Path>/statuscode/200</Path>
- บันทึกการเปลี่ยนแปลงในพร็อกซี API
หากยังคงพบปัญหา ให้ไปที่ ต้องรวบรวมข้อมูลการวินิจฉัย
วิเคราะห์ปัญหาโดยใช้การตรวจสอบ API
การตรวจสอบ API ช่วยให้คุณสามารถแยกปัญหา ด้านต่างๆ อย่างรวดเร็วเพื่อวิเคราะห์ข้อผิดพลาด ประสิทธิภาพ และปัญหาด้านเวลาในการตอบสนอง รวมถึงแหล่งที่มาของปัญหานั้นๆ เช่น นักพัฒนาแอป แอป, พร็อกซี API, เป้าหมายแบ็กเอนด์ หรือแพลตฟอร์ม API
ดูสถานการณ์ตัวอย่าง
ซึ่งแสดงวิธีแก้ปัญหา 5xx เกี่ยวกับ API ของคุณโดยใช้การตรวจสอบ API ตัวอย่างเช่น
คุณอาจต้องตั้งค่าการแจ้งเตือนเมื่อจำนวน messaging.adaptors.http.flow.NoActiveTargets
ข้อผิดพลาดเกินเกณฑ์บางอย่าง
ต้องรวบรวมข้อมูลการวินิจฉัย
หากปัญหายังคงอยู่แม้จะทำตามวิธีการด้านบนแล้ว โปรดรวบรวมข้อมูลต่อไปนี้ ข้อมูลการวินิจฉัย ติดต่อและแชร์กับทีมสนับสนุนของ Apigee ดังนี้
- หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ โปรดระบุข้อมูลต่อไปนี้
- ชื่อองค์กร
- ชื่อสภาพแวดล้อม
- ชื่อพร็อกซี API
- ทำตามคำสั่ง curl ให้เสร็จเพื่อทำให้เกิดข้อผิดพลาดซ้ำ
- ไฟล์การย้ายข้อมูลที่มีคำขอที่มี 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets
- หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้
- พบข้อความแสดงข้อผิดพลาดฉบับสมบูรณ์
- ชื่อสภาพแวดล้อม
- แพ็กเกจพร็อกซี API
- ไฟล์การย้ายข้อมูลที่มีคำขอที่มี 503 Service Unavailable ที่มีรหัสข้อผิดพลาด NoActiveTargets
- บันทึกการเข้าถึง NGINX
(
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
) - บันทึกของตัวประมวลผลข้อความ
(
/opt/apigee/var/log/edge-message-processor/logs/system.log
)