通知を受け取る

UiPath Automation Suite

UiPath Automation Suite ガイド

トラブルシューティング

このページでは、Automation Suite の設定時に発生する可能性のある問題を修正する方法について説明します。

トラブルシューティング方法

Automation Suite generates logs you can explore whenever you need to troubleshoot installation errors. You can find all details on the issues occurring during installation in a log file saved in a directory that also contains the install-uipath.sh script. Each execution of the installer generates a new log file that follows the install-$(date +'%Y-%m-%dT%H_%M_%S').log naming convention, and that you can look into whenever encountering any installation issues.
If you want to troubleshoot post-installation errors, use the Support Bundle tool.

 

インストール時にサービスをトラブルシューティングする方法

クラスター サーバー ノードの 1 つで次の手順を実行します。

  1. Kubernetes へのアクセス権を取得します。
on server nodes:
export KUBECONFIG="/etc/rancher/rke2/rke2.yaml"
export PATH="$PATH:/usr/local/bin:/var/lib/rancher/rke2/bin"

on agent nodes:
export KUBECONFIG="/var/lib/rancher/rke2/agent/kubelet.kubeconfig"
export PATH="$PATH:/usr/local/bin:/var/lib/rancher/rke2/bin"

# To validate, execute the following command which should not return an error:
kubectl get nodes
  1. 次のコマンドを使用して、ArgoCD パスワードを取得します。
kubectl get secrets/argocd-admin-password -n argocd --template '{{ .data.password }}' | base64 -d

  1. ArgoCD に接続します。
    a. Navigate to https://alm.<fqdn>/:443
    b. Login using admin as the username and the password obtained at Step 2.

  2. 次のように UiPath サービス アプリケーションを見つけます。
    a. Using the search bar provided in ArgoCD, type in uipath です。

    b. 次に、カードをクリックして UiPath アプリケーションを開きます。

    c. Check for the following: Application was not synced due to a failed job/pod です。

    d. 上記のエラーが存在する場合は、以下の手順を実行します。

    e. 赤いひびの入ったハート型のアイコンを探して、同期されていないコンポーネントを見つけます (下図を参照)。

    f. 右端のコンポーネント (通常はポッド) を開いて、[ログ] タブをクリックします。[ログ] には、ポッド障害の原因を示すエラー メッセージが含まれます。

    g. 未解決の設定の問題を解決したら、ホーム ページに戻り、UiPath アプリケーションの [同期] ボタンをクリックします。

 

クラスターをアンインストールする方法

クラスターで実行されている Kubernetes に固有の問題が発生した場合は、rke2 クラスターを直接アンインストールできます。

  1. インストール プロファイルに応じて、次のいずれかのコマンドを実行します。
    1.1. In an online setup, run the following script with elevated privileges, i.e. sudo, on each node of the cluster. This will uninstall the nodes.
function remove_rke2_entry_from_exclude() {
  local current_exclude_list new_exclude_list
  YUM_CONF_FILE=$1
  if [[ ! -s "${YUM_CONF_FILE}" ]];
  then
    # File is empty
    return
  fi
  current_exclude_list=$(grep 'exclude=' "${YUM_CONF_FILE}" | tail -1)
  if echo "$current_exclude_list" | grep -q 'rke2-*';
  then
    if [[ -w ${YUM_CONF_FILE} ]];
    then
      new_exclude_list=$(printf '%s\n' "${current_exclude_list//rke2-* /}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-*,/}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-\*/}")
      sed -i "/exclude=.*rke2-\*/d" "${YUM_CONF_FILE}"
      echo "${new_exclude_list}" >> "${YUM_CONF_FILE}"
    else
      error "${YUM_CONF_FILE} file is readonly and contains rke2-* under package exclusion. Please remove the entry for AS to work."
    fi
  fi
}

function enable_rke2_package_upgrade() {
  remove_rke2_entry_from_exclude /etc/dnf/dnf.conf
  remove_rke2_entry_from_exclude /etc/yum.conf
}

enable_rke2_package_upgrade

service_exists() {
    local n=$1
    if [[ $(systemctl list-units --all -t service --full --no-legend "$n.service" | cut -f1 -d' ') == $n.service ]]; then
        return 0
    else
        return 1
    fi
}
if service_exists rke2-server; then
  systemctl stop rke2-server
  systemctl disable rke2-server
fi
if service_exists rke2-agent; then
  systemctl stop rke2-agent
  systemctl disable rke2-agent
fi
if [ -e /usr/bin/rke2-killall.sh ]
then
    echo "Running rke2-killall.sh"
    /usr/bin/rke2-killall.sh > /dev/null
else
    echo "File not found: rke2-killall.sh"
fi
if [ -e /usr/bin/rke2-uninstall.sh ]
then
    echo "Running rke2-uninstall.sh"
    /usr/bin/rke2-uninstall.sh > /dev/null
else
    echo "File not found: rke2-uninstall.sh"
fi

crontab -l > backupcron
sed -i '/backupjob/d' backupcron > /dev/null
crontab backupcron > /dev/null
rm -rf backupcron > /dev/null
rm -rfv /usr/bin/backupjob > /dev/null
rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
umount -l -f /var/lib/rancher/rke2/server/db > /dev/null 2>&1 || true
rm -rfv /var/lib/rancher/* > /dev/null
umount -l -f /var/lib/rancher
rm -rfv /var/lib/rancher/* > /dev/null
while ! rm -rfv /var/lib/kubelet/* > /dev/null; do
  findmnt --list   --submounts  -n -o TARGET  --target /var/lib/kubelet | grep '/var/lib/kubelet/plugins'  | xargs -r umount -f -l
  sleep 5
done
umount -l -f /var/lib/kubelet
rm -rfv /var/lib/kubelet/* > /dev/null
rm -rfv /datadisk/* > /dev/null
umount -l -f /datadisk
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mount /var/lib/rancher
mkdir -p /var/lib/rancher/rke2/server/db/ && mount -a
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
echo "Uninstall RKE complete."

     1.2 In an offline setup, run the following script with elevated privileges, i.e. sudo, on each node of the cluster. This will uninstall the nodes.

function remove_rke2_entry_from_exclude() {
  local current_exclude_list new_exclude_list
  YUM_CONF_FILE=$1
  if [[ ! -s "${YUM_CONF_FILE}" ]];
  then
    # File is empty
    return
  fi
  current_exclude_list=$(grep 'exclude=' "${YUM_CONF_FILE}" | tail -1)
  if echo "$current_exclude_list" | grep -q 'rke2-*';
  then
    if [[ -w ${YUM_CONF_FILE} ]];
    then
      new_exclude_list=$(printf '%s\n' "${current_exclude_list//rke2-* /}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-*,/}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-\*/}")
      sed -i "/exclude=.*rke2-\*/d" "${YUM_CONF_FILE}"
      echo "${new_exclude_list}" >> "${YUM_CONF_FILE}"
    else
      error "${YUM_CONF_FILE} file is readonly and contains rke2-* under package exclusion. Please remove the entry for AS to work."
    fi
  fi
}

function enable_rke2_package_upgrade() {
  remove_rke2_entry_from_exclude /etc/dnf/dnf.conf
  remove_rke2_entry_from_exclude /etc/yum.conf
}

enable_rke2_package_upgrade

service_exists() {
    local n=$1
    if [[ $(systemctl list-units --all -t service --full --no-legend "$n.service" | cut -f1 -d' ') == $n.service ]]; then
        return 0
    else
        return 1
    fi
}
if service_exists rke2-server; then
  systemctl stop rke2-server
  systemctl disable rke2-server
fi
if service_exists rke2-agent; then
  systemctl stop rke2-agent
  systemctl disable rke2-agent
fi
if [ -e /usr/local/bin/rke2-killall.sh ]
then
  echo "Running rke2-killall.sh"
  /usr/local/bin/rke2-killall.sh > /dev/null
else
  echo "File not found: rke2-killall.sh"
fi
if [ -e /usr/local/bin/rke2-uninstall.sh ]
then
  echo "Running rke2-uninstall.sh"
  /usr/local/bin/rke2-uninstall.sh > /dev/null
else
    echo "File not found: rke2-uninstall.sh"
fi

crontab -l > backupcron
sed -i '/backupjob/d' backupcron > /dev/null
crontab backupcron > /dev/null
rm -rf backupcron > /dev/null
rm -rfv /usr/bin/backupjob > /dev/null
rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
umount -l -f /var/lib/rancher/rke2/server/db > /dev/null 2>&1 || true
rm -rfv /var/lib/rancher/* > /dev/null
umount -l -f /var/lib/rancher
rm -rfv /var/lib/rancher/* > /dev/null
while ! rm -rfv /var/lib/kubelet/* > /dev/null; do
  findmnt --list   --submounts  -n -o TARGET  --target /var/lib/kubelet | grep '/var/lib/kubelet/plugins'  | xargs -r umount -f -l
  sleep 5
done
umount -l -f /var/lib/kubelet
rm -rfv /var/lib/kubelet/* > /dev/null
rm -rfv /datadisk/* > /dev/null
umount -l -f /datadisk
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mount /var/lib/rancher
mkdir -p /var/lib/rancher/rke2/server/db/ && mount -a
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
echo "Uninstall RKE complete."
  1. アンインストール後、ノードを再起動します。

🚧

重要

When uninstalling one of the nodes from the cluster, you must run the following command: kubectl delete node <node_name>. This removes the node from the cluster.

 

オフライン成果物をクリーンアップしてディスク領域を改善する方法

オフライン インストールを実行する場合、一般に、使用されるオフライン成果物により、大きなディスク サイズが必要になります。

インストールが完了したら、これらのローカル成果物を削除できます。削除できなかった場合、クラスター操作時に不要なディスク容量の圧迫が発生する可能性があります。

次のコマンドを使用して、インストールが実行されたプライマリ サーバーでクリーンアップを実行できます。

  1. 次のコマンドを使用して、podman によってローカル コンテナー ストレージに読み込まれたすべてのイメージを削除します。
podman image rm -af
  1. Then remove the temporary offline folder, used with the flag --offline-tmp-folder. This parameter defaults to /tmp: 
rm -rf /path/to/temp/folder

 

一般的な問題

RHEL 8.4 OS でオフライン インストールを実行できない

説明

RHEL 8.4 をインストールして、podman を必要とするオフライン インストールを実行する場合、次の問題が発生する可能性があります。これらの問題は、podman および一緒にインストールされる OS に固有の問題です。以下の 2 つを参照してください。

潜在的な問題

  • クラスターに以下の両方をインストールすることはできない
    • podman-1.0.0-8.git921f98f.module+el8.3.0+10171+12421f43.x86_64
    • podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
  • パッケージ cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch requires podman >= 1.3.0, but none of the providers can be installed
  • ジョブの最適な候補をインストールできない
  • problem with installed package cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch

潜在的な問題

  • パッケージ podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 requires containernetworking-plugins >= 0.8.1-1, but none of the providers can be installed
  • 以下の両方をインストールすることはできない
    • containernetworking-plugins-0.7.4-4.git9ebe139.module+el8.3.0+10171+12421f43.x86_64
    • containernetworking-plugins-0.9.1-1.module+el8.4.0+10607+f4da7515.x86_64
  • パッケージ podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 requires podman = 3.0.1-6.module+el8.4.0+10607+f4da7515, but none of the providers can be installed
  • ジョブの最適な候補をインストールできない
  • problem with installed package podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
    (try to add --allowerasing to command line to replace conflicting packages or --skip-broken to skip uninstallable packages or --nobest to use not only best candidate packages)

解決策

You need to remove the current version of podman and allow Automation Suite to install the required version.

  1. Remove the current version of podman using the yum remove podman command.

  2. 現在のバージョンを削除した後、インストーラーを再実行すると、正しいバージョンがインストールされます。

 

バイナリがないため、オフライン インストールが失敗する

説明

オフライン インストール時に、ファブリック ステージで、次のエラー メッセージが表示されて実行が失敗します。

Error: overlay: can't stat program "/usr/bin/fuse-overlayfs": stat /usr/bin/fuse-overlayfs: no such file or directory

解決策

You need to remove the line containing the mount_program key from the podman configuration /etc/containers/storage.conf です。
コメント アウトするのではなく、行を削除してください。

 

サンドボックス イメージを取得できない

説明

You can receive an error message specific when trying to get the following sandbox image: index.docker.io/rancher/pause3.2

これは、オフライン インストールで発生します。

解決策

Restart either rke2-server または rke2-agent (depending on whether the machine that the pod is scheduled on is either a server or an agent).

To check which node the pod is scheduled on, run kubectl -n <namespace> get pods -o wide です。

# If machine is a Master node
systemctl restart rke2-server
# If machine is an Agent Node
systemctl restart rke2-agent

 

SQL 接続文字列の検証エラー

説明

次のような、接続文字列に関連するエラーが表示されることがあります。

Sqlcmd: Error: Microsoft Driver 17 for SQL Server :
Server—tcp : <connection string>
Login failed for user

このエラーは、すべての資格情報が正しい場合でも表示されます。接続文字列の検証に失敗しました。

解決策

接続文字列が次の構造を持つことを確認します。

Server=<Sql server host name>;User Id=<user_name for sql server>;Password=<Password>;Initial Catalog=<database name>;Persist Security Info=False;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Max Pool Size=100;

📘

注:

User Id は大文字と小文字を区別します。

 

ポッドが ArgoCD UI に表示されない

説明

ArgoCD UI にポッドが表示されず、アプリケーションおよび対応するデプロイのみが表示されることがあります。詳しくは、次の画像をご覧ください。

17631763

When clicking on any of the deployments, the following error is displayed: Unable to load data: EOF です。

19201920

解決策

この問題を修正するには、ArgoCD 名前空間からすべての Redis レプリカを削除して、再び戻ってくるのを待ちます。

kubectl -n argocd delete pod argocd-redis-ha-server-0 argocd-redis-ha-server-1 argocd-redis-ha-server-2

# Wait for all 3 pods to come back up
kubectl -n argocd get pods | grep argocd-redis-ha-server

 

オフライン インストールでの証明書の問題

説明

証明書が不明な機関によって署名されているというエラーが表示されることがあります。

Error: failed to do request: Head "https://sfdev1778654-9f843b23-lb.westeurope.cloudapp.azure.com:30071/v2/helm/audit-service/blobs/sha256:09bffbc520ff000b834fe1a654acd089889b09d22d5cf1129b0edf2d76554892": x509: certificate signed by unknown authority

解決策

rootCA とサーバー証明書の両方が、マシンの信頼されたストアに格納されている必要があります。

調べるには、次のコマンドを実行します。

[[email protected] ~]# find /etc/pki/ca-trust/source{,/anchors} -maxdepth 1 -not -type d -exec ls -1 {} +
/etc/pki/ca-trust/source/anchors/rootCA.crt
/etc/pki/ca-trust/source/anchors/server.crt

指定した証明書が、これらのコマンドの出力に含まれている必要があります。

または、次のコマンドを実行します。

[[email protected] ~]# openssl x509 -in /etc/pki/ca-trust/source/anchors/server.crt -text -noout

出力のサブジェクトの別名に完全修飾ドメイン名があることを確認します。

X509v3 Subject Alternative Name:
                DNS:sfdev1778654-9f843b23-lb.westeurope.cloudapp.azure.com

次のように CA 証明書を更新できます。

[[email protected] ~]# update-ca-trust

 

バンドルのダウンロード中のエラー

説明

The documentation lists wget as an option for downloading the bundles. Because of the large sizes, the connection may be interrupted and not recover.

解決策

One way to mitigate this could be to switch to a different download tool, such as azcopy (more information here). Run these commands, while updating the bundle URL to match the desired version/bundle combination.

wget https://aka.ms/downloadazcopy-v10-linux -O azcopy.tar.gz
tar -xvf ./azcopy.tar.gz
azcopy_linux_amd64_10.11.0/azcopy copy https://download.uipath.com/service-fabric/0.0.23-private4/sf-0.0.23-private4.tar.gz /var/tmp/sf.tar.gz --from-to BlobLocal

 

Longhorn エラー

Rook Ceph または Looker ポッドが Init ステートでスタックする

説明

ポッドに PVC をアタッチするのに必要なボリュームがないために、ノードの再起動時に問題が発生すると、Looker または Rook Ceph ポッドが Init ステートでスタックすることがあります。

次のコマンドを実行して、問題が本当に Longhorn に関連しているかを確認します。

kubectl get events -A -o json | jq -r '.items[] | select(.message != null) | select(.message | contains("cannot get resource \"volumeattachments\" in API group \"storage.k8s.io\""))'

Longhorn に関連している場合、このコマンドは問題の影響を受けるポッド名のリストを返します。コマンドから何も返されない場合、問題の原因は別にあります。

解決策

前のコマンドから空でない出力が返された場合は、次のスクリプトを実行して、問題のあるポッドを修正します。

#!/bin/bash


function wait_till_rollout() {
    local namespace=$1
    local object_type=$2
    local deploy=$3

    local try=0
    local maxtry=2
    local status="notready"

    while [[ ${status} == "notready" ]]  && (( try != maxtry )) ; do
        kubectl -n "$namespace" rollout status "$deploy" -w --timeout=600s; 
        # shellcheck disable=SC2181
        if [[ "$?" -ne 0 ]]; 
        then
            status="notready"
            try=$((try+1))
        else
            status="ready"
        fi
    done
    if [[ $status == "notready" ]]; then 
        echo "$deploy of type $object_type failed in namespace $namespace. Plz re-run the script once again to verify that it's not a transient issue !!!"
        exit 1
    fi
}

function fix_pv_deployments() {
    for pod_name in $(kubectl get events -A -o json | jq -r '.items[]  | select(.message | contains("cannot get resource \"volumeattachments\" in API group \"storage.k8s.io\"")) | select(.involvedObject.kind == "Pod") | .involvedObject.name + "/" + .involvedObject.namespace' | sort | uniq)
    do
        POD_NAME=$(echo "${pod_name}" | cut -d '/' -f1)
        NS=$(echo "${pod_name}" | cut -d '/' -f2)
        controller_data=$(kubectl -n "${NS}" get po "${POD_NAME}" -o json | jq -r '[.metadata.ownerReferences[] | select(.controller==true)][0] | .kind + "=" + .name')
        [[ $controller_data == "" ]] && error "Error: Could not determine owner for pod: ${POD_NAME}" && exit 1
        CONTROLLER_KIND=$(echo "${controller_data}" | cut -d'=' -f1)
        CONTROLLER_NAME=$(echo "${controller_data}" | cut -d'=' -f2)
        if [[ $CONTROLLER_KIND == "ReplicaSet" ]]
        then
            controller_data=$(kubectl  -n "${NS}" get "${CONTROLLER_KIND}" "${CONTROLLER_NAME}" -o json | jq -r '[.metadata.ownerReferences[] | select(.controller==true)][0] | .kind + "=" + .name')
            CONTROLLER_KIND=$(echo "${controller_data}" | cut -d'=' -f1)
            CONTROLLER_NAME=$(echo "${controller_data}" | cut -d'=' -f2)

            replicas=$(kubectl -n "${NS}" get "$CONTROLLER_KIND" "$CONTROLLER_NAME" -o json | jq -r '.status.replicas')
            unavailable_replicas=$(kubectl -n "${NS}" get "$CONTROLLER_KIND" "$CONTROLLER_NAME" -o json | jq -r '.status.unavailableReplicas')

            if [ -n "$unavailable_replicas" ]; then 
                available_replicas=$((replicas - unavailable_replicas))
                if [ $available_replicas -eq 0 ]; then
                    kubectl -n "$NS" scale "$CONTROLLER_KIND" "$CONTROLLER_NAME" --replicas=0
                    sleep 15
                    kubectl -n "$NS" scale "$CONTROLLER_KIND" "$CONTROLLER_NAME" --replicas="$replicas"
                    deployment_name="$CONTROLLER_KIND/$CONTROLLER_NAME"
                    wait_till_rollout "$NS" "deploy" "$deployment_name"
                fi 
            fi
        fi
    done
}

fix_pv_deployments

 

StatefulSet ボリューム アタッチ エラー

RabbitMQ または cattle-monitoring-system 内のポッドや、その他の StatefulSet ポッドが init ステートでスタックしています。

説明

ノードの電源障害時やアップグレード時に問題が発生すると、ポッドに PVC をアタッチするのに必要なボリュームがないために、RabbitMQ または cattle-monitoring-system 内のポッドが init ステートでスタックすることがあります。

次のコマンドを実行して、問題が本当に StatefulSet ボリュームのアタッチに関連しているかを確認します。

kubectl -n <namespace> describe pod <pod-name> | grep "cannot get resource \"volumeattachments\" in API group \" storage.k8s.io\""

StatefulSet ボリュームのアタッチに関連している場合、エラー メッセージが表示されます。

解決策

この問題を修正するには、ノードを再起動します。

 

永続ボリュームを作成できない

説明

Longhorn は正常にインストールされますが、永続ボリュームを作成できません。

解決策

Verify if the kernel modules are successfully loaded in the cluster by using the command lsmod | grep <module_name> です。
置換 (Replace) <module_name> with each of the kernel modules below:

  • libiscsi_tcp
  • libiscsi
  • iscsi_tcp
  • scsi_transport_iscsi

欠落しているモジュールを読み込みます。

 

rke2-coredns-rke2-coredns-autoscaler ポッドが CrashLoopBackOff になる

説明

ノードの再起動後に、rke2-coredns-rke2-coredns-autoscaler が CrashLoopBackOff になることがあります。このことは、Automation Suite に影響しません。

解決策

Delete the rke2-coredns-rke2-coredns-autoscaler pod that is in CrashLoopBackOff using the following command: kubectl delete pod <pod name> -n kube-system です。

 

Redis プローブの障害

説明

ノード ID ファイルが存在しない場合、Redis プローブは失敗することがあります。これは、ポッドがまだブートストラップされていない場合に発生する可能性があります。

この問題を自動的に修正するリカバリー ジョブがあります。このジョブの実行時には、以下の手順を実行しないでください。

Redis Enterprise クラスターが半数以上のノードとの接続を失うと (ノードのエラーまたはネットワーク分断により)、クラスターはクライアント接続への応答を停止します。ポッドも、クラスターへの再参加に失敗します。

解決策

  1. 次のコマンドを使用して、Redis クラスターとデータベースを削除します。
kubectl delete redb -n redis-system redis-cluster-db --force --grace-period=0 &
kubectl delete rec -n redis-system redis-cluster --force --grace-period=0 &
kubectl patch redb -n redis-system redis-cluster-db --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"finalizer.redisenterprisedatabases.app.redislabs.com"}]'
kubectl patch rec redis-cluster -n redis-system --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"redbfinalizer.redisenterpriseclusters.app.redislabs.com"}]'
kubectl delete job redis-cluster-db-job -n redis-system
  1. ArgoCD UI に移動して、redis-cluster アプリケーションを同期します。

 

RKE2 サーバーの起動に失敗する

説明

サーバーを起動できません。RKE2 が適切に起動しない理由は複数あり、通常はログで確認できます。

解決策

次のコマンドを使用してログを確認します。

journalctl -u rke2-server

考えられる理由 (ログに基づく): クラスター内のラーナー メンバーの数が多すぎる。

Too many etcd servers are added to the cluster, and there are two learner nodes trying to be promoted. More information here: Runtime reconfiguration.

次の手順を実行します。

  1. 通常の状況では、十分に時間がある場合、ノードはフル メンバーになるはずです。
  2. アンインストール/再インストールのサイクルを試行できます。

Alternatively, this could be caused by a networking problem. Ensure you have configured the machine to enable the necessary ports.

 

停止されたノードに対してノードのドレインが行われない

説明

クラスター内でノードが停止し、15 分後に対応するポッドが利用可能なノードに再スケジュールされない場合は、次のスクリプトを実行して手動でノードのドレインを行います。

#!/bin/sh

KUBECTL="/usr/local/bin/kubectl"

# Get only nodes which are not drained yet
NOT_READY_NODES=$($KUBECTL get nodes | grep -P 'NotReady(?!,SchedulingDisabled)' | awk '{print $1}' | xargs echo)
# Get only nodes which are still drained
READY_NODES=$($KUBECTL get nodes | grep '\sReady,SchedulingDisabled' | awk '{print $1}' | xargs echo)

echo "Unready nodes that are undrained: $NOT_READY_NODES"
echo "Ready nodes: $READY_NODES"


for node in $NOT_READY_NODES; do
  echo "Node $node not drained yet, draining..."
  $KUBECTL drain --ignore-daemonsets --force --delete-emptydir-data $node
  echo "Done"
done;

for node in $READY_NODES; do
  echo "Node $node still drained, uncordoning..."
  $KUBECTL uncordon $node
  echo "Done"
done;

 

Istio ログを有効化する

Istio をデバッグするには、ログを有効化する必要があります。そのためには、以下の手順を実行します。

  1. Find the istio-ingressgateway pod by running the following command. Copy the gateway pod name. It should be something like istio-ingressgateway-r4mbx です。
kubectl -n istio-system get pods
  1. 次のコマンドを実行して、ゲートウェイ ポッド シェルを開きます。
kubectl exec -it -n istio-system istio-ingressgateway-r4mbx bash
  1. 次のコマンドを実行して、デバッグ レベルのログを有効化します。
curl -X POST http://localhost:15000/logging?level=debug
  1. サーバー ノードから次のコマンドを実行します。
istioctl_bin=$(find /var/lib/rancher/rke2/ -name "istioctl" -type f -perm -u+x   -print -quit)
if [[ -n ${istioctl_bin} ]]
then
echo "istioctl bin found"
  kubectl -n istio-system get cm istio-installer-base -o go-template='{{ index .data "istio-base.yaml" }}'  > istio-base.yaml
  kubectl -n istio-system get cm istio-installer-overlay  -o go-template='{{ index .data "overlay-config.yaml" }}'  > overlay-config.yaml 
  ${istioctl_bin} -i istio-system install -y -f istio-base.yaml -f overlay-config.yaml --set meshConfig.accessLogFile=/dev/stdout --set meshConfig.accessLogEncoding=JSON 
else
  echo "istioctl bin not found"
fi

 

UiPath 名前空間でシークレットが見つからない

説明

If service installation fails, and checking kubectl -n uipath get pods returns failed pods, take the following steps.

解決策

  1. チェック (Check) kubectl -n uipath describe pod <pod-name> and look for secret not found.
  2. シークレットが見つからない場合は、資格情報マネージャー ジョブのログを探して、失敗したかどうかを確認します。
  3. If the credential manager job failed and kubectl get pods -n rook-ceph|grep rook-ceph-tool returns more than one pod, do the following:
    a. delete rook-ceph-tool that is not running.
    b. go to ArgoCD UI and sync sfcore appllication.
    c. ジョブが完了したら、資格情報マネージャー ジョブのログですべてのシークレットが作成されているかどうかを確認します。
    d. Now sync uipath application.

 

移行後にログインできない

説明

An issue might affect the migration from a standalone product to Automation Suite. It prevents you from logging in, with the following error message being displayed: Cannot find client details です。

解決策

To fix this problem, you need to re-sync uipath app first, and then sync platform app in ArgoCD.

 

ArgoCD へのログインに失敗した

説明

管理者パスワードを使用している場合に ArgoCD へのログイン、またはインストーラーが失敗することがあります。次のエラー メッセージが表示されます。

33963396

解決策

この問題を修正するには、パスワードを入力し、bcrypt のパスワードを作成して、次のセクションで説明するコマンドを実行します。

password="<enter_your_password>"
bcryptPassword=<generate bcrypt password using link https://www.browserling.com/tools/bcrypt >

# Enter your bcrypt password and run below command
kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "admin.password": "<enter you bcryptPassword here>",
    "admin.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

# Run below commands
argocdInitialAdminSecretPresent=$(kubectl -n argocd get secret argocd-initial-admin-secret --ignore-not-found )
if [[ -n ${argocdInitialAdminSecretPresent} ]]; then
   echo "Start updating argocd-initial-admin-secret"
   kubectl -n argocd patch secret argocd-initial-admin-secret \
   -p "{
      \"stringData\": {
         \"password\": \"$password\"
      }
   }"
fi

argocAdminSecretName=$(kubectl -n argocd get secret argocd-admin-password --ignore-not-found )
if [[ -n ${argocAdminSecretName} ]]; then
   echo "Start updating argocd-admin-password"
   kubectl -n argocd patch secret argocd-admin-password \
   -p "{
      \"stringData\": {
         \"password\": \"$password\"
      }
   }"
fi

 

初期インストール後、ArgoCD アプリが Progressing ステートになる

説明

Whenever the cluster state deviates from what has been defined in the helm repository, argocd tries to sync the state and reconciliation happens every minute. Whenever this happens, you can notice that the ArgoCD app is in progressing state.

解決策

これは、ArgoCD の予期される動作であり、アプリケーションには一切影響しません。

 

Automation Suite requires backlog_wait_time to be set 1

説明

Audit events can cause instability (system freeze) if backlog_wait_time is not set to 1 です。
For more details, see this issue description.

解決策

If the installer fails with the Automation Suite requires backlog_wait_time to be set 1 error message, take the following steps to set backlog_wait_time to 1 です。

  1. Set backlog_wait_time to 1 by appending --backlog_wait_time 1 in the /etc/audit/rules.d/audit.rules file.
  2. ノードを再起動します。
  3. Validate if backlog_wait_time value is set to 1 for auditctl by running sudo auditctl -s | grep "backlog_wait_time" in the node.

 

ObjectStore PVC のサイズを変更できない

説明

This issue occurs when the objectstore resize-pvc operation fails with the following error: 

Failed resizing the PVC: <pvc name> in namespace: rook-ceph, ROLLING BACK

解決策

この問題を修正するには、次の手順に従います。

  1. 次のスクリプトを手動で実行します。
#!/bin/sh

ROOK_CEPH_OSD_PREPARE=$(kubectl -n rook-ceph get pods | grep rook-ceph-osd-prepare-set | awk '{print $1}')
if [[ -n ${ROOK_CEPH_OSD_PREPARE} ]]; then
    for pod in ${ROOK_CEPH_OSD_PREPARE}; do
    echo "Start deleting rook ceph osd pod $pod .."
    kubectl -n rook-ceph delete pod $pod
    echo "Done"
    done;
fi
  1. Rerun the objectstore resize-pvc command.

 

object-store (rook-ceph) にデータをアップロード/ダウンロードできない

967967

説明

この問題は、配置グループ (PG) の不整合のために、object-store のステートが degraded ステートになっている場合に発生する可能性があります。
次のコマンドを実行して、問題が本当に rook-ceph の PG の不整合に関連しているかを確認します。

export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin
ROOK_CEPH_TOOLS=$(kubectl -n rook-ceph get pods | grep rook-ceph-tools)
kubectl -n rook-ceph exec -it $ROOK_CEPH_TOOLS -- ceph status

問題が rook-ceph の PG の不整合に関連している場合は、出力に次のメッセージが含まれます。

602602 
....
....
Possible data damage: X pgs inconsistent
....
....
X active+clean+inconsistent
....
....

解決策

不整合な PG を修復するには、次の手順を実行します。

  1. rook-ceph ツールを実行します。
kubectl -n rook-ceph exec -it $ROOK_CEPH_TOOLS -- sh
  1. rook-ceph のガベージ コレクター プロセスをトリガーします。プロセスが完了するまで待ちます。
radosgw-admin gc process
  1. Find a list of active+clean+inconsistent PGs:
ceph health detail
# output of this command be like
# ....
# pg <pg-id> is active+clean+inconsistent, acting ..
# pg <pg-id> is active+clean+inconsistent, acting ..
# ....
#
  1. 詳細スクラブを一度に 1 つの PG でトリガーします。PG のサイズによっては、このコマンドの実行に数分かかります。
ceph pg deep-scrub <pg-id>
  1. スクラブのステータスを確認します。
ceph -w | grep <pg-id>
  1. Check the PG scrub status. If the PG scrub is successful, the PG status should be active+clean+inconsistent です。 
ceph health detail | grep <pg-id>
  1. PG を修復します。
ceph pg repair <pg-id>
  1. Check the PG repair status. The PG ID should be removed from the active+clean+inconsistent list if the PG is repaired successfully.
ceph health detail | grep <pg-id>
  1. 残りの不整合な PG で手順 3 から 8 を繰り返します。

 

証明書の更新後のエラー

説明

この問題は、証明書の更新手順が内部で失敗した場合に発生します。Automation Suite または Orchestrator にアクセスできないことがあります。

Error

18131813

解決策

  1. 任意のサーバー ノードから、以下のコマンドを実行します。
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
export PATH=$PATH:/var/lib/rancher/rke2/bin

kubectl -n uipath rollout restart deployments
  1. 上記のコマンドが成功するまで待機してから、以下のコマンドを実行して前のコマンドのステータスを確認します。
deployments=$(kubectl -n uipath get deployment -o name)
for i in $deployments; 
do 
kubectl -n uipath rollout status "$i" -w --timeout=600s; 
if [[ "$?" -ne 0 ]]; 
then
    echo "$i deployment failed in namespace uipath."
fi
done
echo "All deployments are succeeded in namespace uipath"

上記のコマンドの実行が完了したら、Automation Suite や Orchestrator にアクセスできます。

 

Unexpected inconsistency; run fsck manually

Automation Suite のインストールまたはアップグレード中にポッドが PVC ポッドにマウントできない場合、次のエラー メッセージが表示されます。
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

11881188

回復の手順

上記のエラーが発生する場合は、次の回復手順に従います。

  1. 次のコマンドを実行して、システムに SSH 接続します。
ssh <user>@<node-ip>
  1. PVC のイベントをチェックし、この問題がファイル エラーによる PVC のマウント エラーに関連していることを確認します。このためには、以下のコマンドを実行します。
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin:/usr/local/bin
kubectl get events -n mongodb
kubectl get events -n longhorn-system
  1. Check the PVC volume mentioned in the event and run the fsck command.
fsck -a <pvc-volume-name>
Eg - fsck -a /dev/longhorn/pvc-5abe3c8f-7422-44da-9132-92be5641150a
  1. 失敗した MongoDB ポッドを削除して、PVC に適切にマウントします。
kubectl delete pod <pod-name> -n mongodb

 

2021.10 からの自動アップグレード後にクラスターが異常になる

Automation Suite 2021.10 からの自動アップグレード中に、CNI プロバイダーが Canal からCilium に移行されます。この操作では、すべてのノードを再起動する必要があります。まれに、1 つ以上のノードが正常に再起動されないことがあります。この場合、それらのノードで実行されているポッドが異常なままになります。

回復の手順

  1. 失敗した再起動を特定します。
    Ansible の実行中に、次のスニペットのような出力が表示される場合があります。
TASK [Reboot the servers] ***************************************************************************************************************************

fatal: [10.0.1.6]: FAILED! =>

  msg: 'Failed to connect to the host via ssh: ssh: connect to host 10.0.1.6 port 22: Connection timed out'

Alternatively, browse the logs on the Ansible host machine, located at /var/tmp/uipathctl_<version>/_install-uipath.log. If any failed restarts were identified, execute steps 2 through 4 on all nodes.

  1. 各ノードで、再起動が必要であるかを確認します。
    各ノードに接続し、次のコマンドを実行します。
ssh <username>@<ip-address>
iptables-save 2>/dev/null | grep -i cali -c

結果が 0 でない場合は、再起動が必要です。

  1. ノードを再起動します。
sudo reboot
  1. ノードが応答可能になるまで待ち (ノードに SSH で接続できる必要があります)、他のすべてのノードで手順 2 から 4 を繰り返します。

 

Longhorn のセットアップ中に最初のインストールが失敗する

On rare occasions, if the first attempt to install Longhorn fails, subsequent retries might throw a Helm-specific error: Error: UPGRADE FAILED: longhorn has no deployed releases です。

回復の手順

インストールをリトライする前に、次のコマンドを実行して Longhorn Helm のリリースを削除します。

/opt/UiPathAutomationSuite/<version>/bin/helm uninstall longhorn --namespace longhorn-system

 

OS のアップグレード後に Automation Suite が動作しない

説明

After an OS upgrade, Ceph OSD pods can sometimes get stuck in CrashLoopBackOff state. This issue causes Automation Suite not to be accessible.

解決策

  1. 次のコマンドを実行して、ポッドのステートを確認します。
kubectl - n rook-ceph get pods
  1. If any of the pods in previous output are in CrashLoopBackOff, recover them by running the following command:
$OSD_PODS=$(kubectl -n rook-ceph get deployment -l app=rook-ceph-rgw --no-headers | awk '{print $1}')
kubectl -n rook-ceph rollout restart deploy $OSD_PODS
  1. ポッドが再び「実行中」ステートになるまで約 5 分待ってから、次のコマンドを実行してそのステータスを確認します。
kubectl - n rook-ceph get pods

 

Identity Server の問題

管理ポータルのタイムアウト期間を設定する

インストール前には、ホストレベルおよび組織レベルの管理ポータルでの認証に使用されるトークンの有効期限を更新できません。そのため、ユーザー セッションはタイムアウトしません。

To set a time interval for timeout for these portals, you can update the accessTokenLifetime property.
次の例では、タイムアウト期間を 86400 秒 (24 時間) に設定します。

UPDATE [identity].[Clients] SET AccessTokenLifetime = 86400 WHERE ClientName = 'Portal.OpenId'

 

Kerberos の問題

kinit: Cannot find KDC for realm while getting initial credentials

説明

This error might occur during installation (if you have Kerberos authentication enabled) or during the kerberos-tgt-update cron job execution when the UiPath cluster cannot connect to the AD server to obtain the Kerberos ticket for authentication.

解決策

Active Directory ドメインをチェックし、ドメインが次のように正しく設定されていて、ルーティング可能であることを確認します。

getent ahosts <AD domain> | awk '{print $1}' | sort | uniq

このコマンドがルーティング可能な IP アドレスを返さない場合、Kerberos 認証に必要な Active Directory ドメインは正しく設定されていません。

IT 管理者と協力して Active Directory ドメインを DNS サーバーに追加し、このコマンドがルーティング可能な IP アドレスを返すようにする必要があります。

 

kinit: Keytab contains no suitable keys for *** while getting initial credentials

説明

This error could be found in the log of a failed job, with one of the following job names: services-preinstall-validations-job kerberos-jobs-trigger kerberos-tgt-update です。

解決策

Active Directory ユーザーがまだ存在していてアクティブで、パスワードが変更されておらず期限切れではなかったことを確認します。必要に応じて、ユーザーのパスワードをリセットして keytab を再生成します。
Also make sure to provide the default Kerberos AD user parameter <KERB_DEFAULT_USERNAME> in the following format: HTTP/<Service Fabric FQDN> です。

 

GSSAPI operation failed with error: An invalid status code was supplied (Client's credentials have been revoked).

説明

This log could be found when using Kerberos for SQL access, and SQL connection is failing inside services. Similarly, you may see kinit: Client's credentials have been revoked while getting initial credential in one of the following job names: services-preinstall-validations-job kerberos-jobs-trigger kerberos-tgt-update です。

解決策

これは、keytab の生成に使用した Active Directory ユーザー アカウントが無効化されていることが原因である可能性があります。Active Directory ユーザー アカウントを再度有効化すると、問題は修正されます。

Alarm received for failed kerberos-tgt-update job

説明

これは、UiPath クラスターが最新の Kerberos チケットの取得に失敗した場合に発生します。

解決策

To find the issue, check the log for a failed job whose name starts with kerberos-tgt-update. After you've identified the problem in the log, check the related troubleshooting information in this section and in the Troubleshooting section for configuring Active Directory.

 

SSPI Provider: Server not found in Kerberos database

解決策

Make sure that the correct SPN records are set up in the AD domain controller for the SQL server. For instructions, see SPN formats in the Microsoft SQL Server documentation.

 

 

Login failed for user <ADDOMAIN>\<aduser>. Reason: The account is disabled.

説明

このログは、Kerberos を SQL アクセスに使用していて、SQL 接続がサービス内で失敗するときに見つかる可能性があります。

解決策

This issue could be caused by the AD user losing access to the SQL server. See instructions on how to reconfigure the AD user.

 

Orchestrator に関連する問題

CrashLoopBackOff または 1/2 になっている Orchestrator ポッドが複数の再起動で実行されている

説明

CrashLoopBackOff または 1/2 になっている Orchestrator ポッドが複数の再起動で実行されている場合、エラーはオブジェクト ストレージ プロバイダー Ceph の認証キーに関連している可能性があります。

エラーが Ceph に関連しているかどうかを確認するには、次のコマンドを実行します。

kubectl -n uipath get pod -l app.kubernetes.io/component=orchestrator

このコマンドの出力が、次のいずれかのオプションの出力と似ている場合は、追加のコマンドを実行する必要があります。

Option 1:
NAME                            READY   STATUS    RESTARTS   AGE
orchestrator-6dc848b7d5-q5c2q   1/2     Running   2          6m1s

OR 

Option 2
NAME                            READY   STATUS             RESTARTS   AGE
orchestrator-6dc848b7d5-q5c2q   1/2     CrashLoopBackOff   6          16m

次のコマンドを実行して、障害が Ceph 認証キーに関係しているかどうかを検証します。

kubectl -n uipath logs -l app.kubernetes.io/component=orchestrator | grep 'Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden' -o

If the output of the above command contains the string Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden, the failure is due to the Ceph authentication keys.

解決策

Rerun the rook-ceph-configure-script-job and credential-manager jobs using the following commands:

kubectl -n uipath-infra get job "rook-ceph-configure-script-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath-infra get job "credential-manager-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath delete pod -l app.kubernetes.io/component=orchestrator

 

Test Manager に関連する問題

Test Manager のライセンスに関する問題

ユーザーが Automation Suite にログイン中にライセンスが割り当てられた場合、Test Manager を開いた際にライセンスの割り当てが検出されないことがあります。

この問題が発生する場合は、以下の手順に従ってください。

  1. Test Manager に移動します。
  2. ポータルからログアウトします。
  3. 再度ログインします。

 

AI Center に関連する問題

AI Center のスキルのデプロイに関する問題

DU モデル スキルのデプロイが、最初のモデルのデプロイ時に断続的に、デプロイのリスト表示の失敗または不明なエラーで失敗することがあります。回避するには、そのモデルを再度デプロイします。1 回目のデプロイ試行時に画像構築のデプロイ作業のほとんどが完了しているため、2 回目のデプロイには時間がかかりません。DU モデルの最初のデプロイには約 1 - 1.5 時間を要しますが、再度デプロイする際は、これより短時間で完了します。

まれに、クラスターのステートが原因で、スキルのデプロイやパッケージのアップロードなどの非同期操作が長時間スタックしてしまうことがあります。DU スキルのデプロイに 2 - 3 時間以上かかる場合は、よりシンプルなモデル (例: TemplateModel) のデプロイを試みてください。シンプルなモデルを使用した場合でもデプロイに 1 時間以上かかる場合は、軽減策として以下のコマンドを使用した AI Center サービスの再起動を実行します。

kubectl -n uipath rollout restart deployment ai-deployer-deployment
kubectl -n uipath rollout restart deployment ai-trainer-deployment
kubectl -n uipath rollout restart deployment ai-pkgmanager-deployment
kubectl -n uipath rollout restart deployment ai-helper-deployment
kubectl -n uipath rollout restart deployment ai-appmanager-deployment

以下のコマンドを使用して検証し、AI Center の pod が復旧されるまで待機します。

kubectl -n uipath get pods | grep ai-*

成功していれば、上記の pod のステートはすべて「Running」になり、コンテナーのステートは「2/2」になるはずです。

 

Document Understanding に関連する問題

Document Understanding が Automation Suite の画面左側のレールにない

説明

Document Understanding が Automation Suite の左側のレールで見つからない場合は、現在 Document Understanding が Automation Suite の独立したアプリケーションではないため、左側のレールに表示されないということをご承知おきください。

解決策

データ マネージャーのコンポーネントは AI Center の一部であるため、AI Center が有効化されていることを確認してください。

また、下記の公開 URL から、フォーム抽出器、インテリジェント フォーム抽出器 (HandwritingRecognition (手書き文字認識) を含む)、インテリジェント キーワード分類器にアクセスしてください。

<FQDN>/du_/svc/formextractor
<FQDN>/du_/svc/intelligentforms
<FQDN>/du_/svc/intelligentkeywords

If you get the Your license can not be validated error message when trying to use Intelligent Keyword Classifier, Form Extractor and Intelligent Form Extractor in Studio, besides making sure you have input the right endpoint, please also take the API key that you generated for Document Understanding under License in the Automation Suite install, and not from cloud.uipath.com.

 

データのラベル付けセッションの作成時の失敗ステータス

説明

AI Center のデータ マネージャーでデータのラベル付けセッションを作成できない場合は、次の手順を実行します。

解決策 1

Please double-check if Document Understanding is properly enabled. You should have updated the configuration file before the installation and set documentunderstanding.enabled to True, or you could update it in ArgoCD post-installation as below.

それを行った後、これを無効化し、データのラベル付け機能を使用するテナントで AI Center を無効化するか、新しいテナントを作成する必要があります。

14921492

解決策 2

構成ファイルまたは ArgoCD で Document Understanding が適切に有効化されている場合に、Document Understanding が DefaultTenant で有効化されないことがあります。これにより、データのラベル付けセッションを作成できません。

この問題を修正するには、テナント上の AI Center を無効化にしてから再度有効化します。再度有効化できるようになるまで、数分かかる場合がある点にご注意ください。

 

ML スキルのデプロイ試行時の失敗ステータス

説明

Document Understanding ML Skill を AI Center に正常にデプロイできない場合は、次の解決策を確認してください。

解決策 1

Automation Suite をオフラインでインストールする場合、Document Understanding のバンドルがダウンロードされインストールされていることをダブルチェックしてください。

バンドルには、AI Center の UI を介して ML パッケージをアップロードした後にモデルが AI Center で適切に動作するためのベース イメージ (例: モデル ライブラリ) が含まれます。

For details about installing Document Understanding bundle, please refer to the documentation here and here. To add Document Understanding bundle, please follow the documentation to re-run the Document Understanding bundle installation.

解決策 2

Even if you have installed the Document Understanding bundle for offline installation, another issue might occur along with this error message: modulenotfounderror: no module named 'ocr.release'; 'ocr' is not a package です。

AI Center で Document Understanding OCR ML パッケージを作成する場合、その名前に ocr または OCR を使用できないことに注意してください。これらの名前はパッケージ内のフォルダーと競合します。必ず別の名前を選択してください。

解決策 3

Sometimes, intermittently, Document Understanding Model Skill Deployments can fail with Failed to list deployment または Unknown Error when deploying the model for the first time.

回避するには、そのモデルを再度デプロイします。1 回目のデプロイ試行時に画像構築のデプロイ作業のほとんどが完了しているため、2 回目のデプロイには時間がかかりません。Document Understanding ML パッケージの最初のデプロイには約 1 - 1.5 時間を要しますが、再度デプロイする際は、これより短時間で完了します。

 

ArgoCD で移行ジョブが失敗する

説明

ArgoCD で Document Understanding の移行ジョブが失敗する。

解決策

Document Understanding を使用するには、SQL サーバーでフルテキスト検索機能が有効化されている必要があります。有効化されていない場合に移行ジョブが ArgoCD で失敗すると、明示的なエラー メッセージが表示されないままインストールに失敗することがあります。

 

インテリジェント フォーム抽出器による手書き文字認識が機能しない

説明

インテリジェント フォーム抽出器による手書き文字認識が機能しない、または動作が遅い。

解決策 1

インテリジェント フォーム抽出器をオフラインで使用している場合、手書き文字機能を ArgoCD でインストールまたは有効化する前に、構成ファイルで有効化済みであることを確認してください。

ダブルチェックするには、ArgoCD > [Document Understanding] > [App details] > du-services.handwritingEnabled に移動し、これを True に設定します。

エアギャップ シナリオでは、これを実行する前に Document Understanding バンドルをインストールする必要があります。こうしないと、ArgoCD の同期が失敗します。

解決策 2

構成ファイルで手書き文字を有効化していても、依然として同じ問題が発生する場合があります。

Please know that the default for the maximum amount of CPUs each container is allowed to use for handwriting is 2. You may need to adjust handwriting.max_cpu_per_pod parameter if you have a larger handwriting processing workload. You could update it in the configuration file before installation or update it in ArgoCD.

For more details on how to calculate the parameter value based on your volume, please check the documentation here.

 

Insights に関連する問題

Insights のホーム ページに移動すると 404 エラーが表示される

まれに、ルーティング エラーが発生し、Insights のホーム ページに 404 が表示されることがあります。このエラーは、ArgoCD で Insights アプリケーションに移動し、仮想サービス insightsprovisioning-vs を削除することで解決できます。この仮想サービスを表示および削除するために [clear filters to show X additional resources] をクリックする必要が生じることがあります。

Looker が初期化に失敗する

During Looker initialization, you might encounter and error stating RuntimeError: Error starting Looker. A Looker pod failure produced this error due to a possible system failure or loss of power. The issue is persistent even if you reinitialize Looker.

この問題を解決するには、永続ボリューム要求 (PVC) を削除してから再起動します。

約 1 か月前に更新

トラブルシューティング

このページでは、Automation Suite の設定時に発生する可能性のある問題を修正する方法について説明します。

改善の提案は、API リファレンスのページでは制限されています

改善を提案できるのは Markdown の本文コンテンツのみであり、API 仕様に行うことはできません。