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

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Video

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

Triệu chứng

Ứng dụng sẽ nhận được mã trạng thái phản hồi HTTP 503 với thông báo Service Invalid (Dịch vụ không có sẵn) và mã lỗi NoActiveTargets (NoActiveTargets) cho các yêu cầu proxy API.

Thông báo lỗi

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

HTTP/1.1 503 Service Unavailable
  

Bạn sẽ thấy thông báo lỗi sau đây 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 ServiceKhông khả dụng với mã lỗi NoActiveTargets thường được quan sát thấy 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 mục tiêu trong Proxy API.

Cẩm nang này đề cập đến trạng thái 503 Service Không khả dụng với mã lỗi NoActiveTargets gây ra do không thành công khi 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.

Không kiểm tra được tình trạng

Các lỗi kiểm tra tình trạng sẽ chỉ được quan sát nếu bạn đã định cấu hình Trình theo dõi tình trạ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 đích của Proxy API.

Khi 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ượng lỗi của máy chủ đó. Nếu số lần kiểm tra tình trạng không thành công của máy chủ đó đạt đến ngưỡng định sẵn (<MaxFailures>), Trình 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 mình:

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. Điều này giúp bạn biết được máy chủ mục tiêu nào đã đạt đến số lượng MaxFailure:

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

Sau đó, Edge sẽ ngừng gửi thêm bất kỳ yêu cầu nào đến máy chủ đó. Sau khi tất cả máy chủ đích được định cấu hình trong cấu hình Load Balances đạ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 Service Existing (Không có dịch vụ 503) kèm theo mã lỗi NoActiveTargets.

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

Dưới đây là những nguyên nhân có thể dẫn đến việc kiểm tra tình trạng không thành công:

Các bước chẩn đoán phổ biế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

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

Khi máy chủ mục tiêu được sử dụng 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 trong nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log) cho 503 ServiceKhông khả dụng có mã lỗi 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>

Những thông báo lỗi này cho biết rằng không thể gửi yêu cầu tới máy chủ phụ trợ do xảy ra lỗi. Do đó, Trình xử lý thông báo sẽ gửi thông báo 503 Service available (Không có dịch vụ 503) kèm theo mã lỗi NoActiveTargets làm phản hồi cho ứng dụng.

Nguyên nhân: Kết nối hết thời gian chờ

Chẩn đoán

1. Xác định mã nhận dạng của thông báo của yêu cầu không thành công.
2. Tìm kiếm mã nhận dạng thư trong nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Bạn sẽ thấy 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 tế của các 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 rồi kiểm tra xem có lỗi nào liên quan đến MÁY KIỂM TRA SỨC KHOẺ hay không.

   Ví dụ: thông báo lỗi SỨC KHOẺ sau đây cho biết Trình xử lý thông báo không thành công với lỗi hết thời gian kết nối khi thực hiện 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 trong MaxFailure lần được định cấu hình trong Trình theo dõi sức khoẻ, 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 được cung cấp trong cảnh báo. Đảm bảo bạn đã đạt đến số lượng MaxFailure cho một máy chủ mục tiêu dùng trong Proxy API cụ thể mà bạn đang gặp phải mã phản hồi 503 có mã lỗi NoActiveTargets.

4. Trong ví dụ trên, quy trình kiểm tra tình trạng không thành công với 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ừ từng Bộ xử lý thông báo bằng lệnh telnet hay không:

telnet <BackendServer-HostName> 443
      

5. Nếu kết nối được với máy chủ phụ trợ, thì bạn có thể thấy một thông báo như Đã kết nối với máy chủ phụ trợ. Khi đó, vấn đề có thể là vấn đề tạm thời và có thể đã được giải quyết hoặc là vấn đề gián đoạn. Lặp lại bước 4 một vài lần (hơn 10 lần) và xác minh kết quả.
1. Nếu không có lỗi nào xảy ra với lệnh telnet 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 đã kết thúc hay chưa. Nếu có, thì bạn không cần phải làm gì thêm.
2. 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ố mạng hoặc máy chủ phụ trợ của bạn có thể đang bận.
6. Nếu bạn không thể kết nối một cách nhất quán với máy chủ phụ trợ bằng lệnh telnet, thì nguyên nhân có thể là do Bộ xử lý thông báo không cho phép lưu lượng truy cập trên một máy chủ phụ trợ cụ thể.

Độ phân giải

Nếu bạn liên tục quan sát thấy 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ừ Bộ xử lý thư Apigee Edge. Ví dụ: trên Linux, bạn có thể dùng iptables để cho phép lưu lượng truy cập từ địa chỉ IP của Trình xử lý thông báo trên máy chủ phụ trợ.

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

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

Chẩn đoán

1. Xác định mã nhận dạng của thông báo của yêu cầu không thành công.
2. Tìm kiếm mã nhận dạng thư trong nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Bạn sẽ thấy 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 tế khiến các lỗi kiểm tra tình trạng không thành công, hãy di chuyển lên trên các thông báo lỗi thường gặp này rồi kiểm tra xem có bất kỳ lỗi nào liên quan đến MÁY PHÁT SÓNG SỨC KHOẺ.

   Ví dụ: bạn có thể thấy lỗi Giám sát SỨC KHOẺ 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 trong MaxFailure lần được định cấu hình trong Trình theo dõi tình trạng, thì bạn sẽ thấy 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 được cung cấp trong cảnh báo. Đảm bảo bạn đã đạt đến số lượng MaxFailure cho một máy chủ mục tiêu dùng trong Proxy API cụ thể mà bạn đang gặp phải mã phản hồi 503 có mã lỗi NoActiveTargets.

4. Kiểm tra tình trạng không thành cô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 sự cố này là do lệnh gọi an toàn (HTTPS) đã được thực hiện trên cổng không an toàn 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 an toàn
   • Đã xác định máy chủ đích bảo mật nhưng Health Monitor đã định cấu hình bằng một cổng không an toàn

   Cổng không bảo mật và đích bảo mật

   Trường hợp 1: Máy chủ mục tiêu bảo mật được xác định bằng cổng không an toàn

   Nếu bạn đã xác định một máy chủ đích bảo mật nhưng với một cổng không an toàn 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 của vấn đề này không:

   1. Kiểm tra định nghĩa của máy chủ đích dùng trong cấu hình điểm cuối mục tiêu.

   Sử dụng Tải API máy chủ mục tiêu để nhận định nghĩa máy chủ mục tiêu.

   Kết quả định nghĩa máy chủ mục tiêu

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

   Trong ví dụ trên, định nghĩa cho thấy máy chủ mục tiêu mocktarget là một máy chủ bảo mật như được chỉ định bởi khối SSLInfo. Tuy nhiên, cổng này được định cấu hình với Cổng 80 không an toàn.

   2. Bây giờ, hãy kiểm tra cấu hình Health Monitor (Trình theo dõi 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 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>
                

      Xin 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ủ mục tiêu (là 80) để thực hiện 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ủ mục tiêu được xác định là máy chủ bảo mật (khi khối SSLInfo được bật), nhưng có cổng không an toàn 80.

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

   Trường hợp 2: Đã xác định máy chủ mục tiêu bảo mật nhưng Health Monitor đã định cấu hình bằng một cổng không an toàn

   Nếu bạn đã xác định một máy chủ đích bảo mật nhưng Trình theo dõi sức khoẻ được định cấu hình bằng một cổng không an toàn 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 của vấn đề này không:

   1. Kiểm tra định nghĩa của máy chủ đích dùng trong cấu hình điểm cuối mục tiêu.

      Hãy sử dụng API Máy chủ mục tiêu để nhận định nghĩa về máy chủ mục tiêu.

      Kết quả định nghĩa máy chủ mục tiêu

      <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 được chỉ định bởi khối SSLInfo.

   2. Tiếp theo, hãy kiểm tra cấu hình Health Monitor (Trình theo dõi tình trạng) cho máy chủ đích trong cấu hình điểm cuối mục tiêu:

      Cấu hình của 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>
              

      Trong ví dụ trên, Trình theo dõi sức khoẻ được định cấu hình bằng Cổng 80 không an toàn như được chỉ định bằng phần tử <Port>.

   3. Dựa trên thông tin ở trên, nguyên nhân của lỗi này là do máy chủ mục tiêu được định nghĩa 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 với cổng không an toàn 80 (được chỉ định trong phần tử <Port>).

      Trong trường hợp này, Edge sẽ tạo các API kiểm tra tình trạng dưới dạng một lệnh gọi an toàn với cổng 80 không an toàn và không gặp lỗi nêu trên.

Độ phân giải

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

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

Chẩn đoán

1. Xác định mã nhận dạng của thông báo của yêu cầu không thành công.
2. Tìm kiếm mã nhận dạng thư trong nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Bạn sẽ thấy 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 tế khiến các lỗi kiểm tra tình trạng không thành công, hãy di chuyển lên trên các thông báo lỗi thường gặp này rồi kiểm tra xem có bất kỳ lỗi nào liên quan đến MÁY PHÁT SÓNG SỨC KHOẺ.

   Ví dụ: bạn có thể thấy lỗi Giám sát SỨC KHOẺ 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 trong MaxFailure lần được định cấu hình trong Trình theo dõi tình trạng, thì bạn sẽ thấy 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 được cung cấp trong cảnh báo. Đảm bảo bạn đã đạt đến số lượng MaxFailure cho một máy chủ mục tiêu dùng trong Proxy API cụ thể mà bạn đang gặp phải mã phản hồi 503 có mã lỗi NoActiveTargets.

4. Kiểm tra tình trạng không thành cô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 sự cố này là do lệnh gọi không an toàn (HTTP) đã được thực hiện trên cổng bảo mật 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 bảo mật nhưng Health Monitor được định cấu hình bằng một cổng bảo mật

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

   Trường hợp 1: Máy chủ mục tiêu không an toàn được xác định bằng cổng bảo mật

   Nếu đã xác định một máy chủ đích không an toàn nhưng có 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 của vấn đề này không:

   1. Kiểm tra định nghĩa của máy chủ đích dùng trong cấu hình điểm cuối mục tiêu.

      Hãy sử dụng API Máy chủ mục tiêu để nhận định nghĩa về máy chủ mục tiêu.

      Kết quả định nghĩa máy chủ mục tiêu

      <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ủ mục tiêu mocktarget là máy chủ không an toàn vì không có khối SSLInfo. Tuy nhiên, cổng được định cấu hình không chính xác với Cổng 443 bảo mật.

   2. Bây giờ, hãy kiểm tra cấu hình Health Monitor (Trình theo dõi 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 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>
                      

      Xin lưu ý rằng không có phần tử <Port> nào được chỉ định trong cấu hình Health Monitor (Trình theo dõi sức khoẻ) nêu 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ủ mục tiêu 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ủ mục tiêu được xác định là máy chủ không an toàn (vì khối SSLInfo không được xác định), nhưng có cổng bảo mật 443.

      Điều này nghĩa là Edge thực hiện việc kiểm tra tình trạng dưới dạng một lệnh gọi không an toàn với cổng bảo mật 443 và không thành công với lỗi nêu trên.

   Cổng HM bảo mật không bảo mật cho mục tiêu

   Trường hợp 2: Máy chủ mục tiêu không an toàn được xác định nhưng Trình theo dõi sức khoẻ đượ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 Trình theo dõi sức khoẻ đượ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 của vấn đề này không:

   1. Kiểm tra định nghĩa của máy chủ đích dùng trong cấu hình điểm cuối mục tiêu.

      Hãy sử dụng API Máy chủ mục tiêu để nhận định nghĩa về máy chủ mục tiêu.

      Kết quả định nghĩa máy chủ mục tiêu

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

      Trong ví dụ trên, định nghĩa trên cho thấy máy chủ mục tiêu mocktarget là máy chủ không an toàn (vì không có khối SSLInfo nào được định cấu hình chính xác với cổng không an toàn 80.

   2. Tiếp theo, hãy kiểm tra cấu hình Health Monitor (Trình theo dõi tình trạng) cho máy chủ đích trong cấu hình điểm cuối mục tiêu:

      Cấu hình của 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>
            

      Trong ví dụ trên, Health Monitor được định cấu hình bằng Cổng 443 bảo mật như được chỉ định bằng phần tử <Port>.

   3. Dựa trên thông tin ở trên, nguyên nhân của lỗi này là do máy chủ mục tiêu được xác định là máy chủ không bảo mật (vì khối SSLInfo không được xác định) với cổng 80 không bảo mật một cách chính xác, nhưng Trình theo dõi tình trạng được định cấu hình để thực hiện kiểm tra tình trạng với 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 việc kiểm tra tình trạng dưới dạng lệnh gọi không an toàn với cổng bảo mật 443 và không thành công với lỗi nêu trên.

Độ phân giải

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

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

Chẩn đoán

1. Xác định mã nhận dạng của thông báo của yêu cầu không thành công.
2. Tìm kiếm mã nhận dạng thư trong nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Bạn sẽ thấy 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 tế khiến các lỗi kiểm tra tình trạng không thành công, hãy di chuyển lên trên các thông báo lỗi thường gặp này rồi kiểm tra mọi Lỗi/Cảnh báo về SỨC KHOẺ.

   Ví dụ: bạn có thể thấy cảnh báo về GIÁ TRỊ SỨC KHOẺ 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 trong MaxFailure lần được định cấu hình trong Trình theo dõi tình trạng, thì bạn sẽ thấy 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 được cung cấp trong cảnh báo. Đảm bảo bạn đã đạt đến số lượng MaxFailure cho một máy chủ mục tiêu dùng trong Proxy API cụ thể mà bạn đang gặp phải mã phản hồi 503 có mã lỗi NoActiveTargets.

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

5. Trước khi tìm hiểu nguyên nhân phản hồi lỗi của API kiểm tra tình trạng, hãy xác định lý do Edge dự kiến mã phản hồi là 200 đối với API kiểm tra tình trạng. Đối với việc này, hãy kiểm tra cấu hình Trình theo dõi tình trạng cho máy chủ đích trong cấu hình điểm cuối mục tiêu:

   Cấu hình của Health Monitor

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

   Xin lưu ý rằng cấu hình Health Monitor được định cấu hình bằng 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 bất kỳ mã phản hồi nào (chẳng hạn như 400, 401, 404, 500) ngoài 200 từ API kiểm tra tình trạng, thì mã đó sẽ được coi là lỗi và làm tăng số lượng lỗi.

6. Bây giờ, để điều tra nguyên nhân của phản hồi lỗi từ API kiểm tra tình trạng, hãy làm theo các bước dưới đây:
1. Xem thông báo trước khi đưa ra cảnh báo trong nhật ký Bộ xử lý thư.

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

   Hãy ghi lại URL kiểm tra tình trạng trong thư này.

2. Bạn có thể thực hiện lệnh gọi trực tiếp đến URL này từ Bộ xử lý tin nhắn để kiểm tra phản hồi thực tế

   curl -i https://mocktarget.apigee.net:443/status/200
             

   Phản hồi từ cuộc gọi ở trên cho ra mã 404 như trong nhật ký của Trình xử lý thông báo:

   < HTTP/2 404
             

3. Đ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 đang được truy cập trong URL không còn nữa.
4. Trong ví dụ về API kiểm tra tình trạng được cung cấp ở trên, vấn đề xảy ra do bạn sử dụng sai URL trong cấu hình Trình theo dõi tình trạng. Đã tìm thấy URL chính xác là https://mocktarget.apigee.net:443/statuscode/200 trong API mục tiêu mô phỏng.
7. 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 tương tự 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ợ của bạn.

Độ phân giải

1. Khắc phục vấn đề với API kiểm tra tình trạng trên máy chủ phụ trợ của bạn.
2. Cách khắc phục vấn đề trong ví dụ đã thảo luận ở trên:
1. Sửa đổi phần tử <Path> trong cấu hình Health Monitor thành /statuscode/200 như sau:

   <Path>/statuscode/200</Path>
           

2. Lưu các thay đổi trong Proxy API.

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

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

Giám sát API giúp bạn nhanh chóng tách biệt 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ư các nguồn liên quan, chẳng hạn như ứng dụng dành cho nhà phát triển, proxy API, mục tiêu phụ trợ hoặc nền tảng API.

Xem tình huống mẫu minh hoạ cách khắc phục sự cố 5xx xảy ra với API bằng tính năng Giám sát API. Ví dụ: bạn nên thiết lập cảnh báo để nhận 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 sau khi đã làm theo hướng dẫn ở trên, vui lòng thu thập thông tin chẩn đoán sau đây. Hãy liên hệ và chia sẻ thông tin với Nhóm hỗ trợ API:

1. Nếu bạn là người dùng Public Cloud, hãy cung cấp những thông tin sau:
1. Tên tổ chức
2. Tên môi trường
3. Tên proxy API
4. Hoàn tất lệnh curl để tái hiện lỗi
5. Tệp theo dõi chứa các yêu cầu có dịch vụ 503 không khả dụng kèm theo mã lỗi NoActiveTargets
2. 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. Đã phát hiện thấy Thông báo lỗi hoàn chỉnh
   2. Tên môi trường
   3. Gói Proxy API
   4. Tệp theo dõi chứa các yêu cầu có dịch vụ 503 không khả dụng kèm theo 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ý bộ xử lý thông báo

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