Solución de problemas de Temporal como servicio

Resuelve problemas con Temporal como servicio en Automation Suite en OpenShift.

Los flujos de trabajo de Maestro están atascados o no se inician

Síntoma: las instancias de proceso de Maestro permanecen en estado pendiente o en ejecución sin progresar.

Causa: los pods de TaaS no están disponibles o no están en buen estado, lo que impide que los trabajadores envíen o recojan las tareas del flujo de trabajo.

Resolución

1. Comprueba el estado de todos los pods de TaaS:

   kubectl get pods -n uipath | grep taas
   

2. Identifique cualquier pod que no esté en estado Running y revise sus registros:

   kubectl logs -n uipath <pod-name> --tail=100
   

3. Busca las entradas de nivel warn y error . Las causas comunes incluyen fallos de conectividad de la base de datos y agotamiento de recursos.
4. Si el pod taas-temporal-history se está reiniciando, comprueba el uso de memoria. El servicio de historial hace un uso intensivo de la memoria y su escalador automático está configurado en función de la utilización de la memoria.

Los pods de TaaS se bloquean

Síntoma: uno o más pods taas-temporal-* están en estado CrashLoopBackOff .

Causa: la causa más común es un fallo en la conexión a la base de datos PostgreSQL en el inicio.

Resolución

1. Revisa los registros del pod afectado:

   kubectl logs -n uipath <pod-name> --previous
   

2. Comprueba si hay errores de conexión que hagan referencia al almacén de persistencia o visibilidad.
3. Comprueba que se puede acceder al servidor PostgreSQL desde el clúster y que las credenciales en el secreto taas-temporal-app-secrets son correctas.
4. Confirme que el valor max_connections de PostgreSQL cumple el requisito mínimo para su perfil TaaS. El valor predeterminado de PostgreSQL de 100 no es suficiente. Para obtener los valores necesarios por perfil, consulta Base de datos SQL.

La ejecución del flujo de trabajo es lenta

Síntoma: los flujos de trabajo de Maestro se inician, pero las tareas tardan más de lo esperado en ser recogidas o completadas.

Causa: TaaS no tiene suficientes recursos, el grupo de conexiones de PostgreSQL está agotado o el número de sondeadores de trabajadores es insuficiente para la carga actual.

Resolución

1. Comprueba las métricas de Prometheus para temporal_activity_schedule_to_start_latency_bucket y temporal_workflow_task_schedule_to_start_latency_bucket. Los valores altos indican que las tareas están esperando en la cola más tiempo del esperado.
2. Comprueba que la instancia de PostgreSQL tenga suficientes conexiones disponibles. El agotamiento del grupo de conexiones provoca tiempos de espera de persistencia bajo carga.
3. Revise el uso de recursos del pod para taas-temporal-history y taas-temporal-matching. Si los pods tienen restricciones de CPU o de memoria, considera ajustar los límites de recursos o escalar la implementación.

Acceder a la IU temporal para diagnósticos

La IU web temporal (taas-temporal-web) no se expone fuera del clúster de forma predeterminada. Para acceder a él con fines de diagnóstico, reenvía el puerto al pod:

kubectl port-forward -n uipath deployment/taas-temporal-web 8008:8008

Abre http://localhost:8008 en un navegador. No es necesario iniciar sesión al acceder a través de reenvío de puerto.

La IU temporal te permite inspeccionar ejecuciones de flujos de trabajo individuales, ver el historial de ejecuciones e identificar actividades fallidas o con tiempo de espera agotado.

Bloquear errores de contención en los registros de TaaS

Síntoma: los registros de TaaS contienen errores que hacen referencia a la contención de bloqueo o escrituras en la base de datos en conflicto.

Causa: dos clústeres de Kubernetes están conectados al mismo almacén de persistencia de PostgreSQL simultáneamente. Solo un clúster puede ejecutar activamente TaaS a la vez.

Resolución

En una implementación activa/pasiva, escala todas las implementaciones de TaaS en el clúster pasivo a cero réplicas. Para obtener más información sobre los requisitos activos/pasivos para TaaS, consulta Información general.

El trabajo de inicio de TaaS falla en un entorno de proxy

Descripción

Cuando Maestro o Temporal como servicio (TaaS) está habilitado en un entorno de proxy, el trabajo de inicio de TaaS falla con el siguiente error:

Unable to get namespace default info ... context deadline exceeded

Los registros de pod taas-temporal-frontend, taas-temporal-history y taas-temporal-internal-frontend contienen el siguiente error:

failed to do connect handshake ... HTTP/1.1 503

Los servicios TaaS se conectan entre sí por la dirección IP del pod. Si la lista no_proxy no cubre una dirección IP de pod, la conexión se dirige al proxy, que no puede acceder a las direcciones IP de pod y rechaza la solicitud. Esto sucede cuando las direcciones IP de los pods quedan fuera de los rangos de la lista no_proxy , por ejemplo, cuando el clusterNetwork CIDR cae fuera de 10.0.0.0/8.

Solución

Para solucionar el problema, sigue los siguientes pasos:

1. Añade los rangos CIDR del pod y los rangos CIDR de la subred del nodo a proxy.no_proxy en input.json. Para obtener más información, consulta Proxy.

2. Aplicar la configuración:

   uipathctl manifest apply input.json --versions versions.json