翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
マネージドPrometheusコレクターを使用してSlurmメトリクスを収集する
AWS PCS クラスターでSlurmメトリクスを有効にした後 (「」を参照Slurm PCS AWS の メトリクス)、マネージドPrometheusコレクターを使用してメトリクスエンドポイントを自動的にスクレイプし、PromQLクエリ用のデータを配信できます。マネージドコレクターは、VPC サブネットに Elastic Network Interface を作成して、ポート 6817 でクラスターコントローラーのメトリクスエンドポイントに到達します。
コレクターは、次のいずれかの宛先にメトリクスを配信できます。
-
Amazon Managed Service for Prometheus ワークスペース – 設定可能な保持期間 (デフォルトでは 150 日) を持つ Prometheus互換の専用メトリクスストア。Prometheus互換 APIs または を使用してクエリを実行できますGrafana。
-
CloudWatch データセット – 15 か月間の保持期間を含むアカウントのデフォルトの CloudWatch データセット。CloudWatch Query Studio または Prometheus互換の HTTP API を使用してクエリを実行できます。
クラスター側の設定 (Slurm設定、コントローラーターゲット、セキュリティグループ、スクレイプ設定) は、選択した送信先に関係なく同じです。create-scraper リクエストの destinationブロックとクエリエンドポイントのみが異なります。
aws amp create-scraper コマンドを使用してコレクターを作成します。このコマンドは CLI amp 名前空間に属しますが、両方の送信先をサポートしています。
VPC に接続されたマネージドコレクターの詳細については、Amazon CloudWatch ユーザーガイド」の「VPC に接続されたマネージドコレクターのセットアップ」を参照してください。
前提条件
マネージドコレクターを設定する前に、以下を確認してください。
-
Slurm メトリクスが有効 – メトリクスエンドポイントはクラスターでアクティブである必要があります。これを有効にするには、
MetricsTypeと のCommunicationParametersカスタムSlurm設定を行います。Slurm メトリクスを有効にする手順については、「」を参照してくださいSlurm PCS AWS の メトリクス。カスタムSlurm設定の詳細については、「」を参照してくださいPCS でのカスタム Slurm AWS 設定の設定。 -
Slurm バージョン 25.11 以降 – メトリクスエンドポイントを公開するには、クラスターSlurmが 25.11 以降を実行する必要があります。
-
送信先リソース – メトリクスの送信先を作成します。
-
Amazon Managed Service for Prometheus ワークスペース – ワークスペースを作成し、
ACTIVEステータスになるまで待ちます。ワークスペースの作成手順については、「Amazon Managed Service for Prometheus ユーザーガイド」の「ワークスペースの作成」を参照してください。 -
CloudWatch データセット – すべてのアカウントに各リージョンに
defaultデータセットがあります。作成する必要はありません。
-
-
VPC サブネットとネットワーク – クラスターコントローラーと同じ VPC 内の異なるアベイラビリティーゾーンに少なくとも 2 つのサブネットが必要です。コントローラーのネットワークインターフェイスが存在するアベイラビリティーゾーンを含めます。VPC では、DNS サポートと DNS ホスト名が有効になっている必要があります。ネットワーク要件の詳細については、Amazon CloudWatch ユーザーガイド」の「VPC 接続マネージドコレクターのセットアップ」を参照してください。
-
セキュリティグループ – コレクター専用のセキュリティグループが必要です。セキュリティグループの設定手順については、「」を参照してくださいコレクターのセキュリティグループを設定する。
-
IAM アクセス許可 – スクレイパーのニーズ
aps:CreateScraperとiam:CreateServiceLinkedRoleアクセス許可を作成する IAM プリンシパル。サービスにリンクされたロール () が自動的に作成されますAWSServiceRoleForAmazonPrometheusScraper。このロールは、VPC リソースにアクセスし、選択した宛先に書き込むアクセス許可をコレクターに付与します。手動のロール設定は必要ありません。詳細については、「Amazon Managed Service for Prometheus ユーザーガイド」の「サービスにリンクされたロールの使用」を参照してください。 -
インターネットまたは VPC エンドポイント – コレクターサブネットは送信先サービスに到達できる必要があります。サブネットにインターネットアクセスがない場合は、同じ VPC とサブネットにインターフェイス VPC エンドポイントを作成します。
com.amazonaws.Amazon Managed Service for Prometheus ワークスペースの送信先、または CloudWatch データセットの送信先region.aps-workspacescom.amazonaws.に使用します。region.monitoring
コレクターのセキュリティグループを設定する
既存のセキュリティグループを再利用するのではなく、マネージドコレクター専用のセキュリティグループを作成することをお勧めします。専用グループは、最小特権の原則に従う明示的で監査可能なルールを提供します。
重要
enable_http この設定では、ポート 6817 で認証されていない HTTP エンドポイントが公開されます。このポートのインバウンドアクセスをコレクターのセキュリティグループのみに制限します。このポートへの広範なネットワークアクセス (CIDR 範囲など) を許可しないでください。
次の手順では、セキュリティグループ IDs のシェル変数を使用します。コマンドを実行する前に、これらの変数を設定します。
-
VPC_ID– PCS クラスターが存在する VPC AWS の ID。 -
CLUSTER_SG_ID– クラスターにアタッチされたセキュリティグループの ID (クラスターの作成時に指定したセキュリティグループ)。 -
VPCE_SG_ID– インターフェイス VPC エンドポイントにアタッチされたセキュリティグループの ID。この変数は、コレクターサブネットがインターネットや NAT 出力ではなくインターフェイス VPC エンドポイントを介して送信先サービスに到達する場合にのみ必要です。エンドポイントはcom.amazonaws.、Amazon Managed Service for Prometheus ワークスペースの送信先または CloudWatch データセットの送信先region.aps-workspacescom.amazonaws.用です。region.monitoring
マネージドPrometheusコレクターのセキュリティグループを設定するには
-
コレクター専用のセキュリティグループを作成し、グループ ID をキャプチャします。
COLLECTOR_SG_ID=$(aws ec2 create-security-group \ --group-name "pcs-prometheus-collector" \ --description "Security group for managed Prometheus collector" \ --vpc-id "$VPC_ID" \ --query 'GroupId' \ --output text) -
コレクターのセキュリティグループからのポート 6817 での TCP トラフィックを許可するインバウンドルールをクラスターのセキュリティグループに追加します。このルールは、コレクターがコントローラー上のSlurmメトリクスエンドポイントをスクレイプすることを許可します。
--ip-permissionsフォームを使用して、監査可能性に関するルールの説明を含めます。aws ec2 authorize-security-group-ingress \ --group-id "$CLUSTER_SG_ID" \ --ip-permissions \ 'IpProtocol=tcp,FromPort=6817,ToPort=6817,UserIdGroupPairs=[{GroupId='"$COLLECTOR_SG_ID"',Description="Prometheus collector scrapes Slurm metrics"}]'または、ルールの説明なしで短い形式を使用することもできます。
aws ec2 authorize-security-group-ingress \ --group-id "$CLUSTER_SG_ID" \ --protocol tcp \ --port 6817 \ --source-group "$COLLECTOR_SG_ID" -
(オプション) コレクターのセキュリティグループのアウトバウンドトラフィックをロックダウンします。デフォルトでは、新しく作成されたセキュリティグループはすべてのアウトバウンドトラフィックを許可します。セキュリティ体制を強化するために明示的な送信のみを適用する場合は、デフォルトの allow-all ルールを取り消し、コレクターが必要とする送信ルールのみを追加します。
デフォルトの allow-all 出力ルールを取り消します。
aws ec2 revoke-security-group-egress \ --group-id "$COLLECTOR_SG_ID" \ --ip-permissions '[{"IpProtocol":"-1","IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'明示的な出力ルールを追加して、コレクターが TCP 6817 でコントローラーに到達できるようにします。
aws ec2 authorize-security-group-egress \ --group-id "$COLLECTOR_SG_ID" \ --ip-permissions \ 'IpProtocol=tcp,FromPort=6817,ToPort=6817,UserIdGroupPairs=[{GroupId='"$CLUSTER_SG_ID"',Description="Egress to Slurm controller for metrics scraping"}]'メトリクス配信先 (Amazon Managed Service for Prometheus または CloudWatch) に到達するための HTTPS (TCP 443) の明示的な出力ルールを追加します。
aws ec2 authorize-security-group-egress \ --group-id "$COLLECTOR_SG_ID" \ --ip-permissions \ 'IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges=[{CidrIp=0.0.0.0/0,Description="HTTPS egress for metrics delivery"}]'配信に VPC エンドポイントを使用するサブネットをより厳密に制御するには、CIDR 範囲を VPC エンドポイントのセキュリティグループに置き換えます。
aws ec2 authorize-security-group-egress \ --group-id "$COLLECTOR_SG_ID" \ --ip-permissions \ 'IpProtocol=tcp,FromPort=443,ToPort=443,UserIdGroupPairs=[{GroupId='"$VPCE_SG_ID"',Description="HTTPS egress to VPC endpoint for metrics delivery"}]'注記
デフォルトの出力ルールを取り消しなかった場合は、このステップをスキップできます。デフォルトのルールでは、ポート 6817 およびポート 443 へのトラフィックを含むすべてのアウトバウンドトラフィックが既に許可されています。
-
(分離されたクラスター) コレクターサブネットにインターネットアクセスがなく、インターフェイス VPC エンドポイントを使用して送信先サービスに到達する場合は、VPC エンドポイントのセキュリティグループにインバウンドルールを追加します。このルールは、コレクターの HTTPS トラフィックがエンドポイントネットワークインターフェイスに到達することを許可します。これは、一般的に見逃されるステップです。
aws ec2 authorize-security-group-ingress \ --group-id "$VPCE_SG_ID" \ --ip-permissions \ 'IpProtocol=tcp,FromPort=443,ToPort=443,UserIdGroupPairs=[{GroupId='"$COLLECTOR_SG_ID"',Description="Managed collector reaches service endpoint"}]'
注記
よりシンプルで制限の少ない代替手段として、そのセキュリティグループにそれ自体からのトラフィックを許可する自己参照ルールが含まれている場合は、コントローラーの既存のセキュリティグループをコレクターにアタッチできます。これにより、専用グループを作成せずに接続要件が満たされます。
たとえば、クラスターのセキュリティグループ (sg-0abc1234def56789a) が既にそれ自体からのすべての TCP トラフィックを許可している場合は、スクレイパーの作成時に --security-group-idsパラメータにそのセキュリティグループ ID を渡します。
aws amp create-scraper \ --source '{"vpcConfiguration":{"subnetIds":["subnet-id-1","subnet-id-2"],"securityGroupIds":["sg-0abc1234def56789a"]}}' \ ...
ただし、前述の手順で説明した専用のセキュリティグループアプローチは、明示的で監査可能なルールを持つより高いセキュリティバーを提供します。
セキュリティグループのルールの詳細についてはAmazon VPCユーザーガイドの「セキュリティグループのルール」を参照してください。
マネージドコレクターを作成する
AWS CLI を使用して、クラスターコントローラーをスクレイプし、選択した送信先にメトリクスを配信する VPC 接続マネージドコレクターを作成します。
Slurm メトリクスのマネージドコレクターを作成するには
-
スクレイプ設定を という名前のローカル YAML ファイルに保存します
scrape-config.yaml。推奨される設定については、「」を参照してください推奨されるスクレイプ設定。 -
次の構造
create-scraper-input.jsonで という名前の JSON 入力ファイルを作成します。ターゲットに一致するdestinationブロックを選択します。{ "source": { "vpcConfiguration": { "subnetIds": ["subnet-1", "subnet-2"], "securityGroupIds": ["sg-collector"] } }, "destination": { ... }, "scrapeConfiguration": { "configurationBlob": "raw-yaml-contents" } }置き換え前:
-
subnet-1およびsubnet-2– クラスターコントローラーと同じ VPC 内の異なるアベイラビリティーゾーンに少なくとも 2 つのサブネット IDs。 -
sg-collector– マネージドコレクターのセキュリティグループ ID。 -
raw-yaml-contents– 単一の JSON 文字列値として貼り付けられたscrape-config.yamlファイルの全文。 AWS CLI base64 はワイヤの値を自動的にエンコードします。
destinationフィールドには、次のいずれかを使用します。送信先: Amazon Managed Service for Prometheus ワークスペース
"destination": { "ampConfiguration": { "workspaceArn": "arn:aws:aps:region:account-id:workspace/workspace-id" } }送信先: CloudWatch データセット
"destination": { "cloudWatchConfiguration": { "datasetArn": "arn:aws:cloudwatch:region:account-id:dataset/default" } }パラメータの完全なセットについては、AWS CLI 「 コマンドリファレンス」の「create-scraper」を参照してください。
-
-
スクレイパーを作成します。
aws amp create-scraper --cli-input-json file://create-scraper-input.jsonコマンドは、
scraperIdと のステータスを返しますCREATING。 -
スクレイパーのステータスが に変わるまで待ちます
ACTIVE(通常は 5~15 分)。aws amp describe-scraper --scraper-idscraper-idscraper-idを前のステップで返された ID に置き換えます。スクレイパーは、ACTIVEステータスに達するまで削除できません。
クラスターコントローラーエンドポイントを検索する
スクレイプ設定には、 AWS PCS クラスターコントローラーのプライベート IP アドレスが必要です。次のいずれかの方法を使用して検索します。
推奨されるスクレイプ設定
次の YAML 設定は、クラスターコントローラーから 4 つのSlurmメトリクスエンドポイント (ジョブ、ノード、スケジューラ、パーティション) をスクレイプします。各エンドポイントは個別のジョブとして定義され、クエリでソース別にメトリクスを識別できます。
global: scrape_interval: 60s scrape_timeout: 30s scrape_configs: - job_name: 'slurm-jobs' metrics_path: /metrics/jobs static_configs: - targets: - 'controller-endpoint:6817' relabel_configs: - target_label: cluster replacement: 'my-cluster-name' - job_name: 'slurm-nodes' metrics_path: /metrics/nodes static_configs: - targets: - 'controller-endpoint:6817' relabel_configs: - target_label: cluster replacement: 'my-cluster-name' - job_name: 'slurm-scheduler' metrics_path: /metrics/scheduler static_configs: - targets: - 'controller-endpoint:6817' relabel_configs: - target_label: cluster replacement: 'my-cluster-name' - job_name: 'slurm-partitions' metrics_path: /metrics/partitions static_configs: - targets: - 'controller-endpoint:6817' relabel_configs: - target_label: cluster replacement: 'my-cluster-name'
置き換え前:
-
controller-endpoint– PCS AWS クラスターコントローラーのプライベート IP アドレス。この値を検索する手順については、「」を参照してくださいクラスターコントローラーエンドポイントを検索する。 -
my-cluster-name– クラスターを識別するラベル。relabel_configsブロックは、このスクレイパーのすべてのメトリクスにclusterラベルをスタンプします。常にclusterラベルでクエリをフィルタリングします。ラベルをスタンプしなかったスクレイパーの系列は、期限切れになるまで重複したラベルなし系列として表示されます。
マネージドコレクターscrape_intervalの最小値は 30 秒です。この設定では、スクレイピングによってSlurmコントローラー (slurmctld) に負荷がかかるため、60 秒が使用されます。メトリクスをクエリすると、内部ロックを取得し、インメモリデータ構造を読み取ります。このアクティビティは、ビジークラスターのスケジューラのパフォーマンスに影響を与える可能性があります。Slurm メトリクスガイドでは、パフォーマンスへの影響を最小限に抑えるために 60~120 秒のスクレイプ間隔を推奨しています。
注記
この設定には/metrics/jobs-users-acctsエンドポイントは含まれません。 Slurmドキュメントでは、このエンドポイントが無制限の系列を生成し、ストアドモニタリングには適していないことを警告しています。すべてのサブエンドポイントデータを 1 つのレスポンスにまとめるため、ベア/metricsインデックスもスクレイプしないでください。
サポートされているスクレイプ設定オプションの詳細については、Amazon CloudWatch ユーザーガイド」の「スクレイパー設定」を参照してください。
メトリクス配信の検証
スクレイパーACTIVEのステータスに達すると、最初のデータポイントが約 1 スクレイプ間隔に配信時間を加えた後に表示されます。送信先に一致する検証方法を使用します。
Amazon Managed Service for Prometheus ワークスペースへの配信を確認する
SigV4-signedリクエストを送信して、ワークスペースから使用可能なメトリクス名を一覧表示します。
awscurl --service aps --regionregion\ "https://aps-workspaces.region.amazonaws.com/workspaces/workspace-id/api/v1/label/__name__/values"
呼び出し元のプリンシパルには、 aps:QueryMetricsと aps:GetLabels アクセス許可 (または AmazonPrometheusQueryAccess管理ポリシー) が必要です。
CloudWatch データセットへの配信を検証する
SigV4-signedリクエストを送信して、CloudWatch データセットから使用可能なメトリクス名を一覧表示します。
awscurl --service monitoring --regionregion\ "https://monitoring.region.amazonaws.com/api/v1/label/__name__/values"
呼び出し元のプリンシパルには、 cloudwatch:GetMetricDataと cloudwatch:ListMetrics アクセス許可が必要です。
重要
CloudWatch データセットに配信されるメトリクスは、OpenTelemetry (OTel) メトリクスとして保存されます。これらは、従来の CloudWatch Metrics 名前空間ブラウザや の出力には表示されませんaws cloudwatch list-metrics。でクエリを実行する必要がありますPromQL。
どちらの送信先でも、、slurm_nodes、 slurm_jobs_runningなどslurm_、 で始まるメトリクス名を探しますslurm_node_cpus。Slurm メトリクスが表示されない場合は、以下を確認します。
-
スクレイパーのステータスは です
ACTIVE。 -
セキュリティグループルールにより、コレクターはコントローラーのポート 6817 に到達できます。
-
Slurm メトリクスエンドポイントはクラスターで有効になっています。
を使用してSlurmメトリクスをクエリする PromQL
を使用して、収集されたSlurmメトリクスをクエリしますPromQL。同じクエリがどちらの送信先でも機能します。クエリ方法は、メトリクスを配信した場所によって異なります。
Amazon Managed Service for Prometheus ワークスペースをクエリする
-
HTTP API – SigV4-signedリクエスト (サービス名
aps) をhttps://aps-workspaces.または に送信しますregion.amazonaws.com/workspaces/workspace-id/api/v1/query/api/v1/query_range。 -
Grafana – SigV4 認証とサービス名 を使用してPrometheusデータソースを追加します
aps。を使用したクエリの手順についてはGrafana、「Amazon Managed Service for Prometheus ユーザーガイド」の「Grafana を使用したクエリ」を参照してください。
次の例ではawscurl、 を使用して Amazon Managed Service for Prometheus ワークスペースから実行中のジョブをクエリします。
awscurl --service aps --regionregion\ -X POST "https://aps-workspaces.region.amazonaws.com/workspaces/workspace-id/api/v1/query" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "query=slurm_jobs_running"
呼び出し元プリンシパルには、aps:QueryMetrics、aps:GetMetricMetadata、aps:GetSeries、および アクセスaps:GetLabels許可 (または AmazonPrometheusQueryAccessマネージドポリシー) が必要です。
CloudWatch データセットをクエリする
-
CloudWatch コンソール – CloudWatch を開き、Query Studio を選択し、クエリ言語メニューから PromQL を選択します。
-
HTTP API – SigV4-signedリクエスト (サービス名
monitoring) をhttps://monitoring.または に送信しますregion.amazonaws.com/api/v1/query/api/v1/query_range。 -
Grafana – URL 、
https://monitoring.SigV4 認証、サービス名 を持つPrometheusデータソースを追加しますregion.amazonaws.com.rproxy.goskope.commonitoring。PromQL で を使用して CloudWatch メトリクスをクエリする手順についてはGrafana、「Amazon Managed Grafana ユーザーガイド」の「Grafana で PromQL を使用して CloudWatch メトリクスをクエリする」を参照してください。
次の例ではawscurl、 を使用して CloudWatch データセットから実行中のジョブをクエリします。
awscurl --service monitoring --regionregion\ -X POST "https://monitoring.region.amazonaws.com/api/v1/query" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "query=slurm_jobs_running"
呼び出し元のプリンシパルには、 cloudwatch:GetMetricDataと cloudwatch:ListMetrics アクセス許可が必要です。
PromQL クエリの例
次のクエリは、どちらの送信先でも機能します。my-cluster-name を、スクレイプ設定のラベルcluster変更で設定した値に置き換えます。
- CPU 使用率
-
100 * slurm_node_cpus_alloc{cluster="my-cluster-name"} / slurm_node_cpus{cluster="my-cluster-name"} - 保留中のジョブ (キューバックログ)
-
slurm_jobs_pending{cluster="my-cluster-name"} - ジョブの実行
-
slurm_jobs_running{cluster="my-cluster-name"} - ジョブスループット
-
slurm_jobs_completed{cluster="my-cluster-name"}
使用可能なメトリクスとスクレイピング設定の詳細については、 Slurmウェブサイトの「 メトリクスガイド