Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

503 Service AVAILABLE - NoActiveTargets - HealthCheckFailures

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Videos

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

Video	Descripción
Soluciona el error 503 de servicio no disponible: NoActiveTargets	Obtén más información sobre lo siguiente: Importancia de los servidores de destino y los monitores de estado Solución de problemas y resolución de un error en tiempo real 503 Servicio no disponible - NoActiveTargets causado por una falla en la verificación de estado

Síntoma

La aplicación cliente recibe el código de estado de respuesta HTTP 503 con 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, la respuesta HTTP 503 Service Unavailable con el código de error NoActiveTargets se observa cuando usas uno o más servidores de destino en la configuración del extremo de destino de tu proxy de API.

Este manual abarca el error 503 Service Unavailable con el código de error NoActiveTargets causado por fallas en la 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 en la verificación de estado solo se observarán si configuraste un monitor de estado como 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 en la verificación de estado para ese servidor alcanza el umbral predefinido (<MaxFailures>), el Message Processor registra el mensaje de advertencia que 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

A partir de ese momento, 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 de LoadBalancer alcanzan el recuento de MaxFailure, las solicitudes posteriores a la API reciben la respuesta 503 Servicio no disponible con el código de error NoActiveTargets.

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

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

Causa	Descripción	Quién puede realizar los pasos para solucionar problemas
Error de tiempo de espera de conexión	El Message Processor no puede conectarse al servidor de destino dentro del período de tiempo de espera especificado en la configuración del balanceador de cargas.	Usuarios de la nube privada de Edge
Solicitud segura en un puerto no seguro	Si el servidor de destino se define como un servidor seguro, pero se configuró de forma incorrecta con un puerto no seguro. Si el servidor de destino se define como un servidor seguro, pero el monitor de estado está configurado para realizar verificaciones de estado en un puerto no seguro.	Usuarios de la nube privada de Edge
Solicitud no segura en un puerto seguro	Si el servidor de destino se define como un servidor no seguro, pero se configuró incorrectamente con un puerto seguro. Si el servidor de destino se define como un servidor no seguro, pero el monitor de estado está configurado para realizar verificaciones de estado en un puerto seguro.	Usuarios de la nube privada de Edge
La API de Health Check responde con un error	Si la API de verificación de estado responde con un error o un código de respuesta, cualquier elemento que no sea el especificado en el elemento SuccessResponse del Monitoreo de estado	Usuarios de la nube privada de Edge

Pasos comunes de diagnóstico

Determina el ID del mensaje de la solicitud con errores

Herramienta de Trace

Para determinar el ID del mensaje de la solicitud con errores con la herramienta de seguimiento, haz lo siguiente:

Habilita la sesión de registro, realiza la llamada a la API y reproduce el problema: 503 Service Unavailable con el código de error NoActiveTargets.
Selecciona una de las solicitudes con errores.
Navega a la fase de AX y determina el ID del mensaje (X-Apigee.Message-ID) de la solicitud desplazándote hacia abajo en la sección Detalles de la fase, como se muestra en la siguiente figura.

Registros de acceso de NGINX

Para determinar el ID del mensaje de la solicitud con errores a través de los registros de acceso de NGINX, haz lo siguiente:

También puedes consultar los registros de acceso de NGINX para determinar el ID del mensaje de los errores 503. Esto es particularmente útil si el problema ocurrió en el pasado o si el problema es intermitente y no puedes capturar el registro en la IU. Sigue estos pasos para determinar esta información a partir de los registros de acceso de NGINX:

Verifica los registros de acceso de NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Busca si hay errores 503 para el proxy de API específico durante un período determinado (si el problema ocurrió en el pasado) o si aún hay solicitudes que fallan con el error 503.
Si hay errores 503 con X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, anota el ID del mensaje de una o más de esas solicitudes, como se muestra en el siguiente ejemplo:
Entrada de ejemplo que muestra el error 503

Mensajes de error habituales

Cuando se usan 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 de excepción o error real que provocó la falla.

Los mensajes de error comunes que se observan en los registros del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para el error 503 Service Unavailable 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 de backend debido a una falla. Como resultado, el Message Processor envía 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

Determina el ID del mensaje de la solicitud con errores.
Busca el ID del mensaje en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Verás los mensajes de error comunes correspondientes al ID del mensaje. Sin embargo, para conocer la causa real de las fallas en la verificación de estado, desplázate hacia arriba y busca los mensajes de error comunes y los errores de HEALTH MONITOR.
Por ejemplo, el siguiente mensaje de error de HEALTH MONITOR indica que Message Processor falló con un error de tiempo de espera agotado de la conexión cuando realizó 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 la cantidad de veces MaxFailure configurada en el monitor de estado, verás un mensaje de advertencia como este:
```
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 con atención la información que se proporciona en el mensaje de advertencia. Asegúrate de que se haya alcanzado el recuento de MaxFailure para un servidor de destino que se usa en el proxy de API específico para el que experimentas el código de respuesta 503 con el código de error NoActiveTargets.
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 uno de los procesadores de mensajes con el comando telnet:

telnet <BackendServer-HostName> 443

Si puedes conectarte al servidor de backend, es posible que veas un mensaje como Connected to backend-server. En ese caso, es posible que el problema sea temporal y que se haya resuelto o que sea intermitente. Repite el paso 4 varias veces (más de 10) y verifica el resultado.

Si no hay errores con el comando telnet de forma constante, el problema se resolvió. Vuelve a verificar si se detuvieron las fallas de la verificación de estado. Si es así, no tienes que hacer nada más.
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.

Si no puedes conectarte al servidor de backend con el comando telnet de forma constante, es posible que el tráfico no esté permitido desde los procesadores de mensajes en el servidor de backend específico.

Solución

Si el error connection timed out se observa de forma constante, asegúrate de que el servidor de backend no tenga restricciones de firewall y permita el tráfico de 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, trabaja con tu administrador de red para determinar y solucionar el problema. 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

Determina el ID del mensaje de la solicitud con errores.
Busca el ID del mensaje en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).

Verás los mensajes de error comunes correspondientes al ID del mensaje. Sin embargo, para conocer la causa real de las fallas en la verificación de estado, desplázate hacia arriba y busca los mensajes de error comunes y los 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 la cantidad de veces MaxFailure configurada en el monitor de estado, verás un mensaje de advertencia como este:

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 con atención la información que se proporciona en el mensaje de advertencia. Asegúrate de que se haya alcanzado el recuento de MaxFailure para un servidor de destino que se usa en el proxy de API específico para el que experimentas el código de respuesta 503 con el código de error NoActiveTargets.

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 que la causa de este problema es que 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 un puerto no seguro
- Se definió un servidor de destino seguro, pero el Monitor de estado se configuró con un puerto no seguro
Protege el puerto no seguro de destino

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, recibirá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.
2. Ahora, verifica la configuración del monitor de estado para el servidor de destino en la configuración del extremo de destino:
  Configuración de 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>
  Ten en cuenta que no se especifica ningún elemento <Port> en la configuración del verificador de estado anterior. En este caso, el Message Processor 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 se definió como un servidor seguro (ya que el bloque SSLInfo está habilitado), pero con un puerto 80 no seguro.
Protege el puerto HM no seguro del objetivo

Situación 2: Se definió un 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 el 80, recibirá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 la API de Get TargetServer para obtener la definición del servidor de destino.
  
  Salida 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 monitor de estado del servidor de destino en la configuración del extremo de destino:
  Configuración de 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>
  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 (ya que 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 no seguro 80 (especificado en el elemento <Port>).
  Es decir, en este caso, Edge realiza las APIs de verificación de estado como una llamada segura con el puerto 80 no seguro y falla con el error mencionado anteriormente.
  
  Nota: El elemento <Port> configurado en la supervisión de estado tiene prioridad sobre el puerto que se usa en la definición del servidor de destino.

Solución

Protege el puerto no seguro de destino

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

Para corregir este error, actualiza la definición del servidor de destino para que use un puerto seguro adecuado.

Usa la API de Update a TargetServer para actualizar la definición del servidor de destino y asegúrate de que se use un puerto seguro (por ejemplo, 443) , como se muestra en el siguiente ejemplo:

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

Protege el puerto HM no seguro del objetivo

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

Para corregir este error, sigue las instrucciones que se indican a continuación:

Modifica la configuración del Monitor de estado para usar un puerto seguro (por ejemplo, el 443) para realizar verificaciones de estado del servidor de destino en la configuración del extremo de destino del proxy de API con errores, como se muestra a continuación:

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

Guarda los cambios en el proxy de API.

Causa: Solicitud no segura en un puerto seguro

Diagnóstico

Determina el ID del mensaje de la solicitud con errores.
Busca el ID del mensaje en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).

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 la cantidad de veces MaxFailure configurada en el monitor de estado, verás un mensaje de advertencia como este:

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}

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 se configuró 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 el 443, recibirá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 la API de Get TargetServer para obtener la definición del servidor de destino.
  
  Salida 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 ningún bloque SSLInfo. Sin embargo, está configurado de forma incorrecta con un puerto 443 seguro.
2. Ahora, verifica la configuración del monitor de estado para el servidor de destino en la configuración del extremo de destino:
  Configuración de 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>
  Ten en cuenta que no se especifica ningún elemento <Port> en la configuración del Monitor de estado anterior. En este caso, el Message Processor de Edge usará el puerto especificado en la definición del servidor de destino, que es el 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 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 seguro de destino no seguro

Situación 2: Se define un servidor de destino no seguro, pero el Monitoreo de estado se configura con un puerto seguro

Si definiste un servidor de destino no seguro, pero el Health Monitor está configurado con un puerto seguro, como el 443, recibirá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 la API de Get TargetServer para obtener la definición del servidor de destino.
  
  Salida 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 monitor de estado del servidor de destino en la configuración del extremo de destino:
  Configuración de 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>
  En el ejemplo anterior, el monitor de estado se configura con un puerto 443 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 no seguro (ya que no se define el bloque SSLInfo) 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.

Solución

Puerto seguro de destino no seguro

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

Para corregir este error, actualiza la definición del servidor de destino para que use un puerto seguro adecuado.

Usa la API de Update a Target Server para actualizar la definición del servidor de destino y asegurarte de que se use un puerto no seguro (por ejemplo, 80) como se muestra en el siguiente ejemplo:

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

Puerto HM seguro de destino no seguro

Situación 2: Se define un servidor de destino no seguro, pero el Monitoreo de estado se configura con un puerto seguro

Para corregir este error, sigue las instrucciones que se indican a continuación:

Quita el elemento <Port> de la configuración del Monitoreo de estado o modifica la configuración del Monitoreo de estado para usar un puerto no seguro (por ejemplo, el 80) para realizar verificaciones de estado del servidor de destino en la configuración del extremo de destino del proxy de API con errores, como se muestra a continuación:

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

Guarda los cambios en el proxy de API.

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

Diagnóstico

Determina el ID del mensaje de la solicitud con errores.
Busca el ID del mensaje en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Verás los mensajes de error comunes correspondientes al ID del mensaje. Sin embargo, para conocer la causa real de las fallas en la verificación de estado, desplázate hacia arriba y busca los mensajes de error comunes y comprueba si hay errores o advertencias del MONITOR DE ESTADO.
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 la cantidad de veces MaxFailure configurada en el monitor de estado, verás un mensaje de advertencia como este:
```
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 con atención la información que se proporciona en el mensaje de advertencia. Asegúrate de que se haya alcanzado el recuento de MaxFailure para un servidor de destino que se usa en el proxy de API específico para el que experimentas el código de respuesta 503 con el código de error NoActiveTargets.
La verificación de estado devolvió 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 el código de respuesta real recibido es 404. Por lo tanto, se considera un error.
Antes de investigar la causa de la respuesta de error de la API de verificación de estado, determina por qué Edge espera el código de respuesta 200 para la API de verificación de estado. Para ello, verifica la configuración del monitor de estado del servidor de destino en la configuración del extremo de destino:
Configuración de 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>
        
```
Ten en cuenta que la configuración de la supervisión de estado se establece con el código de respuesta 200 en el elemento <SuccessResponse>. Esto significa que, si Edge recibe cualquier código de respuesta (como 400, 401, 404 o 500) que no sea 200 de la API de verificación de estado, se tratará como un error y se incrementará el recuento de errores.
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:

Consulta el mensaje anterior al 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 la verificación de estado que se incluye en este mensaje.

Puedes realizar una llamada directa a esta URL desde el Message Processor y verificar la respuesta real.
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
La respuesta de la llamada anterior arroja un error 404, como se ve en los registros de Message Processor:
```
< HTTP/2 404
          
```
Esto demuestra 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 la verificación de estado puede ser incorrecta o que el recurso al que se accede como parte de la URL ya no está disponible.
En el ejemplo de la API de verificación de estado proporcionado anteriormente, el problema ocurre porque se usó una URL incorrecta en la configuración del Monitor de estado. Se encontró que la URL correcta es https://mocktarget.apigee.net:443/statuscode/200 de Mock Target API.

Si recibes cualquier otra respuesta de error, sigue los pasos anteriores para determinar la causa. Si es necesario, trabaja con tu equipo de backend.

Solución

Corrige el problema con la API de verificación de estado en tu servidor de backend.
Para solucionar el problema en el ejemplo anterior, haz lo siguiente:

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>
        
```
Guarda los cambios en el proxy de API.

Si el problema persiste, consulta Recopila información de diagnóstico.

Diagnostica problemas con la supervisión de la API

La supervisión de API te permite aislar rápidamente las áreas con problemas para diagnosticar errores, problemas de rendimiento y latencia, y su fuente, como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Sigue un caso de ejemplo que muestra cómo solucionar problemas de 5xx con tus APIs usando API Monitoring. Por ejemplo, puedes configurar una alerta para recibir una notificación cuando la cantidad de fallas de 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 el equipo de asistencia de Apigee y comparte los siguientes datos:

Si eres usuario de la nube pública, proporciona la siguiente información:

Nombre de la organización
Nombre del entorno
Nombre del proxy de API
Comando curl completo para reproducir el error
Archivo de registro que contiene las solicitudes con el error 503 Servicio no disponible y el código de error NoActiveTargets

Si eres usuario de Private Cloud, proporciona la siguiente información:
1. Mensaje de error completo observado
2. Nombre del entorno
3. Paquete de proxy de API
4. Archivo de registro que contiene las solicitudes con el error 503 Servicio no disponible y 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)