Red Hat OpenShift Cluster Observability Operator について
Cluster Observability Operator の概要
概要
第1章 Cluster Observability Operator の概要 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Observability Operator (COO) は、高度にカスタマイズ可能なモニタリングスタックを作成し、管理するために設計された OpenShift Container Platform のオプションのコンポーネントです。これにより、クラスター管理者はモニタリングの設定と管理を大幅に自動化でき、デフォルトの OpenShift Container Platform のモニタリングシステムと比べて、各 namespace に対するより詳細でカスタマイズされたビューを提供できます。
COO は、次のモニタリングコンポーネントをデプロイします。
- Prometheus: リモート書き込みを使用してメトリクスを外部エンドポイントに送信できる高可用性 Prometheus インスタンス。
- Thanos Querier (オプション): Prometheus インスタンスを中央の場所からクエリーできるようにします。
- Alertmanager (オプション): さまざまなサービスのアラート設定機能を提供します。
- UI plugins (オプション): モニタリング、ロギング、分散トレーシング、およびトラブルシューティング用にプラグインで可観測性機能を強化します。
- Korrel8r (オプション): オープンソースの Korrel8r プロジェクトが提供する可観測性シグナルの相関を提供します。
- Incident detection (オプション): アラートバーストの根本原因を特定するために、関連するアラートをインシデントにグループ化します。
1.1. デフォルトのモニタリングスタックと比較した COO リンクのコピーリンクがクリップボードにコピーされました!
COO コンポーネントは、Cluster Monitoring Operator (CMO) でデプロイおよび管理されるデフォルトのクラスター内モニタリングスタックとは独立して機能します。2 つの Operator でデプロイされたモニタリングスタックは競合しません。CMO でデプロイされたデフォルトのプラットフォームモニタリングコンポーネントに加え、COO モニタリングスタックを使用できます。
COO とデフォルトのクラスター内のモニタリングスタックの主な相違点を次の表に示します。
| 機能 | COO | デフォルトのモニタリングスタック |
|---|---|---|
| スコープおよびインテグレーション | クラスターやワークロードのパフォーマンスを含め、エンタープライズレベルのニーズに対応した包括的なモニタリングと分析を提供します。 ただし、OpenShift Container Platform との直接統合がなく、通常はダッシュボードに外部 Grafana インスタンスが必要です。 | クラスター内のコアコンポーネント (API サーバーや etcd など) および OpenShift 固有の namespace に限定されます。 OpenShift Container Platform へのディープインテグレーションがあり、コンソールのダッシュボードやアラート管理が含まれています。 |
| 設定とカスタマイズ | データ保持期間、ストレージ方法、収集したデータタイプなど、より広範な設定オプション。 COO は、カスタマイズを強化する Server-Side Apply (SSA) を使用して、カスタムリソース内にある 1 つの設定可能フィールドの所有権をユーザーに委譲できます。 | カスタマイズオプションが制限された組み込み設定。 |
| データの保持とストレージ | 長期のデータ保持。履歴分析と容量計画をサポートします。 | 短期間のデータ保持。短期間のモニタリングとリアルタイム検出に焦点を当てています。 |
1.2. COO を使用する主な利点 リンクのコピーリンクがクリップボードにコピーされました!
COO のデプロイは、デフォルトのモニタリングスタックを使用して達成することが困難なモニタリング要件に対応する際に役立ちます。
1.2.1. 拡張性 リンクのコピーリンクがクリップボードにコピーされました!
- COO でデプロイされたモニタリングスタックにさらにメトリクスを追加できますが、これをコアプラットフォームモニタリングで行った場合はサポートされません。
- フェデレーションを介して、コアプラットフォームのモニタリングからクラスター固有のメトリクスを受け取ることができます。
- COO は、トレンド予測や異常検出などの高度なモニタリングシナリオをサポートします。
1.2.2. マルチテナンシーのサポート リンクのコピーリンクがクリップボードにコピーされました!
- ユーザー namespace ごとにモニタリングスタックを作成できます。
- namespace ごとに複数のスタックをデプロイすることや、複数の namespace に単一のスタックをデプロイすることができます。
- COO は、異なるチームのアラートとレシーバーの独立した設定を可能にします。
1.2.3. スケーラビリティー リンクのコピーリンクがクリップボードにコピーされました!
- 単一クラスターで複数のモニタリングスタックをサポートします。
- 手動シャーディングを使用した大規模なクラスターのモニタリングを可能にします。
- メトリクスが単一の Prometheus インスタンスの機能を超えるケースに対応します。
1.2.4. 柔軟性 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform リリースサイクルから切り離されます。
- より速いリリースサイクルを実現し、変化する要件へ迅速に対応します。
- アラートルールを独立して管理します。
1.3. COO のターゲットユーザー リンクのコピーリンクがクリップボードにコピーされました!
COO は、特に複雑なマルチテナントエンタープライズ環境で、高いカスタマイズ性、スケーラビリティー、および長期のデータ保持が必要なユーザーに適しています。
1.3.1. エンタープライズレベルのユーザーおよび管理者 リンクのコピーリンクがクリップボードにコピーされました!
エンタープライズユーザーには、高度なパフォーマンス分析、長期のデータ保持、トレンド予測、履歴分析など、OpenShift Container Platform クラスターの詳細なモニタリング機能が必要です。これらの機能により、企業はリソースの使用状況をより深く理解し、パフォーマンスの問題を防ぎ、リソースの割り当てを最適化できます。
1.3.2. マルチテナント環境でのオペレーションチーム リンクのコピーリンクがクリップボードにコピーされました!
マルチテナンシーのサポートにより、COO はさまざまなチームがプロジェクトやアプリケーションのモニタリングビューを設定できるため、柔軟なモニタリングニーズがあるチームに適しています。
1.3.3. 開発およびオペレーションチーム リンクのコピーリンクがクリップボードにコピーされました!
COO は、詳細なトラブルシューティング、異常検出、開発および運用時のパフォーマンス調整のために、きめ細かなモニタリングとカスタマイズ可能な可観測性ビューを提供します。
1.4. Server-Side Apply を使用した Prometheus リソースのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
Server-Side Apply は、Kubernetes リソースの共同管理を可能にする機能です。コントロールプレーンは、さまざまなユーザーおよびコントローラーが Kubernetes オブジェクト内のフィールドをどのように管理するかを追跡します。フィールドマネージャーの概念を導入し、フィールドの所有権を追跡します。この集中制御により、競合検出および解決が行われ、意図しない上書きのリスクが軽減されます。
Client-Side Apply と比較すると、より宣言的であり、最後に適用された状態ではなく、フィールド管理を追跡します。
- Server-Side Apply
- リソースの状態を更新することで、削除や再作成を必要とせずに宣言型の設定を管理します。
- フィールド管理
- ユーザーは、他のフィールドに影響を与えずに、更新するリソースのフィールドを指定できます。
- 管理対象フィールド
-
Kubernetes は、メタデータ内の
managedFieldsフィールドでオブジェクトの各フィールドを管理するユーザーに関するメタデータを保存します。 - Conflicts
- 複数のマネージャーが同じフィールドを変更しようとすると、競合が発生します。アプライヤーは、上書きするか、制御を放棄するか、または管理を共有するかを選択できます。
- マージストラテジー
- Server-Side Apply は、管理しているアクターに基づいてフィールドをマージします。
手順
次の設定を使用して
MonitoringStackリソースを追加します。MonitoringStackオブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow sample-monitoring-stackという名前の Prometheus リソースが、coo-demonamespace に生成されます。次のコマンドを実行して、生成された Prometheus リソースの管理対象フィールドを取得します。oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields
$ oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fieldsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
metadata.managedFields値を確認し、metadataとspecの一部のフィールドがMonitoringStackリソースによって管理されていることを確認します。 MonitoringStackリソースで制御されないフィールドを変更します。MonitoringStackリソースによって設定されていないフィールドであるspec.enforcedSampleLimitを変更します。prom-spec-edited.yamlファイルを作成します。prom-spec-edited.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して YAML を適用します。
oc apply -f ./prom-spec-edited.yaml --server-side
$ oc apply -f ./prom-spec-edited.yaml --server-sideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記--server-sideフラグを使用する必要があります。変更された Prometheus オブジェクトを取得し、
spec.enforcedSampleLimitを持つmanagedFieldsに、もう 1 つセクションがあることに注意してください。oc get prometheus -n coo-demo
$ oc get prometheus -n coo-demoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
MonitoringStackリソースによって管理されるフィールドを変更します。次の YAML 設定を使用して、
MonitoringStackリソースによって管理されるフィールドであるspec.LogLevelを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
spec.logLevelが追加されました。
以下のコマンドを実行して YAML を適用します。
oc apply -f ./prom-spec-edited.yaml --server-side
$ oc apply -f ./prom-spec-edited.yaml --server-sideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
フィールド
spec.logLevelはobservability-operatorによってすでに管理されているため、Server-Side Apply を使用して変更できないことに注意してください。 この変更を強制するには、
--force-conflictsフラグを使用します。oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts
$ oc apply -f ./prom-spec-edited.yaml --server-side --force-conflictsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied
prometheus.monitoring.rhobs/sample-monitoring-stack serverside-appliedCopy to Clipboard Copied! Toggle word wrap Toggle overflow --force-conflictsフラグの場合、このフィールドは強制的に変更できますが、同じフィールドがMonitoringStackリソースでも管理されるため、Observability Operator は変更を検出し、MonitoringStackリソースによって設定された値に戻します。注記MonitoringStackリソースによって生成される一部の Prometheus フィールドは、logLevelなど、MonitoringStackspecスタンザのフィールドの影響を受けます。これらは、MonitoringStackspecを変更することで変更できます。Prometheus オブジェクトの
logLevelを変更するには、次の YAML を適用してMonitoringStackリソースを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更が実行されたことを確認するには、次のコマンドを実行してログレベルをクエリーします。
oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'$ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
info
infoCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator の新規バージョンが、以前にアクターによって生成および制御されるフィールドを生成する場合、アクターによって設定された値はオーバーライドされます。
たとえば、
MonitoringStackリソースによって生成されないフィールドenforcedSampleLimitを管理しているとします。Observability Operator がアップグレードされ、新しいバージョンの Operator がenforcedSampleLimitの値を生成すると、以前に設定した値がオーバーライドされます。-
MonitoringStackリソースによって生成されたPrometheusオブジェクトには、モニタリングスタックによって明示的に設定されていないフィールドが含まれる場合があります。これらのフィールドは、デフォルト値があるために表示されます。