翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon SageMaker HyperPod オブザーバビリティアドオンのトラブルシューティング
Amazon SageMaker HyperPod (SageMaker HyperPod) オブザーバビリティアドオンの一般的な問題を解決するには、次のガイダンスを使用します。
## Amazon Managed Grafana で提供されないメトリクスのトラブルシューティング
Amazon Managed Grafana ダッシュボードにメトリクスが表示されない場合は、次の手順を実行して問題を特定し、解決します。
### Amazon Managed Service for Prometheus-Amazon Managed Grafana の接続を検証する
1. Amazon Managed Grafana コンソールにサインインします。
1. 左側のペインで、**[すべてのワークスペース]** を選択します。
1. **[WorkSpaces]** テーブルで、ワークスペースを選択します。
1. ワークスペースの詳細ページで、**[データソース]** タブを選択します。
1. Amazon Managed Service for Prometheus データソースが存在することを確認します。
1. 接続設定を確認します。
+ エンドポイント URLが正しいことを確認します。
+ IAM 認証が適切に設定されていることを検証します。
+ **[Test connection]** を選択します。ステータスが **[データソースは機能しています]** であることを検証します。
### Amazon EKS アドオンのステータスを検証する
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. クラスターを選択します。
1. **[アドオン]** タブを選択してください。
1. SageMaker HyperPod オブザーバビリティアドオンが表示され、そのステータスが **[アクティブ]** であることを検証します。
1. ステータスが **[アクティブ]** でない場合は、「」を参照してください[アドオンのインストール失敗のトラブルシューティング](#troubleshooting-addon-installation-failures)。
### Pod Identity の関連付けを検証する
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. クラスターを選択します。
1. クラスターの詳細ページで、**[アクセス]** タブをクリックします。
1. **[Pod Identity の関連付け]** テーブルで、次のプロパティ値を持つ関連付けを選択します。
+ **名前空間**: `hyperpod-observability`
+ **サービスアカウント**: `hyperpod-observability-operator-otel-collector`
+ **アドオン**: `amazon-sagemaker-hyperpod-observability`
1. この関連付けにアタッチされている IAM ロールに次のアクセス許可があることを確認します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrometheusAccess",
"Effect": "Allow",
"Action": "aps:RemoteWrite",
"Resource": "arn:aws:aps:us-east-1:111122223333:workspace/workspace-ID"
},
{
"Sid": "CloudwatchLogsAccess",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:FilterLogEvents",
"logs:GetLogRecord",
"logs:StartQuery",
"logs:StopQuery",
"logs:GetQueryResults"
],
"Resource": [
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*",
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*:log-stream:*"
]
}
]
}
```
------
1. この関連付けにアタッチされている IAM ロールに次の信頼ポリシーがあることを確認します。ソース ARN とソースアカウントが正しいことを検証します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:cluster/cluster-name",
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
### Amazon Managed Service for Prometheus のスロットリングを確認する
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) で Service Quotas コンソールを開きます。
1. **[マネージドクォータ]** ボックスで、Amazon Managed Service for Prometheus を検索して選択します。
1. **[ワークスペースあたりのアクティブシリーズ]** クォータを選択します。
1. **[リソースレベルのクォータ]** タブで、Amazon Managed Service for Prometheus ワークスペースを選択します。
1. 使用率が現在のクォータ未満であることを確認します。
1. クォータ制限に達している場合は、左側のラジオボタンをオンにしてワークスペースを選択し、**[リソースレベルで引き上げをリクエスト]** を選択します。
### KV キャッシュとインテリジェントルーティングが有効になっていることを確認する
`KVCache Metrics` ダッシュボードがない場合、機能は有効になっていないか、ポートが に記載されていません`modelMetrics`。これを有効にする方法の詳細については、「」のステップ 1 と 3 を参照してください[パフォーマンスを向上させるために KV キャッシュとインテリジェントルーティングを設定する](sagemaker-hyperpod-model-deployment-deploy-ftm.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route)。
`Intelligent Router Metrics` ダッシュボードがない場合は、機能を有効にして表示させます。これを有効にする方法の詳細については、「」を参照してください[パフォーマンスを向上させるために KV キャッシュとインテリジェントルーティングを設定する](sagemaker-hyperpod-model-deployment-deploy-ftm.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route)。
## アドオンのインストール失敗のトラブルシューティング
オブザーバビリティアドオンのインストールに失敗した場合、次の手順を使用して問題を診断して解決します。
### ヘルスプローブのステータスを確認する
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. クラスターを選択します。
1. **[アドオン]** タブを選択してください。
1. 失敗したアドオンを選択します。
1. **[ヘルスの問題]** セクションを確認します。
1. ヘルスの問題が認証情報またはポッド ID に関連している場合は、「[Pod Identity の関連付けを検証する](#verify-pod-identity-association)」を参照してください。また、ポッド ID エージェントのアドオンがクラスターで実行されていることを確認します。
1. マネージャーログにエラーがないか確認します。手順については、「[マネージャーログを確認する](#review-manager-logs)」を参照してください。
1. 問題の詳細については、 AWS サポートにお問い合わせください。
### マネージャーログを確認する
1. アドオンマネージャーポッドを取得します。
```
kubectl logs -n hyperpod-observability -l control-plane=hyperpod-observability-controller-manager
```
1. 緊急の問題については、 サポートにお問い合わせください。
## すべてのオブザーバビリティポッドを確認する
SageMaker HyperPod オブザーバビリティアドオンが作成するすべてのポッドは、`hyperpod-observability` 名前空間にあります。次のコマンドを実行して、デプロイのステータスを取得します。
```
kubectl get pods -n hyperpod-observability
```
ステータスが `pending` または `crashloopbackoff` のポッドを探します。次のコマンドを実行して、保留中または失敗したポッドのログを取得します。
```
kubectl logs -n hyperpod-observability pod-name
```
ログにエラーが見つからない場合は、次のコマンドを実行してポッドを説明し、エラーを探します。
```
kubectl describe -n hyperpod-observability pod pod-name
```
さらにコンテキストを取得するには、次の 2 つのコマンドを実行して、これらのポッドのデプロイとデーモンセットについて説明します。
```
kubectl describe -n hyperpod-observability deployment deployment-name
```
```
kubectl describe -n hyperpod-observability daemonset daemonset-name
```
## 保留中のステータスのままになっているポッドのトラブルシューティング
`pending` ステータスのままになっているポッドがある場合は、ノードがすべてのポッドに収まるサイズであることを確認します。検証するには、次の手順を実行します。
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. クラスターを選択します。
1. クラスターの **[コンピューティング]** タブを選択します。
1. インスタンスタイプが最も小さいノードを選択します。
1. キャパシティ割り当てセクションで、使用可能なポッドを探します。
1. 使用可能なポッドがない場合は、よりサイズの大きいインスタンスタイプが必要です。
緊急の問題については、 AWS サポートにお問い合わせください。
## 制限付きインスタンスグループのオブザーバビリティのトラブルシューティング
制限されたインスタンスグループを持つクラスターに固有の問題を解決するには、次のガイダンスを使用します。
### 制限付きノードで起動しないオブザーバビリティポッド
オブザーバビリティポッドが制限付きノードで起動しない場合は、ポッドのステータスとイベントを確認します。
```
kubectl get pods -n hyperpod-observability -o wide
kubectl describe pod pod-name -n hyperpod-observability
```
一般的な原因には、以下が含まれます。
+ **イメージプルの失敗:** オブザーバビリティコンテナイメージが制限付きノードにまだ許可リストに登録されていない場合、ポッドイベントにイメージプルエラーが表示されることがあります。オブザーバビリティアドオンの最新バージョンが実行されていることを確認します。アップグレード後も問題が解決しない場合は、 にお問い合わせください サポート。
+ **テイント許容値:** ポッド仕様に、制限されたノードに必要な許容値が含まれていることを確認します。バージョン 以降のアドオンでは、RIG サポートが有効になっている場合、この許容値`v1.0.5-eksbuild.1`が自動的に追加されます。古いバージョンを使用している場合は、最新バージョンにアップグレードしてください。
### 制限付きノードでのポッドのログの表示
`kubectl logs` コマンドは、制限されたノードで実行されているポッドでは機能しません。これは、ログストリーミングに必要な通信パスが制限付きノードで使用できないため、予想される制限です。
制限されたノードからのログを表示するには、CloudWatch **Logs に直接クエリを実行する Amazon Managed Grafana のクラスター**ログダッシュボードを使用します。インスタンス ID、ログストリーム、ログレベル、およびフリーテキスト検索でフィルタリングして、関連するログエントリを検索できます。
### 標準ノードと制限付きノードの両方を持つクラスターでの DNS 解決の失敗
ハイブリッドクラスター (標準インスタンスグループと制限付きインスタンスグループの両方を持つクラスター) では、Amazon Managed Service for Prometheus や CloudWatch などの AWS サービスエンドポイントに到達しようとすると、標準ノードのポッドで DNS 解決タイムアウトが発生することがあります。
**原因:** `kube-dns`サービスには、標準の CoreDNS ポッドと RIG CoreDNS ポッドの両方からのエンドポイントがあります。ネットワーク分離のため、標準ノードポッドは RIG CoreDNS エンドポイントに到達できません。が標準ノードポッドから RIG CoreDNS エンドポイントへの DNS リクエストを`kube-proxy`ロードバランシングすると、リクエストはタイムアウトします。
**解決策:** ポッドがローカルノード`internalTrafficPolicy: Local`の CoreDNS にのみ到達するように、 `kube-dns`サービスで を設定します。
```
kubectl patch svc kube-dns -n kube-system -p '{"spec":{"internalTrafficPolicy":"Local"}}'
```
このパッチを適用したら、影響を受けるオブザーバビリティポッドを再起動します。
```
kubectl delete pods -n hyperpod-observability -l app.kubernetes.io/name=hyperpod-node-collector
```
### Amazon Managed Service for Prometheus に到達しない制限付きノードからのメトリクス
制限されたノードからのメトリクスが Amazon Managed Service for Prometheus ワークスペースに表示されない場合:
1. **実行ロールのアクセス許可を確認します。**制限付きインスタンスグループの実行ロールに Prometheus ワークスペースに対する`aps:RemoteWrite`アクセス許可があることを確認します。詳細については、「[制限付きインスタンスグループの追加の前提条件](hyperpod-observability-addon-setup.md#hyperpod-observability-addon-rig-prerequisites)」を参照してください。
1. **ノードコレクターポッドのステータスを確認します。**次のコマンドを実行し、ノードコレクターポッドが制限付きノードで実行されていることを確認します。
```
kubectl get pods -n hyperpod-observability | grep node-collector
```
1. **中央コレクターのデプロイを確認します。**ノードが制限されているクラスターでは、アドオンはネットワーク境界ごとに 1 つの中央コレクターをデプロイします。各境界に中央コレクターが存在することを確認します。
```
kubectl get deployments -n hyperpod-observability | grep central-collector
```
1. **ポッドイベントにエラーがないか確認します。**コレクターポッド`kubectl describe`で を使用してエラーイベントを検索します。
```
kubectl describe pod collector-pod-name -n hyperpod-observability
```
上記の検証後も問題が解決しない場合は、 にお問い合わせください サポート。
### Pod Identity 検証は制限されたインスタンスグループノードには適用されません
[Pod Identity の関連付けを検証する](#verify-pod-identity-association) トラブルシューティング手順は、標準ノードにのみ適用されます。制限されたノードでは、アドオンは Amazon EKS Pod Identity の代わりにクラスターインスタンスグループ実行ロールを AWS 認証に使用します。制限されたノードにメトリクスがない場合は、Pod Identity の関連付けではなく、実行ロールのアクセス許可を確認します。
### Fluent Bit が制限付きノードで実行されていない
これは想定される動作です。Fluent Bit は、意図的に制限されたノードにデプロイされません。制限されたノードからのログは、オブザーバビリティアドオンとは無関係に SageMaker HyperPod プラットフォームを介して CloudWatch に発行されます。Amazon Managed Grafana の**クラスターログ**ダッシュボードを使用して、これらのログを表示します。