第1章 可観測性サービスについて
可観測性コンポーネントは、フリート全体のクラスターの正常性と使用率を理解するために使用できるサービスです。デフォルトでは、マルチクラスター可観測性 Operator は Red Hat Advanced Cluster Management のインストール中に有効になります。
可観測性コンポーネントの詳細は、次のドキュメントを参照してください。
1.1. 可観測性アーキテクチャー
multiclusterhub-operator は、デフォルトで multicluster-observability-operator Pod を有効にします。multicluster-observability-operator Pod を設定する必要があります。
サービスを有効にすると、observability-endpoint-operator がインポートまたは作成された各クラスターに自動的にデプロイされます。このコントローラーは、Red Hat OpenShift Container Platform Prometheus からデータを収集してから、Red Hat Advanced Cluster Management ハブクラスターに送信します。ハブクラスターのインポート自体が self-managed であり、それ自体を local-cluster としてインポートする場合、そのハブクラスターで可観測性も有効になり、メトリックがハブクラスターから収集されます。ただし、ハブクラスターが self-managed の場合、disableHubSelfManagement パラメーターは false に設定されます。
次の図は、可観測性の設定要素を示しています。
可観測性アーキテクチャーのコンポーネントには次の項目が含まれます。
-
マルチクラスターハブオペレーター (
multiclusterhub-operatorPod とも呼ばれます) は、multicluster-observability-operatorPod をデプロイします。ハブクラスターデータをマネージドクラスターに送信します。 - 可観測性アドオンコントローラー は、マネージドクラスターのログを自動的に更新する API サーバーです。
Thanos インフラストラクチャーには、
multicluster-observability-operatorPod によってデプロイされる Thanos Compactor が含まれます。Thanos Compactor は、保持設定とストレージ内のデータの圧縮を使用して、クエリーが適切に実行されることを保証します。Thanos Compactor でいつ問題が発生しているかを特定するには、その正常性を監視する 4 つのデフォルトのアラートを使用します。次のデフォルトアラートの表を確認してください。
表1.1 デフォルトの Thanos アラートの表 アラート 重大度 説明 ACM サノスコンパクト停止critical
コンパクターが停止するとアラートが送信されます。
ACMThanosCompactHighCompactionFailureswarning
圧縮失敗率が 5% を超えると、アラートが送信されます。
ACMThanosCompactBucketHigh 操作障害warning
バケット操作の失敗率が 5% を超えると、アラートが送信されます。
ACMThanosCompact は実行されていませんwarning
コンパクターが過去 24 時間以内に何もアップロードしなかった場合、アラートが送信されます。
- 可観測性コンポーネントは、Grafana のインスタンスをデプロイして、ダッシュボード (静的) またはデータ探索によるデータの視覚化を可能にします。Red Hat Advanced Cluster Management は、Grafana のバージョン 8.5.20 をサポートします。Grafana ダッシュボードを設計することもできます。詳細は、Grafana ダッシュボードの設計 を参照してください。
- Prometheus Alertmanager を使用すると、サードパーティーアプリケーションでアラートを転送できます。カスタムのレコーディングルールまたはアラートルールを作成して、可観測性サービスをカスタマイズできます。Red Hat Advanced Cluster Management は、Prometheus Alertmanager のバージョン 0.25 をサポートします。
1.1.1. 可観測性サービスで使用される永続ストア
重要: 永続ストレージにローカルボリュームを使用するローカルストレージ Operator またはストレージクラスを使用しないでください。再起動後に Pod が別のノードで再起動されると、データが失われる可能性があります。これが発生すると、Pod はノード上のローカルストレージにアクセスできなくなります。データの損失を回避するために、receive Pod および receive Pod の永続ボリュームにアクセスできることを確認してください。
Red Hat Advanced Cluster Management をインストールするときは、次の永続ボリューム (PV) を作成して、Persistent Volume Claims (PVC) を自動的にアタッチできるようにする必要があります。デフォルトのストレージクラスが指定されていない場合、またはデフォルト以外のストレージクラスを使用して PV をホストする場合は、MultiClusterObservability カスタムリソースでストレージクラスを定義する必要があります。Prometheus が使用するものと同様の、ブロックストレージを使用することを推奨します。また、alertmanager、thanos-compactor、thanos-ruler、thanos-receive-default、および thanos-store-shard の各レプリカには、独自の PV が必要です。次の表を参照します。
| 永続ボリューム名 | 目的 |
| alertmanager |
alertmanager は |
| thanos-compact | コンパクターは、処理の中間データとバケット状態キャッシュの保存にローカルのディスク領域が必要です。必要な領域は、下層にあるブロックサイズにより異なります。コンパクターには、すべてのソースブロックをダウンロードして、ディスクで圧縮ブロックを構築するのに十分な領域が必要です。ディスク上のデータは、次回の再起動までに安全に削除でき、最初の試行でクラッシュループコンパクターの停止が解決されるはずです。ただし、次の再起動までにバケットの状態キャッシュを効果的に使用するには、コンパクターの永続ディスクを用意することが推奨されます。 |
| thanos-rule |
thanos ruler は、固定の間隔でクエリーを発行して、選択したクエリー API に対して Prometheus 記録およびアラートルールを評価します。ルールの結果は、Prometheus 2.0 ストレージ形式でディスクに書き込まれます。このステートフルセットで保持されるデータの期間 (時間または日) は、API バージョンの |
| thanos-receive-default |
Thanos receiver は、受信データ (Prometheus リモート書き込みリクエスト) を受け入れて Prometheus TSDB のローカルインスタンスに書き込みます。TSDB ブロックは定期的 (2 時間) に、長期的に保存および圧縮するためにオブジェクトストレージにアップロードされます。ローカルキャッシュを実行するこのステートフルセットで保持される期間 (時間または日) は、API バージョン |
| thanos-store-shard | これは、主に API ゲートウェイとして機能するため、大量のローカルディスク容量は必要ありません。これは、起動時に Thanos クラスターに参加して、アクセスできるデータを広告します。ローカルディスク上のすべてのリモートブロックに関する情報のサイズを小さく保ち、バケットと同期させます。このデータは通常、起動時間が長くなると、再起動時に安全に削除できます。 |
注記: 時系列の履歴データはオブジェクトストアに保存されます。Thanos は、オブジェクトストレージをメトリクスおよび関連するメタデータのプライマリーストレージとして使用します。オブジェクトストレージおよび downsampling 機能の詳細は、可観測性サービスの有効化 を参照してください。
1.1.2. 関連情報
- 可観測性サービスについて を参照してください。
- 可観測性の設定 を参照してください。
- 可観測性サービスの有効化 を参照してください。
