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 khách nhận được mã trạng thái phản hồi HTTP 503 bằng thông báo Service Available và mã lỗi 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:

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ể

Thường thấy phản hồi HTTP 503 Service Available với mã lỗi NoActiveTargets khi bạn sử dụng một hoặc nhiều máy chủ mục tiêu trong cấu hình thiết bị đầu cuối đích trong Proxy API.

Cẩm nang này trình bày về việc 503 Service không có sẵn kèm theo mã lỗi NoActiveTargets gây ra 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

Lỗi kiểm tra tình trạng sẽ chỉ được quan sát nếu bạn đã định cấu hình một Giám sát 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 mục tiêu của Proxy API.

Khi một máy chủ mục tiêu không vượt qua được quy trình kiểm tra tình trạng, Edge sẽ tăng số 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 xác định trước (<MaxFailures>), Trình xử lý thư ghi lại thông báo cảnh báo như được hiển thị bên dưới vào tệp nhật ký:

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 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 thiết bị đầu 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ủ cụ thể đó. Sau khi tất cả mục tiêu các máy chủ được định cấu hình trong cấu hình Loadbalancer đạt đến số lượng MaxFailure, tiếp theo là Các yêu cầu API được phản hồi bằng trạng thái 503 Service Available kèm theo mã lỗi NoActiveTargets.

Việc sử dụng tính năng Theo dõi sức khoẻ giúp Apigee Edge tự động thêm một máy chủ mục tiêu vào lại xoay khi nó hoạt động mà không cần phải triển khai lại Proxy API.

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

Các bước chẩn đoán phổ biến

Xác định Mã nhận dạng tin nhắn của yêu cầu không thành công

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

Khi các máy chủ đích đượ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ợ, thì bạn sẽ thấy một số thông báo lỗi phổ biến trong Nhật ký Trình xử lý thư. 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.

Các thông báo lỗi phổ biến được phát hiện trong nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log) cho Dịch vụ 503 không có sẵn với mã lỗi NoActiveTargets như sau:

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 đó, Bộ xử lý tin nhắn sẽ gửi thông báo 503 Dịch vụ không hoạt động có mã lỗi NoActiveTargets là phản hồi cho ứng dụng khách.

Nguyên nhân: Hết thời gian kết nố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ư (/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ã nhận dạng thông báo. Tuy nhiên, để xem nguyên nhân thực tế gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên các mục này các thông báo lỗi thường gặp và kiểm tra xem có lỗi "MÁT GIÁ TRỊ SỨC KHOẺ" nào không.

   Ví dụ: Thông báo lỗi HEALTH MONITOR sau đây cho biết Trình xử lý thư không hoạt động với 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 số lần được định cấu hình trong Trình theo dõi 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 có trong cảnh báo. Đảm bảo rằng MaxFailure đã đạt đến số lượng máy chủ mục tiêu được sử dụng trong Proxy API cụ thể mà bạn đang gặp phải mã phản hồi 503 với mã lỗi NoActiveTargets.

4. Trong ví dụ trên, quá 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ừ mỗi Trình xử lý thư sử dụng lệnh telnet:

telnet <BackendServer-HostName> 443
      

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

Độ phân giải

Nếu liên tục gặp lỗi connection timed out, hãy đảm bảo phần phụ trợ máy chủ 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ý tin nhắn 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ý thư 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 hỗ trợ thêm từ Apigee, hãy liên hệ với Nhóm hỗ trợ Apigee.

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ư (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. 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 tế gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên các mục này các thông báo lỗi thường gặp và kiểm tra xem có lỗi "MÁT GIÁ TRỊ SỨC KHOẺ" nào không.

   Ví dụ: Bạn có thể thấy lỗi SỨC KHOẺ VÀ SỨC KHOẺ như 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 số lần 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 : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

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

4. Quá trình 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 vấn đề này là do cuộc 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ủ 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

   Cổng không an toàn của đích đến được bảo mật

   Tình huống 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 được một máy chủ đích bảo mật nhưng với cổng không bảo mật như 80, thì bạn sẽ nhận được lỗi này. Hãy làm theo các bước bên dưới để xác minh xem đây có phải là nguyên nhân gây ra vấn đề này không:

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

   Sử dụng Tải TargetServer API để lấy đị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áy chủ được chỉ định bởi khối SSLInfo. Tuy nhiên, cổng này được định cấu hình bằng Cổng 80 không an toàn.

   2. Bây giờ, hãy kiểm tra cấu hình Health Monitor cho máy chủ mục tiêu trong cấu hình thiết bị đầu cuối mục tiêu:

      Cấu hình của màn hình giám sát 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 chưa có phần tử <Port> nào được chỉ định trong Cấu hình của tính năng Giám sát sức khoẻ ở trên. Trong trường hợp này, Trình xử lý tin nhắn của Edge sẽ sử dụng cổng được chỉ định trong định nghĩa máy chủ mục tiêu (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 (vì khối SSLInfo được bật), nhưng với cổng 80 không an toàn.

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

   Tình huống 2: Máy chủ mục tiêu được xác định nhưng Health Monitor được đị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ủ mục tiêu bảo mật nhưng Trình theo dõi tình trạng đượ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 bên dưới để xác minh nếu đây là nguyên nhân gây ra vấn đề này:

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

      Sử dụng Tải TargetServer API để 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>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ủ mục tiêu mocktarget là một máy chủ bảo mật được biểu thị bằng khối SSLInfo.

   2. Tiếp theo, hãy kiểm tra cấu hình Health Monitor cho máy chủ mục tiêu trong cấu hình thiết bị đầu cuối mục tiêu:

      Cấu hình của màn hình giám sát 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, Health Monitor đượ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 gây ra lỗi này là do máy chủ đích được xác định dưới dạng 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 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 không an toàn 80 (được chỉ định trong phần tử <Port>).

      Trong trường hợp này, Edge sẽ coi các API kiểm tra tình trạng là một lệnh gọi an toàn với các URL không bảo mật cổng 80 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ư (/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ã nhận dạng thông báo. Tuy nhiên, để biết nguyên nhân thực tế gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên các mục này các thông báo lỗi thường gặp và kiểm tra xem có lỗi "MÁT GIÁ TRỊ SỨC KHOẺ" nào không.

   Ví dụ: Bạn có thể thấy lỗi SỨC KHOẺ VÀ SỨC KHOẺ như 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 số lần 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 : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
             

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

4. Quá trình 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 vấn đề 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ủ mục tiêu không an toàn nhưng tính năng Giám sát sức khoẻ được định cấu hình bằng một cổng bảo mật

   Cổng bảo mật đích không an toàn

   Tình huống 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 bạn đã xác định một máy chủ đích không an toàn 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 bên dưới để xác minh xem đây có phải là nguyên nhân gây ra vấn đề này không:

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

      Sử dụng Tải TargetServer API để 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>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ột máy chủ không bảo mật vì không có khối SSLInfo. Tuy nhiên, điều này không chính xác định cấu hình bằng Cổng 443 bảo mật.

   2. Bây giờ, hãy kiểm tra cấu hình Health Monitor cho máy chủ mục tiêu trong cấu hình thiết bị đầu cuối mục tiêu:

      Cấu hình của màn hình giám sát 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 chưa có phần tử <Port> nào được chỉ định trong Trình theo dõi tình trạng cấu hình ở trên. Trong trường hợp này, Trình xử lý thư 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ủ đích được xác định dưới dạng máy chủ không bảo mật (như khối SSLInfo không được xác định), nhưng với cổng bảo mật 443.

      Tức là Edge sẽ 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 HR bảo mật cho mục tiêu không được bảo mật

   Tình huống 2: Máy chủ mục tiêu không được bảo mật nhưng ứng dụng Giám sát 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ủ mục tiêu không an toàn 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 bên dưới để xác minh xem đây có phải là nguyên nhân gây ra vấn đề này không:

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

      Sử dụng Tải TargetServer API để 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>
      </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ủ không bảo mật máy chủ (vì không có khối SSLInfo) được định cấu hình với cổng không an toàn 80 đúng cách.

   2. Tiếp theo, hãy kiểm tra cấu hình Health Monitor cho máy chủ mục tiêu trong cấu hình thiết bị đầu cuối mục tiêu:

      Cấu hình của màn hình giám sát 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, 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 gây ra lỗi này là do máy chủ mục tiêu được định nghĩa 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 đúng cách, nhưng Health Monitor được định cấu hình để tiến hành kiểm tra tình trạng với cổng bảo mật 443 (được chỉ định trong phần tử <Port>).

      Trong trường hợp này, Edge thực hiện việc kiểm tra tình trạng là 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.

Độ 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 bằng một 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ư (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. 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 tế gây ra lỗi kiểm tra tình trạng, hãy di chuyển lên các mục này các thông báo lỗi thường gặp và kiểm tra xem có Lỗi/Cảnh báo SỨC KHOẺ SỨC KHOẺ nào không.

   Ví dụ: Bạn có thể thấy cảnh báo GIÁM SÁT SỨC KHOẺ như 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 số lần 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 : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

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

4. Quá 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 câu trả lời thực tế nhận được lại là 404. Do đó, hệ thống sẽ coi đây là lỗi.

5. Trước khi điều tra nguyên nhân phản hồi lỗi từ API kiểm tra tình trạng, hãy xác định lý do nên sử dụng Edge dự kiến mã phản hồi là 200 cho API kiểm tra tình trạng. Để biết thông tin này, hãy kiểm tra màn hình Giám sát sức khoẻ cấu hình cho máy chủ mục tiêu trong cấu hình điểm cuối đích:

   Cấu hình của màn hình giám sát 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>
           

   Xin lưu ý rằng cấu hình Giám sát sức khoẻ được định cấu hình bằng mã phản hồi 200 trong phần tử <SuccessResponse>. Tức là nếu Edge nhận được mã phản hồi bất kỳ (chẳng hạn như 400, 401, 404, 500) ngoài 200 từ API kiểm tra tình trạng, thì hệ thống sẽ coi đó là một lỗi và làm tăng số lượng lỗi.

6. Bây giờ, để điều tra nguyên nhân phản hồi lỗi của 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 thông báo cảnh báo trong nhật ký Trình xử lý thư.

   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 trong thư này.

2. Bạn có thể gọi điện trực tiếp tới URL này từ Bộ xử lý thư 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ừ cuộc gọi ở trên sẽ trả về 404 như trong nhật ký Trình xử lý tin nhắn:

   < 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ột 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 dưới dạng một phần của URL không còn hoạt động nữa.
4. Trong ví dụ về API kiểm tra tình trạng được cung cấp ở trên, vấn đề này xảy ra do URL đã không chính xác trong cấu hình Giám sát 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 gây ra lỗi bằng cách làm theo các bước nêu 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ợ.
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ư minh hoạ dưới đây:

   <Path>/statuscode/200</Path>
           

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

Nếu sự cố vẫn tiếp diễn, hãy chuyển đế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

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

Tìm hiểu một tình huống mẫu minh hoạ cách khắc phục sự cố 5xx với API của bạn bằng cách sử dụng Giám sát API. Ví dụ: bạn có thể thiết lập cảnh báo để nhận thông báo khi số messaging.adaptors.http.flow.NoActiveTargets lỗi vượt quá một ngưỡng cụ thể.

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

Nếu sự cố vẫn tiếp diễn ngay cả sau khi đã làm theo các hướng dẫn trên, hãy thu thập các thông tin sau thông tin chẩn đoán. Liên hệ và chia sẻ chúng với Nhóm hỗ trợ Apigee:

1. Nếu bạn là người dùng Đám mây công cộng, hãy cung cấp các 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 với 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 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ý bộ xử lý thư

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