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 を編集します。

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

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

    以下の設定マップは、クライアント TLS 認証でベアラートークンを使用して Prometheus の追加の Alertmanager を設定します。

    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 を編集します。

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

    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 設定マップを編集して、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 を編集します。

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

    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 を設定します。

    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 を編集します。

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

    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 を使用しないでください。これらを使用すると、開発者ダッシュボードでデータが表示されなくなる問題が発生する可能性があります。

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

    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.16 では、アラート 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 設定 (Prometheus ドキュメント)を参照してください。

前提条件

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

手順

  1. Alertmanager の YAML 設定ファイルを開きます。

    • CLI から Alertmanager 設定を開くには、以下を実行します。

      1. 現在アクティブな Alertmanager 設定を、alertmanager-main シークレットから alertmanager.yaml ファイルに出力します。

        $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
      2. alertmanager.yaml ファイルを開きます。
    • OpenShift Container Platform Web コンソールから Alertmanager 設定を開くには、以下を実行します。

      1. Web コンソールの Administration Cluster Settings Configuration Alertmanager YAML ページに移動します。
  2. YAML 内のパラメーターを更新して、Alertmanager 設定を編集します。

    global:
      resolve_timeout: 5m
    route:
      group_wait: 30s 1
      group_interval: 5m 2
      repeat_interval: 12h 3
      receiver: default
      routes:
      - matchers:
        - "alertname=Watchdog"
        repeat_interval: 2m
        receiver: watchdog
      - matchers:
        - "service=<your_service>" 4
        routes:
        - matchers:
          - <your_matching_rules> 5
          receiver: <receiver> 6
    receivers:
    - name: default
    - name: watchdog
    - name: <receiver>
      <receiver_configuration> 7
    1
    Alertmanager が通知を送信する前に、アラートグループの初期アラートを収集するまで待機する時間を指定します。
    2
    最初の通知がすでに送信されているアラートグループに追加された新しいアラートに関する通知を Alertmanager が送信するまでの時間を指定します。
    3
    アラート通知を繰り返すまでの最小時間を指定します。各グループの間隔で通知を繰り返す場合は、repeat_interval の値を group_interval の値よりも小さく設定します。ただし、特定の Alertmanager Pod が再起動または再スケジュールされた場合などには、通知の繰り返しが遅れる可能性があります。
    4
    アラートを発生させるサービスの名前を指定します。
    5
    アラートに一致するラベルを指定します。
    6
    アラートに使用するレシーバーの名前を指定します。
    7
    レシーバーの設定を指定します。
    重要
    • matchers キー名を使用して、ノードの照合でアラートが満たす必要のあるマッチャーを指定します。match または match_re キー名は使用しないでください。どちらも非推奨であり、今後のリリースで削除される予定です。
    • 抑制ルールを定義する場合は、次のキー名を使用します。

      • target_matchers: ターゲットマッチャーを示します。
      • source_matchers: ソースマッチャーを示します。

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

    以下の Alertmanager 設定例は、PagerDuty をアラートレシーバーとして設定します。

    global:
      resolve_timeout: 5m
    route:
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 12h
      receiver: default
      routes:
      - matchers:
        - "alertname=Watchdog"
        repeat_interval: 2m
        receiver: watchdog
      - matchers:
        - "service=example-app"
        routes:
        - matchers:
          - "severity=critical"
          receiver: team-frontend-page
    receivers:
    - name: default
    - name: watchdog
    - name: team-frontend-page
      pagerduty_configs:
      - service_key: "<your_key>"

    この設定では、example-app サービスによって発生した重大度が critical のアラートが、team-frontend-page レシーバーを介して送信されます。通常、この種のアラートは、個人または緊急対応チームに通知します。

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

    • CLI から変更を適用するには、次のコマンドを実行します。

      $ 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=-
    • OpenShift Container Platform Web コンソールから変更を適用するには、Save をクリックします。

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 サーバーのホスト名、および認証情報を含む詳細情報が含まれます。
      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 は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.