503 Служба недоступна — NoActiveTargets — HealthCheckFailures

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Видео

Для получения дополнительной информации об ошибках 503 смотрите следующие видеоролики:

Симптом

Клиентское приложение получает HTTP-ответ со статусом 503 , сообщением " Сервис недоступен" и кодом ошибки 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 обычно наблюдается при использовании одного или нескольких целевых серверов в конфигурации целевой конечной точки в вашем API-прокси.

В этом руководстве рассматривается ошибка 503 Service Unavailable с кодом NoActiveTargets , возникающая из-за сбоев проверки работоспособности. Для получения информации о других причинах этой ошибки обратитесь к данному руководству .

Сбои в медицинских проверках

Сбои проверки работоспособности будут наблюдаться только в том случае, если вы настроили монитор работоспособности в рамках конфигурации балансировки нагрузки целевого сервера в целевой конечной точке вашего 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 count):

• Имя целевого сервера
• Названия организаций и окружающей среды
• Имя API-прокси
• Имя целевой конечной точки

После этого Edge прекращает отправку дальнейших запросов на этот конкретный сервер. Как только все целевые серверы, настроенные в конфигурации LoadBalancer, достигнут значения MaxFailure , последующие запросы к API будут завершаться ответом с кодом ошибки 503 Service Unavailable и кодом ошибки NoActiveTargets.

Использование Health Monitor помогает Apigee Edge автоматически включать целевой сервер обратно в ротацию, когда он становится работоспособным, без необходимости повторного развертывания API-прокси.

Вот возможные причины неудачных результатов медицинского обследования:

Общие этапы диагностики

Определите идентификатор сообщения (Message ID) запроса, завершившегося с ошибкой.

Типичные сообщения об ошибках

При использовании целевых серверов и возникновении ошибки во время попытки подключения обработчика сообщений к бэкэнд-серверу, в журналах обработчика сообщений появятся несколько распространенных сообщений об ошибках. Эти ошибки регистрируются после фактического сообщения об исключении/ошибке, приведшей к сбою.

В журналах обработчика сообщений ( /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>

Эти сообщения об ошибках указывают на то, что запрос не удалось отправить на серверную часть из-за сбоя. В результате обработчик сообщений отправляет клиенту ответ с кодом ошибки 503 Service Unavailable и кодом ошибки NoActiveTargets .

Причина: Истекло время ожидания соединения

Диагноз

1. Определите идентификатор сообщения запроса, который завершился неудачей .
2. Найдите идентификатор сообщения в журнале обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
3. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Однако, чтобы узнать фактическую причину сбоев проверки работоспособности, прокрутите страницу выше этих распространенных сообщений об ошибках и проверьте наличие ошибок МОНИТОРА ЗДОРОВЬЯ.

   Например, следующее сообщение об ошибке HEALTH MONITOR указывает на то, что при выполнении запроса к API проверки работоспособности обработчик сообщений завершился с ошибкой «время ожидания соединения истекло»:

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

   Если эта ошибка повторяется MaxFailure количество раз, заданное в мониторе работоспособности, то вы увидите предупреждение следующего вида:

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

   Внимательно прочтите информацию, содержащуюся в предупреждающем сообщении. Убедитесь, что достигнут лимит MaxFailure для целевого сервера, используемого в конкретном API-прокси, для которого вы получаете код ответа 503 с кодом ошибки NoActiveTargets .

4. В приведенном выше примере проверка работоспособности завершилась с ошибкой " connection timed out истекло". Проверьте, можете ли вы подключиться к конкретному серверу бэкэнда напрямую из каждого из обработчиков сообщений, используя команду telnet :

telnet <BackendServer-HostName> 443
      

5. Если вам удаётся подключиться к бэкэнд-серверу, вы можете увидеть сообщение типа «Подключено к бэкэнд-серверу» . В таком случае проблема может быть временной и либо уже решена, либо носит периодический характер. Повторите шаг 4 несколько раз (более 10 раз) и проверьте результат.
1. Если команда telnet постоянно не выдает ошибок, значит, проблема решена. Проверьте еще раз, прекратились ли сбои проверки работоспособности. Если да, то никаких дальнейших действий не требуется.
2. Если вам периодически не удаётся подключиться к серверу через команду telnet , возможно, проблема в сети или ваш сервер занят.
6. Если вам не удаётся стабильно подключаться к серверу бэкэнда с помощью команды telnet , это может быть связано с тем, что трафик от обработчиков сообщений на данном сервере бэкэнда запрещён.

Разрешение

Если ошибка connection timed out наблюдается постоянно, убедитесь, что на бэкэнд-сервере нет ограничений брандмауэра и разрешен трафик от обработчиков сообщений Apigee Edge. Например, в Linux можно использовать iptables для разрешения трафика с IP-адресов обработчиков сообщений на бэкэнд-сервере.

Если проблема сохраняется, обратитесь к сетевому администратору для выявления и устранения неисправности. Если вам потребуется дополнительная помощь от Apigee, свяжитесь со службой поддержки Apigee .

Причина: Защищенный запрос на незащищенном порту.

Диагноз

1. Определите идентификатор сообщения запроса, который завершился неудачей .
2. Найдите идентификатор сообщения в журнале обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
3. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Однако, чтобы узнать фактическую причину сбоев проверки работоспособности, прокрутите страницу выше этих распространенных сообщений об ошибках и проверьте наличие ошибок МОНИТОРА ЗДОРОВЬЯ.

   Например, вы можете увидеть ошибку «Монитор здоровья», как показано ниже:

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

   Если эта ошибка повторяется MaxFailure количество раз, заданное в мониторе работоспособности, то вы увидите предупреждение следующего вида:

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

   Внимательно прочтите информацию, содержащуюся в предупреждающем сообщении. Убедитесь, что достигнут лимит MaxFailure для целевого сервера, используемого в конкретном API-прокси, для которого вы получаете код ответа 503 с кодом ошибки NoActiveTargets .

4. Проверка работоспособности завершилась с ошибкой:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   Сообщение об ошибке и URL-адрес указывают на то, что причиной проблемы является выполнение защищенного вызова (HTTPS) через незащищенный порт 80 .

   Эта ошибка может возникнуть в двух следующих случаях:

   • Защищенный целевой сервер определен с использованием незащищенного порта.
   • Защищенный целевой сервер определен, но монитор состояния настроен с использованием незащищенного порта.

   Защищенный целевой незащищенный порт

   Сценарий 1: Защищенный целевой сервер определен с использованием незащищенного порта.

   Если вы указали защищенный целевой сервер, но с незащищенным портом, например, 80, то вы получите эту ошибку. Выполните следующие шаги, чтобы проверить, является ли это причиной проблемы:

   1. Проверьте определение целевого сервера, используемого в конфигурации целевой конечной точки.

   Используйте API Get TargetServer для получения определения целевого сервера.

   Вывод определения целевого сервера

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

   В приведенном выше примере указано, что целевой сервер mocktarget является защищенным сервером, как это показано в блоке SSLInfo . Однако он настроен с использованием незащищенного порта 80.

   2. Теперь проверьте конфигурацию монитора работоспособности целевого сервера в конфигурации целевой конечной точки:

      Настройка монитора здоровья

      <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> . В этом случае обработчик сообщений Edge использует порт, указанный в определении целевого сервера (80), для выполнения вызовов API проверки работоспособности.

   3. Исходя из приведенной выше информации, причиной этой ошибки является то, что целевой сервер определен как защищенный сервер (поскольку включена блокировка SSLInfo ), но с незащищенным портом 80.

   Защищенный целевой незащищенный порт HM

   Сценарий 2: Защищенный целевой сервер определен, но монитор работоспособности настроен с использованием незащищенного порта.

   Если вы указали защищенный целевой сервер, но монитор работоспособности настроен на незащищенный порт, например, 80, то вы получите эту ошибку. Выполните следующие шаги, чтобы проверить, является ли это причиной проблемы:

   1. Проверьте определение целевого сервера, используемого в конфигурации целевой конечной точки.

      Используйте API Get TargetServer для получения определения целевого сервера.

      Вывод определения целевого сервера

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

      В приведенном выше примере определение показывает, что целевой сервер mocktarget является защищенным сервером, как указано в блоке SSLInfo .

   2. Далее проверьте конфигурацию монитора работоспособности целевого сервера в конфигурации целевой конечной точки:

      Настройка монитора здоровья

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

      В приведенном выше примере монитор состояния системы настроен на использование незащищенного порта 80, как указано элементом <Port> .

   3. Исходя из приведенной выше информации, причиной этой ошибки является то, что целевой сервер определен как защищенный сервер (поскольку блок SSLInfo включен) и использует защищенный порт 443, но монитор работоспособности настроен на выполнение проверок работоспособности с использованием незащищенного порта 80 (указанного в элементе <Port> ).

      То есть в этом случае Edge выполняет проверку работоспособности через API в защищенном режиме с использованием незащищенного порта 80 и выдает вышеупомянутую ошибку.

Разрешение

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

Причина: Небезопасный запрос на защищенном порту.

Диагноз

1. Определите идентификатор сообщения запроса, который завершился неудачей .
2. Найдите идентификатор сообщения в журнале обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
3. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Однако, чтобы узнать фактическую причину сбоев проверки работоспособности, прокрутите страницу выше этих распространенных сообщений об ошибках и проверьте наличие ошибок МОНИТОРА ЗДОРОВЬЯ.

   Например, вы можете увидеть ошибку «Монитор здоровья», как показано ниже:

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

   Если эта ошибка повторяется MaxFailure количество раз, заданное в мониторе работоспособности, то вы увидите предупреждение следующего вида:

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

   Внимательно прочтите информацию, содержащуюся в предупреждающем сообщении. Убедитесь, что достигнут лимит MaxFailure для целевого сервера, используемого в конкретном API-прокси, для которого вы получаете код ответа 503 с кодом ошибки NoActiveTargets .

4. Проверка работоспособности завершилась с ошибкой:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   Сообщение об ошибке и URL-адрес указывают на то, что причиной проблемы стал незащищенный вызов (HTTP) через защищенный порт 443 .

   Эта ошибка может возникнуть в двух следующих случаях:

   • Незащищенный целевой сервер, определенный с использованием защищенного порта.
   • Указан незащищенный целевой сервер, но монитор работоспособности настроен с использованием защищенного порта.

   Незащищенный целевой защищенный порт

   Сценарий 1: Незащищенный целевой сервер, определенный с использованием защищенного порта.

   Если вы указали незащищенный целевой сервер, но с защищенным портом, например, 443, то вы получите эту ошибку. Выполните следующие шаги, чтобы проверить, является ли это причиной проблемы:

   1. Проверьте определение целевого сервера, используемого в конфигурации целевой конечной точки.

      Используйте API Get TargetServer для получения определения целевого сервера.

      Вывод определения целевого сервера

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

      В приведенном выше примере указано, что целевой сервер mocktarget является незащищенным сервером, поскольку отсутствует блок SSLInfo . Однако он некорректно настроен с использованием защищенного порта 443.

   2. Теперь проверьте конфигурацию монитора работоспособности целевого сервера в конфигурации целевой конечной точки:

      Настройка монитора здоровья

      <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> . В этом случае обработчик сообщений Edge будет использовать порт, указанный в определении целевого сервера, а именно 443.

   3. Исходя из приведенной выше информации, причиной этой ошибки является то, что целевой сервер определен как незащищенный сервер (поскольку блок SSLInfo не определен), но с защищенным портом 443.

      То есть, Edge выполняет проверку работоспособности как незащищенный вызов через защищенный порт 443 и завершается с вышеупомянутой ошибкой.

   Незащищенный целевой защищенный порт HM

   Сценарий 2: Определен незащищенный целевой сервер, но монитор работоспособности настроен с использованием защищенного порта.

   Если вы указали незащищенный целевой сервер, но монитор работоспособности настроен на защищенный порт, например, 443, то вы получите эту ошибку. Выполните следующие шаги, чтобы проверить, является ли это причиной проблемы:

   1. Проверьте определение целевого сервера, используемого в конфигурации целевой конечной точки.

      Используйте API Get TargetServer для получения определения целевого сервера.

      Вывод определения целевого сервера

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

      В приведенном выше примере определение показывает, что целевой сервер mocktarget является незащищенным сервером (поскольку отсутствует блок SSLInfo ), корректно настроенным с использованием незащищенного порта 80.

   2. Далее проверьте конфигурацию монитора работоспособности целевого сервера в конфигурации целевой конечной точки:

      Настройка монитора здоровья

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

      В приведенном выше примере монитор состояния здоровья настроен на использование защищенного порта 443, как указано элементом <Port> .

   3. Исходя из приведенной выше информации, причиной этой ошибки является то, что целевой сервер правильно определен как незащищенный сервер (поскольку блок SSLInfo не определен) с незащищенным портом 80, но монитор работоспособности настроен на выполнение проверок работоспособности с использованием защищенного порта 443 (указанного в элементе <Port> ).

      То есть в этом случае Edge выполняет проверку работоспособности как незащищенный вызов через защищенный порт 443 и завершается с вышеупомянутой ошибкой.

Разрешение

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

Причина: API проверки работоспособности выдает ошибку.

Диагноз

1. Определите идентификатор сообщения запроса, который завершился неудачей .
2. Найдите идентификатор сообщения в журнале обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
3. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Однако, чтобы узнать фактическую причину сбоев проверки работоспособности, прокрутите страницу выше этих распространенных сообщений об ошибках и проверьте наличие ошибок/предупреждений системы мониторинга работоспособности.

   Например, вы можете увидеть предупреждение от системы мониторинга здоровья, как показано ниже:

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

   Если эта ошибка повторяется MaxFailure количество раз, заданное в мониторе работоспособности, то вы увидите предупреждение следующего вида:

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

   Внимательно прочтите информацию, содержащуюся в предупреждающем сообщении. Убедитесь, что достигнут лимит MaxFailure для целевого сервера, используемого в конкретном API-прокси, для которого вы получаете код ответа 503 с кодом ошибки NoActiveTargets .

4. В результате проверки состояния здоровья появилось предупреждающее сообщение:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   В приведенном выше предупреждении указано, что ожидаемый код ответа для API проверки работоспособности был 200 , но фактически получен ответ 404. Следовательно, это рассматривается как ошибка.

5. Прежде чем разбираться с причиной ошибки в ответе от API проверки работоспособности, выясните, почему Edge ожидает код ответа 200 для API проверки работоспособности. Для этого проверьте конфигурацию монитора работоспособности целевого сервера в конфигурации целевой конечной точки:

   Настройка монитора здоровья

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

   Обратите внимание, что в конфигурации монитора работоспособности код ответа 200 задан в элементе <SuccessResponse> . Это означает, что если Edge получит от API проверки работоспособности любой код ответа (например, 400, 401, 404, 500), отличный от 200, это будет расценено как ошибка, и счетчик ошибок увеличится.

6. Чтобы выяснить причину ошибки, возникшей в ответ на запрос проверки работоспособности API, выполните следующие шаги:
1. Просмотрите сообщение, предшествующее предупреждающему сообщению, в журнале обработчика сообщений.

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

   Запишите URL-адрес проверки состояния здоровья из этого сообщения.

2. Вы можете напрямую обратиться к этому URL-адресу из обработчика сообщений и проверить фактический ответ.

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

   В ответ на указанный выше вызов приходит ошибка 404, как видно из журналов обработчика сообщений:

   < HTTP/2 404
             

3. Это показывает, что даже прямой вызов URL-адреса проверки работоспособности завершается ошибкой с тем же кодом ответа 404. Это означает, что URL-адрес проверки работоспособности может быть некорректным или ресурс, к которому осуществляется доступ через этот URL-адрес, больше недоступен.
4. В приведенном выше примере проверки работоспособности API проблема возникает из-за использования некорректного URL-адреса в конфигурации монитора работоспособности. Правильный URL-адрес был найден в API Mock Target: https://mocktarget.apigee.net:443/statuscode/200 .
7. Если вы получили какой-либо другой ответ об ошибке, определите его причину, выполнив описанные выше шаги. При необходимости обратитесь к вашей команде разработчиков бэкэнда.

Разрешение

1. Устраните проблему с API проверки работоспособности на вашем бэкэнд-сервере.
2. Чтобы исправить проблему, описанную в примере выше:
1. Измените элемент <Path> в конфигурации монитора состояния на /statuscode/200 , как показано ниже:

   <Path>/statuscode/200</Path>
           

2. Сохраните изменения в API-прокси.

Если проблема сохраняется, перейдите к разделу «Необходимо собрать диагностическую информацию» .

Диагностика проблем с помощью мониторинга API.

Мониторинг API позволяет быстро выявлять проблемные области для диагностики ошибок, проблем с производительностью и задержкой, а также определять их источник, например, приложения разработчиков, API-прокси, целевые серверы или API-платформу.

Рассмотрим пример сценария , демонстрирующий, как устранять проблемы 5xx в ваших API с помощью мониторинга API. Например, вы можете настроить оповещение, которое будет отправляться, когда количество ошибок messaging.adaptors.http.flow.NoActiveTargets превысит определенный порог.

Необходимо собрать диагностическую информацию.

Если проблема сохраняется даже после выполнения вышеуказанных инструкций, пожалуйста, соберите следующую диагностическую информацию. Свяжитесь со службой поддержки Apigee и предоставьте её:

1. Если вы являетесь пользователем публичного облака, предоставьте следующую информацию:
1. Название организации
2. Название среды
3. Имя API-прокси
4. Выполните команду curl для воспроизведения ошибки.
5. Файл трассировки, содержащий запросы с кодом ошибки 503 Service Unavailable и кодом ошибки NoActiveTargets.
2. Если вы являетесь пользователем частного облака, предоставьте следующую информацию:
   1. Полное сообщение об ошибке.
   2. Название среды
   3. Пакет API-прокси
   4. Файл трассировки, содержащий запросы с кодом ошибки 503 Service Unavailable и кодом ошибки NoActiveTargets.
   5. Журналы доступа NGINX

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

   6. Журналы обработки сообщений

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