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

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

Видео

Дополнительные сведения об ошибках 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 :

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

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

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

Вот возможные причины сбоев проверки работоспособности:

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

Определите идентификатор сообщения неудачного запроса.

Распространенные сообщения об ошибках

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

Общие сообщения об ошибках, наблюдаемые в журналах процессора сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) для службы 503, недоступной с кодом ошибки 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.

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

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

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

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

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

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. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Однако, чтобы узнать реальную причину сбоев проверки работоспособности, прокрутите выше этих распространенных сообщений об ошибках и проверьте наличие ошибок HEALTH MONITOR.

   Например, вы можете увидеть ошибку HEALTH MONITOR, как показано ниже:

   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 .

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

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

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

   Сценарий 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. Теперь проверьте конфигурацию 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>
                

      Обратите внимание, что в приведенной выше конфигурации Health Monitor не указан элемент <Port> . В этом случае процессор сообщений Edge использует порт, указанный в определении целевого сервера (80), для выполнения вызовов API проверки работоспособности.

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

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

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

   Если вы определили безопасный целевой сервер, но Health Monitor настроен на незащищенный порт, например 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. Затем проверьте конфигурацию Health Monitor для целевого сервера в конфигурации целевой конечной точки:

      Конфигурация монитора работоспособности

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

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

   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. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Однако, чтобы узнать реальную причину сбоев проверки работоспособности, прокрутите выше этих распространенных сообщений об ошибках и проверьте наличие ошибок HEALTH MONITOR.

   Например, вы можете увидеть ошибку HEALTH MONITOR, как показано ниже:

   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-адрес указывают, что причина этой проблемы заключается в том, что через защищенный порт 443 был выполнен незащищенный вызов (HTTP).

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

   • Незащищенный целевой сервер, определенный с безопасным портом
   • Определен незащищенный целевой сервер, но Health Monitor настроен с безопасным портом

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

   Сценарий 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. Теперь проверьте конфигурацию 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>
                      

      Обратите внимание, что в приведенной выше конфигурации Health Monitor не указан элемент <Port> . В этом случае процессор сообщений Edge будет использовать порт, указанный в определении целевого сервера, который равен 443.

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

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

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

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

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

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

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

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

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

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

   2. Затем проверьте конфигурацию Health Monitor для целевого сервера в конфигурации целевой конечной точки:

      Конфигурация монитора работоспособности

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

      В приведенном выше примере Health Monitor настроен на безопасный порт 443, как указано элементом <Port> .

   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. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Однако, чтобы узнать фактическую причину сбоев проверки работоспособности, прокрутите выше этих распространенных сообщений об ошибках и проверьте наличие ошибок/предупреждений HEALTH MONITOR.

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

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

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

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

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

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 проверки работоспособности. Для этого проверьте конфигурацию 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>
           

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

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 проверки работоспособности проблема возникает из-за того, что в конфигурации Health Monitor использовался неправильный URL-адрес. Правильный URL-адрес оказался https://mocktarget.apigee.net:443/statuscode/200 из Mock Target API .
7. Если вы получили какой-либо другой ответ об ошибке, определите ее причину, выполнив действия, описанные выше. При необходимости поработайте со своей серверной командой.

Разрешение

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

   <Path>/statuscode/200</Path>
           

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

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

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

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

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

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

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

1. Если вы являетесь пользователем Public Cloud, предоставьте следующую информацию:
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 var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

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

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