第1章 環境の監視の紹介
可観測性サービスを有効にすると、Red Hat Advanced Cluster Management for Kubernetes を使用して、マネージドクラスターに関する理解を深め、最適化することができます。この情報は、コストを節約し、不要なイベントを防ぐことができます。
1.1. 環境の監視
Red Hat Advanced Cluster Management for Kubernetes を使用して、マネージドクラスターに関する理解を深め、最適化することができます。可観測性サービス Operator (multicluster-observability-operator) を有効化して、マネージドクラスターの状態を監視します。以下のセクションでは、マルチクラスター可観測性サービスのアーキテクチャーについて説明します。
注記: オンデマンドログ は、特定 の Pod のログをリアルタイムで取得するエンジニア用のアクセスを提供します。ハブクラスターからのログは集約されません。これらのログは、検索サービスとコンソールの他の部分を使用してアクセスできます。
1.1.1. 可観測性サービス
デフォルトでは可観測性は、製品のインストール時に追加されますが、有効化されません。永続ストレージの要件で、可観測性サービスはデフォルトで有効化されていません。Red Hat Advanced Cluster Management は、以下の安定したオブジェクトストアをサポートします。
- Amazon S3 (または Ceph など、他の S3 と互換性のあるオブジェクトストア)
- Google Cloud Storage
- Azure ストレージ
- Red Hat OpenShift Container Storage
サービスを有効にすると、observability-endpoint-operator はインポートまたは作成された各クラスターに自動的にデプロイされます。このコントローラーは、Red Hat OpenShift Container Platform Prometheus からデータを収集してから、Red Hat Advanced Cluster Management ハブクラスターに送信します。
ハブクラスターで可観測性を有効にすると、ハブクラスターを local-cluster というマネージドクラスターとして処理してメトリクスを収集します。
注記: Red Hat Advanced Cluster Management では、metrics-collector は Red Hat OpenShift Container Platform 4.x クラスターでのみサポートされます。
可観測性サービスは、Prometheus AlertManager のインスタンスをデプロイすることで、サードパーティーのアプリケーションでのアラートの転送が可能になります。また、ダッシュボード (静的) またはデータ検索を使用してデータの可視化を有効にする Grafana のインスタンスも含まれます。Red Hat Advanced Cluster Management は、Grafana のバージョン 6.4.x をサポートします。Grafana ダッシュボードを設計することもできます。詳細は「Grafana ダッシュボードの設計」を参照してください。
カスタムの レコーディングルール または アラートルール を作成して、可観測性サービスをカスタマイズできます。
可観測性の有効化に関する詳細は、「 可観測性サービスの有効化」を参照してください。
1.1.1.1. 可観測性の証明書
可観測性証明書は、期限が切れると自動的に更新されます。以下の一覧を表示し、証明書が自動更新される場合の影響について確認します。
- ハブクラスターのコンポーネントは自動的に再起動し、更新された証明書を取得します。
- Red Hat Advanced Cluster Management は、更新された証明書をマネージドクラスターに送信します。
metrics-collectorは再起動して、更新された証明書をマウントします。注記:
metrics-collectorは、証明書の削除前および削除後にメトリクスをハブクラスターにプッシュできます。クラスター全体での証明書の更新に関する詳細は、「管理対象証明書の更新」を参照してください。
1.1.1.2. メトリクスのタイプ
デフォルトで、OpenShift Container Platform は Telemetry サービスを使用してメトリクスを Red Hat に送信します。以下のメトリクスが Red Hat Advanced Cluster Management に追加され、テレメトリーに同梱されていますが、Red Hat Advanced Cluster Management Observe 環境の概要 ダッシュボードには表示されません。
-
visual_web_terminal_sessions_totalはハブクラスターで収集されます。 -
acm_managed_cluster_infoは、各マネージドクラスターで収集され、ハブクラスターに送信されます。
OpenShift Container Platform ドキュメントで、Telemetry を使用して収集されて送信されるメトリクスのタイプについて確認します。詳細は、Telemetry で収集される情報 を参照してください。
1.1.1.3. 可観測性 Pod の容量要求
可観測性サービスをインストールするには、可観測性コンポーネントで 2636 mCPU の CPU および 11388 Mi のメモリーが必要です。以下の表は、observability-addons が有効なマネージドクラスター 5 台の Pod 容量要求です。
表1.1 可観測性 Pod の容量要求
| デプロイメントまたは StatefulSet | コンテナー名 | CPU (mCPU) | メモリー (Mi) | レプリカ | Pod の合計 CPU | Pod の合計メモリー |
|---|---|---|---|---|---|---|
| Alertmanager | Alertmanager | 4 | 200 | 3 | 12 | 600 |
| config-reloader | 4 | 25 | 3 | 12 | 75 | |
| grafana | grafana | 4 | 100 | 2 | 8 | 200 |
| grafana-dashboard-loader | 4 | 50 | 2 | 8 | 100 | |
| observability-observatorium-observatorium-api | observatorium-api | 20 | 128 | 2 | 40 | 256 |
| observability-observatorium-thanos-compact | thanos-compact | 100 | 512 | 1 | 100 | 512 |
| observability-observatorium-thanos-query | thanos-query | 300 | 1024 | 2 | 600 | 2048 |
| observability-observatorium-thanos-query-frontend | thanos-query-frontend | 100 | 256 | 2 | 200 | 512 |
| observability-observatorium-thanos-receive-controller | thanos-receive-controller | 4 | 32 | 1 | 4 | 32 |
| observability-observatorium-thanos-receive-default | thanos-receive | 300 | 512 | 3 | 900 | 1536 |
| observability-observatorium-thanos-rule | thanos-rule | 50 | 512 | 3 | 150 | 1536 |
| configmap-reloader | 4 | 25 | 3 | 12 | 75 | |
| observability-observatorium-thanos-store-memcached | Memcached CRD | 45 | 128 | 3 | 135 | 384 |
| exporter | 5 | 50 | 3 | 15 | 150 | |
| observability-observatorium-thanos-store-shard | thanos-store | 100 | 1024 | 3 | 300 | 3072 |
| observatorium-operator | observatorium-operator | 100 | 100 | 1 | 100 | 100 |
| rbac-query-proxy | rbac-query-proxy | 20 | 100 | 2 | 40 | 200 |
1.1.2. 可観測性サービスで使用される永続ストア
Red Hat Advanced Cluster Management のインストール時に、以下の永続ボリュームを作成します。
表1.2 永続ボリュームの表一覧
| 永続ボリューム名 | 目的 |
| Alertmanager |
Alertmanager は |
| thanos-compact | コンパクターは、処理の中間データとバケット状態キャッシュの保存にローカルのディスク領域が必要です。必要な領域は、下層にあるブロックサイズにより異なります。コンパクターには、すべてのソースブロックをダウンロードして、ディスクで圧縮ブロックを構築するために十分な領域が必要です。ディスク上のデータは、次回の再起動までに安全に削除でき、最初の試行でクラッシュループコンパクターの停止が解決されるはずです。ただし、次の再起動までにバケットの状態キャッシュを効果的に使用するためには、コンパクターの永続ディスクを用意することが推奨されます。 |
| thanos-rule | thanos ruler は、固定の間隔でクエリーを発行して、選択したクエリー API に対して Prometheus 記録およびアラートルールを評価します。ルールの結果は、Prometheus 2.0 ストレージ形式でディスクに書き込まれます。 |
| thanos-receive-default | Thanos receiver は、受信データ (Prometheus リモート書き込みリクエスト) を受け入れて Prometheus TSDB のローカルインスタンスに書き込みます。TSDB ブロックは定期的に (2 時間)、長期的に保存および圧縮するためにオブジェクトストレージにアップロードされます。 |
| thanos-store-shard | これは、主に API ゲートウェイとして機能するため、大量のローカルディスク容量は必要ありません。これは、起動時に Thanos クラスターに参加して、アクセスできるデータを広告します。ローカルディスク上のすべてのリモートブロックに関する情報のサイズを小さく保ち、バケットと同期させます。このデータは通常、起動時間が長くなると、再起動時に安全に削除できます。 |
注記: 時系列の履歴データはオブジェクトストアに保存されます。Thanos は、オブジェクトストレージをメトリクスおよび関連するメタデータのプライマリーストレージとして使用します。オブジェクトストレージおよびダウンサンリングの詳細は、「 可観測性サービスの有効化 」を参照してください。