Solución de problemas de Temporal como servicio

Soluciones para problemas temporales como servicio en Automation Suite en EKS/AKS.

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. Confirm that the PostgreSQL max_connections value meets the minimum requirement for your TaaS profile. The default PostgreSQL value of 100 is insufficient. For the required values per profile, refer to SQL database.

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

In an active/passive deployment, scale all TaaS deployments on the passive cluster to zero replicas. For details on active/passive requirements for TaaS, refer to Overview.

TaaS init job fails in a proxy environment

Descripción

When Maestro or Temporal as a Service (TaaS) is enabled in a proxy environment, the TaaS init job fails with the following error:

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

The taas-temporal-frontend, taas-temporal-history, and taas-temporal-internal-frontend pod logs contain the following error:

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

TaaS services connect to each other by pod IP address. If the no_proxy list does not cover a pod IP address, the connection goes to the proxy, which cannot reach pod IP addresses and rejects the request. This happens when pod IP addresses fall outside the ranges in the no_proxy list, for example with EKS custom networking or AKS with Azure CNI Overlay.

Solución

Para solucionar el problema, sigue los siguientes pasos:

1. Add the pod CIDR ranges and the node subnet CIDR ranges to proxy.no_proxy in input.json. For details, refer to Proxy.

2. Apply the configuration:

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