Temporal as a Service のトラブルシューティング

OpenShift の Automation Suite の Temporal as a Service に関する問題のトラブルシューティングを行います。

Maestro ワークフローがスタックしている、または開始されない

症状： Maestro プロセスのインスタンスは、処理が進行することなく保留中または実行中ステートのままです。

原因： TaaS ポッドが利用できないか、異常であるため、ワークフロー タスクが作業者によってディスパッチまたはピックアップされません。

解決方法

1. すべての TaaS ポッドのステータスを確認します。

   kubectl get pods -n uipath | grep taas
   

2. Runningステートではないポッドを特定し、そのログを確認します。

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

3. warn レベルと error レベルのエントリを探します。一般的な原因には、データベース接続のエラーやリソースの枯渇などがあります。
4. taas-temporal-history ポッドが再起動している場合は、メモリ使用量を確認します。履歴サービスはメモリを大量に消費し、そのオートスケーラーはメモリ使用率に基づいて構成されます。

TaaS ポッドがクラッシュ ループする

症状： 1 つ以上の taas-temporal-* ポッドが CrashLoopBackOff 状態です。

原因： 最も一般的な原因は、起動時にPostgreSQLデータベースに接続できないことです。

解決方法

1. 影響を受けるポッドのログを確認します。

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

2. 永続性ストアまたは可視性ストアを参照している接続エラーがないか確認します。
3. クラスターから PostgreSQL サーバーに到達可能であり、 taas-temporal-app-secrets シークレットの資格情報が正しいことを確認します。
4. PostgreSQL の max_connections 値が TaaS プロファイルの最小要件を満たしていることを確認します。PostgreSQLのデフォルト値である100では不十分です。プロファイルごとに必要な値については、「 SQL データベース」をご覧ください。

ワークフローの実行が遅い

症状： Maestro ワークフローは開始するが、タスクが取得または完了するまでに予想以上に時間がかかる

原因： TaaS のリソースが不足しているか、PostgreSQL 接続プールが使い果たされているか、ワーカー ポーラーの数が現在の負荷に対して不十分です。

解決方法

1. Prometheus メトリックで temporal_activity_schedule_to_start_latency_bucket と temporal_workflow_task_schedule_to_start_latency_bucketを確認します。値が大きい場合は、タスクが予想よりも長くキュー内で待機していることを示します。
2. PostgreSQL インスタンスに十分な使用可能な接続があることを確認します。接続プールが枯渇すると、負荷がかかった状態で永続性タイムアウトが発生します。
3. taas-temporal-historyとtaas-temporal-matchingのポッド リソースの使用状況を確認します。ポッドに CPU またはメモリの制約がある場合は、リソースの制限を調整するか、デプロイをスケーリングすることを検討してください。

診断のためのテンポラル UI へのアクセス

テンポラル Web UI (taas-temporal-web) は、既定ではクラスター外に公開されません。診断目的でアクセスするには、ポッドにポートフォワードします。

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

ブラウザーで http://localhost:8008 を開きます。ポートフォワードでアクセスする場合、ログインは必要ありません。

テンポラル UI では、個々のワークフロー実行の検査、実行履歴の表示、失敗やタイムアウトのアクティビティの特定を行うことができます。

TaaS ログのロック競合エラー

症状： TaaS ログには、ロックの競合または競合するデータベース書き込みを参照するエラーが含まれています。

原因： 2つのKubernetesクラスタが同じPostgreSQL永続ストアに同時に接続されています。一度にアクティブに TaaS 実行できるクラスターは 1 つだけです。

解決方法

アクティブ/パッシブ デプロイでは、パッシブ クラスター上のすべての TaaS デプロイをゼロ レプリカにスケーリングします。TaaS のアクティブ/パッシブ要件について詳しくは、「 概要」をご覧ください。

TaaS init job fails in a proxy environment

説明

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.

解決策

この問題に対処するには、次の手順を実行します。

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