Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

503 Dịch vụ không hoạt động – NoActiveTargets – HealthCheckFailures

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X. thông tin

Video

Hãy xem các video sau đây để biết thêm thông tin về lỗi 503:

Video	Mô tả
Khắc phục sự cố và giải quyết lỗi 503 Không có dịch vụ – NoActiveTargets	Tìm hiểu về những nội dung sau: Tầm quan trọng của Máy chủ đích và Trình giám sát trạng thái Khắc phục sự cố và giải quyết lỗi 503 Không có dịch vụ theo thời gian thực – NoActiveTargets do lỗi kiểm tra tình trạng

Dấu hiệu

Ứng dụng khách nhận được mã trạng thái phản hồi HTTP 503 cùng với thông báo Service Unavailable (Dịch vụ không hoạt động) và mã lỗi NoActiveTargets (Không có mục tiêu đang hoạt động) cho các yêu cầu của proxy API.

Thông báo lỗi

Bạn sẽ thấy phản hồi lỗi sau:

HTTP/1.1 503 Service Unavailable

Bạn sẽ thấy thông báo lỗi sau trong phản hồi HTTP:

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

Các nguyên nhân có thể

Phản hồi HTTP 503 Service Unavailable với mã lỗi NoActiveTargets thường xuất hiện khi bạn sử dụng một hoặc nhiều máy chủ đích trong cấu hình điểm cuối đích trong API Proxy.

Sổ tay này đề cập đến lỗi 503 Service Unavailable với mã lỗi NoActiveTargets do lỗi kiểm tra tình trạng. Vui lòng tham khảo cẩm nang này để tìm hiểu về các nguyên nhân khác gây ra lỗi này.

Lỗi kiểm tra tình trạng

Bạn chỉ thấy các lỗi kiểm tra tình trạng hoạt động nếu đã định cấu hình Trình giám sát tình trạng hoạt động trong cấu hình cân bằng tải của máy chủ mục tiêu trong điểm cuối mục tiêu của API Proxy.

Khi một máy chủ đích không vượt qua được quy trình kiểm tra tình trạng, Edge sẽ tăng số lần thất bại của máy chủ đó. Nếu số lần kiểm tra sức khoẻ không thành công cho máy chủ đó đạt đến ngưỡng được xác định trước (<MaxFailures>), Bộ xử lý thông báo sẽ ghi thông báo cảnh báo như bên dưới vào tệp nhật ký của nó:

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}

Thông báo cảnh báo cung cấp những thông tin sau. Chỉ số này giúp bạn biết được máy chủ mục tiêu nào đạt được số lượng MaxFailure:

Tên máy chủ đích
Tên tổ chức và môi trường
Tên API Proxy
Tên Điểm cuối mục tiêu

Sau đó, Edge sẽ ngừng gửi thêm yêu cầu đến máy chủ cụ thể đó. Sau khi tất cả các máy chủ đích được định cấu hình trong cấu hình LoadBalancer đạt đến số lượng MaxFailure, các yêu cầu API tiếp theo sẽ được phản hồi bằng 503 Dịch vụ không hoạt động với mã lỗi NoActiveTargets.

Việc sử dụng Trình giám sát tình trạng giúp Apigee Edge tự động đưa một máy chủ đích trở lại vòng xoay khi máy chủ đó hoạt động bình thường mà không cần triển khai lại API Proxy.

Sau đây là những nguyên nhân có thể gây ra lỗi kiểm tra tình trạng:

Nguyên nhân	Mô tả	Những người có thể thực hiện các bước khắc phục sự cố
Lỗi hết thời gian chờ kết nối	Message Processor không thể kết nối với máy chủ đích trong khoảng thời gian chờ đã chỉ định trong cấu hình LoadBalancer.	Người dùng Edge Private Cloud
Yêu cầu bảo mật trên cổng không bảo mật	Nếu máy chủ đích được xác định là một máy chủ bảo mật, nhưng được định cấu hình không chính xác bằng một cổng không bảo mật. Nếu máy chủ đích được xác định là một máy chủ bảo mật, nhưng màn hình tình trạng được định cấu hình để thực hiện kiểm tra tình trạng trên một cổng không bảo mật.	Người dùng Edge Private Cloud
Yêu cầu không bảo mật trên cổng bảo mật	Nếu máy chủ đích được xác định là một máy chủ không bảo mật, nhưng được định cấu hình không chính xác bằng một cổng bảo mật. Nếu máy chủ đích được xác định là một máy chủ không bảo mật, nhưng màn hình tình trạng được định cấu hình để thực hiện kiểm tra tình trạng trên một cổng bảo mật.	Người dùng Edge Private Cloud
Health Check API phản hồi bằng một lỗi	Nếu API kiểm tra tình trạng phản hồi bằng một lỗi hoặc mã phản hồi, thì mọi thứ khác với mã được chỉ định trong phần tử SuccessResponse của Trình giám sát tình trạng.	Người dùng Edge Private Cloud

Các bước chẩn đoán thường gặp

Xác định Mã thông báo của yêu cầu không thành công

Công cụ theo dõi

Cách xác định mã nhận dạng thông báo của yêu cầu không thành công bằng công cụ Theo dõi:

Bật phiên theo dõi, thực hiện lệnh gọi API và tái hiện vấn đề – 503 Dịch vụ không hoạt động kèm mã lỗi NoActiveTargets.
Chọn một trong các yêu cầu không thành công.
Chuyển đến giai đoạn AX và xác định mã nhận dạng thông báo (X-Apigee.Message-ID) của yêu cầu bằng cách di chuyển xuống trong phần Thông tin chi tiết về giai đoạn như minh hoạ trong hình sau.

Nhật ký truy cập NGINX

Cách xác định mã thông báo của yêu cầu không thực hiện được bằng nhật ký truy cập NGINX:

Bạn cũng có thể tham khảo nhật ký truy cập NGINX để xác định mã thông báo cho lỗi 503. Điều này đặc biệt hữu ích nếu vấn đề đã xảy ra trong quá khứ hoặc nếu vấn đề xảy ra không liên tục và bạn không thể ghi lại dấu vết trong giao diện người dùng. Hãy làm theo các bước sau để xác định thông tin này từ nhật ký truy cập NGINX:

Kiểm tra nhật ký truy cập NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Tìm xem có Lỗi 503 nào cho một proxy API cụ thể trong một khoảng thời gian cụ thể hay không (nếu vấn đề xảy ra trong quá khứ) hoặc có yêu cầu nào vẫn gặp lỗi 503 hay không.
Nếu có bất kỳ Lỗi 503 nào với thông báo X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, hãy lưu ý mã thông báo cho một hoặc nhiều yêu cầu như vậy như trong ví dụ sau:
Ví dụ về mục nhập cho thấy Lỗi 503

Thông báo lỗi thường gặp

Khi sử dụng máy chủ đích và xảy ra lỗi trong khi Trình xử lý thông báo đang cố gắng kết nối với máy chủ phụ trợ, bạn sẽ thấy một số thông báo lỗi thường gặp trong nhật ký Trình xử lý thông báo. Những lỗi này được ghi lại sau thông báo lỗi/ngoại lệ thực tế dẫn đến lỗi.

Sau đây là các thông báo lỗi thường gặp xuất hiện trong nhật ký của Trình xử lý thư (/opt/apigee/var/log/edge-message-processor/logs/system.log) cho 503 Service Unavailable (Dịch vụ không hoạt động) với mã lỗi NoActiveTargets (Không có mục tiêu đang hoạt động):

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>

Những thông báo lỗi này cho biết không thể gửi yêu cầu đến máy chủ phụ trợ do lỗi. Do đó, Message Processor sẽ gửi 503 Service Unavailable (Dịch vụ không hoạt động) với mã lỗi NoActiveTargets (Không có mục tiêu đang hoạt động) làm phản hồi cho máy khách.

Nguyên nhân: Hết thời gian chờ kết nối

Chẩn đoán

Xác định mã nhận dạng thông báo của yêu cầu không thành công.
Tìm mã nhận dạng thư trong nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Bạn sẽ thấy các thông báo lỗi thường gặp tương ứng với mã thông báo. Tuy nhiên, để biết nguyên nhân thực sự gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên trên các thông báo lỗi thường gặp này và kiểm tra xem có Lỗi giám sát tình trạng nào không.
Ví dụ: Thông báo lỗi HEALTH MONITOR (GIÁM SÁT TÌNH TRẠNG) sau đây cho biết Message Processor (Trình xử lý thông báo) không thành công do lỗi hết thời gian chờ kết nối khi đưa ra yêu cầu API kiểm tra tình trạng:
```
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>
        
```
Nếu lỗi này lặp lại MaxFailure lần (số lần được định cấu hình trong Trình giám sát tình trạng), thì bạn sẽ thấy một thông báo cảnh báo như sau:
```
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}
        
```
Đọc kỹ thông tin trong thông báo cảnh báo. Đảm bảo rằng số lượng MaxFailure đã đạt đến số lượng máy chủ đích được dùng trong Proxy API cụ thể mà bạn đang gặp mã phản hồi 503 với mã lỗi NoActiveTargets.
Trong ví dụ trên, quy trình kiểm tra tình trạng không thành công do lỗi connection timed out. Kiểm tra xem bạn có thể kết nối trực tiếp với máy chủ phụ trợ cụ thể từ mỗi Trình xử lý thông báo bằng lệnh telnet hay không:

telnet <BackendServer-HostName> 443

Nếu có thể kết nối với máy chủ phụ trợ, thì bạn có thể thấy một thông báo như Connected to backend-server (Đã kết nối với máy chủ phụ trợ). Khi đó, vấn đề có thể là một vấn đề tạm thời và có thể đã được giải quyết hoặc là một vấn đề không liên tục. Lặp lại bước 4 vài lần (hơn 10 lần) và xác minh kết quả.

Nếu lệnh telnet không gặp lỗi một cách nhất quán, thì vấn đề đã được giải quyết. Kiểm tra lại xem các lỗi kiểm tra tình trạng hoạt động đã dừng hay chưa. Nếu có, thì bạn không cần làm gì thêm.
Nếu bạn không thể kết nối với máy chủ phụ trợ bằng lệnh telnet không liên tục, thì có thể đã xảy ra sự cố về mạng hoặc máy chủ phụ trợ của bạn đang bận.

Nếu bạn không thể kết nối với máy chủ phụ trợ bằng lệnh telnet một cách nhất quán, thì có thể là do lưu lượng truy cập không được phép từ Bộ xử lý tin nhắn trên máy chủ phụ trợ cụ thể.

Độ phân giải

Nếu bạn liên tục gặp lỗi connection timed out, hãy đảm bảo rằng máy chủ phụ trợ không có bất kỳ hạn chế nào về tường lửa và cho phép lưu lượng truy cập từ Trình xử lý thông báo Apigee Edge. Ví dụ: trên Linux, bạn có thể sử dụng iptables để cho phép lưu lượng truy cập từ địa chỉ IP của Trình xử lý tin nhắn trên máy chủ phụ trợ.

Nếu vấn đề vẫn tiếp diễn, hãy phối hợp với Quản trị viên mạng để xác định và khắc phục vấn đề. Nếu bạn cần được Apigee hỗ trợ thêm, hãy liên hệ với Nhóm hỗ trợ Apigee.

Nguyên nhân: Yêu cầu bảo mật trên cổng không bảo mật

Chẩn đoán

Xác định mã nhận dạng thông báo của yêu cầu không thành công.
Tìm mã nhận dạng thư trong nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).

Bạn sẽ thấy các thông báo lỗi thường gặp tương ứng với mã thông báo. Tuy nhiên, để biết nguyên nhân thực sự gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên trên những thông báo lỗi thường gặp này và kiểm tra xem có Lỗi giám sát tình trạng nào không.

Ví dụ: bạn có thể thấy lỗi HEALTH MONITOR như minh hoạ dưới đây:

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>

Nếu lỗi này lặp lại MaxFailure lần (số lần được định cấu hình trong Trình giám sát trạng thái), thì bạn sẽ thấy một thông báo cảnh báo như sau:

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}

Đọc kỹ thông tin trong thông báo cảnh báo. Đảm bảo rằng số lượng MaxFailure đã đạt đến số lượng máy chủ đích được dùng trong Proxy API cụ thể mà bạn đang gặp mã phản hồi 503 với mã lỗi NoActiveTargets.

Không vượt qua được bước kiểm tra tình trạng với lỗi:
```
Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
      
```
Thông báo lỗi và URL cho biết nguyên nhân của vấn đề này là do một lệnh gọi bảo mật (HTTPS) được thực hiện trên cổng không bảo mật 80.

Lỗi này có thể xảy ra trong 2 trường hợp sau:
- Máy chủ đích bảo mật được xác định bằng cổng không bảo mật
- Máy chủ đích bảo mật được xác định nhưng Trình giám sát trạng thái được định cấu hình bằng một cổng không bảo mật
Bảo mật cổng không bảo mật của mục tiêu

Trường hợp 1: Máy chủ đích bảo mật được xác định bằng cổng không bảo mật

Nếu bạn đã xác định một máy chủ đích bảo mật nhưng lại dùng một cổng không bảo mật như 80, thì bạn sẽ gặp lỗi này. Hãy làm theo các bước dưới đây để xác minh xem đây có phải là nguyên nhân gây ra vấn đề này hay không:
1. Kiểm tra định nghĩa của máy chủ đích được dùng trong cấu hình điểm cuối đích.
2. Giờ đây, hãy kiểm tra cấu hình Health Monitor (Giám sát tình trạng) cho máy chủ đích trong cấu hình thiết bị đầu cuối đích:
  Cấu hình của Trình theo dõi sức khoẻ
  <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>
  Lưu ý rằng không có phần tử <Port> nào được chỉ định trong cấu hình Health Monitor ở trên. Trong trường hợp này, Trình xử lý thông báo của Edge sẽ sử dụng cổng được chỉ định trong định nghĩa máy chủ đích (là 80) để thực hiện các lệnh gọi API kiểm tra tình trạng.
3. Dựa trên thông tin ở trên, nguyên nhân gây ra lỗi này là do máy chủ đích được xác định là máy chủ bảo mật (khi khối SSLInfo được bật), nhưng lại có cổng 80 không bảo mật.
Bảo mật cổng HM không bảo mật của mục tiêu

Trường hợp 2: Máy chủ đích bảo mật được xác định nhưng Health Monitor được định cấu hình bằng một cổng không bảo mật

Nếu bạn đã xác định một máy chủ đích bảo mật nhưng Health Monitor được định cấu hình bằng một cổng không bảo mật như 80, thì bạn sẽ gặp lỗi này. Hãy làm theo các bước dưới đây để xác minh xem đây có phải là nguyên nhân gây ra vấn đề này hay không:
1. Kiểm tra định nghĩa của máy chủ đích được dùng trong cấu hình điểm cuối đích.
  Sử dụng Get TargetServer API để lấy định nghĩa về máy chủ đích.
  
  Đầu ra định nghĩa máy chủ đích
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
  Trong ví dụ trên, định nghĩa cho thấy máy chủ đích mocktarget là một máy chủ bảo mật như được chỉ ra bởi khối SSLInfo.
2. Tiếp theo, hãy kiểm tra cấu hình Health Monitor (Giám sát tình trạng) cho máy chủ đích trong cấu hình điểm cuối đích:
  Cấu hình của Trình theo dõi sức khoẻ
  <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>
  Trong ví dụ trên, Trình giám sát trạng thái được thiết lập bằng Cổng 80 không bảo mật như được chỉ ra bởi phần tử <Port>.
3. Dựa trên thông tin ở trên, nguyên nhân gây ra lỗi này là do máy chủ đích được xác định là máy chủ bảo mật (khi khối SSLInfo được bật) và sử dụng cổng bảo mật 443, nhưng Health Monitor được định cấu hình để thực hiện kiểm tra tình trạng bằng cổng không bảo mật 80 (được chỉ định trong phần tử <Port>).
  Tức là trong trường hợp này, Edge thực hiện các API kiểm tra tình trạng hoạt động dưới dạng một lệnh gọi bảo mật với cổng 80 không bảo mật và không thành công với lỗi nêu trên.
  
  Lưu ý: Phần tử <Port> được định cấu hình trong Trình giám sát tình trạng sẽ được ưu tiên hơn cổng được dùng trong định nghĩa máy chủ đích.

Độ phân giải

Cổng không an toàn của mục tiêu an toàn

Trường hợp 1: Máy chủ đích bảo mật được xác định bằng cổng không bảo mật

Để khắc phục lỗi này, hãy cập nhật định nghĩa máy chủ đích để sử dụng một cổng bảo mật thích hợp.

Sử dụng Update a TargetServer API (Cập nhật API TargetServer) để cập nhật định nghĩa máy chủ đích và đảm bảo rằng một cổng bảo mật (ví dụ: 443) được dùng như trong ví dụ bên dưới:

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

Bảo mật cổng HM không bảo mật của mục tiêu

Trường hợp 2: Máy chủ đích bảo mật được xác định nhưng Health Monitor được định cấu hình bằng một cổng không bảo mật

Để khắc phục lỗi này, hãy làm theo hướng dẫn bên dưới:

Sửa đổi cấu hình Health Monitor để sử dụng một cổng bảo mật (ví dụ: 443) nhằm thực hiện các quy trình kiểm tra tình trạng máy chủ đích trong cấu hình điểm cuối đích của API Proxy không thành công như minh hoạ bên dưới:

<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>

Lưu các thay đổi đối với API Proxy.

Nguyên nhân: Yêu cầu không an toàn trên một cổng an toàn

Chẩn đoán

Xác định mã nhận dạng thông báo của yêu cầu không thành công.
Tìm mã nhận dạng thư trong nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Bạn sẽ thấy các thông báo lỗi thường gặp tương ứng với mã thông báo. Tuy nhiên, để biết nguyên nhân thực sự gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên trên những thông báo lỗi thường gặp này và kiểm tra xem có Lỗi giám sát tình trạng nào không.
Ví dụ: bạn có thể thấy lỗi HEALTH MONITOR như minh hoạ dưới đây:
```
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>
          
```
Nếu lỗi này lặp lại MaxFailure lần (số lần được định cấu hình trong Trình giám sát trạng thái), thì bạn sẽ thấy một thông báo cảnh báo như sau:
```
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}
          
```
Đọc kỹ thông tin trong thông báo cảnh báo. Đảm bảo rằng số lượng MaxFailure đã đạt đến số lượng máy chủ đích được dùng trong Proxy API cụ thể mà bạn đang gặp mã phản hồi 503 với mã lỗi NoActiveTargets.
Không vượt qua được bước kiểm tra tình trạng với lỗi:
```
Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
      
```
Thông báo lỗi và URL cho biết nguyên nhân của vấn đề này là do một lệnh gọi không an toàn (HTTP) đã được thực hiện trên cổng an toàn 443.

Lỗi này có thể xảy ra trong 2 trường hợp sau:
- Máy chủ đích không bảo mật được xác định bằng cổng bảo mật
- Đã xác định máy chủ đích không an toàn nhưng Health Monitor được định cấu hình bằng một cổng an toàn
Cổng bảo mật mục tiêu không an toàn

Tình huống 1: Máy chủ đích không bảo mật được xác định bằng cổng bảo mật

Nếu bạn đã xác định một máy chủ đích không bảo mật nhưng có cổng bảo mật như 443, thì bạn sẽ gặp lỗi này. Hãy làm theo các bước dưới đây để xác minh xem đây có phải là nguyên nhân gây ra vấn đề này hay không:
1. Kiểm tra định nghĩa của máy chủ đích được dùng trong cấu hình điểm cuối đích.
  Sử dụng Get TargetServer API để lấy định nghĩa về máy chủ đích.
  
  Đầu ra định nghĩa máy chủ đích
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer>
  Trong ví dụ trên, định nghĩa cho thấy máy chủ đích mocktarget là một máy chủ không bảo mật vì không có khối SSLInfo. Tuy nhiên, nó được định cấu hình không chính xác bằng Cổng 443 bảo mật.
2. Giờ đây, hãy kiểm tra cấu hình Health Monitor (Giám sát tình trạng) cho máy chủ đích trong cấu hình thiết bị đầu cuối đích:
  Cấu hình của Trình theo dõi sức khoẻ
  <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>
  Lưu ý rằng không có phần tử <Port> nào được chỉ định trong cấu hình Health Monitor ở trên. Trong trường hợp này, Trình xử lý thông báo của Edge sẽ sử dụng cổng được chỉ định trong định nghĩa máy chủ đích là 443.
3. Dựa trên thông tin ở trên, nguyên nhân gây ra lỗi này là do máy chủ đích được xác định là máy chủ không bảo mật (vì khối SSLInfo không được xác định), nhưng có cổng bảo mật 443.
  Tức là Edge thực hiện các quy trình kiểm tra tình trạng như một lệnh gọi không an toàn với cổng an toàn 443 và không thành công với lỗi nêu trên.
Cổng HM bảo mật mục tiêu không an toàn

Trường hợp 2: Máy chủ đích không bảo mật được xác định nhưng Trình giám sát tình trạng được định cấu hình bằng một cổng bảo mật

Nếu bạn đã xác định một máy chủ đích không bảo mật nhưng Health Monitor được định cấu hình bằng một cổng bảo mật như 443, thì bạn sẽ gặp lỗi này. Hãy làm theo các bước dưới đây để xác minh xem đây có phải là nguyên nhân gây ra vấn đề này hay không:
1. Kiểm tra định nghĩa của máy chủ đích được dùng trong cấu hình điểm cuối đích.
  Sử dụng Get TargetServer API để lấy định nghĩa về máy chủ đích.
  
  Đầu ra định nghĩa máy chủ đích
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
  Trong ví dụ trên, định nghĩa cho thấy máy chủ đích mocktarget là một máy chủ không bảo mật (vì không có khối SSLInfo) được định cấu hình với cổng không bảo mật 80 một cách chính xác.
2. Tiếp theo, hãy kiểm tra cấu hình Health Monitor (Giám sát tình trạng) cho máy chủ đích trong cấu hình điểm cuối đích:
  Cấu hình của Trình theo dõi sức khoẻ
  <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>
  Trong ví dụ trên, Trình giám sát tình trạng được thiết lập bằng Cổng 443 bảo mật như được chỉ ra bởi phần tử <Port>.
3. Dựa trên thông tin ở trên, nguyên nhân gây ra lỗi này là do máy chủ đích được xác định là một máy chủ không bảo mật (vì khối SSLInfo không được xác định) với cổng không bảo mật 80 một cách chính xác, nhưng Health Monitor được định cấu hình để thực hiện kiểm tra tình trạng bằng cổng bảo mật 443 (được chỉ định trong phần tử <Port>).
  Tức là trong trường hợp này, Edge thực hiện các quy trình kiểm tra tình trạng dưới dạng một lệnh gọi không bảo mật bằng cổng bảo mật 443 và gặp lỗi như đã đề cập ở trên.

Độ phân giải

Cổng bảo mật mục tiêu không an toàn

Tình huống 1: Máy chủ đích không bảo mật được xác định bằng cổng bảo mật

Để khắc phục lỗi này, hãy cập nhật định nghĩa máy chủ đích để sử dụng một cổng bảo mật thích hợp.

Sử dụng Cập nhật API máy chủ mục tiêu để cập nhật định nghĩa máy chủ mục tiêu và đảm bảo rằng một cổng không bảo mật (ví dụ: 80) được dùng như trong ví dụ bên dưới:

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

Cổng HM bảo mật mục tiêu không an toàn

Trường hợp 2: Máy chủ đích không bảo mật được xác định nhưng Trình giám sát tình trạng được định cấu hình bằng một cổng bảo mật

Để khắc phục lỗi này, hãy làm theo hướng dẫn bên dưới:

Xoá phần tử <Port> khỏi cấu hình Health Monitor hoặc sửa đổi cấu hình Health Monitor để dùng cổng không bảo mật (ví dụ: 80) để thực hiện các quy trình kiểm tra tình trạng máy chủ đích trong cấu hình điểm cuối đích của API Proxy không thành công như minh hoạ bên dưới:

<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>

Lưu các thay đổi đối với API Proxy.

Nguyên nhân: API kiểm tra tình trạng phản hồi lỗi

Chẩn đoán

Xác định mã nhận dạng thông báo của yêu cầu không thành công.
Tìm mã nhận dạng thư trong nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Bạn sẽ thấy các thông báo lỗi thường gặp tương ứng với mã thông báo. Tuy nhiên, để biết nguyên nhân thực sự gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên trên những thông báo lỗi thường gặp này và kiểm tra xem có Lỗi/Cảnh báo về GIÁM SÁT TÌNH TRẠNG hay không.
Ví dụ: bạn có thể thấy cảnh báo HEALTH MONITOR (GIÁM SÁT TÌNH TRẠNG) như minh hoạ dưới đây:
```
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
        
```
Nếu lỗi này lặp lại MaxFailure lần (số lần được định cấu hình trong Trình giám sát trạng thái), thì bạn sẽ thấy một thông báo cảnh báo như sau:
```
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}
        
```
Đọc kỹ thông tin trong thông báo cảnh báo. Đảm bảo rằng số lượng MaxFailure đã đạt đến số lượng máy chủ đích được dùng trong Proxy API cụ thể mà bạn đang gặp mã phản hồi 503 với mã lỗi NoActiveTargets.
Quy trình kiểm tra tình trạng đã trả về thông báo cảnh báo:
```
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
      
```
Thông báo cảnh báo ở trên cho biết mã phản hồi dự kiến cho API kiểm tra tình trạng là 200, nhưng phản hồi thực tế nhận được là 404. Do đó, trường hợp này được coi là không thành công.
Trước khi điều tra nguyên nhân gây ra phản hồi lỗi từ API kiểm tra tình trạng, hãy xác định lý do Edge mong đợi mã phản hồi là 200 cho API kiểm tra tình trạng. Để làm việc này, hãy kiểm tra cấu hình Health Monitor (Giám sát tình trạng) cho máy chủ đích trong cấu hình điểm cuối đích:
Cấu hình của Trình theo dõi sức khoẻ
```
<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>
        
```
Lưu ý rằng cấu hình Health Monitor được định cấu hình với mã phản hồi 200 trong phần tử <SuccessResponse>. Điều này có nghĩa là nếu Edge nhận được mã phản hồi (chẳng hạn như 400, 401, 404, 500) khác với 200 từ API kiểm tra tình trạng, thì mã phản hồi đó sẽ được coi là lỗi và làm tăng số lượng lỗi.
Bây giờ, để tìm hiểu nguyên nhân gây ra lỗi phản hồi từ API kiểm tra tình trạng, hãy làm theo các bước bên dưới:

Xem thông báo trước thông báo cảnh báo trong nhật ký Message Processor.

Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200

Ghi lại URL kiểm tra tình trạng hoạt động trong thông báo này.

Bạn có thể gọi trực tiếp đến URL này từ Trình xử lý tin nhắn và kiểm tra phản hồi thực tế
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
Phản hồi từ lệnh gọi ở trên cho biết 404 như trong nhật ký của Trình xử lý tin nhắn:
```
< HTTP/2 404
          
```
Điều này cho thấy ngay cả lệnh gọi trực tiếp đến URL kiểm tra tình trạng cũng không thành công với cùng mã phản hồi 404. Điều này có nghĩa là URL kiểm tra tình trạng có thể không chính xác hoặc tài nguyên được truy cập trong URL không còn hoạt động.
Trong ví dụ về API kiểm tra tình trạng được cung cấp ở trên, vấn đề xảy ra là do bạn đã dùng một URL không chính xác trong cấu hình Health Monitor. URL chính xác được tìm thấy là https://mocktarget.apigee.net:443/statuscode/200 từ Mock Target API.

Nếu bạn nhận được bất kỳ phản hồi lỗi nào khác, hãy xác định nguyên nhân bằng cách làm theo các bước ở trên. Nếu cần, hãy làm việc với nhóm phụ trách phần phụ trợ.

Độ phân giải

Khắc phục vấn đề với API kiểm tra tình trạng sức khoẻ trên máy chủ phụ trợ.
Cách khắc phục vấn đề trong ví dụ đã thảo luận ở trên:

Sửa đổi phần tử <Path> trong cấu hình Health Monitor thành /statuscode/200 như minh hoạ dưới đây:
```
<Path>/statuscode/200</Path>
        
```
Lưu các thay đổi trong API Proxy.

Nếu vấn đề vẫn tiếp diễn, hãy chuyển đến phần Thông tin chẩn đoán cần thu thập.

Chẩn đoán vấn đề bằng tính năng giám sát API

Tính năng Giám sát API cho phép bạn nhanh chóng cô lập các khu vực có vấn đề để chẩn đoán lỗi, hiệu suất và các vấn đề về độ trễ cũng như nguồn của các vấn đề đó, chẳng hạn như ứng dụng của nhà phát triển, proxy API, mục tiêu phụ trợ hoặc nền tảng API.

Xem xét một kịch bản mẫu minh hoạ cách khắc phục các vấn đề 5xx với API bằng tính năng Giám sát API. Ví dụ: bạn có thể muốn thiết lập một cảnh báo để nhận được thông báo khi số lượng lỗi messaging.adaptors.http.flow.NoActiveTargets vượt quá một ngưỡng cụ thể.

Phải thu thập thông tin chẩn đoán

Nếu vấn đề vẫn tiếp diễn ngay cả sau khi bạn làm theo hướng dẫn ở trên, vui lòng thu thập thông tin chẩn đoán sau. Liên hệ và chia sẻ những thông tin đó với Nhóm hỗ trợ Apigee:

Nếu bạn là người dùng Đám mây công cộng, hãy cung cấp những thông tin sau:

Tên tổ chức
Tên môi trường
Tên Proxy API
Hoàn tất lệnh curl để tái tạo lỗi
Tệp theo dõi chứa các yêu cầu có lỗi 503 Không có dịch vụ với mã lỗi NoActiveTargets

Nếu bạn là người dùng Đám mây riêng tư, hãy cung cấp những thông tin sau:
1. Thông báo lỗi hoàn chỉnh đã quan sát được
2. Tên môi trường
3. Gói API Proxy
4. Tệp theo dõi chứa các yêu cầu có lỗi 503 Không có dịch vụ với mã lỗi NoActiveTargets
5. Nhật ký truy cập NGINX
  (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)
6. Nhật ký của Trình xử lý thông báo
  (/opt/apigee/var/log/edge-message-processor/logs/system.log)

503 Dịch vụ không hoạt động – NoActiveTargets – HealthCheckFailures

Video

Dấu hiệu

Thông báo lỗi

Các nguyên nhân có thể

Lỗi kiểm tra tình trạng

Các bước chẩn đoán thường gặp

Xác định Mã thông báo của yêu cầu không thành công

Công cụ theo dõi

Nhật ký truy cập NGINX

Thông báo lỗi thường gặp

Nguyên nhân: Hết thời gian chờ kết nối

Chẩn đoán

Độ phân giải

Nguyên nhân: Yêu cầu bảo mật trên cổng không bảo mật

Chẩn đoán

Bảo mật cổng không bảo mật của mục tiêu

Bảo mật cổng HM không bảo mật của mục tiêu

Độ phân giải

Cổng không an toàn của mục tiêu an toàn

Bảo mật cổng HM không bảo mật của mục tiêu

Nguyên nhân: Yêu cầu không an toàn trên một cổng an toàn

Chẩn đoán

Cổng bảo mật mục tiêu không an toàn

Cổng HM bảo mật mục tiêu không an toàn

Độ phân giải

Cổng bảo mật mục tiêu không an toàn

Cổng HM bảo mật mục tiêu không an toàn

Nguyên nhân: API kiểm tra tình trạng phản hồi lỗi

Chẩn đoán

Độ phân giải

Chẩn đoán vấn đề bằng tính năng giám sát API

Phải thu thập thông tin chẩn đoán