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

Solutions pour Temporal en tant que service dans Automation Suite sur EKS/AKS.

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 aux exigences minimales de votre profil TaaS. La valeur PostgreSQL par défaut de 100 est insuffisante. Pour les valeurs requises par profil, reportez-vous à la 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 à zéro réplique. Pour de plus amples informations sur les exigences actives/passives pour TaaS, consultez la section Aperçu.

La tâche d'initialisation de TaaS échoue dans un environnement proxy

Description

Lorsque Maestro ou Temporal en tant que service est activé dans un environnement proxy, la tâche d'initialisation de TaaS échoue avec l'erreur suivante:

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

Les journaux des pods taas-temporal-frontend, taas-temporal-history et taas-temporal-internal-frontend contiennent l'erreur suivante:

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

Les services TaaS se connectent entre eux par l'adresse IP du pod. Si la liste no_proxy ne couvre pas une adresse IP de pod, la connexion passe au proxy, qui ne peut pas atteindre les adresses IP de pod et rejette la demande. Cela se produit lorsque les adresses IP du pod se situent en dehors des plages de la liste no_proxy , par exemple avec la mise en réseau personnalisée EKS ou AKS avec superposition CNI Azure.

Solution

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

1. Ajoutez les plages CIDR du pod et les plages CIDR du sous-réseau de nœud à proxy.no_proxy dans input.json. Pour de plus amples informations, consultez la section Proxy.

2. Appliquez la configuration:

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