503 Service Unavailable - NoActiveTargets - HealthCheckFailures

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

Видео

Чтобы узнать больше об ошибках 503, посмотрите следующие видео:

Symptom

Клиентское приложение получает код статуса 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.

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

Ниже перечислены возможные причины сбоев при проверке состояния.

Распространенные этапы диагностики

Как определить идентификатор сообщения для запроса, который не удалось выполнить

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

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

Распространенные сообщения об ошибках, которые можно найти в журналах Message Processor (/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>

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

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

диагностика;

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

   Например, следующее сообщение об ошибке HEALTH MONITOR указывает на то, что Message Processor не смог выполнить запрос к 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}
           

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

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. Найдите идентификатор сообщения в журнале Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Чтобы узнать причину сбоев при проверке состояния, прокрутите страницу вверх и найдите сообщения об ошибках, связанные с мониторингом состояния.

   Например, может появиться ошибка 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}
           

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

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. Проверьте определение целевого сервера, используемого в конфигурации целевой конечной точки.

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

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

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

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

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

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

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

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

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

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

      <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. Найдите идентификатор сообщения в журнале Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Вы увидите распространенные сообщения об ошибках, соответствующие идентификатору сообщения. Чтобы узнать причину сбоев при проверке состояния, прокрутите страницу вверх и найдите сообщения об ошибках, связанные с мониторингом состояния.

   Например, может появиться ошибка 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}
             

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

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. Проверьте определение целевого сервера, используемого в конфигурации целевой конечной точки.

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

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

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

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

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

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

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

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

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

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

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

      <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. Найдите идентификатор сообщения в журнале Message Processor (/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}
           

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

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. Чтобы выяснить причину ошибки, следуйте инструкциям ниже.
1. Посмотрите сообщение, которое предшествует предупреждению в журнале обработчика сообщений.

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

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

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

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

   Ответ на вызов выше содержит код ошибки 404, как показано в журналах Message Processor:

   < HTTP/2 404
             

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

Разрешение

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

   <Path>/statuscode/200</Path>
           

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

Если проблема не устранена, перейдите к разделу Сбор диагностической информации.

Как диагностировать проблемы с помощью мониторинга API

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

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

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

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

1. Если вы используете общедоступное облако, предоставьте следующую информацию:
1. Название организации
2. Название среды
3. Название прокси API
4. Полная команда curl для воспроизведения ошибки
5. Файл трассировки, содержащий запросы с ошибкой "503: сервис недоступен" и кодом ошибки NoActiveTargets
2. Если вы используете частное облако, предоставьте следующую информацию:
   1. Полное сообщение об ошибке
   2. Название среды
   3. Пакет прокси API
   4. Файл трассировки, содержащий запросы с ошибкой "503: сервис недоступен" и кодом ошибки 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)