503 Service AVAILABLE - NoActiveTargets - HealthCheckFailures

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Videos

Mira los siguientes videos para obtener más información sobre los errores 503:

Síntoma

La aplicación cliente recibe el código de estado de respuesta HTTP 503 con el mensaje Servicio no disponible y el código de error NoActiveTargets para las solicitudes de 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 Available con el código de error NoActiveTargets cuando usas uno o más servidores de destino en la configuración de extremo de destino en tu proxy de API.

En esta guía, se explica el error 503 Service AVAILABLE (Servicio no disponible) con el código de error NoActiveTargets causado por fallas de verificación de estado. Consulta esta guía para obtener información sobre otras causas de este error.

Fallas de verificación de estado

Las fallas de la verificación de estado se observarán solo si configuraste un supervisor de estado como parte de la configuración del balanceo de cargas del servidor de destino en el extremo de destino del proxy de la 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>), Message Processor registra el mensaje de advertencia como se muestra a continuación en su archivo de registro:

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

Después, Edge deja de enviar más solicitudes a ese servidor específico. Una vez que todos los servidores de destino configurados en la configuración LoadBalancer alcanzan el recuento de MaxFailure, las solicitudes a la API posteriores se responden con el mensaje 503 Service available con el código de error NoActiveTargets.

El uso del monitor de estado ayuda a Apigee Edge a incluir de forma automática un servidor de destino en la rotación cuando este se encuentra en buen estado, sin tener que volver a implementar el proxy de API.

Estas son las posibles causas de las fallas de 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 conectarse con el servidor de backend, verás algunos mensajes de error comunes en los registros de Message Processor. Estos errores se registran después del mensaje real de excepción o error que produjo el error.

Estos son los mensajes de error comunes que se observan en los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para el error 503 Service AVAILABLE con el código de error 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>

Estos mensajes de error indican que no se pudo enviar la solicitud al servidor de backend debido a un error. Como resultado, Message Processor envía 503 Service Available 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 los mensajes de error comunes correspondientes al ID del mensaje. Sin embargo, para obtener la causa real de las fallas de verificación de estado, desplázate sobre estos mensajes de error comunes y comprueba si hay errores de HEALTH MONITOR.

   Por ejemplo, el siguiente mensaje de error de HEALTH MONITOR indica que Message Processor falló y se agotó el tiempo de espera de la conexión cuando se realizaba 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 veces la 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 : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Lee detenidamente la información incluida en el mensaje de advertencia. Asegúrate de que se haya alcanzado el recuento de MaxFailure para un servidor de destino usado en el proxy de API específico para el que experimentas 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. Verifica si puedes conectarte al servidor de backend específico directamente desde cada uno de los procesadores de mensajes con el comando telnet:

telnet <BackendServer-HostName> 443
      

5. Si puedes conectarte al servidor de backend, es posible que veas un mensaje como Conectado a backend-server. Entonces, el problema puede ser temporal y podría resolverse o ser un problema intermitente. Repite el paso 4 varias veces (10 veces o más) y verifica el resultado.
1. Si no hay errores con el comando telnet de forma constante, el problema está resuelto. Vuelve a comprobar si se detuvieron las fallas de 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 el servidor de backend esté ocupado.
6. Si no puedes conectarte al servidor de backend con el comando telnet de forma coherente, es posible que se deba a que no se permite el tráfico desde Message Processor en el servidor de backend específico.

Resolución

Si el error connection timed out se observa de manera coherente, asegúrate de que el servidor de backend no tenga ninguna restricción de firewall y que permita el tráfico desde los procesadores de mensajes de Apigee Edge. Por ejemplo, en Linux, puedes usar iptables para permitir el tráfico de las direcciones IP del procesador de mensajes en el servidor de backend.

Si el problema persiste, consulta al 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 del mensaje. Sin embargo, para obtener la causa real de las fallas de verificación de estado, desplázate por encima de estos mensajes de error comunes y comprueba si hay errores de HEALTH MONITOR.

   Por ejemplo, es posible que veas un error de HEALTH MONITOR como 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 veces la 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 se haya alcanzado el recuento de MaxFailure para un servidor de destino usado en el proxy de API específico para el que experimentas 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 de este problema porque se realizó una llamada segura (HTTPS) en el puerto no seguro 80.

   Este error puede ocurrir en las siguientes dos situaciones:

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

   Puerto no seguro de destino 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 80, verás este error. Sigue estos pasos para verificar si esta es la causa del problema:

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

   Usa 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 seguro, como lo indica el bloque SSLInfo. Sin embargo, está configurado con un puerto no seguro 80.

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

      Configuración del monitor 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 la configuración del monitor de estado anterior. En este caso, el procesador de mensajes de Edge usa el puerto especificado 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 (ya que el bloque SSLInfo está habilitado), pero con un puerto 80 no seguro.

   Puerto HM no seguro de destino seguro

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

   Si definiste un servidor de destino seguro, pero el monitor de estado está configurado con un puerto no seguro, como 80, verá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 usó en la configuración del extremo de destino.

      Usa 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 para el servidor de destino en la configuración del extremo de destino:

      Configuración del monitor 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 define como un servidor seguro (cuando el bloque SSLInfo está habilitado) y usa el puerto seguro 443, pero el monitor de estado está configurado para realizar verificaciones de estado con un puerto 80 no seguro (especificado en el elemento <Port>).

      Es decir, en este caso, Edge establece las APIs de verificación de estado como una llamada segura con el puerto no seguro 80 y falla con el error mencionado anteriormente.

Resolució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 los mensajes de error comunes correspondientes al ID del mensaje. Sin embargo, para obtener la causa real de las fallas de verificación de estado, desplázate por encima de estos mensajes de error comunes y comprueba si hay errores de HEALTH MONITOR.

   Por ejemplo, es posible que veas un error de HEALTH MONITOR como 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 veces la 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 se haya alcanzado el recuento de MaxFailure para un servidor de destino usado en el proxy de API específico para el que experimentas 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 que la causa de este problema es que 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 un puerto seguro

   Si definiste un servidor de destino no seguro, pero con un puerto seguro, como 443, verás este error. Sigue estos pasos para verificar si esta es la causa del problema:

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

      Usa 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, está configurada de manera incorrecta con un puerto seguro 443.

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

      Configuración del monitor 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 la configuración del monitor de estado anterior. En este caso, el procesador de mensajes de 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 define como un servidor no seguro (ya que el bloque SSLInfo no está definido), 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 seguro de destino 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, verás este error. Sigue estos pasos para verificar si esta es la causa del problema:

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

      Usa 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 no seguro (ya que no hay un bloque SSLInfo) configurado con un puerto no seguro 80 correctamente.

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

      Configuración del monitor 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 está definido como un servidor no seguro (ya que el bloque SSLInfo no está definido) con el puerto no seguro 80 correctamente, pero el monitor 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.

Resolució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 del mensaje. Sin embargo, para obtener la causa real de las fallas de verificación de estado, desplázate por encima de estos mensajes de error comunes y comprueba si hay 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 veces la 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 se haya alcanzado el recuento de MaxFailure para un servidor de destino usado en el proxy de API específico para el que experimentas 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
         

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

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

   Configuración del monitor 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>
           

   Ten en cuenta 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, 500) distinto de 200 de la API de verificación de estado, se considerará 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 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 proporciona un error 404, como se muestra 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 es posible que la URL de verificación de estado sea incorrecta o que el recurso al que se accede como parte de la URL ya no esté disponible.
4. En la API de verificación de estado de ejemplo que se proporcionó anteriormente, el problema se produce porque se usó una URL incorrecta en la configuración del supervisor de estado. Se descubrió que la URL correcta es https://mocktarget.apigee.net:443/statuscode/200 en la API de Mock Target.
7. Si recibes alguna otra respuesta de error, sigue los pasos anteriores para determinar su causa. Si es necesario, trabaja con tu equipo de backend.

Resolució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 Debes recopilar información de diagnóstico.

Diagnostica problemas con la supervisión de APIs

La supervisión de las API te permite aislar las áreas problemáticas con rapidez a fin de diagnosticar problemas de errores, rendimiento y latencia y su fuente, como las apps para desarrolladores, los proxies de API, los objetivos de backend o la plataforma de la API.

Analiza una situación de muestra en la que se demuestra cómo solucionar problemas 5xx de tus APIs con la supervisión de APIs. Por ejemplo, es posible que desees configurar una alerta para recibir una notificación cuando la cantidad de fallas messaging.adaptors.http.flow.NoActiveTargets supere un umbral determinado.

Se debe recopilar información de diagnóstico

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

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 de proxy de API
4. Completa el comando curl para reproducir el error
5. Archivo de seguimiento que contiene las solicitudes con el error 503 Service Available con el código de error NoActiveTargets
2. Si eres usuario de una 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 el error 503 Service Available 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)