第5章 アラートの管理


5.1. 管理者としてアラートを管理する

OpenShift Dedicated では、アラート UI を使用してアラート、サイレンス、およびアラートルールを管理できます。

重要

OpenShift Dedicated 4.19 以降、Web コンソールのパースペクティブが統合されました。Developer パースペクティブは、デフォルトでは有効になっていません。

すべてのユーザーが、OpenShift Dedicated Web コンソールのすべての機能を操作できます。ただし、クラスターの所有者でない場合は、特定の機能にアクセスする権限をクラスターの所有者に要求する必要がある場合があります。

引き続き Developer パースペクティブを有効にできます。Web コンソールの Getting Started ペインでは、コンソールツアーの実行、クラスター設定に関する情報の検索、Developer パースペクティブを有効にするためのクイックスタートの表示、リンク先を表示して新機能の確認などを行えます。

注記

アラート UI で利用可能なアラート、サイレンス、およびアラートルールは、アクセス可能なプロジェクトに関連付けられます。たとえば、管理者としてログインしている場合は、すべてのアラート、サイレンス、アラートルールにアクセスできます。

5.1.1. アラート UI へのアクセス

アラート UI は OpenShift Dedicated Web コンソールからアクセスできます。

  • OpenShift Dedicated Web コンソールで、Observe Alerting に移動します。このパースペクティブのアラート UI には主要なページが 3 つあり、それが Alerts ページ、Silences ページ、Alerting rules ページです。

5.1.2. アラート、サイレンスおよびアラートルールに関する情報の取得

アラート UI は、アラートおよびそれらを規定するアラートルールおよびサイレンスの詳細情報を提供します。

前提条件

  • アラートを表示しているプロジェクトの表示権限を持つユーザーとしてクラスターにアクセスできる。

手順

アラートに関する情報を取得するには、以下を実行します。

  1. OpenShift Dedicated Web コンソールで、Observe Alerting Alerts ページに移動します。
  2. オプション: 検索リストで Name フィールドを使用し、アラートを名前で検索します。
  3. オプション: Filter リストでフィルターを選択し、アラートを状態、重大度およびソースでフィルターします。
  4. オプション: 1 つ以上の NameSeverityState、および Source 列ヘッダーをクリックし、アラートを並べ替えます。
  5. アラートの名前をクリックして、Alert details ページを表示します。このページには、アラートの時系列データを示すグラフが含まれます。アラートに関する次の情報も提供されます。

    • アラートの説明
    • アラートに関連付けられたメッセージ
    • アラートの GitHub 上の Runbook ページへのリンク (ページが存在する場合)
    • アラートに割り当てられるラベル
    • アラートを規定するアラートルールへのリンク
    • アラートが存在する場合のアラートのサイレンス

サイレンスの情報を取得するには、以下を実行します。

  1. OpenShift Dedicated Web コンソールで、Observe Alerting Silences ページに移動します。
  2. オプション: Search by name フィールドを使用し、サイレンスを名前でフィルターします。
  3. オプション: Filter リストでフィルターを選択し、サイレンスをフィルターします。デフォルトでは、Active および Pending フィルターが適用されます。
  4. オプション: NameFiring alertsStateCreator 列のヘッダーを 1 つ以上クリックして、サイレンスを並べ替えます。
  5. サイレンスの名前を選択すると、その Silence details ページが表示されます。このページには、以下の詳細が含まれます。

    • アラート仕様
    • 開始時間
    • 終了時間
    • サイレンス状態
    • 発生するアラートの数およびリスト

アラートルールの情報を取得するには、以下を実行します。

  1. OpenShift Dedicated Web コンソールで、Observe Alerting Alerting rules ページに移動します。
  2. オプション: Filter 一覧でフィルターを選択し、アラートルールを状態、重大度およびソースでフィルターします。
  3. オプション: NameSeverityAlert StateSource 列のヘッダーを 1 つ以上クリックし、アラートルールを並べ替えます。
  4. アラートルールの名前を選択して、その Alerting rule details ページを表示します。このページには、アラートルールに関する以下の情報が含まれます。

    • アラートルール名、重大度、説明
    • アラートを発動する条件を定義する式
    • 条件が true で持続してアラートが発生するまでの期間
    • アラートルールで管理される各アラートのグラフ。アラートが発動される値が表示されます。
    • アラートルールで管理されるすべてのアラートを示す表。

5.1.3. サイレンスの管理

OpenShift Dedicated Web コンソールでアラートのサイレンスを作成できます。サイレンスを作成した後、それらを表示、編集、および期限切れにすることができます。また、アラートが発生しても、サイレンスが適用されたアラートに関する通知は届きません。

注記

サイレンスを作成すると、それらは Alertmanager Pod 全体に複製されます。ただし、Alertmanager の永続ストレージを設定しないと、サイレンスが失われる可能性があります。これは、たとえば、すべての Alertmanager Pod が同時に再起動した場合に発生する可能性があります。

5.1.3.1. アラートをサイレントにする

特定のアラート、または定義する仕様に一致するアラートのいずれかをサイレンスにすることができます。

前提条件

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

    • Alertmanager へのアクセスを許可する cluster-monitoring-view クラスターロール。
    • アラートの作成と無音化を許可する monitoring-alertmanager-edit ロール。

手順

特定のアラートをサイレントにするには、以下を実行します。

  1. OpenShift Dedicated Web コンソールで、Observe Alerting Alerts に移動します。
  2. 消音したいアラートについては、 kebab をクリックし、アラートを消音 を選択すると、選択したアラートのデフォルト設定が表示された アラートを消音 ページが開きます。
  3. オプション: サイレンスのデフォルト設定の詳細を変更します。

    注記

    サイレンスを保存する前にコメントを追加する必要があります。

  4. サイレンスを保存するには、Silence をクリックします。

一連のアラートをサイレントにします。

  1. OpenShift Dedicated Web コンソールで、Observe Alerting Silences に移動します。
  2. Create silence をクリックします。
  3. Create silence フォームで、アラートのスケジュール、期間、およびラベルの詳細を設定します。

    注記

    サイレンスを保存する前にコメントを追加する必要があります。

  4. 入力したラベルと一致するアラートのサイレンスを作成するには、Silence をクリックします。

5.1.3.2. サイレンスの編集

サイレンスを編集すると、既存のサイレンスが期限切れになり、変更された設定で新しいサイレンスが作成されます。

前提条件

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

    • Alertmanager へのアクセスを許可する cluster-monitoring-view クラスターロール。
    • アラートの作成と無音化を許可する monitoring-alertmanager-edit ロール。

手順

  1. OpenShift Dedicated Web コンソールで、Observe Alerting Silences に移動します。
  2. 変更したい無音部分については、 kebab をクリックして 無音を編集 を選択してください。

    または、Actions をクリックし、サイレンスの Silence details ページで Edit silence を選択することもできます。

  3. Edit silence ページで変更を加え、Silence をクリックします。これにより、既存のサイレンスが期限切れになり、更新された設定でサイレンスが作成されます。

5.1.3.3. 有効期限切れにするサイレンス

単一のサイレンスまたは複数のサイレンスを期限切れにすることができます。サイレンスを期限切れにすると、そのサイレンスは永久に非アクティブ化されます。

注記

サイレンスが適用された期限切れのアラートは削除できません。120 時間を超えて期限切れになったサイレンスはガベージコレクションされます。

前提条件

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

    • Alertmanager へのアクセスを許可する cluster-monitoring-view クラスターロール。
    • アラートの作成と無音化を許可する monitoring-alertmanager-edit ロール。

手順

  1. Observe Alerting Silences に移動します。
  2. 期限切れにするサイレンスは、対応する行のチェックボックスを選択します。
  3. Expire 1 silence をクリックして選択した 1 つのサイレンスを期限切れにするか、Expire <n> silences をクリックして複数の沈黙を期限切れにします (<n> は選択した沈黙の数になります)。

    または、単一の沈黙を期限切れにするには、Actions をクリックし、サイレンスの Silence details ページで Expire silence を選択します。

5.1.4. ユーザー定義プロジェクトのアラートルールの管理

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

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

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

注記

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

前提条件

  • ユーザー定義プロジェクトのモニタリングが有効化されている。
  • アラートルールを作成するプロジェクトのクラスター管理者または 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

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

user-workload-monitoring-config config map でプロジェクトを設定することにより、元のプロジェクトにバインドされないアラートルールを作成できます。このプロジェクトで作成された PrometheusRule オブジェクトは、すべてのプロジェクトに適用できます。

そのため、各ユーザープロジェクトに個別の PrometheusRule オブジェクトを用意する代わりに、複数のユーザー定義プロジェクトに適用される汎用のアラートルールを設定できます。PrometheusRule オブジェクトで PromQL クエリーを使用すると、アラートルールに追加または除外するプロジェクトをフィルタリングできます。

前提条件

  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。

    注記

    管理者以外のユーザーであっても、アラートルールを作成するプロジェクトに対して、monitoring-rules-edit クラスターロールを持っている場合は、プロジェクト間アラートルールを作成できます。ただし、そのプロジェクトは user-workload-monitoring-config config map の namespacesWithoutLabelEnforcement プロパティーで設定する必要があり、これはクラスター管理者のみが実行できます。

  • user-workload-monitoring-config ConfigMap オブジェクトが存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。
  • 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: [ <namespace1>, <namespace2> ] 
    1
    
        # ...
    1
    クロスプロジェクトアラートルールを作成するプロジェクトを 1 つ以上指定します。ユーザー定義のモニタリング用の Prometheus および Thanos Ruler は、これらのプロジェクトで作成された PrometheusRule オブジェクトの namespace ラベルを適用しません。そのため、PrometheusRule オブジェクトはすべてのプロジェクトに適用できます。
  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 クエリー式。namespace ラベルにラベルマッチャーを使用すると、アラートルールに追加および除外するプロジェクトをフィルタリングできます。
    5
    アラートに関連付けられたメッセージ。
    6
    アラートルールがアラートに割り当てる重大度。
    重要

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

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

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

5.1.4.3. 単一ビューでのすべてのプロジェクトのアラートルールのリスト表示

dedicated-admin として、コア OpenShift Dedicated プロジェクトとユーザー定義プロジェクトのアラートルールを 1 つのビューにまとめてリストできます。

前提条件

  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift Dedicated Web コンソールで、Observe Alerting Alerting rules に移動します。
  2. Filter ドロップダウンメニューで、Platform および User ソースを選択します。

    注記

    Platform ソースはデフォルトで選択されます。

5.1.4.4. ユーザー定義プロジェクトのアラートルールの削除

ユーザー定義プロジェクトのアラートルールを削除できます。

前提条件

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

手順

  • <namespace> 内のルール <alerting_rule> を削除するには、次のコマンドを実行します。

    $ oc -n <namespace> delete prometheusrule <alerting_rule>

5.1.4.5. ユーザー定義プロジェクトのクロスプロジェクトアラートルールの無効化

ユーザー定義プロジェクトのクロスプロジェクトアラートルールの作成は、デフォルトで有効になっています。クラスター管理者は、次の理由により、cluster-monitoring-config config map でこの機能を無効にできます。

  • ユーザー定義のモニタリングによってクラスターモニタリングスタックが過負荷になるのを防止するため。
  • バグのあるアラートルールがクラスターに適用されないようにして、問題の原因となるルールを特定する必要を排除するため。

前提条件

  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. cluster-monitoring-config config map で、data/config.yaml/userWorkloadrulesWithoutLabelEnforcementAllowed 値を false に設定して、クロスプロジェクトアラートルールを作成するオプションを無効にします。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        userWorkload:
          rulesWithoutLabelEnforcementAllowed: false
        # ...
  3. 変更を適用するためにファイルを保存します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る