Se usó la API de Cloud Translation para traducir esta página.

Solicitudes a la API no capturadas en la IU de Edge

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

Síntoma

En la siguiente imagen, se muestra que las solicitudes a la API no se capturan en la IU de Edge cuando se inicia una sesión de registro:

Mensaje de error

No se mostrarán mensajes de error en la IU de Edge cuando se produzca este problema.

Causas posibles

En la siguiente tabla, se muestran las posibles causas de un error al capturar solicitudes a la API en el seguimiento de la IU de Edge:

Causa	Descripción	Instrucciones de solución de problemas aplicables a
Solicitudes no procesadas por el procesador de mensajes	El componente Message Processor de Edge debe procesar las solicitudes a la API para capturar el seguimiento. Si una solicitud a la API no llega a Apigee Edge, falla en el punto de entrada a Edge (es decir, router) o falla antes de que lo procese el Message Processor, no se podrá capturar el seguimiento.	Usuarios de la nube pública y privada perimetral
No se encontró el proxy de la API en el árbol de clasificación	Los procesadores de mensajes de Apigee usan una definición de regla de enrutamiento llamada árbol de clasificación para enviar solicitudes basadas en el nombre de host, la ruta base, la revisión y el entorno de la solicitud entrante. Si por algún motivo se quita el proxy de API correspondiente del árbol de clasificación, es posible que no se propaguen las transacciones de Trace.	Usuarios de la nube privada perimetral

Causa: Solicitudes no procesadas por Message Processor

Diagnóstico

Para capturar una solicitud a la API en una sesión de Trace, el componente Message Processor de Edge debe procesar la solicitud a la API. Existen varios motivos por los que una solicitud a la API puede no ser capturada en una transacción de Trace.

Por ejemplo, si una solicitud a la API no llega a Apigee Edge, falla en el punto de entrada a Edge (es decir, router) o falla antes de que lo procese el Message Processor, no se podrá capturar el seguimiento. Cada una de estas situaciones se describe con más detalle a continuación.

Situación 1: Las solicitudes no llegan a Apigee Edge

Causa

En este caso, el error puede deberse a una resolución de DNS o a un problema de conectividad de red. Si es así, es posible que veas el siguiente error cuando ejecutes este comando:
```
curl https://hostName:port/apiProxyBasePath/requestPath
```
```
curl: (6) Could not resolve host: hostName
```
Solución

Puedes verificar la configuración de DNS con el siguiente comando:
```
dig hostName
```
Puedes verificar la conectividad de red con el siguiente comando:
```
telnet hostName port
```

Situación 2: Las solicitudes fallan en el router de Apigee Edge

Causa

En esta situación, el error puede deberse a una falla del protocolo de enlace TLS/SSL. Si es así, es posible que aparezca uno de los siguientes errores:
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
También es posible que veas un error de certificado SSL.
Solución

Consulta las siguientes guías para solucionar estos problemas:

Fallas del protocolo de enlace TLS/SSL

Solicitud incorrecta 400: error de certificado SSL

Situación 3: Message Processor no puede procesar las solicitudes

Causa

En esta situación, Apigee Message Processor no puede encontrar el proxy de API para el host virtual y la ruta de acceso especificados. Como resultado, es posible que veas uno de los los siguientes errores:

HTTP/1.1 404 Not Found

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

Solución

Consulta esta guía para solucionar el problema: 404 No se puede identificar el proxy del host.

Causa: No se encontró el proxy de API en el árbol de clasificación

Diagnóstico

Si un procesador de mensajes no puede encontrar un proxy de API en su árbol de clasificación, las solicitudes de la API a ese proxy específico no se mostrarán en las sesiones de seguimiento de la IU de Edge.

Sigue los pasos que se indican a continuación para determinar si este es el caso:

Accede a cada uno de los Message Processor y verifica si la revisión específica de la API solicitada está implementada en el entorno relevante de Message Processor con el siguiente comando:
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
Resultado de ejemplo:

El comando anterior mostrará una lista de las revisiones implementadas. Por ejemplo, si se implementa la revisión 12, verás el siguiente resultado:
```
[ "12" ]
```
A menos que encuentres errores intermitentes de HTTP 404, es probable que veas que la revisión específica está implementada.
Lee el árbol de clasificación y verifica la existencia del nombre del proxy de API con el siguiente comando:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
Repite los pasos 1 y 2 para cada Message Processor. Si el nombre del proxy de API no se encuentra en el árbol de clasificación de alguno de los procesadores de mensajes, siga la resolución que se indica a continuación.

Solución

Sigue los pasos que se indican a continuación para resolver este problema. Asegúrate de tomar todas las precauciones necesarias para evitar interrupciones de producción que puedan producirse por reiniciar Message Processors mientras experimentas cargas de solicitudes altas.

Accede a cada uno de los hosts de Message Processor que no tengan el proxy de API específico en el árbol de clasificación y usa el comando que aparece a continuación para reiniciarlo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

Una vez reiniciada, usa el siguiente comando para esperar hasta que se active:

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

Una vez que Message Processor esté listo, verifica la disponibilidad del proxy de API con el siguiente comando:
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
Resultado de ejemplo:

El comando anterior mostrará una lista de las revisiones implementadas. Por ejemplo, si se implementa la revisión 12, verás el siguiente resultado:
```
[ "12" ]
```
A menos que encuentres errores intermitentes de HTTP 404, es probable que veas que la revisión específica está implementada.
Lee el árbol de clasificación y verifica la existencia del nombre del proxy de API con el siguiente comando:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
Si el problema persiste, consulta Se debe recopilar información de diagnóstico.

Se debe recopilar información de diagnóstico

Si el problema persiste después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y compártela con el equipo de asistencia de Apigee Edge:

Tipo de información de diagnóstico	Comando
Resultado del comando de la sesión de seguimiento	curl -v `management-server-host`:8080/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiProxyName`/revisions/`revisionNumber`/debugsessions -u `user`
Registro del servidor de administración	/opt/apigee/var/log/edge-management-server/logs/system.log
Registros del procesador de mensajes	/opt/apigee/var/log/edge-message-processor/logs/system.log
Resultado de los comandos `telnet`/`netcat` del servidor de administración al procesador de mensajes	telnet `MessageProcessor_IP` 8082 nc -vz `MessageProcessor_IP` 8082
Resultado del comando netstat en Message Processor	netstat -an > netstat.txt
Resultado que muestra una lista de revisiones implementadas para el proxy de API específico en todos los Message Processor	curl -v http://localhost:8082/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiName`/revisions
Resultado del árbol de clasificación en todos los procesadores de mensajes	curl -i http://localhost:8082/v1/classification/tree