2.2. モニタリングのメンテナンスおよびサポート
モニタリングスタックのすべての設定オプションが公開されているわけではありません。唯一サポートされている OpenShift Dedicated モニタリング設定方法は、Cluster Monitoring Operator (CMO) の Config map リファレンス で説明されているオプションを使用して Cluster Monitoring Operator を設定する方法です。サポートされていない他の設定は使用しないでください。
設定のパラダイムが Prometheus リリース間で変更される可能性があり、このような変更には、設定のすべての可能性が制御されている場合のみ適切に対応できます。Cluster Monitoring Operator の Config map リファレンス で説明されている設定以外の設定を使用すると、デフォルトおよび設計により、CMO が自動的に差異を調整し、サポートされていない変更を元の定義済みの状態にリセットするため、変更は消えてしまいます。
2.2.1. モニタリングのサポートに関する考慮事項
メトリクス、記録ルールまたはアラートルールの後方互換性を保証されません。
以下の変更は明示的にサポートされていません。
-
追加の
ServiceMonitor、PodMonitor、およびPrometheusRuleオブジェクトをopenshift-*およびkube-*プロジェクトに作成します。 openshift-monitoringまたはopenshift-user-workload-monitoringプロジェクトにデプロイされるリソースまたはオブジェクト変更OpenShift Container Platform モニタリングスタックによって作成されるリソースは、後方互換性の保証がないために他のリソースで使用されることは意図されていません。注記Alertmanager 設定は、
openshift-monitoringnamespace のalertmanager-mainシークレットリソースとしてデプロイされます。ユーザー定義のアラートルーティング用に別の Alertmanager インスタンスを有効にしている場合、Alertmanager 設定もopenshift-user-workload-monitoringnamespace のalertmanager-user-workloadシークレットリソースとしてデプロイされます。Alertmanager のインスタンスの追加ルートを設定するには、そのシークレットをデコードし、変更し、エンコードする必要があります。この手順は、前述のステートメントに対してサポートされる例外です。- スタックのリソースの変更。OpenShift Container Platform モニタリングスタックは、そのリソースが常に期待される状態にあることを確認します。これらが変更される場合、スタックはこれらをリセットします。
-
ユーザー定義ワークロードの
openshift-*、およびkube-*プロジェクトへのデプロイ。これらのプロジェクトは Red Hat が提供するコンポーネント用に予約され、ユーザー定義のワークロードに使用することはできません。 -
Prometheus Operator での
Probeカスタムリソース定義 (CRD) による現象ベースのモニタリングの有効化。 -
openshift.io/cluster-monitoring: "true"ラベルを持つ namespace にモニタリングリソースを手動でデプロイ。 -
namespace に
openshift.io/cluster-monitoring: "true"ラベルを追加。このラベルは、コア OpenShift Container Platform コンポーネントと Red Hat 認定コンポーネントを含む namespace 用に予約されています。 - カスタム Prometheus インスタンスの OpenShift Container Platform へのインストール。カスタムインスタンスは、Prometheus Operator によって管理される Prometheus カスタムリソース (CR) です。
2.2.2. Operator のモニタリングに関するサポートポリシー
モニタリング Operator により、OpenShift Container Platform モニタリングリソースの設定およびテスト通りに機能することを確認できます。Operator の Cluster Version Operator (CVO) コントロールがオーバーライドされる場合、Operator は設定の変更に対応せず、クラスターオブジェクトの意図される状態を調整したり、更新を受信したりしません。
Operator の CVO コントロールのオーバーライドはデバッグ時に役立ちますが、これはサポートされず、クラスター管理者は個々のコンポーネントの設定およびアップグレードを完全に制御することを前提としています。
Cluster Version Operator のオーバーライド
spec.overrides パラメーターを CVO の設定に追加すると、管理者はコンポーネントに関する CVO の動作にオーバーライドのリストを追加できます。コンポーネントの spec.overrides[].unmanaged パラメーターを true に設定すると、クラスターのアップグレードがブロックされ、CVO のオーバーライドが設定された後に管理者にアラートが送信されます。
Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
CVO のオーバーライドを設定すると、クラスター全体がサポートされていない状態になり、モニタリングスタックをその意図された状態に調整されなくなります。これは Operator に組み込まれた信頼性の機能に影響を与え、更新が受信されなくなります。サポートを継続するには、オーバーライドを削除した後に、報告された問題を再現する必要があります。
2.2.3. モニタリングコンポーネントのバージョンマトリックスのサポート
以下のマトリックスには、OpenShift Container Platform 4.12 以降のリリースのモニタリングコンポーネントのバージョンに関する情報が含まれています。
| OpenShift Container Platform | Prometheus Operator | Prometheus | Prometheus アダプター | Alertmanager | kube-state-metrics エージェント | node-exporter エージェント | Thanos |
|---|---|---|---|---|---|---|---|
| 4.13 | 0.63.0 | 2.42.0 | 0.10.0 | 0.25.0 | 2.8.1 | 1.5.0 | 0.30.2 |
| 4.12 | 0.60.1 | 2.39.1 | 0.10.0 | 0.24.0 | 2.6.0 | 1.4.0 | 0.28.1 |
| 4.11 | 4. | 2.36.2 | 0.9.1 | 0.24.0 | 2.5.0 | 1.3.1 | 0.26.0 |
openshift-state-metrics エージェントと Telemeter Client は、OpenShift 固有のコンポーネントです。したがって、それらのバージョンは OpenShift Container Platform のバージョンに対応します。
