この文書は自動機械翻訳技術を使用して翻訳されています。正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。相違がある場合は、元の英語版英語が優先され、正式なテキストとなります。

トラブルシューティング

クイックトラブルシューティングガイド

SUSE Observabilityの起動トラブルシューティングのためのクイックガイドです：

インストールが成功裏に完了し、リリースがリストに表示されていることを確認してください：
```
helm list --namespace suse-observability
```
SUSE Observabilityのネームスペース内のすべてのポッドが実行中であることを確認してください：
```
kubectl get pods
```
最初のデプロイメントでは、いくつかのポッド内のコンテナが再起動を数回行うことがあります。これは、他のポッドが起動して`ready`の状態になるのを待っているためです。これは、スケジューリングやDockerイメージのプル遅延により遅れることがあります。

`pending`の状態にあるポッドは、通常、問題の兆候です：
- ポッドは、クラスター内のリソース不足によりスケジュールできません。クラスターオートスケーラーがアクティブな場合、通常は自動的に解決できますが、そうでない場合は、クラスターにノードを追加するための手動介入が必要です。
- ポッドはスケジュールできませんが、適合するノードは存在します。しかし、そのノードにはポッドが許容しない`taints`があります。これを解決するために、タイントのないノードを追加できますが、SUSE Observabilityは特定のタイントを許容し、タイントのあるノードで実行するように構成することもできます。
- ポッドは、永続ボリューム（PV）がマウントされるのを待っています。原因として、SUSE ObservabilityのHelmチャートが`storageClassName`を指定せず、クラスターにデフォルトのストレージクラスがあることに依存している可能性があります。クラスターにデフォルトがない場合、SUSE ObservabilityのHelm値を介してストレージクラスを指定する必要があります。
  
  状態が`ImagePullBackOff`のポッドについては、正確なエラーメッセージも確認してください。一般的な原因は次のとおりです：
- イメージをプルするために使用された不正なユーザー名/パスワード
- Dockerレジストリへの接続に失敗しました。これは、認証の問題や接続の問題（ファイアウォール、エアギャップインストール）による可能性があります。
- オーバーライドされたDockerイメージレジストリURLのタイプミス
Pending、ImagePullBackOff、または`CrashLoopBackOff`の状態の詳細な原因を調べるには、このコマンドを使用してください：

+
```
kubectl describe pod <pod-name>
```
+ 出力の最後には通常、問題を含む`event`セクションがあります。各コンテナの終了に関する詳細が記載された`State`セクションもあります。
プライム顧客の場合は、https://scc.suse.com/のSUSE Observabilityサポートに連絡して、ローカルクラスタでのSUSE Observabilityの設定について支援を受けてください。サポートチームのためにインスタンスに関する情報を収集するには、サポートパッケージ (ログ)を使用してください。
問題がパフォーマンスに関連している場合は、サポートパッケージ (パフォーマンス)を実行して、パフォーマンスを積極的に調査してください。
上記の手順で問題が解決しない場合は、高度なトラブルシューティングガイドが利用可能です。