翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ルールを使用して、受信したメトリクスを変更またはモニタリングする Amazon Managed Service for Prometheus で受信したメトリクスに対してアクションを実行するルールを設定できます。これらのルールは、メトリクスをモニタリングしたり、受信したメトリクスに基づいて新しい計算されたメトリクスを作成したりできます。 Amazon Managed Service for Prometheus は、定期的に評価される 2 種類のルール**をサポートしています。 + 記録ルール**では、頻繁に必要になる式や計算負荷の高い式を事前に計算し、その結果を新しい時系列セットとして保存できます。多くの場合、事前に計算された結果に対してクエリを実行する方が、元の式を必要時に毎回実行するよりもはるかに高速です。 + アラートルール**では、PromQL としきい値に基づいてアラート条件を定義できます。ルールによってしきい値がトリガーされると、[アラートマネージャー](AMP-alert-manager.md)に通知が送信されます。アラートマネージャーでルールを管理するように設定したり、ルールを通知ダウンストリームのレシーバー (Amazon Simple Notification Service など) に転送するように設定したりできます。 Amazon Managed Service for Prometheus でルールを使用するには、ルールを定義する 1 つ以上の YAML ルールファイルを作成します。Amazon Managed Service for Prometheus のルールファイルの形式は、スタンドアロンの Prometheus のルールファイルと同じです。詳細については、Prometheus ドキュメントの「[Defining Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)」と「[Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)」を参照してください。 ワークスペースには複数のルールファイルを含めることができます。それぞれのルールファイルは、別々の名前空間**に格納されます。ルールファイルを複数にすれば、既存の Prometheus ルールファイルを変更したり結合したりする必要なく、そのままワークスペースにインポートできます。また、異なるルールグループ名前空間には、異なるタグを付けることができます。 **ルールの順序** ルールファイル内では、ルールはルールグループ**に格納されます。ルールファイルの 1 つのルールグループ内のルールは、常に上から下に順番に評価されます。したがって、記録ルールでは、ある記録ルールの結果を、同じルールグループに含まれている後の記録ルールの計算やアラートルールで使用できます。ただし、個々のルールファイルの実行順序は指定できないため、ある記録ルールの結果を使用して別のルールグループまたは別のルールファイル内のルールを計算することはできません。 **Topics** + [ルールの使用に必要な IAM アクセス許可を理解する](AMP-ruler-IAM-permissions.md) + [ルールファイルを作成する](AMP-ruler-rulesfile.md) + [Amazon Managed Service for Prometheus にルール設定ファイルをアップロードする](AMP-rules-upload.md) + [ルール設定ファイルを編集または置換する](AMP-rules-edit.md) + [ルール評価のトラブルシューティング](troubleshoot-rule-evaluations.md) + [ルーラーのトラブルシューティング](Troubleshooting-rule-fail-error.md) # ルールの使用に必要な IAM アクセス許可を理解する ユーザーに、Amazon Managed Service for Prometheus でルールを使用するためのアクセス許可を付与する必要があります。次のアクセス許可を持つ AWS Identity and Access Management (IAM) ポリシーを作成し、そのポリシーをユーザー、グループ、またはロールに割り当てます。 **注記** IAM の詳細については、「[Amazon Managed Service for Prometheus の Identity and Access Management](security-iam.md)」を参照してください。 **ルールを使用するためのアクセス権を付与するポリシー** 次のポリシーは、ルールを使用するためのアクセス権を、アカウント内のすべてのリソースに付与します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "aps:CreateRuleGroupsNamespace", "aps:ListRuleGroupsNamespaces", "aps:DescribeRuleGroupsNamespace", "aps:PutRuleGroupsNamespace", "aps:DeleteRuleGroupsNamespace" ], "Resource": "*" } ] } ``` ------ **1 つの名前空間にのみアクセス権を付与するポリシー** 特定のポリシーにのみアクセス権を付与するポリシーを作成することもできます。次のサンプルポリシーは、指定された `RuleGroupNamespace` にのみアクセス権を付与します。このポリシーを使用するには、**、**、**、** を、アカウントに応じた適切な値に置き換えます。 # ルールファイルを作成する Amazon Managed Service for Prometheus でルールを使用するには、ルールを定義するルールファイルを作成します。Amazon Managed Service for Prometheus のルールファイルは、スタンドアロンの Prometheus のルールファイルと同じ形式の YAML テキストファイルです。詳細については、*Prometheus* ドキュメントの「[Defining Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)」と「[Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)」を参照してください。 基本的なルールファイルの例を以下に示します。 ``` groups: - name: cpu_metrics interval: 60s rules: - record: avg_cpu_usage expr: avg(rate(node_cpu_seconds_total[5m])) by (instance) - alert: HighAverageCPU expr: avg_cpu_usage > 0.8 for: 10m keep_firing_for: 20m labels: severity: critical annotations: summary: "Average CPU usage across cluster is too high" ``` この例では、60 秒ごとに評価されるルールグループ `cpu_metrics` を作成します。このルールグループは、`avg_cpu_usage` という名前の記録ルールを使用して新しいメトリクスを作成し、それをアラートで使用します。使用されるプロパティの一部について以下に説明します。含めることができるアラートルールやその他のプロパティの詳細については、*Prometheus* ドキュメントの「[Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)」を参照してください。 + `record: avg_cpu_usage` – この記録ルールは、`avg_cpu_usage` という新しいメトリクスを作成します。 + `interval` プロパティが指定されていない場合、ルールグループのデフォルトの評価間隔は 60 秒です。 + `expr: avg(rate(node_cpu_seconds_total[5m])) by (instance)` – この記録ルールの式は、各ノードの過去 5 分間の CPU 平均使用率を計算し、`instance` ラベル別にグループ化します。 + `alert: HighAverageCPU` – このアラートルールは、`HighAverageCPU` という新しいアラートを作成します。 + `expr: avg_cpu_usage > 0.8 ` – この式は、CPU 平均使用率が 80% を超えるサンプルを検索するようにアラートに指示します。 + `for: 10m` – アラートは、CPU の平均使用率が少なくとも 10 分間 80% を超えた場合にのみ発生します。 この場合、メトリクスは過去 5 分間の平均として計算されます。したがって、アラートは、平均 CPU 使用率が 80% を超える 5 分間のサンプル (合計 10 分) が連続して 2 つ以上ある場合にのみ発生します。 + `keep_firing_for: 20m` – このアラートは、サンプルが少なくとも 20 分間しきい値を下回るまで引き続き発生します。これは、アラートが連続して上昇と下降を繰り返すのを防ぐのに役立ちます。 **注記** ルール定義ファイルをローカルで作成して Amazon Managed Service for Prometheus にアップロードするか、Amazon Managed Service for Prometheus コンソール内で直接、定義を作成、編集、アップロードできます。どちらの場合でも、同じフォーマットルールが適用されます。ファイルのアップロードと編集の詳細については、「[Amazon Managed Service for Prometheus にルール設定ファイルをアップロードする](AMP-rules-upload.md)」を参照してください。 # Amazon Managed Service for Prometheus にルール設定ファイルをアップロードする ルール設定ファイルに必要なルールを確認したら、コンソール内でファイルを作成して編集できます。または、コンソールや AWS CLIを使用してファイルをアップロードできます。 **注記** Amazon EKS クラスターを実行している場合は、[AWS Controllers for Kubernetes](integrating-ack.md) を使用してルール設定ファイルをアップロードすることもできます。 **Amazon Managed Service for Prometheus コンソールを使用してルール設定の編集または置換、および名前空間の作成を行うには** 1. Amazon Managed Service for Prometheus コンソール ([https://console.aws.amazon.com/prometheus/](https://console.aws.amazon.com/prometheus/home)) を開きます。 1. ページの左上隅にあるメニューアイコンを選択し、**[すべての WorkSpaces]** を選択します。 1. ワークスペースのワークスペース ID を選択し、**[ルール管理]** タブを選択します。 1. **[名前空間を追加]** を選択します。 1. **[ファイルを選択]** を選択し、ルール定義ファイルを選択します。 または、**[構成を定義]** を選択して、Amazon Managed Service for Prometheus コンソール内で直接、ルール定義ファイルを作成および編集することもできます。これにより、サンプルデフォルト定義ファイルが作成されます。これを編集してアップロードします。 1. (オプション) 名前空間にタグを追加するには、**[新しいタグを追加]** を選択します。 **[キー]** にタグの名前を入力します。**[値]** では、任意でタグに値を追加できます。 別のタグを追加するには、**[新しいタグを追加]** を選択します。 1. **[続行]** を選択します。Amazon Managed Service for Prometheus は、選択したルールファイルと同じ名前で新しい名前空間を作成します。 **を使用して AWS CLI アラートマネージャー設定を新しい名前空間のワークスペースにアップロードするには** 1. アラートマネージャーファイルの内容を base64 でエンコードします。Linux では、次のコマンドを使用できます。 ``` base64 input-file output-file ``` macOS では、次のコマンドを使用できます。 ``` openssl base64 input-file output-file ``` 1. 以下のいずれかのコマンドを入力して、名前空間の作成とファイルのアップロードを行います。 AWS CLI バージョン 2 で、次のように入力します。 ``` aws amp create-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` AWS CLI バージョン 1 で、次のように入力します。 ``` aws amp create-rule-groups-namespace --data fileb://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 1. アラートマネージャーの設定が有効になるまで数秒かかります。ステータスを確認するには、次のコマンドを入力します。 ``` aws amp describe-rule-groups-namespace --workspace-id workspace_id --name namespace-name --region region ``` `status` が `ACTIVE` であれば、ルールファイルが有効になっています。 # ルール設定ファイルを編集または置換する Amazon Managed Service for Prometheus に既にアップロードしたルールファイルのルールを変更する場合は、新しいルールファイルをアップロードして既存の設定を置き換えるか、コンソールで現在の設定を直接編集できます。必要に応じて、現在のファイルをダウンロードし、テキストエディタで編集して、新しいバージョンをアップロードできます。 **Amazon Managed Service for Prometheus コンソールを使用してルール設定を編集するには** 1. Amazon Managed Service for Prometheus コンソール ([https://console.aws.amazon.com/prometheus/](https://console.aws.amazon.com/prometheus/home)) を開きます。 1. ページの左上隅にあるメニューアイコンを選択し、**[すべての WorkSpaces]** を選択します。 1. ワークスペースのワークスペース ID を選択し、**[ルール管理]** タブを選択します。 1. 編集するルール設定ファイルの名前を選択します。 1. (オプション) 現在のルール設定ファイルをダウンロードする場合は、**[ダウンロード]** または **[コピー]** を選択します。 1. **[変更]** を選択して、コンソール内で設定を直接編集します。完了したら、**[保存]** を選択します。 または、**[構成を置き換える]** を選択して、新しい設定ファイルをアップロードすることもできます。その場合は、新しいルール定義ファイルを選択し、**[続行]** を選択してアップロードします。 **を使用してルール設定ファイル AWS CLI を編集するには** 1. ルールファイルの内容を base64 でエンコードします。Linux では、次のコマンドを使用できます。 ``` base64 input-file output-file ``` macOS では、次のコマンドを使用できます。 ``` openssl base64 input-file output-file ``` 1. 以下のいずれかのコマンドを入力して、新しいファイルをアップロードします。 AWS CLI バージョン 2 で、次のように入力します。 ``` aws amp put-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` AWS CLI バージョン 1 で、次のように入力します。 ``` aws amp put-rule-groups-namespace --data fileb://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 1. ルールファイルが有効になるまで数秒かかります。ステータスを確認するには、次のコマンドを入力します。 ``` aws amp describe-rule-groups-namespace --workspace-id workspace_id --name namespace-name --region region ``` `status` が `ACTIVE` であれば、ルールファイルが有効になっています。それまでは、このルールファイルの以前のバージョンが有効なままになります。 # ルール評価のトラブルシューティング このガイドでは、Amazon Managed Service for Prometheus (AMP) のルール評価に関する一般的な問題のトラブルシューティング手順をステップバイステップで説明します。アラートルールと記録ルールの問題を診断して解決するには、次の手順に従います。 **Topics** + [アラート実行ステータスを検証する](#troubleshoot-rule-validate-firing-status) + [欠落しているアラート通知を解決する](#troubleshoot-rule-missing-alert-notifications) + [ルールのヘルスステータスを確認する](#troubleshoot-rule-check-health-status) + [クエリでオフセットを使用して取り込みの遅延を処理する](#troubleshoot-rule-offset-queries) + [一般的な の問題と解決策](#troubleshoot-rule-common-issues) + [ルール評価のベストプラクティス](#troubleshoot-rule-best-practices) ## アラート実行ステータスを検証する ルール評価の問題をトラブルシューティングするときは、まず合成時系列 `ALERTS` をクエリしてアラートが実行されたかどうかを確認します。`ALERTS` 時系列には次のラベルが含まれます。 + **alertname** – アラートの名前。 + **alertstate** – **[保留中]** または **[実行中]**。 + **pending** – アラートは `for` 句で指定された期間待機しています。 + **firing** — アラートが指定された期間、条件を満たしています。追加のラベルはアラートルールで定義されます。 **注記** アラートが **[実行中]** または **[保留中]** の場合、サンプル値は **[1]** です。アラートがアイドル状態の場合、サンプルは生成されません。 ## 欠落しているアラート通知を解決する アラートが実行中でも通知が届かない場合は、次のアラートマネージャー設定を確認します。 1. **アラートマネージャーの設定を確認する** – ルートレシーバーと設定が正しく設定されていることを確認します。アラートの実行に影響を与える可能性のある待機時間、時間間隔、必要なラベルなどのルートブロック設定を確認します。アラートルールと対応するルートとレシーバーを比較して、適切な一致を確認します。`time_interval` を持つルートの場合、タイムスタンプが指定された間隔内にあることを確認します。 1. **アラートレシーバーのアクセス許可を確認する** – Amazon SNS トピックを使用する場合は、AMP が通知を発行するために必要なアクセス許可を持っていることを確認します。詳細については、「[Amazon SNS トピックにアラートメッセージを送信するためのアクセス許可を Amazon Managed Service for Prometheus に付与する](AMP-alertmanager-receiver-AMPpermission.md)」を参照してください。 1. **レシーバーペイロードの互換性を検証する** – アラートレシーバーがアラートマネージャーのペイロード形式を受け入れていることを確認します。Amazon SNS の要件については、「[Amazon SNS メッセージ検証ルールを理解する](AMP-alertmanager-receiver-validation-truncation.md)」を参照してください。 1. **アラートマネージャーログの確認** – AMP はアラートマネージャーから公開ログを提供し、通知問題のデバッグに役立ちます。詳細については、「[CloudWatch Logs で Amazon Managed Service for Prometheus イベントをモニタリングする](CW-logs.md)」を参照してください。 アラートマネージャーの詳細については、「[アラートマネージャーを使用して Amazon Managed Service for Prometheus でアラートを管理および転送する](AMP-alert-manager.md)」を参照してください。 ## ルールのヘルスステータスを確認する ルールの形式が正しくないと、評価が失敗する可能性があります。ルールが評価に失敗した理由を特定するには、次の方法を使用します。 **Example** **ListRules API を使用する** [ListRules](AMP-APIReference-ListRules.md) API は、ルールのヘルスに関する情報を提供します。`health` および `lastError` フィールドをチェックして、問題を診断します。 **レスポンスの例:** ``` { "status": "success", "data": { "groups": [ { "name": "my_rule_group", "file": "my_namespace", "rules": [ { "state": "firing", "name": "broken_alerting_rule", "query": "...", "duration": 0, "keepFiringFor": 0, "labels": {}, "annotations": {}, "alerts": [], "health": "err", "lastError": "vector contains metrics with the same labelset after applying alert labels", "type": "alerting", "lastEvaluation": "1970-01-01T00:00:00.00000000Z", "evaluationTime": 0.08 } ] } ] } } ``` **Example** **公開ログを使用する** ListRules API には、最新の情報のみが表示されます。より詳細な履歴については、ワークスペースで[公開ログ](CW-logs.md)を有効にして以下にアクセスします。 + 評価失敗のタイムスタンプ + 詳しいエラーメッセージ + 履歴評価データ **公開ログメッセージの例:** ``` { "workspaceId": "ws-a2c55905-e0b4-4065-a310-d83ce597a391", "message": { "log": "Evaluating rule failed, name=broken_alerting_rule, group=my_rule_group, namespace=my_namespace, err=vector contains metrics with the same labelset after applying alert labels", "level": "ERROR", "name": "broken_alerting_rule", "group": "my_rule_group", "namespace": "my_namespace" }, "component": "ruler" } ``` ルーラーまたはアラートマネージャーからのログのその他の例については、「[ルーラーのトラブルシューティング](Troubleshooting-rule-fail-error.md)」および「[アラートマネージャーを使用して Amazon Managed Service for Prometheus でアラートを管理および転送する](AMP-alert-manager.md)」を参照してください。 ## クエリでオフセットを使用して取り込みの遅延を処理する デフォルトでは、式は評価時に値を使用してオフセットなし (インスタントクエリ) で評価されます。メトリクスの取り込みが遅れた場合、記録ルールは、すべてのメトリクスが取り込まれた後に式を手動で評価する場合と同じ値を表さない場合があります。 **ヒント** オフセット修飾子を使用すると、取り込みの遅延による問題を減らすことができます。詳細については、*Prometheus ドキュメント*の「[オフセット修飾子](https://prometheus.io/docs/prometheus/latest/querying/basics/#offset-modifier)」を参照してください。 ### 例: 遅延メトリクスの処理 ルールが 12:00 に評価して、取り込みの遅延によりメトリクスの最新のサンプルが 11:45 からのものである場合、ルールでは 12:00 タイムスタンプでサンプルは見つかりません。これを軽減するには、**my\$1metric\$1name offset 15m ** などのオフセットを追加します。 ### 例: 複数のソースからのメトリクスを処理する メトリクスが、2 つのサーバーなど異なるソースから生成される場合、メトリクスは異なる時間に取り込まれる可能性があります。これを軽減するには、**metric\$1from\$1server\$1A / metric\$1from\$1server\$1B ** のような式を形成します。 ルールがサーバー A とサーバー B の取り込み時間の間で評価されると、予期しない結果が得られます。オフセットを使用すると、評価時間を調整できます。 ## 一般的な の問題と解決策 **記録ルールデータにおけるギャップ** 手動評価と比較した記録ルールデータのギャップに気付いた場合 (クエリ API または UI を使用して記録ルールの元の PromQL 式を直接実行した場合)、次のいずれかが原因である可能性があります。 1. **長い評価時間** – ルールグループは複数の同時評価を持つことはできません。評価時間が設定された間隔を超えると、後続の評価が失われる可能性があります。設定された間隔を超える複数の連続した評価の欠落により、記録ルールが古くなる可能性があります。詳細については、*Prometheus ドキュメント*の「[古さ](https://prometheus.io/docs/prometheus/latest/querying/basics/#staleness)」を参照してください。CloudWatch メトリクス `RuleGroupLastEvaluationDuration` を使用して評価期間をモニタリングし、評価に時間がかかりすぎているルールグループを特定できます。 1. **欠落した評価のモニタリング** – AMP は、評価がスキップされたタイミングを追跡するための `RuleGroupIterationsMissed` CloudWatch メトリクスを提供します。ListRules API には、各ルール/グループの評価時刻と最終評価時刻が表示されます。これにより、欠落した評価のパターンを特定できます。詳細については、「[ListRules](AMP-APIReference-ListRules.md)」を参照してください。 **推奨事項: ルールを別々のグループに分割する** 評価期間を短縮するために、ルールを別々のルールグループに分割します。グループ内のルールは順番に実行されますが、ルールグループは並行して実行できます。相互に依存する関連ルールを同じグループに保持します。一般的に、ルールグループを小さくすると、評価の一貫性が向上し、ギャップが少なくなります。 ## ルール評価のベストプラクティス 1. **ルールグループサイズの最適化** – ルールグループを小さくしておき、一貫した評価を確保します。関連するルールをグループ化しますが、大きなルールグループは避けます。 1. **適切な評価間隔を設定する** — タイムリーなアラートとシステム負荷のバランスをとります。モニタリング対象のメトリクスの安定性パターンを確認して、通常の変動範囲を理解します。 1. **遅延メトリクスにオフセット修飾子を使用する** – 取り込みの遅延を補うオフセットを追加します。観測された取り込みパターンに基づいてオフセット期間を調整します。 1. **評価パフォーマンスのモニタリング** – `RuleGroupIterationsMissed` メトリクスを追跡します。ListRules API で評価時間を確認します。 1. **ルール式の検証** – ルール定義と手動クエリの間で式が完全に一致することを確認します。さまざまな時間範囲で式をテストして動作を理解します。 1. **ルールのヘルスを定期的に確認する** – ルール評価でエラーがないか確認します。定期的な問題がないか、公開ログをモニタリングします。 これらのトラブルシューティング手順とベストプラクティスに従うことにより、Amazon Managed Service for Prometheus のルール評価に関する一般的な問題を特定して解決できます。 # ルーラーのトラブルシューティング [CloudWatch Logs で Amazon Managed Service for Prometheus イベントをモニタリングする](CW-logs.md) を使用すると、アラートマネージャーとルーラーに関する問題のトラブルシューティングを行うことができます。このセクションには、ルーラー関連のトラブルシューティングトピックが含まれています。 ** **ログに次のルーラー失敗エラーが含まれている場合** ``` { "workspaceId": "ws-12345c67-89c0-4d12-345b-f14db70f7a99", "message": { "log": "Evaluating rule failed, name=failure, group=canary_long_running_vl_namespace, namespace=canary_long_running_vl_namespace, err=found duplicate series for the match group {dimension1=\\\"1\\\"} on the right hand-side of the operation: [{__name__=\\\"fake_metric2\\\", dimension1=\\\"1\\\", dimension2=\\\"b\\\"}, {__name__=\\\"fake_metric2\\\", dimension1=\\\"1\\\", dimension2=\\\"a\\\"}];many-to-many matching not allowed: matching labels must be unique on one side", "level": "ERROR", "name": "failure", "group": "canary_long_running_vl_namespace", "namespace": "canary_long_running_vl_namespace" }, "component": "ruler" } ``` これは、ルールの実行中に何らかのエラーが発生したことを示します。 **実行するアクション** エラーメッセージを使用して、ルールの実行のトラブルシューティングを行います。