メインコンテンツまでスキップ

トラブルシューティング

問題を解決するには、このページで症状を探し、原因を確認して、対処方法を適用します。該当するものがない場合は、診断情報を収集 して OpenLM サポートにお問い合わせください。

Pod​

次の症状は、Pod のステータス、イベント、ログに表示されます。

症状原因対処方法
Pending と didn't match Pod's node affinityノード配置が有効だが、openlm.com/role ラベルの付いたノードがないノードにラベルを付けるか、global.affinity.enabled: false と global.taints.enabled: false を設定します。ノード配置
Pending と Too many podsノードの Pod 数の上限に達しているEKS: ノードを追加するか、プレフィックス委任を使用します。K3s: max-pods=250。EKS、K3s
Pending と Insufficient cpu / memory容量が不足しているノードを追加します。要件
PVC が Pending、Pod が Pendingストレージクラスが誤っている、または別のクラスターのプロビジョナーアノテーションが残っているSTORAGE_CLASS を確認し、values ファイルを生成し直して(ステップ 4)、PVC を削除し、インストールを再実行します
ImagePullBackOffpublic.ecr.aws への経路がない、またはミラーにイメージがないレジストリミラー
CreateContainerConfigErrorシークレットが不足しているcreate-openlm-secrets.sh を再実行します(ステップ 3)
CrashLoopBackOff、ログに too many open files / inotifyノードのファイル監視の上限が低すぎるノード設定
CrashLoopBackOff、ログに Login failed for user または FormatExceptionSQL の資格情報が誤っているSQL_USER / SQL_PASSWORD を確認し、シークレットのスクリプトを再実行して、再起動します
CrashLoopBackOff、ログに Redis または abortConnect が含まれるRedis に到達できない、パスワードが誤っている、または TLS の設定が一致しないREDIS_*、特に REDIS_TLS を確認します
CrashLoopBackOff、ログに Kafka の bootstrap または broker が含まれるKafka に到達できない、または Pod から到達できないアドレスを通知しているステップ 2.3
OOMKilledデータ量に対してメモリー制限が低すぎる<component>.resources.limits.memory を引き上げます
OpenShift: FailedCreate ... security context constraintコンポーネントがプロジェクトの範囲外のユーザー ID を設定しているOpenShift の values

サインインと画面​

次の症状は、ブラウザーまたはサービスのログに表示されます。

症状原因対処方法
ホームページは表示されるが、どの画面もデータを読み込めないサービスが https://DOMAIN/identity に到達できない、または信頼していないネットワーク、TLS
サービスのログに IdentityUnavailable(503)が表示される同上同上。その後 kubectl -n openlm rollout restart deployment を実行します
ブラウザーが画面とサインインページの間をループする発行者の設定がブラウザーのアドレスと一致しない、またはどこかで http:// が使われているサインインと ID
/api/licensemanager/bff/user が 401 ではなく 404 を返すID サービスの停止中にサービスが起動し、セキュリティなしで実行されているID サービスが正常になったら、サービスを 1 回再起動します
内部の HTTPS でエラーが出るが、ブラウザーは正常プライベート CA を使用しており、証明書ファイルにルート証明書が含まれていないファイルの末尾にルート証明書を追加し、openlm-lb-cert を作成し直します
OpenShift: サインインが 409 を返すID サービスのルートがまだパスを書き換えているOpenShift のルート、ステップ 2
OpenShift: ページの代わりにホームページが表示されるそのページにルートがないOpenShift のルート、ステップ 1

インストールとアップグレード​

次の症状は、OpenLM Platform のインストール、アップグレード、ライセンス登録の際に表示されます。

症状原因対処方法
helm が timed out waiting for the condition で停止するトピック設定ジョブが --timeout より長くかかった同じコマンドを再実行します。処理は続きから再開します。--timeout 60m を使用してください。
設定を変更したが、何も変わらない構成の内容だけが変わった場合、Helm は Pod を再起動しないkubectl -n openlm rollout restart deployment
rendered manifests contain a resource that already existsチャートが現在使用している名前と同じ名前のオブジェクトが手動で作成されている(OpenShift のルートなど)手動で作成したオブジェクトを削除し、インストールを再実行します
ライセンスのアップロード直後に、製品が「not licensed」と表示されるライセンスのアップロード前に製品が有効化された約 12 時間待つか、OpenLM サポートにお問い合わせください
サービスが Running だが Ready にならず、失敗したバックグラウンドジョブが多数ある失敗したジョブが 10 件を超えると、ジョブのヘルスチェックが失敗する診断情報 を添えて OpenLM サポートにお問い合わせください

診断情報を収集する​

OpenLM サポート向けの診断情報を収集するには、次のスクリプトを実行します。スクリプトは .tgz バンドルを作成します。

NS=openlm; OUT=openlm-diag-$(date +%Y%m%d-%H%M); mkdir -p $OUT
helm -n $NS list -a > $OUT/helm-list.txt
helm -n $NS history openlm-platform > $OUT/helm-history.txt
kubectl -n $NS get pods -o wide > $OUT/pods.txt
kubectl -n $NS get events --sort-by=.lastTimestamp > $OUT/events.txt
for p in $(kubectl -n $NS get pods --no-headers | grep -vE "Running|Completed" | awk '{print $1}'); do
kubectl -n $NS describe pod $p > $OUT/describe-$p.txt
kubectl -n $NS logs $p --all-containers --tail=300 > $OUT/log-$p.txt 2>&1
kubectl -n $NS logs $p --all-containers --previous --tail=300 > $OUT/log-$p-previous.txt 2>&1
done
tar czf $OUT.tgz $OUT && echo "send $OUT.tgz to OpenLM support"

バンドルには Pod 名、イベント、ログが含まれますが、シークレットの内容は含まれません。共有したくない情報がログに含まれていないか、送信する前に内容を確認してください。

ドキュメントチームは、大規模言語モデルを使ってこのページを下書きすることがあります。公開前に、テクニカルライターがすべてのページをレビューし、製品と照らし合わせて検証します。最終的な判断は人間が行います。