Temporär als Dienst-Fehlerbehebung

Lösungen für Temporal as a Service-Probleme in der Automation Suite auf EKS/AKS.

Maestro-Workflows hängen fest oder werden nicht gestartet

Symptome: Maestro-Prozessinstanzen verbleiben im Status „Ausstehend“ oder „Wird ausgeführt“ ohne Fortschritt.

Ursache: TaaS-Pods sind nicht verfügbar oder fehlerhaft, sodass Workflow-Aufgaben nicht verteilt oder von Mitarbeitern aufgenommen werden können.

Resolution

1. Überprüfen Sie den Status aller TaaS-Pods:

   kubectl get pods -n uipath | grep taas
   

2. Identifizieren Sie alle Pods, die sich nicht im Status Running befinden, und überprüfen Sie ihre Protokolle:

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

3. Suchen Sie nach Einträgen der Ebenen warn und error . Häufige Ursachen sind Datenbankverbindungsfehler und Ressourcenerschöpfung.
4. Wenn der taas-temporal-history -Pod neu gestartet wird, überprüfen Sie die Speichernutzung. Der Verlaufsdienst ist speicherintensiv und sein Autoscaler ist für die Speichernutzung konfiguriert.

TaaS-Pods führen eine Absturzschleife durch

Symptome: Ein oder mehrere taas-temporal-* -Pods befinden sich im Status CrashLoopBackOff .

Ursache: Die häufigste Ursache ist, dass beim Start die Verbindung mit der PostgreSQL-Datenbank fehlgeschlagen ist.

Resolution

1. Überprüfen Sie die Protokolle des betroffenen Pods:

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

2. Prüfen Sie auf Verbindungsfehler, die auf den Persistenz- oder Sichtbarkeitsspeicher verweisen.
3. Stellen Sie sicher, dass der PostgreSQL-Server vom Cluster aus erreichbar ist und dass die Anmeldeinformationen im Geheimnis taas-temporal-app-secrets korrekt sind.
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.

Workflow-Ausführung ist langsam

Symptome: Maestro-Workflows werden gestartet, aber es dauert länger als erwartet, bis Aufgaben aufgenommen oder abgeschlossen werden.

Ursache: TaaS hat zu wenige Ressourcen, der PostgreSQL-Verbindungspool ist erschöpft oder die Anzahl der Worker-Abrufe ist für die aktuelle Last unzureichend.

Resolution

1. Überprüfen Sie die Prometheus-Metriken für temporal_activity_schedule_to_start_latency_bucket und temporal_workflow_task_schedule_to_start_latency_bucket. Hohe Werte bedeuten, dass Aufgaben länger als erwartet in der Warteschlange warten.
2. Überprüfen Sie, ob die PostgreSQL-Instanz über ausreichend verfügbare Verbindungen verfügt. Die Erschöpfung des Verbindungspools führt zu Persistenz-Timeouts unter Last.
3. Überprüfen Sie die Pod-Ressourcennutzung für taas-temporal-history und taas-temporal-matching. Wenn Pods durch CPU oder Speicher eingeschränkt sind, sollten Sie die Ressourcenlimits anpassen oder die Bereitstellung skalieren.

Zugriff auf die temporäre Benutzeroberfläche für Diagnosezwecke

Die temporäre Web-UI (taas-temporal-web) wird standardmäßig nicht außerhalb des Clusters verfügbar gemacht. Um zu Diagnosezwecken darauf zuzugreifen, leiten Sie den Port zum Pod weiter:

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

Öffnen Sie http://localhost:8008 in einem Browser. Beim Zugriff über die Portweiterleitung ist keine Anmeldung erforderlich.

Mit der temporären Benutzeroberfläche können Sie einzelne Workflow-Ausführungen überprüfen, den Ausführungsverlauf anzeigen und fehlgeschlagene oder Zeitüberschreitungen identifizieren.

Sperrkonfliktfehler in TaaS-Protokollen

Symptome: TaaS-Protokolle enthalten Fehler, die auf Sperrkonflikte oder Schreibkonflikte in der Datenbank verweisen.

Ursache: Zwei Kubernetes-Cluster sind gleichzeitig mit demselben PostgreSQL-Persistenzspeicher verbunden. Es kann jeweils nur ein Cluster aktiv TaaS ausführen.

Resolution

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

Beschreibung

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.

Lösung

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

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