10.6. ユーザー定義プロジェクトのアラートルールの作成


OpenShift Container Platform では、ユーザー定義プロジェクトのアラートルールを作成できます。これらのアラートルールは、選択したメトリクスの値に基づいてアラートをトリガーします。

ユーザー定義プロジェクトのアラートルールを作成する場合は、新しいルールを定義する際に次の主要な動作と重要な制限事項を考慮してください。

  • ユーザー定義のアラートルールには、コアプラットフォームのモニタリングからのデフォルトメトリクスに加えて、独自のプロジェクトが公開したメトリクスを含めることができます。別のユーザー定義プロジェクトのメトリクスを含めることはできません。

    たとえば、ns1 ユーザー定義プロジェクトのアラートルールでは、CPU やメモリーメトリクスなどのコアプラットフォームメトリクスに加えて、ns1 プロジェクトが公開したメトリクスも使用できます。ただし、ルールには、別の ns2 ユーザー定義プロジェクトからのメトリクスを含めることはできません。

  • デフォルトでは、アラートルールを作成すると、別のプロジェクトに同じ名前のルールが存在する場合でも、namespace ラベルがそのアラートルールに適用されます。元のプロジェクトにバインドされないアラートルールを作成するには、「ユーザー定義プロジェクトのクロスプロジェクトアラートルールの作成」を参照してください。
  • レイテンシーを短縮し、コアプラットフォームモニタリングコンポーネントの負荷を最小限に抑えるために、ルールに openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus ラベルを追加できます。このラベルは、openshift-user-workload-monitoring プロジェクトにデプロイされた Prometheus インスタンスのみにアラートルールの評価を強制し、Thanos Ruler インスタンスによる評価を防ぎます。

    重要

    アラートルールにこのラベルが付いている場合、そのアラートルールはユーザー定義プロジェクトが公開するメトリクスのみを使用できます。デフォルトのプラットフォームメトリクスに基づいて作成したアラートルールでは、アラートがトリガーされない場合があります。

10.6.1. ユーザー定義プロジェクトのアラートの最適化

アラートルールの作成時に以下の推奨事項を考慮して、独自のプロジェクトのアラートを最適化できます。

  • プロジェクト用に作成するアラートルールの数を最小限にします。影響を与える状況を通知するアラートルールを作成します。影響を与えない条件に対して多数のアラートを生成すると、関連するアラートに気づくのがさらに困難になります。
  • 原因ではなく現象に関するアラートルールを作成します。根本的な原因に関係なく、状態を通知するアラートルールを作成します。次に、原因を調査できます。アラートルールのそれぞれが特定の原因にのみ関連する場合に、さらに多くのアラートルールが必要になります。そのため、いくつかの原因は見落される可能性があります。
  • アラートルールを作成する前にプランニングを行います。重要な現象と、その発生時に実行するアクションを決定します。次に、現象別にアラートルールをビルドします。
  • クリアなアラートメッセージングを提供します。アラートメッセージに現象および推奨されるアクションを記載します。
  • アラートルールに重大度レベルを含めます。アラートの重大度は、報告される現象が生じた場合に取るべき対応によって異なります。たとえば、現象に個人または緊急対策チーム (Critical Response Team) による早急な対応が必要な場合は、重大アラートをトリガーする必要があります。

10.6.2. ユーザー定義プロジェクトのアラートルールの作成

ユーザー定義のプロジェクトに対してアラートルールを作成できます。これらのアラートルールは、選択したメトリクスの値に基づいてアラートをトリガーします。

注記

ユーザーがアラートの影響と原因を理解できるように、アラートルールにアラートメッセージと重大度値が含まれていることを確認します。

前提条件

  • ユーザー定義プロジェクトのモニタリングが有効化されている。
  • アラートルールを作成する必要のあるプロジェクトの monitoring-rules-edit クラスターロールを持つユーザーとしてログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. アラートルールの YAML ファイルを作成します。この例では、example-app-alerting-rule.yaml という名前です。
  2. アラートルール設定を YAML ファイルに追加します。以下の例では、example-alert という名前の新規アラートルールを作成します。アラートルールは、サンプルサービスによって公開される version メトリクスが 0 になるとアラートを実行します。

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: example-alert
      namespace: ns1
    spec:
      groups:
      - name: example
        rules:
        - alert: VersionAlert 1
          for: 1m 2
          expr: version{job="prometheus-example-app"} == 0 3
          labels:
            severity: warning 4
          annotations:
            message: This is an example alert. 5
    1
    作成する必要のあるアラートルールの名前。
    2
    アラートが発せられる前に条件が真である必要がある期間。
    3
    新規ルールを定義する PromQL クエリー式。
    4
    アラートルールがアラートに割り当てる重大度。
    5
    アラートに関連付けられたメッセージ。
  3. 設定ファイルをクラスターに適用します。

    $ oc apply -f example-app-alerting-rule.yaml

10.6.3. ユーザー定義プロジェクトのクロスプロジェクトアラートルールの作成

user-workload-monitoring-config config map でプロジェクトを設定することにより、元のプロジェクトにバインドされないユーザー定義プロジェクト用アラートルールを作成できます。これにより、各ユーザープロジェクトに個別の PrometheusRule オブジェクトを用意する代わりに、複数のユーザー定義プロジェクトに適用される汎用のアラートルールを作成できます。

前提条件

  • クラスター管理者の場合は、cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • 管理者以外のユーザーの場合は、次のユーザーロールを持つユーザーとしてクラスターにアクセスできる。

    • user-workload-monitoring-config config map を編集するための、openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロール。
    • アラートルールを作成するプロジェクトの monitoring-rules-edit クラスターロール。
  • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config config map を編集します。

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 特定のプロジェクトにバインドされないアラートルールを作成するプロジェクトを設定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        namespacesWithoutLabelEnforcement: [ <namespace> ] 1
        # ...
    1
    クロスプロジェクトアラートルールを作成するプロジェクトを 1 つ以上指定します。ユーザー定義のモニタリング用の Prometheus および Thanos Ruler は、これらのプロジェクト内に作成された PrometheusRule オブジェクトの namespace ラベルを適用しません。
  3. アラートルールの YAML ファイルを作成します。この例では、example-cross-project-alerting-rule.yaml という名前です。
  4. アラートルール設定を YAML ファイルに追加します。次の例では、example-security という名前の新しいクロスプロジェクトアラートルールを作成します。ユーザープロジェクトが制限付き Pod セキュリティーポリシーを適用しない場合、このアラートルールが起動します。

    クロスプロジェクトアラートルールの例

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: example-security
    namespace: ns1 1
    spec:
      groups:
        - name: pod-security-policy
          rules:
            - alert: "ProjectNotEnforcingRestrictedPolicy" 2
              for: 5m 3
              expr: kube_namespace_labels{namespace!~"(openshift|kube).*|default",label_pod_security_kubernetes_io_enforce!="restricted"} 4
              annotations:
                message: "Restricted policy not enforced. Project {{ $labels.namespace }} does not enforce the restricted pod security policy." 5
              labels:
                severity: warning 6

    1
    必ず namespacesWithoutLabelEnforcement フィールドで定義したプロジェクトを指定します。
    2
    作成する必要のあるアラートルールの名前。
    3
    アラートが発せられる前に条件が真である必要がある期間。
    4
    新規ルールを定義する PromQL クエリー式。
    5
    アラートに関連付けられたメッセージ。
    6
    アラートルールがアラートに割り当てる重大度。
    重要

    namespacesWithoutLabelEnforcement フィールドで指定したプロジェクトのうちの 1 つにだけ、特定のクロスプロジェクトアラートルールを作成してください。複数のプロジェクトで同じクロスプロジェクトアラートルールを作成すると、アラートが繰り返し発生します。

  5. 設定ファイルをクラスターに適用します。

    $ oc apply -f example-cross-project-alerting-rule.yaml
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.