Esta página se ha traducido con Cloud Translation API.

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

En este tema se describen los pasos que puede seguir para solucionar problemas con el procesador de mensajes. El procesador de mensajes forma parte del componente apigee-runtime. Consulta también la información general sobre la configuración del servicio del entorno de ejecución.

La sonda de preparación falla con el código de estado HTTP 500

Síntoma

Uno o varios pods apigee-runtime no están en el estado Ready.

Mensaje de error

Cuando usas kubectl para describir un pod apigee-runtime fallido, aparece 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
...

Posibles motivos

El error significa que no hay ningún contrato activo disponible para que el procesador de mensajes sirva el tráfico. En este estado, el procesador de mensajes no puede considerarse "listo".

Causa	Descripción
Problema de conexión del sincronizador al plano de gestión	El sincronizador no puede conectarse al plano de gestión. Este problema suele producirse cuando se anula la URL `contractProvider` y se asocia la cuenta de servicio incorrecta. Por ejemplo, si configuras una cuenta de servicio para una implementación de staging con una URL `contractProvider` que apunta al servidor de producción.
Problema de conexión del procesador de mensajes al sincronizador	Si el nuevo MP aparece como parte de un reinicio de escalado automático o de pod, es posible que veas este error. Por lo general, este problema se produce cuando el sincronizador no funciona y el MP no ha podido cargar su contrato.

Diagnóstico: problema de conexión del sincronizador al plano de gestión

Para diagnosticar un problema de conexión entre el sincronizador y el plano de gestión, haz lo siguiente:

Lista 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

Comprueba 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 de la carpeta del contrato número. 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
```
Salir del shell del pod.

Resolución

Si falta version.properties o hay una versión incorrecta, como se ha explicado anteriormente, consulta los registros del sincronizador para intentar determinar por qué no se descargan los contratos más recientes. Por ejemplo:

kubectl logs -f -n namespace synchronizer-pod-name

Para obtener información sobre cómo interpretar los registros del sincronizador, consulta Registros del sincronizador. Si el sincronizador no funciona, prueba a reiniciarlo con apigeectl. Por ejemplo:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml -c synchronizer

Diagnóstico: problema de conexión del procesador de mensajes al sincronizador

Para diagnosticar un problema de conexión entre el procesador de mensajes y el sincronizador, haz lo siguiente:

Lista los pods del clúster:
```
kubectl get pods -n namespace
```

Consulta los registros de tiempo de ejecución para intentar averiguar 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, si el nuevo MP aparece como parte de un reinicio de escalado automático o de pod, el MP no cargue los contratos. Por lo general, el problema se produce cuando el sincronizador no funciona, lo que impide que el mercado 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)

Resolución

Prueba a reiniciar el sincronizador. Por ejemplo:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml -c synchronizer

La sonda de preparación falla debido a una clave de cifrado no válida

Síntoma

Los pods apigee-runtime no están en el estado Ready.

Diagnóstico

Cuando usas kubectl para describir un pod apigee-runtime que ha fallado, aparece 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 = []}
...

Resolución

Las longitudes de clave de cifrado admitidas son 16, 24 o 32 bytes, y el valor de la clave debe estar codificado en Base64. Para obtener más información sobre cómo crear una clave con el formato adecuado, consulta Cifrado de datos.

Ver registros del procesador de mensajes

Para obtener información sobre cómo ver e interpretar los registros del procesador de mensajes, consulta Registros de tiempo de ejecución.

Llamar a un proxy de API desde el pod de tiempo de ejecución

En algunas situaciones, para ayudar a aislar un problema, puede que quieras comprobar si puedes hacer una llamada de proxy de API directamente desde el interior del pod apigee-runtime y, de este modo, omitir la puerta de enlace de entrada.

Ejecuta el siguiente comando para reenviar al puerto 8443. De esta forma, puede llamar a la API en el pod:
```
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
```

Llama a un proxy de API desplegado. Por ejemplo, si 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

Consultar la API Management

Puede usar la API que se describe a continuación para comprobar si la API Management funciona correctamente.

Obtén los nombres de los pods de tu clúster:
```
kubectl get pods -n namespace
```

Usa el reenvío de puertos para acceder 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

A continuación, en otra ventana de 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 que incluye información sobre los proxies implementados en el entorno "test":

[ {
  "condition" : "(always matches)",
  "virtualHost" : {
    "env" : "test",
    "name" : "default",
    "org" : "my-organization",
    "tree" : {
      "elements" : [ {
        "application" : "myproxy",
        "basePath" : "/myproxy",
        "name" : "default",
        "revision" : "1"
      } ],
      "name" : "IdentificationTree"
    }
  }
} ]

Usar el modo DEBUG

Para facilitar la solución de problemas, puedes habilitar el modo DEBUG para incluir información más detallada en los registros de pods de apigee-runtime.

Lista los pods de tu espacio de nombres:
```
kubectl get pods -n namespace
```
Elige uno de los pods apigee-runtime de la lista para depurarlo.

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 para habilitar la depuración:
```
curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
```
Ejecuta el comando kubectl logs para consultar el registro en modo DEBUG. Por ejemplo:
```
kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
```
Cuando hayas terminado de examinar el registro DEBUG, vuelve a definir el nivel de registro en 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 vuelve al modo INFO.

Guía de solución de problemas del procesador de mensajes Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

La sonda de preparación falla con el código de estado HTTP 500

Síntoma

Mensaje de error

Posibles motivos

Diagnóstico: problema de conexión del sincronizador al plano de gestión

Resolución

Diagnóstico: problema de conexión del procesador de mensajes al sincronizador

Resolución

La sonda de preparación falla debido a una clave de cifrado no válida

Síntoma

Diagnóstico

Resolución

Ver registros del procesador de mensajes

Llamar a un proxy de API desde el pod de tiempo de ejecución

Consultar la API Management

Usar el modo DEBUG

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