Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

1.3. モニタリングスタックについて - 主な概念

OpenShift Dedicated のモニタリングの概念と用語を解説します。クラスターのパフォーマンスとスケールを向上させる方法、データを保存および記録する方法、メトリクスとアラートを管理する方法などを説明します。

1.3.1. パフォーマンスとスケーラビリティーについて
リンクのコピー

クラスターのパフォーマンスとスケールを最適化できます。次のアいずれかのアクションを実行して、モニタリングスタックを設定できます。

  • モニタリングコンポーネントの配置と分散を制御します。

    • ノードセレクターを使用して、コンポーネントを特定のノードに移動します。
    • taint されたノードにコンポーネントを移動できるように toleration を割り当てます。
  • Pod トポロジー分散制約を使用します。
  • CPU とメモリーのリソースを管理します。

1.3.1.1. ノードセレクターを使用したモニタリングコンポーネントの移動
リンクのコピー

ラベル付きノードで nodeSelector 制約を使用すると、任意のモニタリングスタックコンポーネントを特定ノードに移動できます。これにより、クラスター全体のモニタリングコンポーネントの配置と分散を制御できます。

モニタリングコンポーネントの配置と分散を制御して、システムリソースの使用を最適化し、パフォーマンスを高め、特定の要件やポリシーに基づいてワークロードを分離できます。

ノードセレクターと他の制約の連携

ノードセレクターの制約を使用してモニタリングコンポーネントを移動する場合、クラスターに Pod のスケジューリングを制御するための他の制約があることに注意してください。

  • Pod の配置を制御するために、トポロジー分散制約が設定されている可能性があります。
  • Prometheus、Alertmanager、およびその他のモニタリングコンポーネントでは、コンポーネントの複数の Pod が必ず異なるノードに分散されて高可用性が常に確保されるように、ハードな非アフィニティールールが設定されています。

ノード上で Pod をスケジュールする場合、Pod スケジューラーは既存の制約をすべて満たすように Pod の配置を決定します。つまり、Pod スケジューラーがどの Pod をどのノードに配置するかを決定する際に、すべての制約が組み合わされます。

そのため、ノードセレクター制約を設定しても既存の制約をすべて満たすことができない場合、Pod スケジューラーはすべての制約をマッチさせることができず、ノードへの Pod 配置をスケジュールしません。

モニタリングコンポーネントの耐障害性と高可用性を維持するには、コンポーネントを移動するノードセレクター制約を設定する際に、十分な数のノードが利用可能で、すべての制約がマッチすることを確認してください。

1.3.1.2. モニタリングのための Pod トポロジー分散制約について
リンクのコピー

OpenShift Dedicated Pod が複数のアベイラビリティーゾーンにデプロイされている場合、Pod トポロジーの分散制約を使用して、モニタリング Pod がネットワークトポロジー全体にどのように分散されるかを制御できます。

Pod トポロジーの分散制約は、ノードがリージョンやリージョン内のゾーンなど、さまざまなインフラストラクチャーレベルに分散している階層トポロジー内で Pod のスケジューリングを制御するのに適しています。さらに、さまざまなゾーンで Pod をスケジュールできるため、特定のシナリオでネットワーク遅延を改善できます。

Cluster Monitoring Operator によってデプロイされたすべての Pod に対して Pod トポロジーの分散制約を設定し、ゾーン全体のノードに Pod レプリカをスケジュールする方法を制御できます。これにより、ワークロードが異なるデータセンターまたは階層型インフラストラクチャーゾーンのノードに分散されるため、Pod の可用性が高まり、より効率的に実行されるようになります。

1.3.1.3. モニタリングコンポーネントの制限と要求の指定について
リンクのコピー

ユーザー定義プロジェクトを監視する以下のコンポーネントのリソース制限および要求を設定できます。

  • Alertmanager
  • Prometheus
  • Thanos Ruler

リソース制限を定義することで、コンテナーのリソース使用量を制限し、コンテナーが CPU およびメモリーリソースの指定された最大値を超えないようにします。

リソース要求を定義することで、要求されたリソースに一致するのに十分な CPU およびメモリーリソースがあるノードでのみコンテナーをスケジュールできることを指定します。

1.3.2. データの保存と記録について
リンクのコピー

データを保存および記録することで、データを保護し、トラブルシューティングに役立てることができます。次のアいずれかのアクションを実行して、モニタリングスタックを設定できます。

  • 永続ストレージを設定します。

    • メトリクスとアラートデータを永続ボリューム (PV) に保存することで、データ損失から保護します。その結果、Pod が再起動または再作成されても存続できます。
    • Alertmanager Pod が再起動したときに、重複した通知を受信したり、アラートのサイレンスが失われたりするのを回避します。
  • Prometheus および Thanos Ruler メトリクスデータの保持時間とサイズを変更します。

  • クラスターの問題のトラブルシューティングに役立つロギングを設定します。

    • モニタリングのログレベルを設定します。
    • Prometheus および Thanos Querier のクエリーロギングを有効にします。

1.3.2.1. Prometheus メトリクスの保持時間とサイズ
リンクのコピー

デフォルトで、Prometheus がメトリクスデータを保持する期間のデフォルトは以下のとおりです。

  • コアプラットフォームのモニタリング: 15 日間
  • ユーザー定義プロジェクトの監視: 24 時間

Prometheus インスタンスの保持時間を変更して、データが削除されるまでの時間を変更できます。保持されるメトリクスデータが使用するディスク容量の最大量を設定することもできます。データがこのサイズ制限に達すると、使用するディスク領域が上限を下回るまで、Prometheus は最も古いデータを削除します。

これらのデータ保持設定は、以下の挙動に注意してください。

  • サイズベースのリテンションポリシーは、/prometheus ディレクトリー内のすべてのデータブロックディレクトリーに適用され、永続ブロック、ライトアヘッドログ (WAL) データ、および m-mapped チャンクも含まれます。
  • wal と /head_chunks ディレクトリーのデータは保持サイズ制限にカウントされますが、Prometheus はサイズまたは時間ベースの保持ポリシーに基づいてこれらのディレクトリーからデータをパージすることはありません。したがって、/wal ディレクトリーおよび /head_chunks ディレクトリーに設定された最大サイズよりも低い保持サイズ制限を設定すると、/prometheus データディレクトリーにデータブロックを保持しないようにシステムを設定している。
  • サイズベースの保持ポリシーは、Prometheus が新規データブロックをカットする場合にのみ適用されます。これは、WAL に少なくとも 3 時間のデータが含まれてから 2 時間ごとに実行されます。
  • retention または retentionSize の値を明示的に定義しない場合、保持期間のデフォルトは、コアプラットフォームの監視は 15 日間、ユーザー定義プロジェクトの監視は 24 時間です。保持サイズは設定されていません。
  • retention および retentionSize の両方に値を定義すると、両方の値が適用されます。データブロックが定義された保持時間または定義されたサイズ制限を超える場合、Prometheus はこれらのデータブロックをパージします。
  • retentionSize の値を定義して retention を定義しない場合、retentionSize 値のみが適用されます。
  • retentionSize の値を定義しておらず、p retention の値のみを定義する場合、retention 値のみが適用されます。
  • retentionSize または retention の値を 0 に設定すると、デフォルト設定が適用されます。保持期間のデフォルト設定は、コアプラットフォームの監視の場合は 15 日間、ユーザー定義プロジェクトの監視の場合は 24 時間です。デフォルトでは、保持サイズは設定されていません。
注記

データコンパクションは 2 時間ごとに実行されます。そのため、コンパクションが実行される前に永続ボリューム (PV) がいっぱいになり、retentionSize 制限を超える可能性があります。その場合、PV 上のスペースが retentionSize 制限を下回るまで、KubePersistentVolumeFillingUp アラートが発生します。

1.3.3. メトリクスについて
リンクのコピー

OpenShift Dedicated では、クラスターコンポーネントはサービスエンドポイントで公開されるメトリクスを収集することによりモニターされます。ユーザー定義プロジェクトのメトリクスのコレクションを設定することもできます。メトリクスを使用すると、クラスターコンポーネントおよび独自のワークロードの実行方法をモニターできます。

Prometheus クライアントライブラリーをアプリケーションレベルで使用することで、独自のワークロードに指定するメトリクスを定義できます。

OpenShift Dedicated では、メトリクスは /metrics の正規名の下に HTTP サービスエンドポイント経由で公開されます。curl クエリーを http://<endpoint>/metrics に対して実行して、サービスの利用可能なすべてのメトリクスをリスト表示できます。たとえば、prometheus-example-app サンプルアプリケーションへのルートを公開し、以下のコマンドを実行して利用可能なすべてのメトリクスを表示できます。 

$ curl http://<example_app_endpoint>/metrics
Copy to Clipboard Toggle word wrap

出力例

# HELP http_requests_total Count of all HTTP requests
# TYPE http_requests_total counter
http_requests_total{code="200",method="get"} 4
http_requests_total{code="404",method="get"} 2
# HELP version Version information about this binary
# TYPE version gauge
version{version="v0.1.0"} 1
Copy to Clipboard Toggle word wrap

1.3.3.1. ユーザー定義プロジェクトでバインドされていないメトリクス属性の影響の制御
リンクのコピー

開発者は、キーと値のペアの形式でメトリクスの属性を定義するためにラベルを作成できます。使用できる可能性のあるキーと値のペアの数は、属性に使用できる可能性のある値の数に対応します。数が無制限の値を持つ属性は、バインドされていない属性と呼ばれます。たとえば、customer_id 属性は、使用できる値が無限にあるため、バインドされていない属性になります。

割り当てられるキーと値のペアにはすべて、一意の時系列があります。ラベルに多数のバインドされていない値を使用すると、作成される時系列の数が指数関数的に増加する可能性があります。これは Prometheus のパフォーマンスに影響する可能性があり、多くのディスク領域を消費する可能性があります。

dedicated-admin は、以下の手段を使用して、ユーザー定義プロジェクトでのバインドされていないメトリクス属性の影響を制御できます。

  • ユーザー定義プロジェクトでターゲットスクレイピングごとの許容可能なサンプル数を制限する
  • スクレイピングするラベルの数、ラベル名の長さ、ラベル値の長さを制限する
  • 連続するスクレイピング間および Prometheus ルール評価間の間隔を設定する
  • スクレイピングサンプルのしきい値に達した場合、またはターゲットをスクレイピングできない場合に発するアラートを作成する
注記

スクレイピングサンプル数を制限すると、ラベルにバインドされない属性を多数追加することによって発生する問題を防ぐことができます。さらに開発者は、メトリクスに定義するバインドされていない属性の数を制限することにより、根本的な原因を防ぐことができます。使用可能な値の制限されたセットにバインドされる属性を使用すると、可能なキーと値のペアの組み合わせの数が減ります。

1.3.3.2. クラスター ID ラベルのメトリクスへの追加
リンクのコピー

複数の OpenShift Dedicated クラスターを管理し、リモート書き込み機能を使用してメトリクスデータをこれらのクラスターから外部ストレージの場所に送信する場合、クラスター ID ラベルを追加して、異なるクラスターから送られるメトリクスデータを特定できます。次に、これらのラベルを取得し、メトリクスのソースクラスターを特定し、そのデータを他のクラスターによって送信される同様のメトリクスデータと区別することができます。

これにより、複数の顧客に対して多数のクラスターを管理し、メトリクスデータを単一の集中ストレージシステムに送信する場合、クラスター ID ラベルを使用して特定のクラスターまたはお客様のメトリクスをクエリーできます。

クラスター ID ラベルの作成および使用には、以下の 3 つの一般的な手順が必要です。

  • リモート書き込みストレージの書き込みラベルの設定。
  • クラスター ID ラベルをメトリクスに追加します。
  • これらのラベルを取得し、メトリクスのソースクラスターまたはカスタマーを特定します。

1.3.4. モニタリングダッシュボードについて
リンクのコピー

OpenShift Dedicated は、クラスターコンポーネントとユーザー定義のワークロードの状態を理解するのに役立つ一連の監視ダッシュボードを提供します。

重要

OpenShift Dedicated 4.19 以降、Web コンソールのパースペクティブが統合されました。Developer パースペクティブは、デフォルトでは有効になっていません。

すべてのユーザーが、OpenShift Dedicated Web コンソールのすべての機能を操作できます。ただし、クラスター所有者でない場合は、特定の機能に対する権限をクラスター所有者に要求する必要がある場合があります。

引き続き Developer パースペクティブを有効にできます。Web コンソールの Getting Started ペインでは、コンソールツアーの実行、クラスター設定に関する情報の検索、Developer パースペクティブを有効にするためのクイックスタートの表示、リンク先を表示して新機能の確認などを行えます。

管理者は、以下の項目を含め、OpenShift Dedicated のコアコンポーネントのダッシュボードにアクセスできます。

  • API パフォーマンス
  • etcd
  • Kubernetes コンピュートリソース
  • Kubernetes ネットワークリソース
  • Prometheus
  • クラスターおよびノードのパフォーマンスに関連する USE メソッドダッシュボード
  • ノードのパフォーマンスメトリクス

1.3.5. アラートの管理
リンクのコピー

OpenShift Dedicated では、アラート UI を使用してアラート、サイレンス、およびアラートルールを管理できます。

  • アラートルール。アラートルールには、クラスター内の特定の状態を示す一連の条件が含まれます。アラートは、これらの条件が true の場合にトリガーされます。アラートルールには、アラートのルーティング方法を定義する重大度を割り当てることができます。
  • アラート。アラートは、アラートルールで定義された条件が true の場合に発生します。アラートは、OpenShift Dedicated クラスター内で一連の状況が明らかであることを通知します。
  • サイレンス。サイレンスをアラートに適用し、アラートの条件が true の場合に通知が送信されることを防ぐことができます。最初の通知の後、問題の解決に取り組んでいる間は、アラートをミュートすることができます。
注記

アラート UI で利用可能なアラート、サイレンス、およびアラートルールは、アクセス可能なプロジェクトに関連付けられます。たとえば、cluster-admin ロールを持つユーザーとしてログインしている場合は、すべてのアラート、サイレント、およびアラートルールにアクセスできます。

1.3.5.1. サイレンスの管理
リンクのコピー

OpenShift Dedicated Web コンソールでアラートのサイレンスを作成できます。サイレンスを作成すると、アラートが発生したときにアラートに関する通知を受信しなくなります。

サイレントの作成は、最初のアラート通知を受信し、アラートの発生の原因となっている根本的な問題を解決するまでの間、さらなる通知を受け取りたくないシナリオで役立ちます。

サイレンスの作成時に、サイレンスをすぐにアクティブにするか、後にアクティブにするかを指定する必要があります。また、サイレンスの有効期限を設定する必要もあります。

サイレンスを作成した後、それらを表示、編集、および期限切れにすることができます。

注記

サイレンスを作成すると、それらは Alertmanager Pod 全体に複製されます。ただし、Alertmanager の永続ストレージを設定しないと、サイレンスが失われる可能性があります。これは、たとえば、すべての Alertmanager Pod が同時に再起動した場合に発生する可能性があります。

1.3.5.2. ユーザー定義プロジェクトのアラートルールの作成
リンクのコピー

OpenShift Dedicated では、ユーザー定義のプロジェクトのアラートルールを作成できます。これらのアラートルールは、選択したメトリクスの値に基づいてアラートをトリガーします。

ユーザー定義プロジェクトのアラートルールを作成する場合は、新しいルールを定義する際に次の主要な動作と重要な制限事項を考慮してください。

  • ユーザー定義のアラートルールには、コアプラットフォームのモニタリングからのデフォルトメトリクスに加えて、独自のプロジェクトが公開したメトリクスを含めることができます。別のユーザー定義プロジェクトのメトリクスを含めることはできません。

    たとえば、ns1 ユーザー定義プロジェクトのアラートルールでは、CPU やメモリーメトリクスなどのコアプラットフォームメトリクスに加えて、ns1 プロジェクトが公開したメトリクスも使用できます。ただし、ルールには、別の ns2 ユーザー定義プロジェクトからのメトリクスを含めることはできません。

  • デフォルトでは、アラートルールを作成すると、別のプロジェクトに同じ名前のルールが存在する場合でも、namespace ラベルがそのアラートルールに適用されます。元のプロジェクトにバインドされないアラートルールを作成するには、「ユーザー定義プロジェクトのクロスプロジェクトアラートルールの作成」を参照してください。

  • レイテンシーを短縮し、コアプラットフォームモニタリングコンポーネントの負荷を最小限に抑えるために、ルールに openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus ラベルを追加できます。このラベルは、openshift-user-workload-monitoring プロジェクトにデプロイされた Prometheus インスタンスのみにアラートルールの評価を強制し、Thanos Ruler インスタンスによる評価を防ぎます。

    重要

    アラートルールにこのラベルが付いている場合、そのアラートルールはユーザー定義プロジェクトが公開するメトリクスのみを使用できます。デフォルトのプラットフォームメトリクスに基づいて作成したアラートルールでは、アラートがトリガーされない場合があります。

1.3.5.3. ユーザー定義プロジェクトのアラートルールの管理
リンクのコピー

OpenShift Dedicated では、ユーザー定義のプロジェクトでアラートルールを表示、編集、削除できます。

重要

ユーザー定義プロジェクトのアラートルールの管理は、OpenShift Dedicated バージョン 4.11 以降でのみ利用できます。

アラートルールに関する考慮事項

  • デフォルトのアラートルールは OpenShift Dedicated クラスター専用に使用されます。
  • 一部のアラートルールには、複数の意図的に同じ名前が含まれます。それらは同じイベントに関するアラートを送信しますが、それぞれ異なるしきい値、重大度およびそれらの両方が設定されます。
  • 抑制 (inhibition) ルールは、高い重大度のアラートが実行される際に実行される低い重大度のアラートの通知を防ぎます。

1.3.5.4. ユーザー定義プロジェクトのアラートの最適化
リンクのコピー

アラートルールの作成時に以下の推奨事項を考慮して、独自のプロジェクトのアラートを最適化できます。

  • プロジェクト用に作成するアラートルールの数を最小限にします。影響を与える状況を通知するアラートルールを作成します。影響を与えない条件に対して多数のアラートを生成すると、関連するアラートに気づくのがさらに困難になります。
  • 原因ではなく現象に関するアラートルールを作成します。根本的な原因に関係なく、状態を通知するアラートルールを作成します。次に、原因を調査できます。アラートルールのそれぞれが特定の原因にのみ関連する場合に、さらに多くのアラートルールが必要になります。そのため、いくつかの原因は見落される可能性があります。
  • アラートルールを作成する前にプランニングを行います。重要な現象と、その発生時に実行するアクションを決定します。次に、現象別にアラートルールをビルドします。
  • クリアなアラートメッセージングを提供します。アラートメッセージに現象および推奨されるアクションを記載します。
  • アラートルールに重大度レベルを含めます。アラートの重大度は、報告される現象が生じた場合に取るべき対応によって異なります。たとえば、現象に個人または緊急対策チーム (Critical Response Team) による早急な対応が必要な場合は、重大アラートをトリガーする必要があります。

1.3.5.5. アラート、サイレンスおよびアラートルールの検索およびフィルター
リンクのコピー

アラート UI に表示されるアラート、サイレンス、およびアラートルールをフィルターできます。このセクションでは、利用可能な各フィルターオプションを説明します。

1.3.5.5.1. アラートフィルターについて
リンクのコピー

アラート UI の Alerts ページには、デフォルトの OpenShift Dedicated プロジェクトおよびユーザー定義プロジェクトに関連するアラートの詳細が表示されます。このページには、各アラートの重大度、状態、およびソースの概要が含まれます。アラートが現在の状態に切り替わった時間も表示されます。

アラートの状態、重大度、およびソースでフィルターできます。デフォルトでは、Firing の Platform アラートのみが表示されます。以下では、それぞれのアラートフィルターオプションを説明します。

  • State フィルター:

    • Firing。アラート条件が true で、オプションの for の期間を経過しているためにアラートが実行されます。条件が true である間、アラートの発生が続きます。
    • Pending。アラートはアクティブですが、アラート実行前のアラートルールに指定される期間待機します。
    • Silenced。指定の期間、アラートがサイレントになります。定義するラベルセレクターのセットに基づいてアラートを一時的にミュートします。リストされたすべての値または正規表現に一致するアラートの土は送信されません。

  • Severity フィルター:

    • Critical。アラートをトリガーした状態は重大な影響を与える可能性があります。このアラートには、実行時に早急な対応が必要となり、通常は個人または緊急対策チーム (Critical Response Team) に送信先が設定されます。
    • Warning。アラートは、問題の発生を防ぐために注意が必要になる可能性のある問題に関する警告通知を提供します。通常、警告は早急な対応を要さないレビュー用にチケットシステムにルート指定されます。
    • Info。アラートは情報提供のみを目的として提供されます。
    • None。アラートには重大度が定義されていません。
    • また、ユーザー定義プロジェクトに関連するアラートの重大度の定義を作成することもできます。

  • Source フィルター:

    • Platform。プラットフォームレベルのアラートは、デフォルトの OpenShift Dedicated プロジェクトにのみ該当します。これらのプロジェクトは OpenShift Dedicated のコア機能を提供します。
    • User。ユーザーアラートはユーザー定義のプロジェクトに関連します。これらのアラートはユーザーによって作成され、カスタマイズ可能です。ユーザー定義のワークロードモニタリングはインストール後に有効にでき、独自のワークロードへの可観測性を提供します。
1.3.5.5.2. サイレンスフィルターについて
リンクのコピー

アラート UI の Silences ページには、デフォルトの OpenShift Dedicated プロジェクトおよびユーザー定義プロジェクトのアラートに適用されるサイレンスの詳細が表示されます。このページには、それぞれのサイレンスの状態の概要とサイレンスが終了する時間の概要が含まれます。

サイレンス状態でフィルターを実行できます。デフォルトでは、Active および Pending のサイレンスのみが表示されます。以下は、それぞれのサイレンス状態のフィルターオプションを説明しています。

  • State フィルター:

    • Active。サイレンスはアクティブで、アラートはサイレンスが期限切れになるまでミュートされます。
    • Pending。サイレンスがスケジュールされており、アクティブな状態ではありません。
    • Expiredアラートの条件が true の場合は、サイレンスが期限切れになり、通知が送信されます。
1.3.5.5.3. アラートルールフィルターについて
リンクのコピー

アラート UI の Alerting rules ページには、デフォルトの OpenShift Dedicated プロジェクトおよびユーザー定義プロジェクトに関連するアラートルールの詳細が表示されます。このページには、各アラートルールの状態、重大度およびソースの概要が含まれます。

アラート状態、重大度、およびソースを使用してアラートルールをフィルターできます。デフォルトでは、プラットフォーム のアラートルールのみが表示されます。以下では、それぞれのアラートルールのフィルターオプションを説明します。

  • Alert state フィルター:

    • Firing。アラート条件が true で、オプションの for の期間を経過しているためにアラートが実行されます。条件が true である間、アラートの発生が続きます。
    • Pending。アラートはアクティブですが、アラート実行前のアラートルールに指定される期間待機します。
    • Silenced。指定の期間、アラートがサイレントになります。定義するラベルセレクターのセットに基づいてアラートを一時的にミュートします。リストされたすべての値または正規表現に一致するアラートの土は送信されません。
    • Not Firingアラートは実行されません。

  • Severity フィルター:

    • Critical。アラートルールで定義される状態は重大な影響を与える可能性があります。true の場合は、この状態に早急な対応が必要です。通常、ルールに関連するアラートは個別または緊急対策チーム (Critical Response Team) に送信先が設定されます。
    • Warning。アラートルールで定義される状態は、問題の発生を防ぐために注意を要する場合があります。通常、ルールに関連するアラートは早急な対応を要さないレビュー用にチケットシステムにルート指定されます。
    • Info。アラートルールは情報アラートのみを提供します。
    • None。アラートルールには重大度が定義されていません。
    • ユーザー定義プロジェクトに関連するアラートルールのカスタム重大度定義を作成することもできます。

  • Source フィルター:

    • Platform。プラットフォームレベルのアラートルールは、デフォルトの OpenShift Dedicated プロジェクトにのみ該当します。これらのプロジェクトは OpenShift Dedicated のコア機能を提供します。
    • User。ユーザー定義のワークロードアラートルールは、ユーザー定義プロジェクトに関連します。これらのアラートルールはユーザーによって作成され、カスタマイズ可能です。ユーザー定義のワークロードモニタリングはインストール後に有効にでき、独自のワークロードへの可観測性を提供します。

1.3.6. ユーザー定義プロジェクトのアラートルーティングについて
リンクのコピー

dedicated-admin として、ユーザー定義プロジェクトのアラートルーティングを有効にすることができます。この機能を使用すると、alert-routing-edit クラスターロールを持つユーザーが、ユーザー定義プロジェクトのアラート通知ルーティングとレシーバーを設定できるようになります。これらの通知は、ユーザー定義の監視専用の Alertmanager インスタンスによってルーティングされます。

次に、ユーザーはユーザー定義プロジェクトの AlertmanagerConfig オブジェクトを作成または編集して、ユーザー定義のアラートルーティングを作成し、設定できます。

ユーザー定義プロジェクトのアラートルーティングをユーザーが定義すると、ユーザー定義のアラート通知が openshift-user-workload-monitoring namespace の alertmanager-user-workload Pod にルーティングされます。

注記

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

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

1.3.7. 外部システムへの通知の送信
リンクのコピー

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

  • PagerDuty
  • Webhook
  • Email
  • Slack
  • Microsoft Teams

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

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

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat