Estás viendo la documentación de Apigee y Apigee hybrid.
No hay documentación de Apigee Edge equivalente para este tema.
En este tema, se analizan los pasos que puedes seguir para solucionar problemas relacionados con el procesador de mensajes. El procesador de mensajes es parte del componente apigee-runtime
. Consulta también Descripción general de la configuración del servicio del entorno de ejecución.
La prueba de disponibilidad falla con el código de estado HTTP 500
Síntoma
Uno o más pods apigee-runtime
no están en el estado Listo.
Mensaje de error
Cuando usas kubectl
para describir un pod de apigee-runtime
con errores, verás el siguiente error:
Readiness probe failed: HTTP probe failed with statuscode: 500
Por ejemplo:
kubectl describe pod -n hybrid \ apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7 ... apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7 Readiness probe failed: HTTP probe failed with statuscode: 500 ...
Causas posibles
El error significa que no hay un contrato activo disponible para que el procesador de mensajes entregue el tráfico. En este estado, el procesador de mensajes no puede llamarse a sí mismo como “listo”.
Causa | Descripción |
---|---|
Problema de conexión del plano de administración con el sincronizador | El sincronizador no puede conectarse con el plano de administración. Este problema suele ocurrir en casos en los que anulas la URL contractProvider y asocias la cuenta de servicio incorrecta con ella. Por ejemplo, si configuras una cuenta de servicio para una implementación de etapa de pruebas con una URL contractProvider que apunta al servidor de producción.
|
Problema de conexión entre el procesador de mensajes y el sincronizador | Si aparece un nuevo MP como parte de un ajuste de escala automático o de un reinicio de Pod, es posible que veas este error. Por lo general, este problema ocurre cuando el sincronizador está inactivo y el MP no pudo cargar su contrato. |
Diagnóstico: Problema de conexión entre el Sincronizador y el plano de administración
Para diagnosticar un Problema de conexión entre el Sincronizador y el plano de administración, haz lo siguiente:
- Obtén una lista de los pods del clúster.
kubectl get pods -n namespace
- Abre una shell en un Pod
apigee-synchronizer
:kubectl exec -it -n namespace synchronizer-pod-name -- bash
Por ejemplo:
kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x -- bash
- Ve al siguiente directorio:
cd /opt/apigee/var/log/apigee-synchronizer
ls
dr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750 drwxr-sr-x 2 apigee apigee 4096 Sep 12 16:52 cachedFiles -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log -rw-r--r-- 1 apigee apigee 76 Sep 12 16:52 versions.properties - Verifica la versión activa en
version.properties
. Por ejemplo:cat versions.properties #active repository version #Sat Dec 14 19:45:00 GMT 2019 active.version=749
- Asegúrate de que el valor de
active.version
coincida con el nombre del número de carpeta del contrato. En el ejemplo anterior (que también se muestra a continuación), el nombre de la carpeta es750
. Por lo tanto, no coinciden:dr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750
- Sal de la shell del Pod.
Solución
Si falta version.properties
o si hay una coincidencia incorrecta de la versión como se explicó antes, revisa los registros de sincronizador para tratar de determinar por qué los contratos más actuales no se están descargado. Por ejemplo:
kubectl logs -f -n namespace synchronizer-pod-name
Si deseas obtener información para interpretar los registros de sincronización, consulta Registros del sincronizador.
Si el sincronizador está inactivo, intenta reiniciarlo mediante apigeectl
. Por ejemplo:
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name
Diagnóstico: Problema de conexión del procesador de mensajes para sincronizar la conexión
Para diagnosticar un problema de conexión del procesador de mensajes al sincronizador, haz lo siguiente:
- Obtén una lista de los pods del clúster.
kubectl get pods -n namespace
- Revisa los registros del entorno de ejecución para descubrir por qué no se descargan los contratos:
kubectl logs -f -n namespace pod-name
Por ejemplo:
kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7
Es posible que el nuevo MP aparezca como parte de un ajuste de escala automático o reinicio del Pod, que el MP no pueda cargar los contratos. Por lo general, el problema ocurre cuando el sincronizador está inactivo, lo cual evita que el MP cargue los contratos. Por ejemplo:
2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() : Connection 1/64 creation failed java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local at java.net.InetAddress.getAllByName0(InetAddress.java:1281) at java.net.InetAddress.getAllByName(InetAddress.java:1193) at java.net.InetAddress.getAllByName(InetAddress.java:1127) at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) at java.lang.Thread.run(Thread.java:748) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) at java.lang.Thread.run(Thread.java:748)
Solución
Intenta reiniciar el sincronizador. Por ejemplo:
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name
La prueba de disponibilidad falla para una clave de encriptación no válida.
Síntoma
Los pods apigee-runtime
no están en el estado Listo.
Diagnóstico
Cuando usas kubectl
para describir un Pod de apigee-runtime
con errores, verás este error: Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed
.
Por ejemplo:
$ kubectl describe pod -n namespace apigee-runtime-pod-name ... Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey, message = Invalid encryption key. Please check the length of the encryption key, associated contexts = []} ...
Solución
Las longitudes de clave de encriptación admitidas son 16 o 24 o 32 bytes, y el valor de la clave debe estar codificado en base64. Si deseas obtener más información para crear una clave con el formato correcto, consulta Encriptación de datos.
Visualiza los registros del Message Processor
Si deseas obtener más información para interpretar y ver los registros del procesador de mensajes, consulta Registros del entorno de ejecución.
Llama a un proxy de API desde el Pod del entorno de ejecución
En algunas situaciones para ayudar a aislar un problema, se recomienda verificar si puedes realizar una llamada de proxy de API directamente desde el pod apigee-runtime
y, de ese modo, omitir la puerta de enlace de entrada.
- Ejecuta el siguiente comando para reenviar al puerto 8443. Esto te permite llamar a la API en el Pod:
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
- Llama a un proxy de API implementado. Por ejemplo, en el que la ruta base del proxy es
ilove-apis
:curl -k -v https://0:8443//ilove-apis < HTTP/1.1 200 OK < X-Powered-By: Apigee < Access-Control-Allow-Origin: * < X-Frame-Options: ALLOW-FROM RESOURCE-URL < X-XSS-Protection: 1 < X-Content-Type-Options: nosniff < Content-Type: text/html; charset=utf-8 < Content-Length: 18 < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ" < Date: Fri, 13 Sep 2019 18:33:46 GMT < Via: 1.1 google < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982 < X-Apigee.dp.color: blue < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1 < X-Apigee.proxy.basepath: /ilove-apis < X-Apigee.target-latency: 9 < * Connection #0 to host 0 left intact <H2>I <3 APIs
Verifica la API de Management
Puedes usar la API que se describe a continuación para verificar si la API de Management funciona correctamente.
- Obtén los nombres de los pods en tu clúster:
kubectl get pods -n namespace
- Usa redirección de puertos para obtener acceso al pod
apigee-runtime
. La sintaxis para la redirección de puertos es la siguiente:kubectl port-forward -n namespace podname 8843:8843
Por ejemplo:
kubectl port-forward -n apigee \ apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
- Luego, en otra ventana de la terminal, usa una utilidad como
curl
para enviar una solicitud a la APIclassification/tree
, como se muestra en el siguiente ejemplo:curl -k https://0:8843/v1/classification/tree
A continuación, se muestra una respuesta de ejemplo, en la que se enumera la información sobre los proxies implementados en el entorno de “prueba”:
[ { "condition" : "(always matches)", "virtualHost" : { "env" : "test", "name" : "default", "org" : "my-organization", "tree" : { "elements" : [ { "application" : "myproxy", "basePath" : "/myproxy", "name" : "default", "revision" : "1" } ], "name" : "IdentificationTree" } } } ]
Usa el modo DEPURACIÓN
Para solucionar problemas, puedes habilitar el modo DEPURACIÓN para incluir información más detallada en los registros del pod apigee-runtime
.
- Obtén una lista de los pods de tu espacio de nombres:
kubectl get pods -n namespace
- Elige cualquiera de los pods
apigee-runtime
enumerados para depurar. - Ejecuta el comando de redirección de puertos para ese Pod. Por ejemplo:
kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
- Abre otra terminal y llama a la siguiente API a fin de habilitar la depuración:
curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
- Ejecuta el comando
kubectl logs
para verificar el registro que está en modo DEPURACIÓN. Por ejemplo:kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
- Cuando termines de examinar el registro DEPURACIÓN, restablece el nivel de registro a INFO (el valor predeterminado). Por ejemplo:
curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
- Ejecuta el comando
kubectl logs
para asegurarte de que el registro vuelva a estar en modo INFO.