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 consultando la documentación de Apigee Edge.
Consulta 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 seguimiento:

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 en la captura de solicitudes a la API en el seguimiento de IU de Edge:

Causa	Descripción	Instrucciones de solución de problemas aplicables a
Solicitudes que no procesa el procesador de mensajes	El componente Message Processor del componente 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 el Message Processor lo procese, no se podrá capturar el seguimiento.	Usuarios de la nube pública y privada de Edge
No se encontró el proxy de 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 según 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 que no procesa el procesador de mensajes

Diagnóstico

Para capturar una solicitud a la API en una sesión de Trace, el componente Message Processor del componente de Edge debe procesar la solicitud a la API. Existen varios motivos por los que es posible que una solicitud a la API no se capture 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 Message Processor lo procese, no se podrá capturar el seguimiento. Cada una de estas situaciones se describe con mayor 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 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
```
Resolució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 perimetral de Apigee

Causa

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

Consulta las siguientes guías para solucionar estos problemas:

Fallas de protocolo de enlace TLS/SSL

Solicitud incorrecta 400: error de certificado SSL

Situación 3: El procesador de mensajes 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 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"
    }
  }
}

Resolución

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

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

Diagnóstico

Si un Message Processor no puede encontrar un proxy de API en su árbol de clasificación, las solicitudes a la API para ese proxy específico no se mostrarán en las sesiones de Trace 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 se implementó 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 encuentre errores HTTP 404 intermitentes, es probable que vea que se implementó la revisión específica.
Lea el árbol de clasificación y compruebe la existencia del nombre de proxy de la API con el siguiente comando:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
Repite los pasos 1 y 2 para cada procesador de mensajes. Si el nombre de proxy de la API dado falta en el árbol de clasificación de cualquiera de los procesadores de mensajes, sigue la resolución que se proporciona a continuación.

Solución

Sigue los pasos que se indican a continuación para resolver este problema. Asegúrate de tomar las precauciones necesarias para evitar las interrupciones de producción que puedan ocurrir debido al reinicio de Message Processor mientras se experimentan 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 siguiente comando para reiniciar Message Processor:
```
/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, use el siguiente comando para verificar la disponibilidad del proxy de API:
```
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 encuentre errores HTTP 404 intermitentes, es probable que vea que se implementó la revisión específica.
Lea el árbol de clasificación y verifique la existencia del nombre de proxy de la API con el siguiente comando:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
Si el problema persiste, ve a Debes 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 trace session	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 de 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 los procesadores de mensajes	netstat -an > netstat.txt
Lista de resultados de las revisiones implementadas para el proxy de API específico en todos los procesadores de mensajes	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