3.5. コアプラットフォームモニタリングのアラートと通知の設定


ローカルまたは外部の Alertmanager インスタンスを設定して、Prometheus からエンドポイントレシーバーにアラートをルーティングできます。すべての時系列とアラートにカスタムラベルを割り当てて、便利なメタデータ情報を追加することもできます。

3.5.1. 外部 Alertmanager インスタンスの設定

OpenShift Container Platform モニタリングスタックには、Prometheus からのアラートのルートなど、ローカルの Alertmanager インスタンスが含まれます。

外部の Alertmanager インスタンスを追加すると、OpenShift Container Platform コアプロジェクトのアラートをルーティングできます。

複数のクラスターに同じ外部 Alertmanager 設定を追加し、クラスターごとにローカルインスタンスを無効にする場合には、単一の外部 Alertmanager インスタンスを使用して複数のクラスターのアラートルーティングを管理できます。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    Copy to Clipboard Toggle word wrap
    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml/prometheusK8s の下に、設定の詳細を含む additionalAlertmanagerConfigs セクションを追加します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          additionalAlertmanagerConfigs:
          - <alertmanager_specification> 
    1
    1
    <alertmanager_specification> は、追加の Alertmanager インスタンスの認証やその他の設定の詳細に置き換えます。現時点で、サポートされている認証方法はベアラートークン (bearerToken) およびクライアント TLS(tlsConfig) です。

    次のサンプル config map は、クライアント TLS 認証でベアラートークンを使用して、Prometheus 用の追加の Alertmanager を設定します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          additionalAlertmanagerConfigs:
          - scheme: https
            pathPrefix: /
            timeout: "30s"
            apiVersion: v1
            bearerToken:
              name: alertmanager-bearer-token
              key: token
            tlsConfig:
              key:
                name: alertmanager-tls
                key: tls.key
              cert:
                name: alertmanager-tls
                key: tls.crt
              ca:
                name: alertmanager-tls
                key: tls.ca
            staticConfigs:
            - external-alertmanager1-remote.com
            - external-alertmanager1-remote2.com
  3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。

3.5.1.1. ローカル Alertmanager の無効化

Prometheus インスタンスからのアラートをルーティングするローカル Alertmanager は、OpenShift Container Platform モニタリングスタックの openshift-monitoring プロジェクトではデフォルトで有効になっています。

ローカル Alertmanager を必要としない場合、openshift-monitoring プロジェクトで cluster-monitoring-config config map を指定して無効にできます。

前提条件

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

手順

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

    Copy to Clipboard Toggle word wrap
    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml の下に、alertmanagerMain コンポーネントの enabled: false を追加します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          enabled: false
  3. 変更を適用するためにファイルを保存します。Alertmanager インスタンスは、この変更を適用すると自動的に無効にされます。

関連情報

3.5.2. Alertmanager のシークレットの設定

OpenShift Container Platform モニタリングスタックには、アラートを Prometheus からエンドポイントレシーバーにルーティングする Alertmanager が含まれています。Alertmanager がアラートを送信できるようにレシーバーで認証する必要がある場合は、レシーバーの認証認証情報を含むシークレットを使用するように Alertmanager を設定できます。

たとえば、シークレットを使用して、プライベート認証局 (CA) によって発行された証明書を必要とするエンドポイント受信者を認証するように Alertmanager を設定できます。また、基本 HTTP 認証用のパスワードファイルを必要とする受信者で認証するためにシークレットを使用するように Alertmanager を設定することもできます。いずれの場合も、認証の詳細は、ConfigMap オブジェクトではなく Secret オブジェクトに含まれています。

3.5.2.1. Alertmanager 設定へのシークレットの追加

openshift-monitoring プロジェクトの cluster-monitoring-config config map を編集することで、Alertmanager 設定にシークレットを追加できます。

config map にシークレットを追加すると、シークレットは、Alertmanager Pod の alertmanager コンテナー内の /etc/alertmanager/secrets/<secret_name> にボリュームとしてマウントされます。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config config map を作成している。
  • openshift-monitoring プロジェクトの Alertmanager で設定するシークレットを作成しました。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    Copy to Clipboard Toggle word wrap
    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml/alertmanagerMain の下に secrets: セクションを次の設定で追加します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          secrets: 
    1
    
          - <secret_name_1> 
    2
    
          - <secret_name_2>
    1
    このセクションには、Alertmanager にマウントされるシークレットが含まれています。シークレットは、Alertmanager オブジェクトと同じ namespace 内に配置する必要があります。
    2
    受信者の認証認証情報を含む Secret オブジェクトの名前。複数のシークレットを追加する場合は、それぞれを新しい行に配置します。

    次の config map 設定の例では、test-secret-basic-auth および test-secret-api-token という名前の 2 つの Secret オブジェクトを使用するように Alertmanager を設定します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          secrets:
          - test-secret-basic-auth
          - test-secret-api-token
  3. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

3.5.3. 追加ラベルの時系列 (time series) およびアラートへの割り当て

Prometheus の外部ラベル機能を使用して、Prometheus から送信されるすべての時系列とアラートにカスタムラベルを付けることができます。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    Copy to Clipboard Toggle word wrap
    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml の下の各メトリクスに追加するラベルを定義します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          externalLabels:
            <key>: <value> 
    1
    1
    <key>: <value> をキーと値のペアに置き換えます。<key> は新しいラベルの一意の名前、<value> はその値です。
    警告
    • prometheus または prometheus_replica は予約され、上書きされるため、これらをキー名として使用しないでください。
    • キー名に cluster または managed_cluster を使用しないでください。これらを使用すると、開発者ダッシュボードでデータが表示されなくなる問題が発生する可能性があります。

    たとえば、リージョンと環境に関するメタデータをすべての時系列とアラートに追加するには、次の例を使用します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          externalLabels:
            region: eu
            environment: prod
  3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。

3.5.4. アラート通知の設定

OpenShift Container Platform 4.18 では、アラート UI でアラートの発生を確認できます。アラートレシーバーを設定することで、デフォルトのプラットフォームアラートに関する通知を送信するように Alertmanager を設定できます。

重要

Alertmanager はデフォルトでは通知を送信しません。Web コンソールまたは alertmanager-main シークレットを通じてアラートレシーバーを設定して、通知を受信するように Alertmanager を設定することを強く推奨します。

3.5.4.1. デフォルトのプラットフォームアラートのアラートルーティングを設定する

クラスターからの重要なアラートを受信するために通知を送信するように Alertmanager を設定できます。Alertmanager からデフォルトのプラットフォームアラートに関する通知を送信する場所と方法をカスタマイズするには、openshift-monitoring namespace の alertmanager-main シークレットのデフォルト設定を編集します。

注記

サポート対象のアップストリームバージョンの Alertmanager 機能はすべて、OpenShift Container Platform の Alertmanager 設定でもサポートされます。サポート対象のアップストリーム Alertmanager バージョンのあらゆる設定オプションを確認するには、Alertmanager configuration (Prometheus ドキュメント) を参照してください。

前提条件

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

手順

  1. 現在アクティブな Alertmanager 設定を alertmanager-main シークレットから展開し、ローカルの alertmanager.yaml ファイルとして保存します。

    Copy to Clipboard Toggle word wrap
    $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
  2. alertmanager.yaml ファイルを開きます。
  3. Alertmanager の設定を編集します。

    1. オプション: デフォルトの Alertmanager 設定を変更します。

      デフォルトの Alertmanager シークレット YAML の例

      Copy to Clipboard Toggle word wrap
      global:
        resolve_timeout: 5m
        http_config:
          proxy_from_environment: true 
      1
      
      route:
        group_wait: 30s 
      2
      
        group_interval: 5m 
      3
      
        repeat_interval: 12h 
      4
      
        receiver: default
        routes:
        - matchers:
          - "alertname=Watchdog"
          repeat_interval: 2m
          receiver: watchdog
      receivers:
      - name: default
      - name: watchdog

      1
      HTTP クラスター全体のプロキシーを設定した場合は、proxy_from_environment パラメーターを true に設定して、すべてのアラートレシーバーのプロキシーを有効にします。
      2
      Alertmanager が通知を送信する前に、アラートグループの初期アラートを収集するまで待機する時間を指定します。
      3
      最初の通知がすでに送信されているアラートグループに追加された新しいアラートに関する通知を Alertmanager が送信するまでの時間を指定します。
      4
      アラート通知を繰り返すまでの最小時間を指定します。各グループの間隔で通知を繰り返す場合は、repeat_interval の値を group_interval の値よりも小さく設定します。ただし、特定の Alertmanager Pod が再起動または再スケジュールされた場合などには、通知の繰り返しが遅れる可能性があります。
    2. アラートレシーバーの設定を追加します。

      Copy to Clipboard Toggle word wrap
      # ...
      receivers:
      - name: default
      - name: watchdog
      - name: <receiver> 
      1
      
        <receiver_configuration> 
      2
      
      # ...
      1
      レシーバーの名前。
      2
      レシーバーの設定。サポートされているレシーバーは、PagerDuty、Webhook、メール、Slack、Microsoft Teams です。

      PagerDuty をアラートレシーバーとして設定する例

      Copy to Clipboard Toggle word wrap
      # ...
      receivers:
      - name: default
      - name: watchdog
      - name: team-frontend-page
        pagerduty_configs:
        - routing_key: xxxxxxxxxx 
      1
      
          http_config: 
      2
      
            proxy_from_environment: true
            authorization:
              credentials: xxxxxxxxxx
      # ...

      1
      PagerDuty 統合キーを定義します。
      2
      オプション: 特定のレシーバーのカスタム HTTP 設定を追加します。そのレシーバーはグローバル HTTP 設定を継承しません。

      メールアドレスをアラートレシーバーとして設定する例

      Copy to Clipboard Toggle word wrap
      # ...
      receivers:
      - name: default
      - name: watchdog
      - name: team-frontend-page
        email_configs:
          - to: myemail@example.com 
      1
      
            from: alertmanager@example.com 
      2
      
            smarthost: 'smtp.example.com:587' 
      3
      
            auth_username: alertmanager@example.com  
      4
      
            auth_password: password
            hello: alertmanager 
      5
      
      # ...

      1
      通知を送信するメールアドレスを指定します。
      2
      通知を送信するメールアドレスを指定します。
      3
      メールの送信に使用する SMTP サーバーアドレスを、ポート番号を含めて指定します。
      4
      Alertmanager が SMTP サーバーに接続するために使用する認証情報を指定します。この例では、ユーザー名とパスワードを使用します。
      5
      SMTP サーバーに識別させるためのホスト名を指定します。このパラメーターを含めない場合、ホスト名はデフォルトで localhost になります。
      重要

      Alertmanager には、メールアラートを送信するために外部 SMTP サーバーが必要です。メールアラートのレシーバーを設定する際には、外部 SMTP サーバーの必要な接続の詳細情報があることを確認してください。

    3. ルーティング設定を追加します。

      Copy to Clipboard Toggle word wrap
      # ...
      route:
        group_wait: 30s
        group_interval: 5m
        repeat_interval: 12h
        receiver: default
        routes:
        - matchers:
          - "alertname=Watchdog"
          repeat_interval: 2m
          receiver: watchdog
        - matchers: 
      1
      
          - "<your_matching_rules>" 
      2
      
          receiver: <receiver> 
      3
      
      # ...
      1
      アラートがノードと一致するために満たす必要がある一致ルールを指定するには、matchers キー名を使用します。禁止ルールを定義する場合は、ターゲットマッチャーに target_matchers キー名を使用し、ソースマッチャーに source_matchers キー名を使用します。
      2
      アラートに一致するラベルを指定します。
      3
      アラートに使用するレシーバーの名前を指定します。
      警告

      matchmatch_retarget_matchtarget_match_resource_matchsource_match_re のキー名は使用しないでください。これらは非推奨であり、今後のリリースで削除される予定です。

      アラートルーティングの例

      Copy to Clipboard Toggle word wrap
      # ...
      route:
        group_wait: 30s
        group_interval: 5m
        repeat_interval: 12h
        receiver: default
        routes:
        - matchers:
          - "alertname=Watchdog"
          repeat_interval: 2m
          receiver: watchdog
        - matchers: 
      1
      
          - "service=example-app"
          routes: 
      2
      
          - matchers:
            - "severity=critical"
            receiver: team-frontend-page
      # ...

      1
      この例では、example-app サービスからのアラートが一致します。
      2
      より複雑なアラートルーティングを設定するために、他のルート内にルートを作成することもできます。

      前の例では、example-app サービスによって発生した重大度が critical のアラートが、team-frontend-page レシーバーにルーティングされます。通常、このタイプのアラートは、個人または緊急対応チームに通知します。

  4. 新規設定をファイルで適用します。

    Copy to Clipboard Toggle word wrap
    $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-monitoring replace secret --filename=-
  5. ルーティングツリーを可視化してルーティング設定を確認します。

    Copy to Clipboard Toggle word wrap
    $ oc exec alertmanager-main-0 -n openshift-monitoring -- amtool config routes show --alertmanager.url http://localhost:9093

    出力例

    Copy to Clipboard Toggle word wrap
    Routing tree:
    .
    └── default-route  receiver: default
        ├── {alertname="Watchdog"}  receiver: Watchdog
        └── {service="example-app"}  receiver: default
            └── {severity="critical"}  receiver: team-frontend-page

関連情報

3.5.4.2. OpenShift Container Platform Web コンソールを使用したアラートルーティングの設定

OpenShift Container Platform Web コンソールを使用してアラートルーティングを設定すると、クラスターの重要な問題を確実に把握できます。

注記

OpenShift Container Platform Web コンソールでは、alertmanager-main シークレットよりもアラートルーティングを設定するための設定が少なくなっています。より多くの設定にアクセスしてアラートルーティングを設定するには、「デフォルトのプラットフォームアラートのアラートルーティングを設定する」を参照してください。

前提条件

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

手順

  1. Administrator パースペクティブで、Administration Cluster Settings Configuration Alertmanager に移動します。

    注記

    または、通知ドロワーから同じページに移動することもできます。OpenShift Container Platform Web コンソールの右上にあるベルのアイコンを選択し、AlertmanagerReceiverNotConfigured アラートで Configure を選択します。

  2. ページの Receivers セクションで、Create Receiver をクリックします。
  3. Create Receiver フォームで、Receiver name を追加し、リストから Receiver type を選択します。
  4. レシーバー設定を編集します。

    • PagerDuty receiver の場合:

      1. 統合のタイプを選択し、PagerDuty 統合キーを追加します。
      2. PagerDuty インストールの URL を追加します。
      3. クライアントおよびインシデントの詳細または重大度の指定を編集する場合は、Show advanced configuration をクリックします。
    • Webhook receiver の場合:

      1. HTTP POST リクエストを送信するエンドポイントを追加します。
      2. デフォルトオプションを編集して解決したアラートを receiver に送信する場合は、Show advanced configuration をクリックします。
    • メール receiver の場合:

      1. 通知を送信するメールアドレスを追加します。
      2. SMTP 設定の詳細を追加します。これには、通知の送信先のアドレス、メールの送信に使用する smarthost およびポート番号、SMTP サーバーのホスト名、および認証情報を含む詳細情報が含まれます。

        重要

        Alertmanager には、メールアラートを送信するために外部 SMTP サーバーが必要です。メールアラートのレシーバーを設定する際には、外部 SMTP サーバーの必要な接続の詳細情報があることを確認してください。

      3. TLS が必要かどうかを選択します。
      4. 解決済みのアラートが receiver に送信されないようにデフォルトオプションを編集する、またはメール通知設定のボディーを編集する必要がある場合は、Show advanced configuration をクリックします。
    • Slack receiver の場合:

      1. Slack Webhook の URL を追加します。
      2. 通知を送信する Slack チャネルまたはユーザー名を追加します。
      3. デフォルトオプションを編集して解決済みのアラートが receiver に送信されないようにしたり、アイコンおよびユーザー設定を編集する必要がある場合は、Show advanced configuration を選択します。チャネル名とユーザー名を検索し、これらをリンクするかどうかについて選択することもできます。
  5. デフォルトでは、すべてのセレクターに一致するラベルを持つ Firing アラートが receiver に送信されます。receiver に送信する前に、Firing アラートのラベル値を完全に一致させる場合は、次の手順を実行します。

    1. フォームの Routing Labels セクションに、ルーティングラベルの名前と値を追加します。
    2. Add label を選択して、さらにルーティングラベルを追加します。
  6. Create をクリックしてレシーバーを作成します。

関連情報

3.5.4.3. デフォルトのプラットフォームアラートとユーザー定義アラートに異なるアラートレシーバーを設定する

デフォルトのプラットフォームアラートとユーザー定義アラートに異なるアラートレシーバーを設定して、次の結果を確実に得ることができます。

  • すべてのデフォルトのプラットフォームアラートは、これらのアラートを担当するチームが所有する受信機に送信されます。
  • すべてのユーザー定義アラートは別の受信者に送信されるため、チームはプラットフォームアラートにのみ集中できます。

これを実現するには、Cluster Monitoring Operator によってすべてのプラットフォームアラートに追加される openshift_io_alert_source="platform" ラベルを使用します。

  • デフォルトのプラットフォームアラートを一致させるには、openshift_io_alert_source="platform" マッチャーを使用します。
  • ユーザー定義のアラートを一致させるには、openshift_io_alert_source!="platform" または 'openshift_io_alert_source=""' マッチャーを使用します。
注記

ユーザー定義アラート専用の Alertmanager の別のインスタンスを有効にしている場合、この設定は適用されません。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.