503 Service AVAILABLE - NoActiveTargets - HealthCheckFailures

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Videos

Para obtener más información sobre los errores 503, consulta los siguientes videos:

Síntoma

La aplicación cliente recibe el código de estado de respuesta HTTP 503 con el el mensaje Service Unavailable y el código de error NoActiveTargets para las solicitudes del proxy de API.

Mensaje de error

Verás la siguiente respuesta de error:

HTTP/1.1 503 Service Unavailable
  

Verás el siguiente mensaje de error en la respuesta HTTP:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}
  

Causas posibles

Por lo general, se observa la respuesta HTTP 503 Service Unavailable con el código de error NoActiveTargets cuando usas uno o más servidores de destino en la configuración del extremo de destino en tu proxy de API.

En esta guía, se explica el mensaje 503 Service available con el código de error NoActiveTargets causó debido a fallas en la verificación de estado. Consulta esta guía para obtener más información sobre otras causas del error.

Fallas de verificación de estado

Las fallas de verificación de estado se observarán solo si configuraste una El supervisor de estado forma parte de la configuración del balanceo de cargas del servidor de destino en el extremo de destino de tu proxy de API.

Cuando un servidor de destino falla en una verificación de estado, Edge aumenta el recuento de fallas de ese servidor. Si la cantidad de fallas de verificación de estado de ese servidor alcanza el umbral predefinido (<MaxFailures>), El procesador de mensajes registra el mensaje de advertencia en su archivo de registro, como se muestra a continuación:

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}
    

El mensaje de advertencia proporciona la siguiente información. Esto te ayuda a comprender qué servidor de destino alcanzó el recuento de MaxFailure:

• Nombre del servidor de destino
• Nombres de organizaciones y entornos
• Nombre del proxy de API
• Nombre del extremo de destino

Luego, Edge deja de enviar más solicitudes a ese servidor específico. Una vez que se cree los servidores configurados en la configuración LoadBalancer alcanzan el recuento de MaxFailure, el Las solicitudes a la API se responden con el mensaje 503 Service Unavailable con el código de error NoActiveTargets.

Usar Health Monitor ayuda a Apigee Edge a incluir automáticamente un servidor de destino en el la rotación cuando está en buen estado, sin tener que volver a implementar el proxy de API.

Estas son las posibles causas de las fallas de la verificación de estado:

Pasos comunes de diagnóstico

Determina el ID de mensaje de la solicitud con errores

Mensajes de error habituales

Cuando se usan los servidores de destino y se produce un error mientras Message Processor intenta conectarte con el servidor de backend, luego verás algunos mensajes de error comunes en el Registros del procesador de mensajes. Estos errores se registran después del mensaje real de excepción o error que causó el error.

Los mensajes de error comunes observados en los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para el 503 Servicio no disponible con el código de error NoActiveTargets son los siguientes:

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>

Estos mensajes de error indican que no se pudo enviar la solicitud al servidor backend debido a falla. Como resultado, Message Processor envía el mensaje 503 Service Unavailable con el código de error NoActiveTargets como respuesta al cliente.

Causa: Se agotó el tiempo de espera de la conexión

Diagnóstico

1. Determina el ID del mensaje de la solicitud con errores.
2. Busca el ID del mensaje en el registro de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verás el botón mensajes de error comunes correspondientes al ID del mensaje. Sin embargo, para conocer la causa real de las fallas de la verificación de estado, desplázate sobre estos mensajes de error comunes y buscar errores de HEALTH MONITOR.

   Por ejemplo, el siguiente mensaje de error de HEALTH MONITOR indica que el Message Processor falló Se produjo un error que indica que se agotó el tiempo de espera de la conexión cuando se realiza la solicitud a la API de verificación de estado:

   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>
           

   Si este error se repite durante MaxFailure cantidad de veces configurada en el Monitor de estado, ocurrirá lo siguiente: verás un mensaje de advertencia como el siguiente:

   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}
           

   Lee detenidamente la información incluida en el mensaje de advertencia. Asegúrate de que MaxFailure se alcanzó para un servidor de destino utilizado en el proxy de API específico para el cual el código de respuesta 503 con el código de error NoActiveTargets.

4. En el ejemplo anterior, la verificación de estado falló con el error connection timed out. Comprueba si puedes conectarte al servidor de backend específico directamente desde cada una de las Procesadores de mensajes con el comando telnet:

telnet <BackendServer-HostName> 443
      

5. Si puedes conectarte al servidor backend, es posible que veas un mensaje como Conectado a backend-server. Entonces, es posible que el problema sea temporal puede estar resuelto o es un problema intermitente. Repite el paso 4 varias veces (más de 10 veces) y verifica el resultado.
1. Si no hay errores con el comando telnet de forma coherente, el problema es resuelto. Vuelve a comprobar si se detuvieron las fallas de la verificación de estado. Si es así, no tienes que hacer nada más.
2. Si no puedes conectarte al servidor de backend con el comando telnet de forma intermitente, es posible que haya un problema de red o que tu servidor backend esté ocupado.
6. Si no puedes conectarte al servidor de backend con el comando telnet de forma coherente, puede deberse a que no se permite el tráfico de Message Processor en el servidor de backend específico.

Solución

Si el error connection timed out se observa de forma coherente, asegúrate de que el backend no tiene restricciones de firewall y permite el tráfico de los procesadores de mensajes de Apigee Edge. Por ejemplo, en Linux, puedes usar iptables para permitir el tráfico desde la Envía mensajes a las direcciones IP del procesador de mensajes en el servidor de backend.

Si el problema persiste, trabaja con el administrador de red para determinarlo y corregirlo. Si necesitas más ayuda de Apigee, comunícate con el equipo de asistencia de Apigee.

Causa: Solicitud segura en un puerto no seguro

Diagnóstico

1. Determina el ID del mensaje de la solicitud con errores.
2. Busca el ID del mensaje en el registro de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verás los mensajes de error comunes correspondientes al ID de mensaje. Sin embargo, para conocer la causa real de las fallas de la verificación de estado, desplázate sobre estos mensajes de error comunes y buscar errores de HEALTH MONITOR.

   Por ejemplo, es posible que veas un error de HEALTH MONITOR como el que se muestra a continuación:

   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>
           

   Si este error se repite durante MaxFailure cantidad de veces configurada en el Monitor de estado, verás un mensaje de advertencia como el siguiente:

   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}
           

   Lee detenidamente la información incluida en el mensaje de advertencia. Asegúrate de que MaxFailure se alcanzó para un servidor de destino utilizado en el proxy de API específico para el cual el código de respuesta 503 con el código de error NoActiveTargets.

4. La verificación de estado falló con el siguiente error:

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

   El mensaje de error y la URL indican la causa del problema porque un Se realizó una llamada segura (HTTPS) en el puerto no seguro 80.

   Este error puede ocurrir en las siguientes dos situaciones:

   • El servidor de destino seguro definido con un puerto no seguro
   • Se definió el servidor de destino seguro, pero el Monitor de estado está configurado con un puerto no seguro

   Puerto de destino seguro no seguro

   Situación 1: Servidor de destino seguro definido con un puerto no seguro

   Si definiste un servidor de destino seguro, pero con un puerto no seguro, como el 80, obtendrás este error. Sigue los pasos que se indican a continuación para verificar si esta es la causa del problema:

   1. Verifica la definición del servidor de destino que se usa en la configuración del extremo de destino.

   Usa el Obtener la API de TargetServer para obtener la definición del servidor de destino.

   Resultado de la definición del servidor de destino

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

   En el ejemplo anterior, la definición muestra que el servidor de destino mocktarget es un servidor como lo indica el bloque SSLInfo. Sin embargo, está configurada con un puerto 80 no seguro.

   2. Ahora, verifica la configuración del supervisor de estado del servidor de destino en la configuración del extremo de destino:

      Configuración del supervisor de estado

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

      Ten en cuenta que no se especificó ningún elemento <Port> en el Configuración del supervisor de estado anterior. En este caso, el Message Processor del Edge usa el puerto especificadas en la definición del servidor de destino (que es 80) para realizar llamadas a la API de verificación de estado.

   3. Según la información anterior, la causa de este error es que el servidor de destino está definido como un servidor seguro (como el bloque SSLInfo está habilitado), pero con un puerto 80 no seguro.

   Puerto HM de destino seguro no seguro

   Situación 2: Se definió un servidor de destino seguro, pero el Monitor de estado está configurado con un puerto no seguro

   Si definiste un servidor de destino seguro, pero el supervisor de estado está configurado con un un puerto no seguro, como el 80, aparecerá este error. Sigue los pasos que se indican a continuación para realizar la verificación. si esa es la causa del problema:

   1. Verifica la definición del servidor de destino que se usa en la configuración del extremo de destino.

      Utiliza el Obtén la API de TargetServer para obtener la definición del servidor de destino.

      Resultado de la definición del servidor de destino

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

      En el ejemplo anterior, la definición muestra que el servidor de destino mocktarget es un servidor seguro, como lo indica el bloque SSLInfo.

   2. A continuación, verifica la configuración del supervisor de estado del servidor de destino en la configuración del extremo de destino:

      Configuración del supervisor de estado

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

      En el ejemplo anterior, el monitor de estado se configura con un puerto 80 no seguro, como lo indica el elemento <Port>.

   3. Según la información anterior, la causa de este error es que el servidor de destino se definió como un servidor seguro (como el bloque SSLInfo está habilitado) y usa el puerto seguro 443, pero el Monitoreo esté configurada para realizar verificaciones de estado con un puerto no seguro 80 (especificado en el elemento <Port>).

      Es decir, en este caso, Edge hace que las APIs de verificación de estado sean una llamada segura con el puerto 80 y falla con el error mencionado anteriormente.

Solución

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

Causa: solicitud no segura en un puerto seguro

Diagnóstico

1. Determina el ID del mensaje de la solicitud con errores.
2. Busca el ID del mensaje en el registro de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verás el botón mensajes de error comunes correspondientes al ID del mensaje. Sin embargo, para conocer la causa real de las fallas de la verificación de estado, desplázate sobre estos mensajes de error comunes y buscar errores de HEALTH MONITOR.

   Por ejemplo, es posible que veas un error de HEALTH MONITOR como el que se muestra a continuación:

   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>
             

   Si este error se repite durante MaxFailure cantidad de veces configurada en el Monitor de estado, verás un mensaje de advertencia como el siguiente:

   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}
             

   Lee detenidamente la información incluida en el mensaje de advertencia. Asegúrate de que MaxFailure se alcanzó para un servidor de destino utilizado en el proxy de API específico para el cual el código de respuesta 503 con el código de error NoActiveTargets.

4. La verificación de estado falló con el siguiente error:

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

   El mensaje de error y la URL indican la causa del problema porque un Se realizó una llamada no segura (HTTP) en el puerto seguro 443.

   Este error puede ocurrir en las siguientes dos situaciones:

   • Servidor de destino no seguro definido con puerto seguro
   • Se definió un servidor de destino no seguro, pero el Monitor de estado está configurado con un puerto seguro

   Puerto seguro de destino no seguro

   Situación 1: Servidor de destino no seguro definido con puerto seguro

   Si definiste un servidor de destino no seguro, pero con un puerto seguro, como 443, recibes este error. Sigue los pasos que se indican a continuación para verificar si esta es la causa del problema:

   1. Verifica la definición del servidor de destino que se usa en la configuración del extremo de destino.

      Utiliza el Obtén la API de TargetServer para obtener la definición del servidor de destino.

      Resultado de la definición del servidor de destino

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

      En el ejemplo anterior, la definición muestra que el servidor de destino mocktarget es un servidor no seguro, ya que no hay un bloque SSLInfo. Sin embargo, es incorrecta configurada con un puerto seguro 443.

   2. Ahora, verifica la configuración del supervisor de estado del servidor de destino en la configuración del extremo de destino:

      Configuración del supervisor de estado

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

      Observa que no se especificó ningún elemento <Port> en el Monitor de estado configuración anterior. En este caso, el Message Processor del Edge usará el puerto especificado en la definición del servidor de destino, que es 443.

   3. Según la información anterior, la causa de este error es que el servidor de destino se definió como un servidor no seguro (como no se define el bloque SSLInfo), pero con un puerto seguro 443.

      Es decir, Edge realiza las verificaciones de estado como una llamada no segura con el puerto seguro 443 y falla. con el error mencionado anteriormente.

   Puerto HM de destino seguro no seguro

   Situación 2: Se definió un servidor de destino no seguro, pero el Monitor de estado se configuró con un puerto seguro

   Si definiste un servidor de destino no seguro, pero el Monitor de estado está configurado con un puerto seguro, como 443, recibes este error. Sigue los pasos que se indican a continuación para verificar si esta es la causa del problema:

   1. Verifica la definición del servidor de destino que se usa en la configuración del extremo de destino.

      Utiliza el Obtén la API de TargetServer para obtener la definición del servidor de destino.

      Resultado de la definición del servidor de destino

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

      En el ejemplo anterior, la definición muestra que el servidor de destino mocktarget es un servidor (ya que no hay ningún bloque SSLInfo) configurado con un puerto no seguro 80 correctamente.

   2. A continuación, verifica la configuración del supervisor de estado del servidor de destino en la configuración del extremo de destino:

      Configuración del supervisor de estado

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

      En el ejemplo anterior, el monitor de estado se configura con un puerto seguro 443 como lo indica el elemento <Port>.

   3. Según la información anterior, la causa de este error es que el servidor de destino se definió como un servidor no seguro (ya que el bloque SSLInfo no está definido) con el puerto no seguro 80 correctamente, pero el supervisor de estado está configurado para realizar verificaciones de estado con un puerto seguro 443 (especificado en el elemento <Port>).

      Es decir, en este caso, Edge realiza las verificaciones de estado como una llamada no segura con el puerto seguro 443 y falla con el error mencionado anteriormente.

Solución

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

Causa: La API de verificación de estado responde con un error.

Diagnóstico

1. Determina el ID del mensaje de la solicitud con errores.
2. Busca el ID del mensaje en el registro de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verás los mensajes de error comunes correspondientes al ID de mensaje. Sin embargo, para conocer la causa real de las fallas de la verificación de estado, desplázate sobre estos mensajes de error comunes y busca errores o advertencias de HEALTH MONITOR.

   Por ejemplo, es posible que veas una advertencia de HEALTH MONITOR como la que se muestra a continuación:

   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
           

   Si este error se repite durante MaxFailure cantidad de veces configurada en el Monitor de estado, verás un mensaje de advertencia como el siguiente:

   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}
           

   Lee detenidamente la información incluida en el mensaje de advertencia. Asegúrate de que MaxFailure se alcanzó para un servidor de destino utilizado en el proxy de API específico para el cual el código de respuesta 503 con el código de error NoActiveTargets.

4. La verificación de estado mostró el siguiente mensaje de advertencia:

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

   El mensaje de advertencia anterior indica que el código de respuesta esperado para la API de verificación de estado era 200, pero la respuesta real recibida es 404. Por lo tanto, esto se considera un error.

5. Antes de investigar la causa de una respuesta de error de la API de verificación de estado, determina por qué Edge se espera que el código de respuesta sea 200 para la API de verificación de estado. Para ello, revisa el Monitor de estado del servidor de destino en la configuración del extremo de destino:

   Configuración del supervisor de estado

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

   Observa que la configuración del Monitor de estado se establece con el código de respuesta 200 en el elemento <SuccessResponse>. Esto significa que, si Edge obtiene algún código de respuesta (como 400, 401, 404 o 500) distinto de 200 de la API de verificación de estado, se tratará como un error y aumentará el recuento de fallas.

6. Ahora, para investigar la causa de la respuesta de error de la API de verificación de estado, sigue los pasos que se indican a continuación:
1. Mira el mensaje que aparece antes del mensaje de advertencia en el registro de Message Processor.

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

   Toma nota de la URL de verificación de estado de este mensaje.

2. Puedes realizar una llamada directa a esta URL desde Message Processor y verificar la respuesta real

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

   La respuesta de la llamada anterior muestra un error 404, como se ve en los registros de Message Processor:

   < HTTP/2 404
             

3. Esto muestra que incluso la llamada directa a la URL de verificación de estado falla con el mismo código de respuesta 404. Esto significa que la URL de verificación de estado puede ser incorrecta o que el recurso al que se accede como parte de la URL ya no está disponible.
4. En el ejemplo de la API de verificación de estado que se proporcionó anteriormente, el problema se produce porque se usó una URL incorrecta en la configuración del supervisor de estado. Se encontró que la URL correcta es https://mocktarget.apigee.net:443/statuscode/200 de API de destino ficticio.
7. Si obtienes cualquier otra respuesta de error, sigue los pasos que se indican a continuación para determinar la causa del mismo motivo. pasos anteriores. Si es necesario, trabaja con tu equipo de backend.

Solución

1. Soluciona el problema con la API de verificación de estado en tu servidor de backend.
2. Para solucionar el problema en el ejemplo anterior, haz lo siguiente:
1. Modifica el elemento <Path> en la configuración del Monitor de estado a /statuscode/200 como se muestra a continuación:

   <Path>/statuscode/200</Path>
           

2. Guarda los cambios en el proxy de API.

Si el problema persiste, ve a Se debe recopilar información de diagnóstico.

Diagnostica problemas con la supervisión de API

La supervisión de API permite aislar problemas áreas con rapidez para diagnosticar problemas de errores, latencia y rendimiento, y su fuente, como los proxies de API, destinos de backend o la plataforma de API.

Analizar una situación de ejemplo que demuestra cómo solucionar problemas 5xx con tus APIs con la supervisión de API. Por ejemplo: te recomendamos configurar una alerta para que se te notifique cuando la cantidad de messaging.adaptors.http.flow.NoActiveTargets de errores exceden un umbral en particular.

Se debe recopilar información de diagnóstico

Si el problema persiste, incluso después de seguir las instrucciones anteriores, reúne la siguiente y la información de diagnóstico. Comunícate con el equipo de asistencia de Apigee y compártelas:

1. Si eres usuario de la nube pública, proporciona la siguiente información:
1. Nombre de la organización
2. Nombre del entorno
3. Nombre del proxy de la API
4. Completar el comando curl para reproducir el error
5. Archivo de seguimiento que contiene las solicitudes con 503 Service Unavailable con el código de error NoActiveTargets
2. Si eres usuario de la nube privada, proporciona la siguiente información:
   1. Se observó un mensaje de error completo
   2. Nombre del entorno
   3. Paquete de proxy de API
   4. Archivo de seguimiento que contiene las solicitudes con 503 Service Unavailable con el código de error NoActiveTargets
   5. Registros de acceso de NGINX

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

   6. Registros del procesador de mensajes

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