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

Estás viendo la documentación de Apigee Edge.
Ve a 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 observará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 y 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. especificadas en el mensaje de error.	Usuarios perimetrales de nubes públicas y privadas
Se quitó el host virtual de una revisión recién implementada del proxy de API	Quitar el host virtual de la revisión recién implementada mientras el cliente está en reposo usar el host virtual específico puede causar este problema.	Usuarios perimetrales de nubes públicas y privadas
Ruta de acceso no asociada con 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 perimetrales de nubes públicas y privadas
El proxy de API no se implementó en un entorno	El proxy de API específico no está implementado en el entorno específico en el que te encuentras para hacer las solicitudes a la API.	Usuarios perimetrales de nubes públicas y privadas
El entorno no se cargó en el Message Processor	El entorno específico (en el que intentas realizar las solicitudes a la API) no se cargó en los Message Processors debido a un error.	Usuarios de la nube privada perimetral
El proxy de API no se implementó en uno o más procesadores de mensajes	Es posible que el proxy de API no se implemente en uno o más procesadores de mensajes debido a la falta 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 problemas del 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) para ver si si tienes messaging.adaptors.http.flow.ApplicationNotFound para la API específica o si tienes el ID de mensaje del paso 2 para 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)

El registro anterior muestra el código y el mensaje de error:

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. Compruebe la configuración del Extremo de proxy del proxy de API y compruebe si este se encuentra configurado para aceptar las solicitudes del host virtual especificado en el error. Este es indicado por el elemento VirtualHost Veamos un ejemplo de ProxyEndpoint. actual para entender esto.

   Ejemplo de configuración de extremo de proxy que 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 de host
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Realiza una solicitud a la API para el VirtualHost default con la URL. http://myorg-prod.apigee.net/weather
4. Dado que ProxyEndpoint no tiene default VirtualHost, como se muestra en el ejemplo anterior, obtienes 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, vaya a la siguiente causa: Ruta de acceso no asociada con ningún proxy de API.

Solución

1. Agrega el VirtualHost faltante a la configuración de 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 de extremo de proxy que muestra el valor VirtualHost&gt; se está agregando

   

2. Como alternativa, en el ejemplo anterior, si solo tuvieras la intención de usar la secure VirtualHost para este proxy de API específico y, luego, realiza las solicitudes a la API Solo para el VirtualHost secure con el protocolo HTTPS:

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

Causa: Se quitó el host virtual de una revisión del proxy de API que se implementó recientemente

Si se implementa una revisión nueva de un proxy de API después de quitar un host virtual específico (eso formaba parte de la revisión implementada previamente) que todavía utilizan los clientes para realizar solicitudes a la API, puede causar este problema.

Diagnóstico

1. Verifique la configuración del Extremo de proxy del proxy de API para ver si este se encuentra configurado para aceptar las solicitudes del host virtual especificado en el error. Este es lo que indica el elemento VirtualHost en la configuración ProxyEndpoint.
2. Si el host virtual especificado en el error no existe en el ProxyEndpoint configuración y, luego, sigue estos pasos. De lo contrario, vaya a la siguiente causa: Ruta de acceso no asociada con ningún proxy de API.
3. Compara la configuración de ProxyEndpoint de la revisión implementada anteriormente con la configuración actual revisión implementada.
   1. Por ejemplo, supongamos que la revisión implementada anteriormente era 5 y el 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 quita en revision 6 y se reemplaza por VirtualHost secure.
   3. Si tú o tus clientes hacen solicitudes a este proxy de API con VirtualHost vh1 (que era parte de revision 5), luego, obtendrás la 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 de host virtual se realizó de forma intencional. de forma involuntaria en la revisión implementada actualmente y las medidas adecuadas, como se explica en la sección Resolución.

Solución

Si identificas que el host virtual o los hosts se quitaron en una nueva revisión, es posible que haya sido intencional o que accidente. En cada caso, sigue los siguientes pasos de resolución o recomendados 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 existe en la revisión implementada previamente).

2. Si deseas seguir usando el proxy de API existente, pero usar un host virtual diferente, es mejor retener 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 tener un host virtual diferente, informar a los usuarios con anticipación y realizar este cambio durante un período de mantenimiento.

   Esto garantizará que los usuarios del proxy de API estén al tanto del cambio y puede usar un host virtual diferente para realizar las llamadas a este proxy de API. Por lo tanto, no se vean afectadas por 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 intencionalmente,haz lo siguiente:

1. Actualiza la configuración de ProxyEndpoint en la revisión implementada actualmente para usarla los mismos hosts virtuales que se usaron en la revisión implementada previamente. En la 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 es aconsejable implementar proxies nuevos o revisiones nuevas durante un período de mantenimiento o cuando se espera menos tráfico para que cualquier problema que surja durante la implementación pueda evitar o minimizar el efecto sobre el tráfico.

Causa: Ruta de acceso no asociada con ningún proxy de API

Si el proxy de API no está configurado para aceptar las solicitudes de la ruta específica utilizada en el URL de solicitud a la API, entonces 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 que deseas. para realizar las solicitudes a la API.
2. Comprueba si el proxy de API está configurado para aceptar las solicitudes de la ruta de acceso específica indicada. en el mensaje de error. Para ello, sigue los pasos que se indican 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 el path indicado en el mensaje de error no es el mismo que el basepath. del proxy de API específico o no comienza con basepath, entonces podría ser la causa del error.
2. Veamos un ejemplo para explicarlo:
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 de acceso 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 lo hace no comienzan con basepath. Por lo tanto, recibes el siguiente error:

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

Solución

1. Asegúrate de que el path que se usa en tu 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 solicitud a la API debería ser la siguiente:

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

Situación 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 la solicitud a la API comienza con basepath, entonces es posible que la path suffix (la parte que viene después del basepath) indicado en el mensaje de error no coincide con ninguna de las condiciones esto podría provocar el error 404.
2. Veamos un ejemplo para explicarlo:
   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. Esto significa esa 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 una path suffix de /Delhi.
4. Ahora comprueba si hay algún flujo condicional 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 el ProxyEndpoint solo tiene flujos condicionales, comprueba lo siguiente:
   1. Si las condiciones de todos estos flujos condicionales buscan una proxy.pathsuffix específica (la ruta de acceso después de la ruta base).
   2. Y si el path suffix especificado en la URL de solicitud a la API no coincide con ninguno de los entonces, esa es la causa del error.
7. Supongamos que tenemos dos flujos en ProxyEndpoint y ambos flujos 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 proxy.pathsuffix (ruta después de la ruta base) a /Bangalore y el otra coincide con /Chennai. Pero 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"
            }
         }
      }

Solució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 cualquier conjunto específico de políticas para la ruta /Delhi, Luego, agrega un flujo separado con el conjunto de políticas requerido y asegúrate de que haya una condición que coincida con /proxy.pathsuffix /Delhi, 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, en común, asegúrate de que haya una condición que permita una /proxy.pathsuffix 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, luego pasemos a la siguiente causa: El proxy de API no se implementó en un entorno.

Causa: El proxy de API no se implementó en un entorno

Diagnóstico

1. Determina el entorno en el que existe el alias de host usado en la URL de solicitud a la API. Esto se puede hacer verificando los detalles de todos los hosts virtuales en cada uno de los entornos de tu organización en la IU de Edge.

   Por ejemplo, supongamos la siguiente configuración:

   • Si http://myorg-prod.apigee.net/weather es tu URL, entonces myorg-prod.apigee.net es el alias del host.
   • El alias del host myorg-prod.apigee.net se configura como parte de uno de los hosts virtuales en el entorno prod de tu organización.
2. Compruebe si el proxy específico de la API está implementado en el entorno específico determinado en en el paso 1.
3. Si el proxy de API no se implementa en el entorno específico, entonces esa es la causa de que el error 404.
   1. En el ejemplo usado en el paso 1, digamos que el proxy de API no está implementado en la prod, esa es la causa del error.
   2. Ve a la sección Resolución a continuación.
4. Si el proxy de API se implementó en el entorno específico, continúe con la siguiente causa: El entorno no se cargó en los procesadores de mensajes.

Solución

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

Causa: El entorno no se cargó en Message Processor

Diagnóstico

1. Inicia sesión en cada uno de los procesadores de mensajes y comprueba si el entorno específico que la solicitud a la API se cargue en Message Processor 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, vaya a la siguiente causa: El proxy de API no se implementó en uno o más procesadores de mensajes.
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 el Mensajes de los procesadores de mensajes para detectar cualquier error durante la carga de entornos.
4. Puede haber muchos errores diferentes que podrían conducir a la falla de la carga de un entorno en Message Processor. La resolución depende del error que se haya producido.

Solución

Es posible que el entorno no se cargue en Message Processor por varios motivos. Esta sección ilustra un par de posibles razones que pueden conducir a este problema y explica cómo resolverlo. el problema.

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

   Error #1: java.security.KeyStoreException: No se puede reemplazar el 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 el almacén de confianza especificados en el mensaje de error que se muestra en el paso anterior con la siguiente llamada a la API de Management:

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

   de
   

   Resultado de ejemplo:

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

3. El resultado de ejemplo 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 tener un solo certificado y una única clave.
4. Obtén información detallada 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 uno de los certificados 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 ves algún error distinto de los mencionados en el paso 1 más arriba, ve a Debe recopilar información de diagnóstico.

Causa: El proxy de API no está disponible implementadas en uno o más Message Processor

Es posible que el proxy de API no se implemente en uno o más Message Processor. Este problema ocurre rara vez y ocurre principalmente debido a que falta la notificación de un evento del servidor de administración a Message Processor durante la implementación del proxy de API específico En este caso también, deberás No se podrá crear la sesión de registro en la IU de Edge.

Diagnóstico

1. Inicia sesión en cada uno de los procesadores de mensajes y comprueba si la revisión específica del El proxy de API está implementado 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 aparece como resultado del comando mencionado en el paso 1, luego reinicia el Message Processor específico como se explica en Resolución.
3. Repite los pasos 1 y 2 con todos los Message Processor.
4. Si la revisión específica del proxy de API se implementa en todos los Message Processor, entonces esa no es la causa del problema. Ir a Se debe recopilar información de diagnóstico.

Solución

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

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

Diagnostica problemas con la supervisión de API

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

Para este problema, puedes navegar a Supervisión de API > Investigar y elija la fecha adecuada, el proxy, etc., y es posible que vea los siguientes detalles:

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

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

Analizar una situación de ejemplo demuestra cómo solucionar problemas de 5xx con tus APIs con la supervisión de API Por ejemplo, podrías deseas configurar una alerta para recibir una notificación cuando la cantidad de códigos de estado 404 supere 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 las siguiente la 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
   • Completar el comando curl para reproducir el error
2. Si eres usuario de la 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 Message Processor.

   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 ayudará a acelerar la resolución de este problema.