マネージド ルールの評価とアラート

Google Cloud Managed Service for Prometheus は、Prometheus と互換性のあるルールの評価とアラートをサポートしています。このドキュメントでは、マネージド ルールの評価を設定する方法について説明します。

ルールの評価

Managed Service for Prometheus は、グローバルな Prometheus バックエンドのコンテキストでルールを安全に作成できるルール エバリュエータ コンポーネントを提供します。これにより、大規模な組織で他のユーザーのデータへの干渉を防ぐことができます。このコンポーネントは、Kubernetes クラスタ上で実行されるときに、マネージド コレクションの一部として自動的にデプロイされます。

Managed Service for Prometheus 指標と Cloud Monitoring 指標の両方にルールとアラートを作成できます。Cloud Monitoring の指標のルールを作成する場合は、GlobalRules リソースを使用する必要があります。

注: PromQL クエリと Prometheus アラートルールに基づいて、Cloud Monitoring アラート ポリシーを作成できます。詳細については、PromQL のアラート ポリシーをご覧ください。

ルール

マネージド ルール エバリュエータは、ルールリソースを使用して記録ルールとアラートルールを構成します。以下に、ルールリソースの例を示します。

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

.spec.groups 要素の形式は、アップストリームの Prometheus rule_group 配列と同じです。Rules で定義されたアラートルールと記録ルールのスコープは、リソースの project_id、cluster、namespace です。たとえば、上記のリソースの job:up:sum ルールは、sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"}) に対してクエリを実行します。この保証により、アラートや記録のルールが誤ってアプリケーションの指標を評価することがなくなります。

サンプルルールをクラスタに適用するには、次のコマンドを実行します。

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/examples/rules.yaml

数分後、指標 job:up:sum が利用可能になります。アラート AlwaysFiring も開始します。Alertmanager にアラートを送信する方法については、Alertmanager の構成をご覧ください。

ClusterRules リソースと GlobalRules リソースは Rules リソースと同じインターフェースを提供しますが、ルールに適用されるスコープは広くなります。ClusterRules は project_id と cluster ラベルを使用してデータを選択します。GlobalRules はラベルを制限せずに、クエリ指標スコープのすべてのデータを選択します。

Prometheus カスタム リソースのすべてのマネージド サービスに関するリファレンス ドキュメントについては、prometheus-engine/doc/api リファレンスをご覧ください。

Prometheus ルールから Rules への変換

Rules リソースは Prometheus ルールと互換性のあるインターフェースを提供します。これにより、シームレスな移行を行い、既存のルールをマネージド ルールの評価に組み込むことができます。既存のルールを Rules リソースに含めることができます。たとえば、Prometheus ルールは次のとおりです。

groups:
- name: example
  interval: 30s
  rules:
  - record: job:up:sum
    expr: sum without(instance) (up)
  - alert: AlwaysFiring
    expr: vector(1)

元の Prometheus ルール（太字の部分）に対応する Rules リソースを次に示します。

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

ClusterRules

ClusterRules リソースを使用すると、特定のクラスタ内のすべての名前空間から Managed Service for Prometheus に送信されるすべての時系列データを評価できる記録ルールとアラートルールを構成できます。仕様は Rules と同じです。前の Prometheus ルールの例は、次の ClusterRules リソースになります。

apiVersion: monitoring.googleapis.com/v1
kind: ClusterRules
metadata:
  name: example-clusterrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

ClusterRules リソースは、サービス メッシュで生成された指標など、水平方向の指標にのみ使用することをおすすめします。個々のデプロイの指標について、Rules リソースを使用して、評価に意図しないデータが含まれないようにしてください。

GlobalRules

GlobalRules リソースを使用すると、指標スコープ内のすべてのプロジェクトに関して Managed Service for Prometheus に送信されるすべての時系列データを評価できる記録ルールとアラートルールを構成できます。仕様は Rules と同じです。前の Prometheus ルールの例は、次の GlobalRules リソースになります。

apiVersion: monitoring.googleapis.com/v1
kind: GlobalRules
metadata:
  name: example-globalrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

Cloud Monitoring 指標は名前空間やクラスタをスコープとしないため、Cloud Monitoring 指標のルールやアラートの作成時に GlobalRules リソースを使用する必要があります。Google Kubernetes Engine システムの指標でアラートを作成する場合は、GlobalRules も必要です。

ルールが project_id ラベルまたは location ラベルを保持しない場合は、デフォルトでクラスタの値が使用されます。

Managed Service for Prometheus 指標の場合、アラートがすべてのクラスタにまたがるデータを一度に必要とするまれなユースケースに対してのみ、GlobalRules を使用することをおすすめします。個々のデプロイの指標には、信頼性を高めるためにセキュリティ ルールまたは ClusterRules リソースを使用して、評価に意図しないデータが含まれないようにしてください。cluster ラベルと namespace ラベルは、ルールの目的がこれらのラベルの集約である場合を除き、ルール評価結果で保持することを強くおすすめします。そうしないと、クエリのパフォーマンスが低下し、カーディナリティの制限に達する可能性があります。両方のラベルを削除することはおすすめしません。

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

Google Kubernetes Engine にデプロイされる場合、ルール エバリュエータはクラスタに関連付けられているGoogle Cloud プロジェクトを使用します。これはルール エバリュエータによって自動的に検出されます。プロジェクトにまたがるルールを評価するには、マルチプロジェクトの指標スコープを持つプロジェクトを使用するように、GlobalRules リソースを実行するルール エバリュエータを構成する必要があります。作成する方法は次の 2 つです。

• マルチプロジェクトの指標スコープを持つプロジェクトに GlobalRules リソースを配置します。
• OperatorConfig に queryProjectID フィールドを設定して、マルチプロジェクト指標スコープのプロジェクトを使用します。

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

指標スコープにすべてのプロジェクトが含まれている場合、ルールはグローバルに評価されます。詳細については、指標スコープをご覧ください。

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

GlobalRules リソースを使用すると、PromQL を使用してGoogle Cloudシステム指標に関するアラートを設定できます。有効なクエリを作成する方法については、Cloud Monitoring 指標向け PromQL をご覧ください。

Terraform を使用したルールとアラートの構成

kubernetes_manifest Terraform リソースタイプまたは kubectl_manifestTerraform リソースタイプ（いずれか、任意のカスタム リソースが指定できる方）を使用して、Rules、ClusterRules、GlobalRules のリソースの作成と管理を自動化できます。

Terraform で Google Cloud を使用する場合の一般的な情報については、 Google Cloudでの Terraform をご覧ください。

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

GKE で実行する場合、ルール エバリュエータは、ノードのサービス アカウントに基づいて、環境から認証情報を自動的に取得します。GKE 以外の Kubernetes クラスタでは、gmp-public 名前空間内の OperatorConfig リソースによって認証情報を明示的に提供する必要があります。

1. コンテキストをターゲット プロジェクトに設定します。

   gcloud config set project PROJECT_ID
   

2. サービス アカウントの作成:

   gcloud iam service-accounts create gmp-test-sa
   

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

   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
   

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

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

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

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

6. OperatorConfig リソースを開いて編集します。

   kubectl -n gmp-public edit operatorconfig config
   

   1. 太字で示されているテキストをリソースに追加します。

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      rules:
        credentials:
          name: gmp-test-sa
          key: key.json
      

      マネージド コレクションが機能するように、これらの認証情報を collection セクションに追加します。

   2. ファイルを保存して、エディタを閉じます。変更が適用されると、Pod が再作成され、指定されたサービス アカウントで指標のバックエンドに対する認証が開始します。

   スケーリング ルールの評価

   ルール エバリュエータは、固定のリソース リクエストと上限を持つ単一のレプリカ Deployment として実行されます。多くのルールを評価すると OOMKilled が発生するなど、ワークロードが中断することがあります。この問題を軽減するには、VerticalPodAutoscaler をデプロイして、デプロイを垂直方向にスケーリングします。まず、Kubernetes クラスタで垂直 Pod 自動スケーリングが有効になっていることを確認します。次のように VerticalPodAutoscaler リソースを適用します。

   apiVersion: autoscaling.k8s.io/v1
   kind: VerticalPodAutoscaler
   metadata:
     name: rule-evaluator
     namespace: gmp-system
   spec:
     resourcePolicy:
       containerPolicies:
       - containerName: evaluator
         controlledResources:
           - memory
         maxAllowed:
           memory: 4Gi
         minAllowed:
           memory: 16Mi
         mode: Auto
     targetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: rule-evaluator
     updatePolicy:
       updateMode: Auto
   

   オートスケーラーが機能していることを確認するには、オートスケーラーのステータスを確認します。

   kubectl get vpa --namespace gmp-system rule-evaluator
   

   オートスケーラーが動作している場合、[PROVIDED] 列にワークロードのリソース推奨事項が計算されたことが報告されます。

   NAME             MODE   CPU   MEM        PROVIDED   AGE
   rule-evaluator   Auto   2m    11534336   True       30m
   

   構成を圧縮する

   Rules リソースが多いと、ConfigMap の容量が不足する可能性があります。この問題を解決するには、OperatorConfig リソースで gzip 圧縮を有効にします。

     apiVersion: monitoring.googleapis.com/v1
     kind: OperatorConfig
     metadata:
       namespace: gmp-public
       name: config
     features:
       config:
         compression: gzip
   

   Alertmanager の構成

   OperatorConfig リソースを使用して、Prometheus Alertmanager にアラートを送信するようにマネージド ルール エバリュエータを構成できます。セルフデプロイ Alertmanager に加えて、自動的にデプロイされたマネージド Alertmanager にアラートを送信できます。

   マネージド Alertmanager

   プレビュー版

   この機能は、 サービス固有の規約の対象となります。 一般提供前（pre-GA）の機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。 詳細については、リリース ステージの説明をご覧ください。

   Managed Service for Prometheus は、Alertmanager のマネージド インスタンスをデプロイします。これには、ルール エバリュエータが自動的にアラートを転送するように構成されます。デフォルトでは、この構成は Alertmanager 構成ファイルを含む Kubernetes Secret という名前で設定されています。

   デプロイされた Alertmanager インスタンスへのレポートを有効にして構成するには、次の操作を行います。

   1. Alertmanager の設定を含むローカル構成ファイルを作成します（サンプル構成テンプレートを参照）。

      touch alertmanager.yaml
      

   2. 目的の Alertmanager の設定でファイルを更新し、gmp-public 名前空間に alertmanager という名前の Secret を作成します。

      kubectl create secret generic alertmanager \
        -n gmp-public \
        --from-file=alertmanager.yaml
      

   しばらくすると、Managed Service for Prometheus が新しい構成ファイルの Secret を取得し、設定でマネージド Alertmanager を有効にします。

   構成ファイルの Secret 名のカスタマイズ

   マネージド Alertmanager は、構成を読み込むためのカスタム Secret 名もサポートしています。この機能は、複数の構成ファイルの Secret があり、Alertmanager インスタンスで対応する構成ファイル間の切り替えを行う場合に役立ちます。たとえば、ローテーションのオンコール シフトに基づいてアラート通知チャンネルを変更する場合や、試験運用版の Alertmanager の構成ファイルに切り替えて新しいアラートルートをテストする場合などです。

   OperatorConfig リソースを使用してデフォルト以外の Secret 名を指定するには、次の操作を行います。

   1. ローカルの Alertmanager 構成ファイルから Secret を作成します。

      kubectl create secret generic SECRET_NAME \
        -n gmp-public \
        --from-file=FILE_NAME
      

   2. OperatorConfig リソースを開いて編集します。

      kubectl -n gmp-public edit operatorconfig config
      

   3. マネージド Alertmanager のレポートを有効にするには、次の太字のテキストに示すように managedAlertmanager セクションを変更してリソースを編集します。

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      managedAlertmanager:
        configSecret:
          name: SECRET_NAME
          key: FILE_NAME
      

   Alertmanager の構成を変更する必要がある場合は、前に作成した Secret を更新して、この Alertmanager の構成を編集できます。

   外部 URL のカスタマイズ

   アラート通知でアラート UI へのコールバック リンクが提供されるように、マネージド Alertmanager の外部 URL を構成できます。これは、アップストリームの Prometheus Alertmanager の --web.external-url フラグを使用する場合と同じです。

   apiVersion: monitoring.googleapis.com/v1
   kind: OperatorConfig
   metadata:
     namespace: gmp-public
     name: config
   managedAlertmanager:
     externalURL: EXTERNAL_URL
   

   セルフデプロイ Alertmanager

   セルフデプロイ Alertmanager のルール エバリュエータを構成するには、次の操作を行います。

   1. OperatorConfig リソースを開いて編集します。

      kubectl -n gmp-public edit operatorconfig config
      

   2. Alertmanager サービスにアラートを送信するようにリソースを構成します。

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      rules:
        alerting:
          alertmanagers:
          - name: SERVICE_NAME
            namespace: SERVICE_NAMESPACE
            port: PORT_NAME
      

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

   アイドル時のリソースの節約

   Rules、ClusterRules、GlobalRules リソースが構成されていない場合、GKE はルール評価ツールと Alertmanager のデプロイをゼロにスケーリングし、マネージド ルールやアラートを使用しない場合のクラスタ リソースを節約します。新しい Rules リソースを適用すると、これらの Deployment は自動的にスケールアップされます。何もしない Rules リソースを適用することで、強制的にスケールアップできます。