Guía de solución de problemas del procesador de mensajes

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:

  1. Obtén una lista de los pods del clúster.
    kubectl get pods -n namespace
  2. 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
  3. 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
  4. 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
  5. 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 es  750. Por lo tanto, no coinciden: 
    dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  6. 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:

  1. Obtenga una lista de los pods del clúster.
    kubectl get pods -n namespace
  2. 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.

  1. 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
  2. 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.

  1. Obtén los nombres de los pods en tu clúster:
    kubectl get pods -n namespace
  2. 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
  3. Luego, en otra ventana de la terminal, usa una utilidad como curl para enviar una solicitud a la API classification/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.

  1. Obtén una lista de los pods de tu espacio de nombres: 
    kubectl get pods -n namespace
  2. Elige cualquiera de los pods apigee-runtime enumerados para depurar.
  3. 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
  4. 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
  5. 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
  6. 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
  7. Ejecuta el comando kubectl logs para asegurarte de que el registro vuelva a estar en modo INFO.