Résolution des problèmes de Temporel en tant que service

Résoudre les problèmes avec Temporal en tant que service dans Automation Suite sur OpenShift.

Les workflows Maestro sont bloqués ou ne démarrent pas

Symptômes : les instances de processus Maestro restent dans un état en attente ou en cours d'exécution sans progresser.

Cause : les pods TaaS ne sont pas disponibles ou défectueux, ce qui empêche les tâches de workflow d'être envoyées ou récupérées par les travailleurs.

Résolution

1. Vérifiez le statut de tous les pods SaaS :

   kubectl get pods -n uipath | grep taas
   

2. Identifiez tous les pods qui ne sont pas dans l'état Running et consultez leurs journaux :

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

3. Recherchez les entrées de niveau warn et error . Les causes courantes sont les échecs de connectivité de la base de données et l’épuisement des ressources.
4. Si le pod taas-temporal-history redémarre, vérifiez l'utilisation de la mémoire. Le service d'historique consomme beaucoup de mémoire et son autoscaler est configuré en fonction de l'utilisation de la mémoire.

Les pods SaaS fonctionnent en boucle de plantage

Symptôme : Un ou plusieurs pods taas-temporal-* sont dans l'état CrashLoopBackOff .

Cause : la cause la plus courante est l'échec de la connexion à la base de données PostgreSQL au démarrage.

Résolution

1. Examinez les journaux du pod affecté :

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

2. Recherchez les erreurs de connexion faisant référence au magasin de persistance ou de visibilité.
3. Vérifiez que le serveur PostgreSQL est accessible depuis le cluster et que les informations d'identification dans la clé secrète taas-temporal-app-secrets sont correctes.
4. Confirmez que la valeur PostgreSQL max_connections répond à l'exigence minimale de votre profil TaaS. La valeur PostgreSQL par défaut de 100 est insuffisante. Pour connaître les valeurs requises par profil, reportez-vous à Base de données SQL.

L’exécution du workflow est lente

Symptôme : les workflows Maestro démarrent, mais les tâches prennent plus de temps que prévu pour être récupérées ou terminées.

Cause : SaaS dispose de ressources insuffisantes, le pool de connexions PostgreSQL est épuisé ou le nombre d'interrogateurs de travail est insuffisant pour la charge actuelle.

Résolution

1. Vérifiez les métriques Prometheus pour temporal_activity_schedule_to_start_latency_bucket et temporal_workflow_task_schedule_to_start_latency_bucket. Des valeurs élevées indiquent que les tâches attendent dans la file d’attente plus longtemps que prévu.
2. Vérifiez que l'instance PostgreSQL dispose de suffisamment de connexions disponibles. L’épuisement du pool de connexions entraîne des délais d’attente de persistance sous la charge.
3. Examinez l'utilisation des ressources du pod pour taas-temporal-history et taas-temporal-matching. Si les pods sont limités au processeur ou à la mémoire, envisagez d'ajuster les limites de ressources ou de mettre le déploiement à l'échelle.

Accéder à l’interface utilisateur de Temporel pour les diagnostics

Par défaut, l'interface utilisateur Web temporaire (taas-temporal-web) n'est pas exposée en dehors du cluster. Pour y accéder à des fins de diagnostic, transférez le port au pod :

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

Ouvrez http://localhost:8008 dans un navigateur. Aucune connexion n’est requise lors de l’accès par l’intermédiaire du port.

L'interface utilisateur temporel vous permet d'inspecter des exécutions de workflow individuelles, d'afficher l'historique d'exécution et d'identifier les activités ayant échoué ou expiré.

Verrouiller les erreurs de contenu dans les journaux TaaS

Symptôme : les journaux SaaS contiennent des erreurs faisant référence à un conflit de verrouillage ou à des écritures de base de données en conflit.

Cause : deux clusters Kubernetes sont connectés simultanément au même magasin de persistance PostgreSQL. Un seul cluster peut exécuter activement SaaS à la fois.

Résolution

Dans un déploiement actif/passif, mettez à l’échelle tous les déploiements TaaS sur le cluster passif pour aucun réplica. Pour de plus amples informations sur les exigences actives/passives du TaaS, consultez la section Vue d'ensemble.

TaaS init job fails in a proxy environment

Description

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 when the clusterNetwork CIDR falls outside 10.0.0.0/8.

Solution

Pour résoudre ce problème, procédez comme suit :

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