セルフデプロイルールの評価とアラート

Google Cloud Managed Service for Prometheus は、Prometheus と互換性のあるルールの評価とアラートをサポートしています。このドキュメントでは、スタンドアロンのルールエバリュエータコンポーネントを含む、セルフデプロイルールの評価を設定する方法について説明します。

以下の手順を行う必要があるのは、グローバルデータストアに対してルールとアラートを実行する場合のみです。

セルフデプロイコレクションのルールの評価

Managed Service for Prometheus をデプロイしたら、Prometheus 構成ファイルの rule_files フィールドを使用して、デプロイされた各インスタンスのルールをローカルで引き続き評価できます。ただし、ルールの最大クエリウィンドウは、サーバーがローカルデータを保持する期間によって制限されます。

ほとんどのルールは最後の数分間のみ実行されるため、多くの場合、各ローカルサーバーでルールを実行するのが効果的な方法です。その場合、これ以上の設定は必要ありません。

ただし、グローバル指標バックエンドと比較してルールを評価できると便利な場合があります（たとえば、特定の Prometheus インスタンスにルールのすべてのデータが配置されていない場合など）。このような場合のために、Managed Service for Prometheus ではルールエバリュエータコンポーネントが用意されています。

始める前に

このセクションでは、このドキュメントで説明するタスクに必要な構成について説明します。

環境を構成する

プロジェクト ID またはクラスタ名を繰り返し入力しないようにするには、次の構成を行います。

コマンドラインツールを次のように構成します。
- Google Cloud プロジェクトの ID を参照するように gcloud CLI を構成します。
```
gcloud config set project PROJECT_ID
```
- クラスタを使用するように kubectl CLI を構成します。
```
kubectl config set-cluster CLUSTER_NAME
```
これらのツールの詳細については、以下をご覧ください。
- gcloud CLI の概要
- kubectl コマンド

名前空間を設定する

サンプルアプリケーションの一部として作成するリソースに NAMESPACE_NAME Kubernetes Namespace を作成します。

kubectl create ns NAMESPACE_NAME

サービスアカウントの認証情報を確認する

Kubernetes クラスタで Workload Identity Federation for GKE が有効になっている場合は、このセクションをスキップできます。

GKE で実行すると、Managed Service for Prometheus は Compute Engine のデフォルトのサービスアカウントに基づいて環境から認証情報を自動的に取得します。デフォルトのサービスアカウントには、必要な権限である monitoring.metricWriter と monitoring.viewer がデフォルトで付与されています。Workload Identity Federation for GKE を使用しておらず、以前にいずれかのロールをデフォルトのノードサービスアカウントから削除している場合は、続行する前に、不足している権限を再度追加する必要があります。

GKE で実行していない場合は、認証情報を明示的に提供するをご覧ください。

Workload Identity Federation for GKE 用のサービスアカウントを構成する

Kubernetes クラスタで Workload Identity Federation for GKE が有効になっていない場合は、このセクションをスキップできます。

Managed Service for Prometheus は、Cloud Monitoring API を使用して指標データをキャプチャします。クラスタで Workload Identity Federation for GKE を使用している場合は、Kubernetes サービスアカウントに Monitoring API の権限を付与する必要があります。このセクションでは、次のことを説明します。

専用の Google Cloud サービスアカウント gmp-test-sa を作成する。
テスト用の名前空間 NAMESPACE_NAME のデフォルトの Kubernetes サービスアカウントに Google Cloud サービスアカウントをバインドする。
Google Cloud サービスアカウントに必要な権限を付与する。

サービスアカウントを作成してバインドする

この手順は、Managed Service for Prometheus のドキュメントの複数の場所で説明されています。前のタスクですでに行っている場合は、この手順を繰り返す必要はありません。サービスアカウントを承認するに進んでください。

次のコマンドシーケンスでは、gmp-test-sa サービスアカウントを作成し、NAMESPACE_NAME 名前空間でデフォルトの Kubernetes サービスアカウントにバインドします。

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

別の GKE 名前空間またはサービスアカウントを使用している場合は、コマンドを適宜調整してください。

サービスアカウントを承認する

ロールには関連する権限がまとめられています。このロールをプリンシパル（この例では Google Cloud サービスアカウント）に付与します。Monitoring のロールの詳細については、アクセス制御をご覧ください。

次のコマンドは、Google Cloud サービスアカウント gmp-test-sa に、指標データの読み書きに必要な Monitoring API のロールを付与します。

前のタスクで Google Cloud サービスアカウントに特定のロールを付与している場合は、再度付与する必要はありません。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.viewer \
&& \
gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

Workload Identity Federation for GKE の構成をデバッグする

Workload Identity Federation for GKE の動作に問題がある場合は、Workload Identity Federation for GKE の設定の確認と Workload Identity Federation for GKE のトラブルシューティングガイドをご覧ください。

Workload Identity Federation for GKE の構成で最も一般的なエラーの原因は入力ミスや、部分的なコピー / 貼り付けです。これらの手順のコードサンプルに埋め込まれた編集可能な変数と、クリック可能なコピー / 貼り付けアイコンを使用することを強くおすすめします。

本番環境での Workload Identity Federation for GKE

このドキュメントの例では、Google Cloud サービスアカウントをデフォルトの Kubernetes サービスアカウントにバインドし、Monitoring API を使用するために必要なすべての権限を Google Cloud サービスアカウントに付与しています。

本番環境では、各コンポーネントのサービスアカウントを最小権限で使用し、よりきめ細かいアプローチを使用する必要があります。Workload Identity 管理のサービスアカウントを構成する方法の詳細については、Workload Identity Federation for GKE の使用をご覧ください。

スタンドアロンのルールエバリュエータをデプロイする

Managed Service for Prometheus ルールエバリュエータは、Managed Service for Prometheus HTTP API に対して Prometheus のアラートと記録ルールを評価し、結果を Monarch に書き込みます。Prometheus と同じ構成ファイル形式とルールファイル形式を使用できます。フラグもほとんど同じです。

アラートルールと記録ルールを評価するように事前構成されたルールエバリュエータのデプロイ例を作成します。
```
kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/rule-evaluator.yaml
```
ルールエバリュエータ用の Pod が正常にデプロイされたことを確認します。
```
kubectl -n NAMESPACE_NAME get pod
```
デプロイに成功すると、次のような出力が表示されます。
```
NAME                              READY   STATUS    RESTARTS   AGE
...
rule-evaluator-64475b696c-95z29   2/2     Running   0          1m
```

ルールエバリュエータが正常にデプロイされたことを確認したら、インストール済みのマニフェストを調整して、次の操作を行います。

カスタムルールファイルを追加する。
構成ファイルの alertmanager_config フィールドを使用して、セルフデプロイ Prometheus Alertmanager にアラートを送信するようにルールエバリュエータを構成する。

Alertmanager がルールエバリュエータとは異なるクラスタにある場合は、Endpoints リソースの設定が必要になる場合があります。たとえば、OperatorConfig によって Alertmanager エンドポイントが Endpoints オブジェクト ns=alertmanager/name=alertmanager で検出できると指定されている場合、このオブジェクトを手動またはプログラムで作成し、他のクラスタから到達可能な IP をこのオブジェクトに入力できます。

認証情報を明示的に提供する

GKE で実行する場合、ルールエバリュエータは、ノードのサービスアカウントまたは Workload Identity Federation for GKE の設定に基づいて、環境から認証情報を自動的に取得します。GKE 以外の Kubernetes クラスタでは、フラグまたは GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用して、認証情報をルールエバリュエータに明示的に提供する必要があります。

コンテキストをターゲットプロジェクトに設定します。
```
gcloud config set project PROJECT_ID
```
サービスアカウントの作成:
```
gcloud iam service-accounts create gmp-test-sa
```
この手順では、Workload Identity Federation for GKE の手順ですでに作成したサービスアカウントを作成します。

サービスアカウントに必要な権限を付与します。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.viewer \
&& \
gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

サービスアカウントキーを作成してダウンロードします。

gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

鍵ファイルを Secret として GKE 以外のクラスタに追加します。

kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

ルールエバリュエータの Deployment リソースを開いて編集します。
```
kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
```
1. 太字で示されているテキストをリソースに追加します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: rule-evaluator
spec:
  template
    containers:
    - name: evaluator
      args:
      - --query.credentials-file=/gmp/key.json
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...
```
2. ファイルを保存して、エディタを閉じます。変更が適用されると、Pod が再作成され、指定されたサービスアカウントで指標のバックエンドに対する認証が開始します。
また、この例で設定されたフラグを使用する代わりに、GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用してキーファイルパスを設定することもできます。
マルチプロジェクトとグローバルルールの評価

ルールエバリュエータは、複数のプロジェクトやリージョンに対する評価を 1 つのインスタンスで実行するのではなく、Google Cloud プロジェクトとリージョンごとにインスタンスを実行することをおすすめします。ただし、マルチプロジェクトルールの評価を必要とするシナリオもサポートされています。

Google Kubernetes Engine にデプロイされる場合、ルールエバリュエータはクラスタに関連付けられている Google Cloud プロジェクトを使用します。これは自動的に検出されます。プロジェクトにまたがるルールを評価するには、クエリ対象のプロジェクトをオーバーライドし、--query.project-id フラグを使用してマルチプロジェクト指標スコープのプロジェクトを指定します。指標スコープにすべてのプロジェクトが含まれている場合、ルールはグローバルに評価されます。詳細については、指標スコープをご覧ください。

また、ルールエバリュエータで使用されるサービスアカウントの権限を更新して、サービスアカウントでスコープ対象プロジェクトからの読み取りや、指標スコープ内のすべてのモニタリング対象プロジェクトへの書き込みを可能にする必要があります。

ルールの作成時にラベルを保持する

エバリュエータが Managed Service for Prometheus に書き戻すデータの場合、エバリュエータは Managed Service for Prometheus サーバーバイナリと同じ --export.* フラグと external_labels ベースの構成をサポートしています。ルールは、集計レベルに対して project_id、location、cluster、namespace の各ラベルが適切に保持されるように作成することを強くおすすめします。そうしないと、クエリのパフォーマンスが低下し、カーディナリティの上限に達する場合があります。

project_id または location ラベルは必須です。これらのラベルが欠落している場合、ルール評価結果の値はルールエバリュエータの構成に基づいて設定されます。cluster または namespace のラベルが欠落している場合は、値が指定されていません。

セルフオブザーバビリティ

ルールエバリュエータは、--web.listen-address フラグを使用して構成可能なポートで Prometheus 指標を出力します。

たとえば、Pod rule-evaluator-64475b696c-95z29 がこれらの指標をポート 9092 で公開している場合、kubectl を使用して指標を手動で表示できます。
```
# Port forward the metrics endpoint.
kubectl port-forward rule-evaluator-64475b696c-95z29 9092
# Then query in a separate terminal.
curl localhost:9092/metrics
```
これらのデータを収集するように Prometheus スタックを構成すると、ルールエバリュエータのパフォーマンスを把握できます。

高可用性デプロイメント

ルールエバリュエータは、Prometheus サーバー用に記述されたものと同じ方法に従って、高可用性環境で実行できます。

Cloud Monitoring の指標を使用したアラートの送信

PromQL を使用して、Google Cloud システム指標でアラートを送信するようにルールエバリュエータを構成できます。有効なクエリを作成する方法については、Cloud Monitoring 指標向け PromQL をご覧ください。

セルフデプロイ ルールの評価とアラート

セルフデプロイ コレクションのルールの評価

始める前に

環境を構成する

名前空間を設定する

サービス アカウントの認証情報を確認する

Workload Identity Federation for GKE 用のサービス アカウントを構成する

サービス アカウントを作成してバインドする

サービス アカウントを承認する

Workload Identity Federation for GKE の構成をデバッグする

本番環境での Workload Identity Federation for GKE

スタンドアロンのルール エバリュエータをデプロイする

認証情報を明示的に提供する

マルチプロジェクトとグローバル ルールの評価

ルールの作成時にラベルを保持する

セルフオブザーバビリティ

高可用性デプロイメント

Cloud Monitoring の指標を使用したアラートの送信