10.7. 外部システムへの通知の送信


OpenShift Container Platform 4.11 では、実行するアラートをアラート UI で表示できます。アラートは、デフォルトでは通知システムに送信されるように設定されません。以下のレシーバータイプにアラートを送信するように OpenShift Container Platform を設定できます。

  • PagerDuty
  • Webhook
  • Email
  • Slack

レシーバーへのアラートのルートを指定することにより、障害が発生する際に適切なチームに通知をタイムリーに送信できます。たとえば、重大なアラートには早急な対応が必要となり、通常は個人または緊急対策チーム (Critical Response Team) に送信先が設定されます。重大ではない警告通知を提供するアラートは、早急な対応を要さないレビュー用にチケットシステムにルート指定される可能性があります。

Watchdog アラートの使用によるアラートが機能することの確認

OpenShift Container Platform モニタリングには、継続的に実行される Watchdog アラートが含まれます。Alertmanager は、Watchdog のアラート通知を設定された通知プロバイダーに繰り返し送信します。通常、プロバイダーは Watchdog アラートの受信を停止する際に管理者に通知するように設定されます。このメカニズムは、Alertmanager と通知プロバイダー間の通信に関連する問題を迅速に特定するのに役立ちます。

10.7.1. アラートレシーバーの設定

アラートレシーバーを設定して、クラスターについての重要な問題について把握できるようにします。

前提条件

  • 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. デフォルトでは、実行されるすべてのセレクターに一致するラベルを持つアラートは receiver に送信されます。実行されるアラートのラベルの値を、それらが receiver に送信される前の状態に完全に一致させる必要がある場合は、以下を実行します。

    1. ルーティングラベル名と値をフォームの Routing Labels セクションに追加します。
    2. 正規表現を使用する場合は Regular Expression を選択します。
    3. Add Label を選択して、さらにルーティングラベルを追加します。
  6. Create を選択して receiver を作成します。

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

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
    注記

    ユーザー定義のアラートルールの場合、ユーザー定義のルーティングはリソースが定義される namespace に対してスコープ指定されます。たとえば、namespace ns1AlertmanagerConfig オブジェクトで定義されるルーティング設定は、同じ namespace の PrometheusRules リソースにのみ適用されます。

  3. ファイルを保存します。
  4. リソースをクラスターに適用します。

    $ oc apply -f example-app-alert-routing.yaml

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.