View a markdown version of this page

Amazon SageMaker HyperPod オブザーバビリティアドオンのトラブルシューティング - Amazon SageMaker AI
提供されないメトリクスアドオンのインストール失敗すべてのオブザーバビリティポッドを確認する保留中のままになっているポッド制限付きインスタンスグループのオブザーバビリティのトラブルシューティング

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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 コンソールにサインインします。

  2. 左側のペインで、[すべてのワークスペース] を選択します。

  3. [WorkSpaces] テーブルで、ワークスペースを選択します。

  4. ワークスペースの詳細ページで、[データソース] タブを選択します。

  5. Amazon Managed Service for Prometheus データソースが存在することを確認します。

  6. 接続設定を確認します。

    • エンドポイント URLが正しいことを確認します。

    • IAM 認証が適切に設定されていることを検証します。

    • [Test connection] を選択します。ステータスが [データソースは機能しています] であることを検証します。

Amazon EKS アドオンのステータスを検証する

  1. https://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

  2. クラスターを選択します。

  3. [アドオン] タブを選択してください。

  4. SageMaker HyperPod オブザーバビリティアドオンが表示され、そのステータスが [アクティブ] であることを検証します。

  5. ステータスが [アクティブ] でない場合は、「」を参照してくださいアドオンのインストール失敗のトラブルシューティング。

Pod Identity の関連付けを検証する

  1. https://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

  2. クラスターを選択します。

  3. クラスターの詳細ページで、[アクセス] タブをクリックします。

  4. [Pod Identity の関連付け] テーブルで、次のプロパティ値を持つ関連付けを選択します。

    • 名前空間: hyperpod-observability

    • サービスアカウント: hyperpod-observability-operator-otel-collector

    • アドオン: amazon-sagemaker-hyperpod-observability

  5. この関連付けにアタッチされている 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:*"
            ]
        }
    ]
}

  6. この関連付けにアタッチされている 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/ で Service Quotas コンソールを開きます。

  2. [マネージドクォータ] ボックスで、Amazon Managed Service for Prometheus を検索して選択します。

  3. [ワークスペースあたりのアクティブシリーズ] クォータを選択します。

  4. [リソースレベルのクォータ] タブで、Amazon Managed Service for Prometheus ワークスペースを選択します。

  5. 使用率が現在のクォータ未満であることを確認します。

  6. クォータ制限に達している場合は、左側のラジオボタンをオンにしてワークスペースを選択し、[リソースレベルで引き上げをリクエスト] を選択します。

KV キャッシュとインテリジェントルーティングが有効になっていることを確認する

KVCache Metrics ダッシュボードがない場合、機能は有効になっていないか、ポートが に記載されていませんmodelMetrics。これを有効にする方法の詳細については、「」のステップ 1 と 3 を参照してくださいパフォーマンスを向上させるために KV キャッシュとインテリジェントルーティングを設定する。

Intelligent Router Metrics ダッシュボードがない場合は、機能を有効にして表示させます。これを有効にする方法の詳細については、「」を参照してくださいパフォーマンスを向上させるために KV キャッシュとインテリジェントルーティングを設定する。

アドオンのインストール失敗のトラブルシューティング

オブザーバビリティアドオンのインストールに失敗した場合、次の手順を使用して問題を診断して解決します。

ヘルスプローブのステータスを確認する

  1. https://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

  2. クラスターを選択します。

  3. [アドオン] タブを選択してください。

  4. 失敗したアドオンを選択します。

  5. [ヘルスの問題] セクションを確認します。

  6. ヘルスの問題が認証情報またはポッド ID に関連している場合は、「Pod Identity の関連付けを検証する」を参照してください。また、ポッド ID エージェントのアドオンがクラスターで実行されていることを確認します。

  7. マネージャーログにエラーがないか確認します。手順については、「マネージャーログを確認する」を参照してください。

  8. 問題の詳細については、 AWS サポートにお問い合わせください。

マネージャーログを確認する

  1. アドオンマネージャーポッドを取得します。

    kubectl logs -n hyperpod-observability -l control-plane=hyperpod-observability-controller-manager

  2. 緊急の問題については、 サポートにお問い合わせください。

すべてのオブザーバビリティポッドを確認する

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#/clusters で Amazon EKS コンソールを開きます。

  2. クラスターを選択します。

  3. クラスターの [コンピューティング] タブを選択します。

  4. インスタンスタイプが最も小さいノードを選択します。

  5. キャパシティ割り当てセクションで、使用可能なポッドを探します。

  6. 使用可能なポッドがない場合は、よりサイズの大きいインスタンスタイプが必要です。

緊急の問題については、 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アクセス許可があることを確認します。詳細については、「制限付きインスタンスグループの追加の前提条件」を参照してください。

  2. ノードコレクターポッドのステータスを確認します。次のコマンドを実行し、ノードコレクターポッドが制限付きノードで実行されていることを確認します。

    kubectl get pods -n hyperpod-observability | grep node-collector

  3. 中央コレクターのデプロイを確認します。ノードが制限されているクラスターでは、アドオンはネットワーク境界ごとに 1 つの中央コレクターをデプロイします。各境界に中央コレクターが存在することを確認します。

    kubectl get deployments -n hyperpod-observability | grep central-collector

  4. ポッドイベントにエラーがないか確認します。コレクターポッドkubectl describeで を使用してエラーイベントを検索します。

    kubectl describe pod collector-pod-name -n hyperpod-observability

上記の検証後も問題が解決しない場合は、 にお問い合わせください サポート。

Pod Identity 検証は制限されたインスタンスグループノードには適用されません

Pod Identity の関連付けを検証する トラブルシューティング手順は、標準ノードにのみ適用されます。制限されたノードでは、アドオンは Amazon EKS Pod Identity の代わりにクラスターインスタンスグループ実行ロールを AWS 認証に使用します。制限されたノードにメトリクスがない場合は、Pod Identity の関連付けではなく、実行ロールのアクセス許可を確認します。

Fluent Bit が制限付きノードで実行されていない

これは想定される動作です。Fluent Bit は、意図的に制限されたノードにデプロイされません。制限されたノードからのログは、オブザーバビリティアドオンとは無関係に SageMaker HyperPod プラットフォームを介して CloudWatch に発行されます。Amazon Managed Grafana のクラスターログダッシュボードを使用して、これらのログを表示します。