1.3. モニタリングスタックについて - キーの概念

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

• Alertmanager
• kube-state-metrics
• monitoring-plugin
• node-exporter
• openshift-state-metrics
• Prometheus
• Prometheus アダプター
• Prometheus Operator とそのアドミッション Webhook サービス
• Telemeter クライアント
• Thanos Querier

• Alertmanager
• Prometheus
• Thanos Ruler

• クラスター管理者がアラート、テレメトリー、およびコンソールメトリクスのみを必要とし、他のメトリクスを使用可能にする必要がない場合。
• クラスターのサイズが大きくなり、収集されるデフォルトのメトリクスデータのサイズが大きくなった場合、CPU とメモリーリソースを大幅に増やす必要があります。

• full: Prometheus は、すべてのプラットフォームコンポーネントによって公開されるメトリクスデータを収集します。この設定がデフォルトです。
• minimal: Prometheus は、プラットフォームアラート、記録ルール、テレメトリー、およびコンソールダッシュボードに必要なメトリクスデータのみを収集します。

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

• サイズベースのリテンションポリシーは、/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 時間です。デフォルトでは、保持サイズは設定されていません。

• ユーザー定義プロジェクトでターゲットスクレイピングごとの許容可能なサンプル数を制限する
• 収集されたラベルの数、ラベル名の長さ、およびラベル値の長さを制限します。
• 収集サンプルのしきい値に達するか、ターゲットを収集できない場合に実行されるアラートを作成します。

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

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

• CPU usage (CPU の使用率)
• メモリー使用量
• 帯域幅に関する情報
• パケットレート情報

• しきい値を調整するか、ラベルを追加および変更して、既存のプラットフォームのアラートルールの設定を変更します。たとえば、アラートの severity ラベルを warning から critical に変更すると、アラートのフラグが付いた問題のルーティングおよびトリアージに役立ちます。
• openshift-monitoring namespace のコアプラットフォームメトリクスに基づいてクエリー式を作成することにより、新しいカスタムアラートルールを定義して追加します。

コアプラットフォームのアラートルールの考慮事項

• 新規のアラートルールはデフォルトの OpenShift Container Platform モニタリングメトリクスをベースとする必要があります。
• openshift-monitoring namespace に AlertingRule オブジェクトと AlertRelabelConfig オブジェクトを作成する必要があります。
• アラートルールのみを追加および変更できます。新しい記録ルールを作成したり、既存の記録ルールを変更したりすることはできません。
• AlertRelabelConfig オブジェクトを使用して既存のプラットフォームのアラートルールを変更する場合、変更は Prometheus アラート API に反映されません。そのため、削除されたアラートは Alertmanager に転送されていなくても OpenShift Container Platform Web コンソールに表示されます。さらに、severity ラベルの変更など、アラートへの変更は Web コンソールには表示されません。

• 新しいルールの数を最小限に抑えます。特定の要件に不可欠なルールのみを作成します。ルールの数を最小限に抑えることで、より管理しやすく、焦点を絞ったアラートシステムをモニタリング環境に作成できます。
• 原因ではなく症状に焦点を当てます。根本的な原因ではなく症状をユーザーに通知するルールを作成します。このアプローチにより、関連する症状がユーザーに即座に通知され、アラートがトリガーされた後に根本原因を調査できるようになります。この戦略により、作成する必要があるルールの総数も大幅に削減されます。
• 変更を実装する前に、ニーズを計画し、評価します。まず、どの症状が重要であり、これらの症状が発生した場合にユーザーにどのようなアクションをとってもらいたいかを決定します。次に、既存のルールを評価し、症状ごとにまったく新しいルールを作成するのではなく、ニーズを満たすためにルールを変更できるかどうかを判断します。既存のルールを変更し、新しいルールを慎重に作成することで、アラートシステムを合理化できます。
• クリアなアラートメッセージングを提供します。アラートメッセージを作成するときは、症状、考えられる原因、推奨されるアクションを説明します。明確で簡潔な説明と、トラブルシューティング手順または詳細情報へのリンクを含めます。そうすることで、ユーザーは状況を迅速に評価し、適切に対応することができます。
• 重大度レベルを含めます。ルールに重大度レベルを割り当てて、症状が発生してアラートがトリガーされたときにユーザーがどのように反応する必要があるかを示します。たとえば、アラートを Critical として分類すると、個人または重要な対応チームが直ちに対応する必要があることを示します。重大度レベルを定義することで、ユーザーがアラートへの対応方法を理解し、最も緊急性の高い問題に迅速な対応を確実に受けられるようになります。

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

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

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

  重要

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

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

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

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