4.5. ユーザーワークロードモニタリングのアラートと通知の設定


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

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

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

外部 Alertmanager インスタンスを追加して、ユーザー定義プロジェクトのアラートをルーティングできます。

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-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
    Copy to Clipboard Toggle word wrap
  2. data/config.yaml/<component> 下に、設定の詳細を含む additionalAlertmanagerConfigs セクションを追加します。

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

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

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          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
    Copy to Clipboard Toggle word wrap
  3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。

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

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

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

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

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

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
  • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
  • openshift-user-workload-monitoring プロジェクトの Alertmanager で設定するシークレットを作成しました。
  • 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
    Copy to Clipboard Toggle word wrap
  2. 次の設定で、data/config.yaml/alertmanager の下に secrets: セクションを追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        alertmanager:
          secrets: 
    1
    
          - <secret_name_1> 
    2
    
          - <secret_name_2>
    Copy to Clipboard Toggle word wrap
    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: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        alertmanager:
          secrets:
          - test-secret-basic-auth
          - test-secret-api-token
    Copy to Clipboard Toggle word wrap
  3. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

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

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-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
    Copy to Clipboard Toggle word wrap
  2. data/config.yaml の下の各メトリクスに追加するラベルを定義します。

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

    openshift-user-workload-monitoring プロジェクトでは、Prometheus はメトリクスを処理し、Thanos Ruler はアラートおよび記録ルールを処理します。user-workload-monitoring-config ConfigMap オブジェクトで prometheusexternalLabels を設定すると、すべてのルールではなく、メトリクスの外部ラベルのみが設定されます。

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

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

4.5.4. アラート通知の設定

OpenShift Container Platform では、管理者は次のいずれかの方法でユーザー定義プロジェクトのアラートルーティングを有効にできます。

  • デフォルトのプラットフォーム Alertmanager インスタンスを使用します。
  • ユーザー定義プロジェクトにのみ、別の Alertmanager インスタンスを使用します。

alert-routing-edit クラスターロールを持つ開発者およびその他のユーザーは、アラートレシーバーを設定することによって、ユーザー定義プロジェクトのカスタムアラート通知を設定できます。

注記

ユーザー定義プロジェクトのアラートルーティングに関する次の制限事項を確認してください。

  • ユーザー定義のアラートルーティングのスコープは、リソースが定義されている namespace に指定されます。たとえば、namespace ns1 のルーティング設定は、同じ namespace の PrometheusRules リソースにのみ適用されます。
  • namespace がユーザー定義のモニタリングから除外される場合、namespace の AlertmanagerConfig リソースは、Alertmanager 設定の一部ではなくなります。

4.5.4.1. ユーザー定義プロジェクトのアラートルーティングの設定

alert-routing-edit クラスターロールが付与されている管理者以外のユーザーの場合は、ユーザー定義プロジェクトのアラートルーティングを作成または編集できます。

前提条件

  • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
  • クラスター管理者が、ユーザー定義プロジェクトのアラートルーティングを有効にしている。
  • アラートルーティングを作成する必要のあるプロジェクトの alert-routing-edit クラスターロールを持つユーザーとしてログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. アラートルーティングの YAML ファイルを作成します。この手順の例では、example-app-alert-routing.yaml という名前のファイルを使用します。
  2. AlertmanagerConfig YAML 定義をファイルに追加します。以下に例を示します。

    apiVersion: monitoring.coreos.com/v1beta1
    kind: AlertmanagerConfig
    metadata:
      name: example-routing
      namespace: ns1
    spec:
      route:
        receiver: default
        groupBy: [job]
      receivers:
      - name: default
        webhookConfigs:
        - url: https://example.org/post
    Copy to Clipboard Toggle word wrap
  3. ファイルを保存します。
  4. リソースをクラスターに適用します。

    $ oc apply -f example-app-alert-routing.yaml
    Copy to Clipboard Toggle word wrap

    この設定は Alertmanager Pod に自動的に適用されます。

ユーザー定義のアラートルーティング専用の Alertmanager の別のインスタンスを有効にしている場合は、openshift-user-workload-monitoring namespace の alertmanager-user-workload シークレットを編集して、インスタンスが通知を送信する場所と方法をカスタマイズできます。

注記

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • ユーザー定義のアラートルーティング用に、Alertmanager の別のインスタンスを有効にした。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 現在アクティブな Alertmanager 設定をファイル alertmanager.yaml に出力します。

    $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
    Copy to Clipboard Toggle word wrap
  2. alertmanager.yaml で設定を編集します。

    global:
      http_config:
        proxy_from_environment: true 
    1
    
    route:
      receiver: Default
      group_by:
      - name: Default
      routes:
      - matchers:
        - "service = prometheus-example-monitor" 
    2
    
        receiver: <receiver> 
    3
    
    receivers:
    - name: Default
    - name: <receiver>
      <receiver_configuration> 
    4
    Copy to Clipboard Toggle word wrap
    1
    HTTP クラスター全体のプロキシーを設定した場合は、proxy_from_environment パラメーターを true に設定して、すべてのアラートレシーバーのプロキシーを有効にします。
    2
    アラートに一致するラベルを指定します。この例では、service="prometheus-example-monitor" ラベルを持つすべてのアラートを対象とします。
    3
    アラートグループに使用するレシーバーの名前を指定します。
    4
    レシーバーの設定を指定します。
  3. 新規設定をファイルで適用します。

    $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-
    Copy to Clipboard Toggle word wrap

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

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

これを実現するには、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