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
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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
- <
;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
- 変更を適用するためにファイルを保存します。新しい設定の影響を受ける 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
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
data/config.yaml
の下に、alertmanagerMain
コンポーネントのenabled: false
を追加します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | alertmanagerMain: enabled: false
- 変更を適用するためにファイルを保存します。Alertmanager インスタンスは、この変更を適用すると自動的に無効にされます。
関連情報
- Alertmanager (Prometheus ドキュメント)
- 管理者としてのアラートの管理
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
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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>
次の 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.5.3. 追加ラベルの時系列 (time series) およびアラートへの割り当て
Prometheus の外部ラベル機能を使用して、Prometheus から送信されるすべての時系列とアラートにカスタムラベルを付けることができます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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
- 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。
3.5.4. アラート通知の設定
OpenShift Container Platform 4.16 では、アラート UI で実行するアラートを表示できます。アラートレシーバーを設定して、デフォルトのプラットフォームアラートに関する通知を送信するように Alertmanager を設定できます。
Alertmanager はデフォルトでは通知を送信しません。Web コンソールまたは alertmanager-main
シークレットを使用してアラートレシーバーを設定して、Alertmanager を設定して通知を受信することを強く推奨します。
関連情報
- 外部システムへの通知の送信
- PagerDuty (PagerDuty 公式サイト)
- Prometheus Integration Guide (PagerDuty official site)
- モニタリングコンポーネントのバージョンマトリックスのサポート
- ユーザー定義プロジェクトのアラートルーティングの有効化
3.5.4.1. デフォルトのプラットフォームアラートのアラートルーティングの設定
通知を送信するように Alertmanager を設定できます。Alertmanager からデフォルトのプラットフォームアラートに関する通知を送信する場所と方法をカスタマイズするには、openshift-monitoring
namespace の alertmanager-main
シークレットのデフォルト設定を編集します。
アップストリーム Alertmanager のサポートされているバージョンのすべての機能は、OpenShift Container Platform Alertmanager 設定 でもサポートされています。アップストリーム Alertmanager のサポート対象バージョンのすべての設定オプションを確認するには、Alertmanager 設定 (Prometheus ドキュメント)を参照してください。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。
手順
Alertmanager の YAML 設定ファイルを開きます。
CLI から Alertmanager 設定を開くには、以下を実行します。
現在アクティブな Alertmanager 設定を、
alertmanager-main
シークレットからalertmanager.yaml
ファイルに出力します。$ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
-
alertmanager.yaml
ファイルを開きます。
OpenShift Container Platform Web コンソールから Alertmanager 設定を開くには、以下を実行します。
-
Web コンソールの Administration
Cluster Settings Configuration Alertmanager YAML ページに移動します。
-
Web コンソールの Administration
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_match
、target_match_re
、source_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
レシーバーを介して送信されます。通常、この種のアラートは、個人または緊急対応チームに通知します。新規設定をファイルで適用します。
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
クラスターロールを持つユーザーとしてクラスターにアクセスできる。
手順
Administrator パースペクティブで、Administration
Cluster Settings Configuration Alertmanager に移動します。 注記または、通知ドロワーから同じページに移動することもできます。OpenShift Container Platform Web コンソールの右上にあるベルのアイコンを選択し、AlertmanagerReceiverNotConfigured アラートで Configure を選択します。
- ページの Receivers セクションで、Create Receiver をクリックします。
- Create Receiver フォームで、Receiver name を追加し、リストから Receiver type を選択します。
レシーバー設定を編集します。
PagerDuty receiver の場合:
- 統合のタイプを選択し、PagerDuty 統合キーを追加します。
- PagerDuty インストールの URL を追加します。
- クライアントおよびインシデントの詳細または重大度の指定を編集する場合は、Show advanced configuration をクリックします。
Webhook receiver の場合:
- HTTP POST リクエストを送信するエンドポイントを追加します。
- デフォルトオプションを編集して解決したアラートを receiver に送信する場合は、Show advanced configuration をクリックします。
メール receiver の場合:
- 通知を送信するメールアドレスを追加します。
- SMTP 設定の詳細を追加します。これには、通知の送信先のアドレス、メールの送信に使用する smarthost およびポート番号、SMTP サーバーのホスト名、および認証情報を含む詳細情報が含まれます。
- TLS が必要かどうかを選択します。
- 解決済みのアラートが receiver に送信されないようにデフォルトオプションを編集する、またはメール通知設定のボディーを編集する必要がある場合は、Show advanced configuration をクリックします。
Slack receiver の場合:
- Slack Webhook の URL を追加します。
- 通知を送信する Slack チャネルまたはユーザー名を追加します。
- デフォルトオプションを編集して解決済みのアラートが receiver に送信されないようにしたり、アイコンおよびユーザー設定を編集する必要がある場合は、Show advanced configuration を選択します。チャネル名とユーザー名を検索し、これらをリンクするかどうかについて選択することもできます。
デフォルトでは、すべてのセレクターに一致するラベルを持つ Firing アラートが receiver に送信されます。receiver に送信する前に、Firing アラートのラベル値を完全に一致させる場合は、次の手順を実行します。
- フォームの Routing Labels セクションに、ルーティングラベルの名前と値を追加します。
- Add label を選択して、さらにルーティングラベルを追加します。
- 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 の別のインスタンスを有効にしている場合、この設定は適用されません。