10.7. 外部システムへの通知の送信
OpenShift Container Platform 4.14 では、実行するアラートをアラート UI で表示できます。アラートは、デフォルトでは通知システムに送信されるように設定されません。以下のレシーバータイプにアラートを送信するように OpenShift Container Platform を設定できます。
- PagerDuty
- Webhook
- Slack
レシーバーへのアラートのルートを指定することにより、障害が発生する際に適切なチームに通知をタイムリーに送信できます。たとえば、重大なアラートには早急な対応が必要となり、通常は個人または緊急対策チーム (Critical Response Team) に送信先が設定されます。重大ではない警告通知を提供するアラートは、早急な対応を要さないレビュー用にチケットシステムにルート指定される可能性があります。
Watchdog アラートの使用によるアラートが機能することの確認
OpenShift Container Platform モニタリングには、継続的に実行される Watchdog アラートが含まれます。Alertmanager は、Watchdog のアラート通知を設定された通知プロバイダーに繰り返し送信します。通常、プロバイダーは Watchdog アラートの受信を停止する際に管理者に通知するように設定されます。このメカニズムは、Alertmanager と通知プロバイダー間の通信に関連する問題を迅速に特定するのに役立ちます。
10.7.1. アラートレシーバーの設定
アラートレシーバーを設定して、クラスターに関する重要な問題について把握できるようにします。
前提条件
-
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 をクリックしてレシーバーを作成します。
10.7.2. デフォルトのプラットフォームアラートとユーザー定義アラートに異なるアラートレシーバーを設定する
デフォルトのプラットフォームアラートとユーザー定義アラートに異なるアラートレシーバーを設定して、次の結果を確実に得ることができます。
- すべてのデフォルトのプラットフォームアラートは、これらのアラートを担当するチームが所有する受信機に送信されます。
- すべてのユーザー定義アラートは別の受信者に送信されるため、チームはプラットフォームアラートにのみ集中できます。
これを実現するには、Cluster Monitoring Operator によってすべてのプラットフォームアラートに追加される openshift_io_alert_source="platform"
ラベルを使用します。
-
デフォルトのプラットフォームアラートを一致させるには、
openshift_io_alert_source="platform"
マッチャーを使用します。 -
ユーザー定義のアラートを一致させるには、
openshift_io_alert_source!="platform"
または'openshift_io_alert_source=""'
マッチャーを使用します。
ユーザー定義アラート専用の Alertmanager の別のインスタンスを有効にしている場合、この設定は適用されません。
10.7.3. ユーザー定義プロジェクトのアラートルーティングの作成
alert-routing-edit
クラスターロールが付与されている管理者以外のユーザーの場合は、ユーザー定義プロジェクトのアラートルーティングを作成または編集できます。
前提条件
- クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
- クラスター管理者が、ユーザー定義プロジェクトのアラートルーティングを有効にしている。
-
アラートルーティングを作成する必要のあるプロジェクトの
alert-routing-edit
クラスターロールを持つユーザーとしてログインしている。 -
OpenShift CLI (
oc
) がインストールされている。
手順
-
アラートルーティングの YAML ファイルを作成します。この手順の例では、
example-app-alert-routing.yaml
という名前のファイルを使用します。 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
注記ユーザー定義のアラートルールの場合、ユーザー定義のルーティングはリソースが定義される namespace に対してスコープ指定されます。たとえば、namespace
ns1
のAlertmanagerConfig
オブジェクトで定義されるルーティング設定は、同じ namespace のPrometheusRules
リソースにのみ適用されます。- ファイルを保存します。
リソースをクラスターに適用します。
$ oc apply -f example-app-alert-routing.yaml
この設定は Alertmanager Pod に自動的に適用されます。