404 No se pudo identificar el proxy para el host: <nombre de host virtual> and url: <path>

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

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 404 con el mensaje Not Found y el mensaje de error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH como respuesta a las llamadas a la API.

Este error significa que Edge no pudo encontrar el proxy de API para el host virtual y la ruta de acceso especificados.

Mensaje de error

Obtendrás el siguiente código de estado HTTP:

HTTP/1.1 404 Not Found

También verás un mensaje de error similar al que se muestra a continuación:

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

El mensaje de error anterior indica que Edge no pudo encontrar el proxy de API para el host virtual default ni la ruta de acceso /oauth2/token.

Causas posibles

A continuación, se indican algunas de las posibles causas de este error:

Causa	Descripción	Instrucciones de solución de problemas aplicables para
El proxy de API no está asociado con el host virtual específico.	El proxy de API específico no está configurado para aceptar solicitudes en el host virtual especificado en el mensaje de error.	Usuarios de la nube pública y privada de Edge
Se quitó el host virtual de una revisión recién implementada del proxy de API	Este problema puede deberse a quitar el host virtual de la revisión recién implementada mientras el cliente todavía usa el host virtual específico.	Usuarios de la nube pública y privada de Edge
Ruta de acceso no asociada a ningún proxy de API	El proxy de API específico no está configurado para aceptar solicitudes en la ruta especificada en el mensaje de error.	Usuarios de la nube pública y privada de Edge
No se implementó el proxy de API en un entorno.	El proxy de API específico no está implementado en el entorno específico en el que intentas realizar las solicitudes a la API.	Usuarios de la nube pública y privada de Edge
No se cargó el entorno en Message Processor	El entorno específico (en el que intentas realizar las solicitudes a la API) no se cargó en Message Processor debido a un error.	Usuarios de la nube privada perimetral
El proxy de API no se implementó en uno o más Message Processor	Es posible que el proxy de API no se pueda implementar en uno o más Message Processor debido a que falta una notificación de eventos durante la implementación.	Usuarios de la nube privada perimetral

Pasos comunes de diagnóstico

Los registros de NGINX y Message Processor serán útiles para solucionar el error 404. Sigue estos pasos para verificar los registros:

1. Visualiza los registros de NGINX con el siguiente comando:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. Verifica los siguientes campos en las entradas de registro:

   Campo	Valor
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   Toma nota del ID del mensaje de los registros.

3. Revisa los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)) a fin de ver si tienes messaging.adaptors.http.flow.ApplicationNotFound para la API específica o si tienes el ID del mensaje único del paso 2 de la solicitud a la API.

   Ejemplo de mensaje de error del registro de Message Processor

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

En el registro anterior, se muestra el código y el mensaje de error siguientes:

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

Causa: El proxy de API no está asociado con el host virtual específico.

Si el proxy de API no está configurado para aceptar las solicitudes del host virtual específico, podemos obtener una respuesta 404 Not Found con el mensaje de error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnóstico

1. Verifica la configuración de Proxy Endpoint para el proxy de API y comprueba si este está configurado para aceptar las solicitudes del host virtual especificado en el error. Esto se indica con el elemento VirtualHost. Veamos una configuración de ProxyEndpoint de muestra para comprender esto.

   Ejemplo de configuración del extremo del proxy en el que se muestra que el proxy de API acepta solicitudes en un host virtual seguro

   

2. Supongamos que los hosts virtuales se definen en el entorno específico de la siguiente manera:

   Nombre	Puerto	Alias del host
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Realizas una solicitud a la API a la VirtualHost de default mediante la URL http://myorg-prod.apigee.net/weather.
4. Dado que ProxyEndpoint no tiene default VirtualHost como se muestra en el ejemplo anterior, obtendrás el código de respuesta 404 con el siguiente mensaje de error:

   {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

5. Ve a la sección Resolución que aparece más abajo para solucionar este problema.
6. Si ProxyEndpoint está configurado para aceptar las solicitudes en default VirtualHost, ve a la siguiente causa: Ruta de acceso no asociada con ningún proxy de API.

Resolución

1. Agrega el VirtualHost faltante a la configuración ProxyEndpoint para abordar el problema. En el ejemplo anterior, puedes agregar el VirtualHost predeterminado a la configuración ProxyEndpoint de la siguiente manera:

   <VirtualHost>default</VirtualHost>

   Ejemplo de configuración del extremo del proxy que muestra que se está agregando default> VirtualHost>

   

2. Como alternativa, en el ejemplo anterior, si pretendías usar solo el VirtualHost de secure para este proxy de API específico, realiza las solicitudes a la API solo al VirtualHost de secure con el protocolo HTTPS:

   https://myorg-prod.apigee.net/weather

Causa: Se quitó el host virtual de una revisión recién implementada del proxy de API

Si se implementa una revisión nueva de un proxy de API después de quitar un host virtual específico (que era parte de la revisión implementada antes), los clientes aún la usan para realizar solicitudes a la API, entonces puede causar este problema.

Diagnóstico

1. Verifica la configuración de Proxy Endpoint para el proxy de API y comprueba si este está configurado para aceptar las solicitudes del host virtual especificado en el error. Esto se indica mediante el elemento VirtualHost en la configuración ProxyEndpoint.
2. Si el host virtual especificado en el error no existe en la configuración de ProxyEndpoint, realiza los siguientes pasos. De lo contrario, ve a la siguiente causa: Ruta de acceso no asociada a ningún proxy de API.
3. Compara la configuración de ProxyEndpoint de la revisión implementada antes con la revisión implementada actualmente.
   1. Por ejemplo, supongamos que la revisión implementada anteriormente era 5 y la revisión implementada actualmente es 6:
      • Hosts virtuales configurados en el extremo del proxy en la revisión 5

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>
      

      • Hosts virtuales configurados en el extremo del proxy en la revisión 6

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>
      

   2. En el ejemplo anterior, VirtualHost vh1 existía en revision 5,, pero se quitó en revision 6 y se reemplazó por VirtualHost secure.
   3. Por lo tanto, si tú o tus clientes realizan las solicitudes a este proxy de API mediante VirtualHost vh1 (que era parte de revision 5), obtendrás el código de respuesta 404 con el siguiente mensaje de error:

      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
      

4. Verifica si el cambio del host virtual se realizó de forma intencional o no intencional en la revisión implementada actualmente y toma las medidas adecuadas, como se explica en la sección Resolución.

Resolución

Si identificas que el o los hosts virtuales se quitaron en una revisión nueva, es posible que haya sido intencional o accidental. En cada caso, sigue los pasos recomendados o la resolución que se indican a continuación para resolver el problema.

Situación 1: Cambio intencional

En caso de que la eliminación del host virtual sea intencional, puedes elegir una de las siguientes opciones; la primera es el enfoque recomendado:

1. Crea un proxy nuevo con una ruta base diferente y usa un host virtual diferente (que no exista en la revisión implementada antes).

2. Si deseas seguir usando el proxy de API existente, pero usar un host virtual diferente, es mejor conservar el host virtual existente y agregar el host virtual adicional.

   Esto garantizará que los usuarios de este proxy de API no se vean afectados por el cambio.

3. Si deseas usar el proxy de API existente y solo un host virtual diferente, informa a los usuarios con anticipación y haz este cambio durante un período de mantenimiento.

   Esto garantizará que los usuarios de este proxy de API estén al tanto del cambio y puedan usar un host virtual diferente para realizar las llamadas a este proxy de API. Por lo tanto, no los afectará el cambio.

Situación 2: Cambio no intencional

En caso de que la eliminación del host virtual se haya realizado por error y no de forma intencional,haz lo siguiente:

1. Actualiza la configuración de ProxyEndpoint en la revisión implementada actualmente para usar los mismos hosts virtuales que se usaron en la revisión implementada anteriormente. En el ejemplo anterior, cambia la siguiente sección de:

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>
   

   para

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>
   

2. Vuelve a implementar la revisión.

Prácticas recomendadas

Siempre se recomienda implementar proxies o revisiones nuevos durante un período de mantenimiento o cuando se espera que el tráfico sea menos esperado, de modo que se pueda evitar cualquier problema que surja durante la implementación o se pueda minimizar el efecto en el tráfico.

Causa: La ruta de acceso no está asociada a ningún proxy de API

Si el proxy de la API no está configurado para aceptar las solicitudes de la ruta específica utilizada en la URL de la solicitud a la API, podemos obtener una respuesta 404 Not Found con el mensaje de error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnóstico

1. Observa la configuración de ProxyEndpoint del proxy de API específico para el que deseas realizar las solicitudes a la API.
2. Verifica si el proxy de API está configurado para aceptar las solicitudes de la ruta específica que se indica en el mensaje de error. Para ello, sigue los pasos de la Situación 1 y Situación 2.

Situación 1: La ruta de acceso no coincide con la ruta base del proxy de API

1. Si la path que se indica en el mensaje de error no es la misma que la basepath del proxy de API específico o no comienza con basepath, esa podría ser la causa del error.
2. Revisemos un ejemplo para explicar esto:
1. El basepath del proxy de API previsto es /weather
2. La URL de solicitud a la API es https://myorg-prod.apigee.net/climate. Esto significa que la ruta que se usa en la URL de la solicitud a la API es /climate..
3. En este ejemplo, path no es lo mismo que basepath y no comienza con basepath. Por lo tanto, verás el siguiente error:

   {
      "fault":{
         "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
         "detail":{
            "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
         }
      }
   }

   .

Resolución

1. Asegúrate de que el path que se usa en la URL de solicitud a la API sea el mismo que el basepath del proxy de API específico.
2. En el ejemplo anterior, la URL de la solicitud a la API debería ser la siguiente:

   {
   https://myorg-prod.apigee.net/weather
   

Situación n.o 2: La ruta de acceso no coincide con ninguno de los flujos condicionales disponibles

1. Si el path que se usa en la URL de solicitud a la API comienza con basepath, es posible que el path suffix (la parte que viene después del basepath) indicado en el mensaje de error no coincida con ninguno de los flujos condicionales, lo que podría causar el error 404.
2. Veamos un ejemplo para explicar esto:
   1. El basepath del proxy de API previsto es /weather
   2. La URL de solicitud a la API es https://myorg-prod.apigee.net/weather/Delhi. Es decir, la ruta que se usa en la URL de la solicitud a la API es /weather/Delhi..
3. En este ejemplo, path comienza con basepath /weather. Además, tiene un path suffix de /Delhi.
4. Ahora, verifica si hay flujos condicionales en ProxyEndpoint.
5. Si no hay flujos condicionales o hay algunos no condicionales, ve a la siguiente causa: El proxy de API no se implementó en un entorno.
6. Si ProxyEndpoint solo tiene flujos condicionales, verifica lo siguiente:
   1. Si las condiciones de todos estos flujos condicionales verifican una proxy.pathsuffix específica (la ruta después de la ruta base).
   2. Y si el path suffix especificado en la URL de la solicitud a la API no coincide con ninguna de las condiciones, esa es la causa del error.
7. Supongamos que tenemos dos flujos en ProxyEndpoint y que ambos son condicionales, como se muestra a continuación:

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
   

   1. En el ejemplo anterior, tenemos dos flujos condicionales: uno que coincide con proxy.pathsuffix (la ruta de acceso después de la ruta base) con /Bangalore y el otro que coincide con /Chennai. Sin embargo, no hay ninguno que coincida con /Delhi, que es el path suffix que se pasa en la URL de la solicitud a la API.
   2. Esta es la causa del error 404. Por lo tanto, verás el siguiente error:

      {
         "fault":{
            "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
            "detail":{
               "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
            }
         }
      }

      .

Resolución

1. Asegúrate de que path suffix coincida con al menos uno de los flujos condicionales en el extremo del proxy.
2. En el ejemplo anterior, puedes usar los siguientes enfoques para resolver el error:
   1. Si deseas ejecutar un conjunto específico de políticas para la ruta de acceso /Delhi, agrega un flujo separado con el conjunto de políticas requerido y asegúrate de que haya una condición que coincida con el /Delhi de /proxy.pathsuffix, como se muestra a continuación:

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. Si deseas ejecutar un conjunto común de políticas para la ruta /Delhi, asegúrate de que, en el flujo común, haya una condición que permita un /proxy.pathsuffix genérico. Es decir, permitiría cualquier ruta después de basepath /weather como se muestra a continuación:

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Si ProxyEndpoint tiene el basepath correcto y el path suffix especificado en la URL de la API coincide con uno de los flujos condicionales, continúa con la siguiente causa: El proxy de API no se implementó en un entorno.

Causa: No se implementó el proxy de API en un entorno.

Diagnóstico

1. Determina el entorno para el que existe el alias de host utilizado en tu URL de solicitud a la API. Para ello, se pueden consultar los detalles de todos los hosts virtuales en cada uno de los entornos de la organización en la IU de Edge.

   Por ejemplo, supongamos la siguiente configuración:

   • Si http://myorg-prod.apigee.net/weather es la URL, myorg-prod.apigee.net es el alias del host.
   • El alias de host myorg-prod.apigee.net se configura como parte de uno de los hosts virtuales en el entorno prod de la organización.
2. Verifica si el proxy de API específico está implementado en el entorno específico determinado en el paso 1 anterior.
3. Si el proxy de API no está implementado en el entorno específico, esa es la causa del error 404.
   1. Entonces, en el ejemplo que se usa en el paso 1 anterior, supongamos que el proxy de API no está implementado en el entorno prod. Esa es la causa del error.
   2. Ve a la sección Resolución que se encuentra más abajo.
4. Si el proxy de API se implementó en el entorno específico, ve a la siguiente causa: El entorno no se cargó en Message Processors.

Resolución

Implementa el proxy de API en el entorno específico en el que deseas realizar solicitudes a la API.

Causa: No se cargó el entorno en los procesadores de mensajes

Diagnóstico

1. Accede a cada uno de los procesadores de mensajes y verifica si el entorno específico en el que realizas la solicitud a la API se cargó en el procesador de mensajes con el siguiente comando:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. Si el entorno específico aparece como parte del comando anterior, ve a la siguiente causa: El proxy de API no se implementó en uno o más Message Processor.
3. Si el entorno específico no aparece en la lista, verifica /opt/apigee/var/log/edge-message-processor/logs/system.log y /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log en los procesadores de mensajes para ver si hay errores durante la carga de entornos.
4. Puede haber muchos errores diferentes que podrían provocar un error en la carga de un entorno en Message Processor. La Resolución depende del error que se haya producido.

Resolución

Es posible que el entorno no se cargue en Message Processor por varios motivos. En esta sección, se ilustran algunos motivos posibles que pueden generar este problema y se explica cómo resolverlo.

1. Si ves uno de los siguientes errores en el registro de Message Processor, se debe a un problema que se encontró con los certificados o claves que se agregaron al almacén de claves o almacén de confianza especificado en el entorno especificado.

   Error 1: java.security.KeyStoreException: No se puede reemplazar un certificado propio

   2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
   at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
   …
   Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   

   ... 20 common frames omitted

   2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
   

   Error 2: java.security.KeyStoreException: No se puede reemplazar la clave secreta

   2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   ...
   Caused by: java.security.KeyStoreException: Cannot overwrite secret key
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   ... 20 common frames omitted
   
   2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

2. Obtén los detalles del almacén de claves o almacén de confianza especificado en el mensaje de error que se muestra en el paso anterior con la siguiente llamada a la API de administración:

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   Resultado de ejemplo:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }
   

3. En el resultado de ejemplo, se muestra que hay dos certificados y una clave en el almacén de confianza myTruststore. Por lo general, el almacén de confianza no contiene una clave. Si es así, es mejor tener un solo certificado y una sola clave.
4. Obtén los detalles sobre los dos certificados con la siguiente API:

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. Verifica la fecha de vencimiento de cada certificado y determina cuál es el más antiguo o vencido.
6. Borra el certificado vencido o no deseado del almacén de confianza myTruststore.

Si el problema persiste o si ves algún error distinto de los mencionados en el paso 1, ve a Debes recopilar información de diagnóstico.

Causa: No se implementó el proxy de API en uno o más Message Processor.

El proxy de API no se puede implementar en uno o más Message Processor. Este problema ocurre muy poco y en su mayoría debido a la falta de una notificación de evento del servidor de administración al procesador de mensajes durante la implementación del proxy de API específico. También en este caso, no podrás crear la sesión de seguimiento en la IU de Edge.

Diagnóstico

1. Accede a cada uno de los procesadores de mensajes y verifica si la revisión específica del proxy de API se implementó o no con el siguiente comando:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. Si la revisión específica del proxy de API no se muestra como el resultado del comando mencionado en el paso 1, reinicia el Message Processor específico como se explica en Resolución.
3. Repite los pasos 1 a 2 para todos los procesadores de mensajes.
4. Si la revisión específica del proxy de API se implementa en todos los procesadores de mensajes, esta no es la causa de este problema. Consulta Se debe recopilar información de diagnóstico.

Resolución

Reinicia los procesadores de mensajes específicos en los que no se implementa la revisión específica del proxy de API.

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Diagnostica problemas con la supervisión de API

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.

Para este problema, puedes navegar a la página Supervisión de API > Investigar y elegir la fecha, el proxy y otros parámetros adecuados. Es posible que veas los siguientes detalles:

• Código de falla: messaging.adaptors.http.flow.ApplicationNotFound
• Código de estado: 404
• Fuente de fallas: Apigee o MP

Además, puedes hacer clic en View logs (Ver registros), como se muestra en la captura de pantalla anterior, y realizar más verificaciones.

En esta situación de muestra, se muestra cómo solucionar problemas de 5xx en tus APIs mediante la supervisión de API. Por ejemplo, es posible que desees configurar una alerta para recibir una notificación cuando la cantidad de códigos de estado 404 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 Edge y compártela.

1. 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
   • Completa el comando curl para reproducir el error
2. Si eres usuario de una nube privada, proporciona la siguiente información:
   • Se observó un mensaje de error completo
   • Nombre del entorno
   • Paquete de proxy de API
   • Registros del procesador de mensajes /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Resultado de los siguientes comandos en cada uno de los procesadores de mensajes.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
         

3. Detalles sobre las secciones de esta guía que probaste y cualquier otra información que nos ayude a acelerar la resolución de este problema.