Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Observability

Red Hat Advanced Cluster Management for Kubernetes 2.12

Observability により、クラスターの健全性と使用率、およびクラスター群全体のワークロードを把握する方法を説明します。

概要

可観測性コンポーネントを有効にして、マネージドクラスターに関する洞察を取得します。

第1章 可観測性サービス
リンクのコピー

可観測性により、追加のテストやサポートなしでパフォーマンスの問題を特定して評価できます。Red Hat Advanced Cluster Management for Kubernetes の可観測性コンポーネントは、クラスターの健全性と使用率、およびクラスター全体のワークロードを把握するために使用できるサービスです。可観測性サービスを使用することで、可観測性の範囲内のコンポーネントを自動化および管理できるようになります。

可観測性サービスでは、オープンソースコミュニティーの既存の広く採用されている可観測性ツールを使用します。デフォルトでは、マルチクラスター可観測性 Operator は Red Hat Advanced Cluster Management のインストール中に有効になります。Thanos は、長期的にメトリクスを格納するためにハブクラスター内にデプロイされます。observability-endpoint-operator は、インポートまたは作成された各マネージドクラスターに自動的にデプロイされます。このコントローラーは、Red Hat OpenShift Container Platform Prometheus からデータを収集するメトリクスコレクターを起動し、そのデータを Red Hat Advanced Cluster Management ハブクラスターに送信します。

可観測性コンポーネントの詳細は、次のドキュメントを参照してください。

1.1. 可観測性アーキテクチャー
リンクのコピー

multiclusterhub-operator は、デフォルトで multicluster-observability-operator Pod を有効にします。multicluster-observability-operator Pod を設定する必要があります。

1.1.1. 可観測性オープンソースコンポーネント
リンクのコピー

可観測性サービスは、コミュニティーからのオープンソースの可観測性ツールを使用します。製品の可観測性サービス以外のツールについて、次の説明を参照してください。

  • Thanos: 複数の Prometheus インスタンスにわたってグローバルクエリーを実行するために使用できるコンポーネントのツールキット。Prometheus データを長期保存するには、S3 互換のストレージに保存します。可用性が高くスケーラブルなメトリクスシステムを設定することもできます。
  • Prometheus: アプリケーションからメトリクスを収集し、それらのメトリクスを時系列データとして保存するために使用できる監視およびアラートツール。スクレイピングされたすべてのサンプルをローカルに保存し、ルールを実行して既存のデータから新しい時系列を集計および記録し、アラートを生成します。
  • Alertmanager: Prometheus からのアラートを管理および受信するためのツール。アラートを重複排除、グループ化し、メール、Slack、PagerDuty などのインテグレーションにルーティングします。特定のアラートの通知をオフ、および抑制するように Alertmanager を設定します。

1.1.2. 可観測性アーキテクチャーの図
リンクのコピー

次の図は、可観測性の設定要素を示しています。

Multicluster observability architecture

可観測性アーキテクチャーのコンポーネントには次の項目が含まれます。

  • マルチクラスターハブオペレーター (multiclusterhub-operator Pod とも呼ばれます) は、multicluster-observability-operator Pod をデプロイします。これは、ManifestWorks リソースの生成を通じて、ハブクラスター上のメトリクスストアやマネージドクラスター上のコレクターなどの Red Hat Advanced Cluster Management Observability サービスのリソースをデプロイするルートコンポーネントです。
  • 可観測性アドオンコントローラー は、マネージドクラスターのログを自動的に更新する API サーバーです。

  • Thanos インフラストラクチャーには、multicluster-observability-operator Pod によってデプロイされる Thanos Compactor が含まれます。Thanos Compactor は、保持設定とストレージ内のデータの圧縮を使用して、クエリーが適切に実行されることを保証します。

    Thanos Compactor でいつ問題が発生しているかを特定するには、その正常性を監視する 4 つのデフォルトのアラートを使用します。次のデフォルトアラートの表を確認してください。

    Expand
    表1.1 デフォルトの Thanos アラートの表
    アラートSeverity説明

    ACMThanosCompactHalted

    critical

    コンパクターが停止するとアラートが送信されます。

    ACMThanosCompactHighCompactionFailures

    warning

    圧縮失敗率が 5% を超えると、アラートが送信されます。

    ACMThanosCompactBucketHighOperationFailures

    warning

    バケット操作の失敗率が 5% を超えると、アラートが送信されます。

    ACMThanosCompactHasNotRun

    warning

    コンパクターが過去 24 時間以内に何もアップロードしなかった場合、アラートが送信されます。

  • 可観測性コンポーネントは、Grafana のインスタンスをデプロイして、ダッシュボード (静的) またはデータ探索によるデータの視覚化を可能にします。Red Hat Advanced Cluster Management は、Grafana のバージョン 11.1.5 をサポートします。Grafana ダッシュボードを設計することもできます。詳細は、Grafana ダッシュボードの設計 を参照してください。
  • Prometheus Alertmanager を使用すると、サードパーティーアプリケーションでアラートを転送できます。カスタムのレコーディングルールまたはアラートルールを作成して、可観測性サービスをカスタマイズできます。Red Hat Advanced Cluster Management は、Prometheus Alertmanager のバージョン 0.25 をサポートします。

1.1.3. 可観測性サービスで使用される永続ストア
リンクのコピー

重要: 永続ストレージにローカルボリュームを使用するローカルストレージ 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 が必要です。次の表を参照します。

Expand
表1.2 永続ボリュームの表リスト

コンポーネント名

目的

alertmanager

alertmanager は nflog データおよび通知なしのアラートをストレージに保存します。nflog は、通知されたレシーバーおよび、アクティブな通知と解決済みの通知、通知により特定されたコンテンツのハッシュダイジェストに関する追記専用のログです。

observability-thanos-compactor

コンパクターは、処理の中間データとバケット状態キャッシュの保存にローカルのディスク領域が必要です。必要な領域は、下層にあるブロックサイズにより異なります。コンパクターには、すべてのソースブロックをダウンロードして、ディスクで圧縮ブロックを構築するのに十分な領域が必要です。ディスク上のデータは、次回の再起動までに安全に削除でき、最初の試行でクラッシュループコンパクターの停止が解決されるはずです。ただし、次の再起動までにバケットの状態キャッシュを効果的に使用するには、コンパクターの永続ディスクを用意することが推奨されます。

observability-thanos-rule

thanos ruler は、固定の間隔でクエリーを発行して、選択したクエリー API に対して Prometheus 記録およびアラートルールを評価します。ルールの結果は、Prometheus 2.0 ストレージ形式でディスクに書き込まれます。このステートフルセットで保持されるデータの期間 (時間または日) は、API バージョンの observability.open-cluster-management.io/v1beta1 で修正されました。observability.open-cluster-management.io/v1beta2: RetentionInLocal の API パラメーターとして公開されました。

observability-thanos-receive-default

Thanos receiver は、受信データ (Prometheus リモート書き込みリクエスト) を受け入れて Prometheus TSDB のローカルインスタンスに書き込みます。TSDB ブロックは定期的 (2 時間) に、長期的に保存および圧縮するためにオブジェクトストレージにアップロードされます。ローカルキャッシュを実行するこのステートフルセットで保持される期間 (時間または日) は、API バージョン observability.open-cluster-management.io/v1beta で修正されました。observability.open-cluster-management.io/v1beta2: RetentionInLocal の API パラメーターとして公開されました。

observability-thanos-store-shard

これは、主に API ゲートウェイとして機能するため、大量のローカルディスク容量は必要ありません。これは、起動時に Thanos クラスターに参加して、アクセスできるデータを広告します。ローカルディスク上のすべてのリモートブロックに関する情報のサイズを小さく保ち、バケットと同期させます。このデータは通常、起動時間が長くなると、再起動時に安全に削除できます。

注記: 時系列の履歴データはオブジェクトストアに保存されます。Thanos は、オブジェクトストレージをメトリクスおよび関連するメタデータのプライマリーストレージとして使用します。オブジェクトストレージおよび downsampling 機能の詳細は、可観測性サービスの有効化 を参照してください。

1.1.4. 関連情報
リンクのコピー

可観測性とインテグレーションコンポーネントの詳細は、次のトピックを参照してください。

1.2. 可観測性の設定
リンクのコピー

可観測性サービスが有効になっている場合、ハブクラスターは、ハブの自己管理が有効になっているかどうかに関係なく、設定された Thanos インスタンスにメトリクスを収集して送信するように常に設定されます。ハブクラスターがセルフマネージドの場合、disableHubSelfManagement パラメーターはデフォルトの設定である false に設定されます。multiclusterhub-operator は、デフォルトで multicluster-observability-operator Pod を有効にします。multicluster-observability-operator Pod を設定する必要があります。

ハブクラスターのメトリクスとアラートは、local-cluster namespace に表示されます。local-cluster は、ハブの自己管理が有効になっている場合にのみ使用できます。Grafana エクスプローラーで local-cluster メトリクスをクエリーできます。可観測性コンポーネントで収集できるメトリクスと、可観測性 Pod の容量に関する情報を理解するには、次のセクションも確認してください。

1.2.1. メトリクスのタイプ
リンクのコピー

デフォルトでは、OpenShift Container Platform は Telemetry サービスを使用してメトリクスを Red Hat に送信します。acm_managed_cluster_info は、Red Hat Advanced Cluster Management で利用でき、Telemetry に含まれていますが、Red Hat Advanced Cluster Management Observe 環境の概要 ダッシュボードには表示され ません。

フレームワークでサポートされているメトリクスタイプは、次の表を参照してください。

Expand
表1.3 パラメーターの表
メトリクス名メトリクスのタイプラベル/タグステータス

acm_managed_cluster_info

ゲージ

hub_cluster_id、managed_cluster_id、vendor、cloud、version、available、created_via、core_worker、socket_worker

Stable

config_policies_evaluation_duration_seconds_bucket

ヒストグラム

なし

Stable。詳細は、ガバナンスメトリクス を参照してください。

config_policies_evaluation_duration_seconds_count

ヒストグラム

なし

Stable。詳細は、ガバナンスメトリクス を参照してください。

config_policies_evaluation_duration_seconds_sum

ヒストグラム

なし

Stable。詳細は、ガバナンスメトリクス を参照してください。

policy_governance_info

ゲージ

type、policy、policy_namespace、cluster_namespace

Stable。詳細は、ガバナンスメトリクス を参照してください。

policyreport_info

ゲージ

managed_cluster_id、category、policy、result、severity

Stable。詳細は、insight _PolicyReports_ の管理 を参照してください。

search_api_db_connection_failed_total

カウンター

なし

Stable。コンソールでの検索 ドキュメントの 検索コンポーネント のセクションを参照してください。

search_api_dbquery_duration_seconds

ヒストグラム

なし

Stable。コンソールでの検索 ドキュメントの 検索コンポーネント のセクションを参照してください。

search_api_requests

ヒストグラム

なし

Stable。コンソールでの検索 ドキュメントの 検索コンポーネント のセクションを参照してください。

search_indexer_request_count

カウンター

なし

Stable。コンソールでの検索 ドキュメントの 検索コンポーネント のセクションを参照してください。

search_indexer_request_duration

ヒストグラム

なし

Stable。コンソールでの検索 ドキュメントの 検索コンポーネント のセクションを参照してください。

search_indexer_requests_in_flight

ゲージ

なし

Stable。コンソールでの検索 ドキュメントの 検索コンポーネント のセクションを参照してください。

search_indexer_request_size

ヒストグラム

なし

Stable。コンソールでの検索 ドキュメントの 検索コンポーネント のセクションを参照してください。

1.2.2. デフォルトのメトリクス
リンクのコピー

デフォルトのメトリクスを表示するには、次のコマンドを実行して observability-metrics-allowlist を確認します。 

oc -n open-cluster-management-observability get cm observability-metrics-allowlist -o yaml
Copy to Clipboard Toggle word wrap

注記: 許可リスト内のデフォルトのメトリクスを変更することはできません。

1.2.3. 可観測性 Pod の容量要求
リンクのコピー

可観測性サービスをインストールするには、可観測性コンポーネントで 2701mCPU および 11972Mi のメモリーが必要です。以下の表は、observability-addons が有効なマネージドクラスター 5 台の Pod 容量要求のリストです。

Expand
表1.4 可観測性 Pod の容量要求
デプロイメントまたは StatefulSetコンテナー名CPU (mCPU)メモリー (Mi)レプリカPod の合計 CPUPod の合計メモリー

observability-alertmanager

alertmanager

4

200

3

12

600

config-reloader

4

25

3

12

75

alertmanager-proxy

1

20

3

3

60

observability-grafana

grafana

4

100

2

8

200

grafana-dashboard-loader

4

50

2

8

100

observability-observatorium-api

observatorium-api

20

128

2

40

256

observability-observatorium-operator

observatorium-operator

100

100

1

10

50

observability-rbac-query-proxy

rbac-query-proxy

20

100

2

40

200

oauth-proxy

1

20

2

2

40

observability-thanos-compact

thanos-compact

500

1024

1

100

512

observability-thanos-query

thanos-query

300

1024

2

600

2048

observability-thanos-query-frontend

thanos-query-frontend

100

256

2

200

512

observability-thanos-query-frontend-memcached

memcached

45

128

3

135

384

exporter

5

50

3

15

150

observability-thanos-receive-controller

thanos-receive-controller

4

32

1

4

32

observability-thanos-receive-default

thanos-receive

300

512

3

900

1536

observability-thanos-rule

thanos-rule

50

512

3

150

1536

configmap-reloader

4

25

3

12

75

observability-thanos-store-memcached

memcached

45

128

3

135

384

exporter

5

50

3

15

150

observability-thanos-store-shard

thanos-store

100

1024

3

300

3072

1.2.4. 関連情報
リンクのコピー

1.3. 可観測性サービスの有効化
リンクのコピー

ハブクラスターで可観測性サービスを有効にすると、multicluster-observability-operator が新しいマネージドクラスターを監視し、メトリクスおよびアラート収集サービスをマネージドクラスターに自動的にデプロイします。メトリクスを使用して Grafana ダッシュボードを設定すると、クラスターのリソース情報を可視化し、コストを節約し、サービスの中断を防ぐことができます。

multicluster-observability-operator Pod とも呼ばれる可観測性コンポーネントを使用して、マネージドクラスターのステータスを監視します。

必要なアクセス権: クラスター管理者、open-cluster-management:cluster-manager-admin ロール、または S3 管理者。

1.3.1. 前提条件
リンクのコピー

  • Red Hat Advanced Cluster Management for Kubernetes がインストールされている。詳細は、ネットワーク接続時のオンラインインストール を参照してください。
  • プラットフォームのデフォルト storageClass を使用したくない場合は、MultiClusterObservability カスタムリソースの storageConfig.storageClass フィールドを指定する必要があります。
  • ハブクラスターへの直接的なネットワークアクセスが必要です。ロードバランサーおよびプロキシーへのネットワークアクセスはサポートされていません。詳細は、Networking を参照してください。

  • ストレージソリューションを作成するようにオブジェクトストアが設定されている。

    • 重要: オブジェクトストアを設定する場合は、機密データを永続化する時に必要な暗号化要件を満たすようにしてください。可観測性サービスは、Thanos がサポートする安定したオブジェクトストアを使用します。複数の Red Hat Advanced Cluster Management 可観測性インストールでオブジェクトストアバケットを共有できない場合があります。したがって、インストールごとに個別のオブジェクトストアバケットを提供します。

    • Red Hat Advanced Cluster Management は、安定したオブジェクトストアで以下のクラウドプロバイダーをサポートします。

      • Amazon Web Services S3 (AWS S3)
      • Red Hat Ceph (S3 互換 API)
      • Google Cloud Storage
      • Azure ストレージ
      • Red Hat OpenShift Data Foundation (旧称: Red Hat OpenShift Container Storage)
      • Red Hat OpenShift on IBM Cloud

1.3.2. コマンドラインインターフェイスからの可観測性の有効化
リンクのコピー

MultiClusterObservability カスタムリソースを作成して可観測性サービスを有効にします。可観測性を有効にする前に、可観測性 Pod の容量要求 を参照してください。

注記:

  • Red Hat Advanced Cluster Management が管理する OpenShift Container Platform マネージドクラスターで可観測性を有効または無効にすると、可観測性エンドポイント Operator は、ローカル Prometheus を自動的に再起動する alertmanager 設定を追加して cluster-monitoring-config config map を更新します。
  • 可観測性エンドポイント Operator は、ローカル Prometheus を自動的に再起動する alertmanager 設定を別途追加して、cluster-monitoring-config config map を更新します。OpenShift Container Platform マネージドクラスターに alertmanager 設定を挿入すると、Prometheus メトリクスの保持フィールドに関連する設定が削除されます。

可観測性サービスを有効にするには、以下の手順を実行します。

  1. Red Hat Advanced Cluster Management ハブクラスターにログインします。

  2. 以下のコマンドを使用して可観測性サービスの namespace を作成します。 

    oc create namespace open-cluster-management-observability
    Copy to Clipboard Toggle word wrap

  3. プルシークレットを生成します。Red Hat Advanced Cluster Management が open-cluster-management namespace にインストールされている場合は、以下のコマンドを実行します。 

    DOCKER_CONFIG_JSON=`oc extract secret/multiclusterhub-operator-pull-secret -n open-cluster-management --to=-`
    Copy to Clipboard Toggle word wrap

    1. multiclusterhub-operator-pull-secret が namespace で定義されていない場合は、次のコマンドを実行して、pull-secret を openshift-config namespace から open-cluster-management-observability namespace にコピーします。 

      DOCKER_CONFIG_JSON=`oc extract secret/pull-secret -n openshift-config --to=-`
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、open-cluster-management-observability namespace にプルシークレットを作成します。 

      oc create secret generic multiclusterhub-operator-pull-secret \
    -n open-cluster-management-observability \
    --from-literal=.dockerconfigjson="$DOCKER_CONFIG_JSON" \
    --type=kubernetes.io/dockerconfigjson
      Copy to Clipboard Toggle word wrap

    重要: OpenShift Container Platform ドキュメントを使用してクラスターのグローバルプルシークレットを変更する場合は、必ず可観測性 namespace のグローバルプルシークレットも更新してください。詳細は、グローバルプルシークレットの更新 を参照してください。

  4. お使いのクラウドプロバイダーのオブジェクトストレージのシークレットを作成します。シークレットには、ストレージソリューションへの認証情報を追加する必要があります。たとえば、以下のコマンドを実行します。 

    oc create -f thanos-object-storage.yaml -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap

    サポートされるオブジェクトストアのシークレットの例を以下に示します。

    • Amazon S3 または S3 と互換性のある場合、シークレットは以下のファイルのようになります。 

      apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: s3
    config:
      bucket: YOUR_S3_BUCKET
      endpoint: YOUR_S3_ENDPOINT
      1 
      
      insecure: true
      access_key: YOUR_ACCESS_KEY
      secret_key: YOUR_SECRET_KEY
      Copy to Clipboard Toggle word wrap
      1
      プロトコルなしで URL を入力します。s3.us-east-1.amazonaws.com の URL のような Amazon S3 エンドポイントの URL を入力します。

      詳細は、Amazon Simple Storage Service ユーザーガイド を参照してください。

    • Google Cloud Platform の場合は、以下のファイルのようになります。 

      apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: GCS
    config:
      bucket: YOUR_GCS_BUCKET
      service_account: YOUR_SERVICE_ACCOUNT
      Copy to Clipboard Toggle word wrap

      詳細は、Google Cloud Storage とは を参照してください。

    • Azure の場合は、以下のファイルのようになります。 

      apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: AZURE
    config:
      storage_account: YOUR_STORAGE_ACCT
      storage_account_key: YOUR_STORAGE_KEY
      container: YOUR_CONTAINER
      endpoint: blob.core.windows.net
      1 
      
      max_retries: 0
      Copy to Clipboard Toggle word wrap
      1
      msi_resource パスを使用する場合、エンドポイント認証はシステム割り当てのマネージド ID を使用して完了します。値はエンドポイント https://<storage-account-name>.blob.core.windows.net のようにする必要があります。

      user_assigned_id パスを使用する場合は、ユーザー割り当てマネージド ID を使用してエンドポイント認証が完了します。user_assigned_id を使用する場合、msi_resource エンドポイントのデフォルト値は https:<storage_account>.<endpoint> です。詳細は、Azure Storage のドキュメント を参照してください。

      注記: Azure を Red Hat OpenShift Container Platform クラスターのオブジェクトストレージとして使用する場合には、クラスターに関連付けられたストレージアカウントはサポートされません。新規ストレージアカウントを作成する必要があります。

    • Red Hat OpenShift Data Foundation では、シークレットは以下のファイルのようになります。 

      apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: s3
    config:
      bucket: YOUR_RH_DATA_FOUNDATION_BUCKET
      endpoint: YOUR_RH_DATA_FOUNDATION_ENDPOINT
      1 
      
      insecure: false
      access_key: YOUR_RH_DATA_FOUNDATION_ACCESS_KEY
      secret_key: YOUR_RH_DATA_FOUNDATION_SECRET_KEY
      Copy to Clipboard Toggle word wrap
      1
      プロトコルなしで URL を入力します。次の URL のような Red Hat OpenShift Data Foundation エンドポイントの URL を入力します: example.redhat.com:443。

      詳細は、Red Hat OpenShift Data Foundation を参照してください。

    • Red Hat OpenShift on IBM (ROKS) では、シークレットは以下のファイルのようになります。 
    apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: s3
    config:
      bucket: YOUR_ROKS_S3_BUCKET
      endpoint: YOUR_ROKS_S3_ENDPOINT
    1 
    
      insecure: true
      access_key: YOUR_ROKS_ACCESS_KEY
      secret_key: YOUR_ROKS_SECRET_KEY
    Copy to Clipboard Toggle word wrap
    1
    プロトコルなしで URL を入力します。次の URL のような Red Hat OpenShift Data Foundation エンドポイントの URL を入力します: example.redhat.com:443。

    詳細は、IBM Cloud のドキュメント Cloud Object Storage を参照してください。サービスの認証情報を使用してオブジェクトストレージに接続するようにしてください。詳細は、IBM Cloud のドキュメント、Cloud Object Store および Service Credentials を参照してください。

1.3.2.1. AWS Security Token Service のストレージの設定
リンクのコピー

Amazon S3 または S3 と互換性のあるストレージの場合、AWS Security Token Service (AWS STS) で生成された短期間の限定特権認証情報を使用することもできます。詳細は、AWS Security Token Service ドキュメント を参照してください。

AWS Security Service を使用してアクセスキーを生成するには、次の追加の手順が必要です。

  1. S3 バケットへのアクセスを制限する IAM ポリシーを作成します。
  2. OpenShift Container Platform サービスアカウントの JWT トークンを生成するための信頼ポリシーを持つ IAM ロールを作成します。
  3. S3 バケットへのアクセスが必要な可観測性サービスアカウントのアノテーションを指定します。Red Hat OpenShift Service on AWS (ROSA) クラスターで可観測性を設定して AWS STS トークンを使用する方法の例は 環境の設定 ステップで確認できます。詳細は、Red Hat OpenShift Service on AWS (ROSA) を参照してください。また、STS トークンを使用するための要件とセットアップの詳細な説明は、ROSA with STS の説明 を参照してください。
1.3.2.2. AWS Security Service を使用したアクセスキーの生成
リンクのコピー

AWS Security Service を使用してアクセスキーを生成するには、次の手順を実行します。

  1. AWS 環境をセットアップします。以下のコマンドを実行します。 

    export POLICY_VERSION=$(date +"%m-%d-%y")
export TRUST_POLICY_VERSION=$(date +"%m-%d-%y")
export CLUSTER_NAME=<my-cluster>
export S3_BUCKET=$CLUSTER_NAME-acm-observability
export REGION=us-east-2
export NAMESPACE=open-cluster-management-observability
export SA=tbd
export SCRATCH_DIR=/tmp/scratch
export OIDC_PROVIDER=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer| sed -e "s/^https:\/\///")
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export AWS_PAGER=""
rm -rf $SCRATCH_DIR
mkdir -p $SCRATCH_DIR
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドで S3 バケットを作成します。 

    aws s3 mb s3://$S3_BUCKET
    Copy to Clipboard Toggle word wrap

  3. S3 バケットにアクセスするための s3-policy JSON ファイルを作成します。以下のコマンドを実行します。 

    {
    "Version": "$POLICY_VERSION",
    "Statement": [
        {
            "Sid": "Statement",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:CreateBucket",
                "s3:DeleteBucket"
            ],
            "Resource": [
                "arn:aws:s3:::$S3_BUCKET/*",
                "arn:aws:s3:::$S3_BUCKET"
            ]
        }
    ]
 }
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドでポリシーを適用します。 

    S3_POLICY=$(aws iam create-policy --policy-name $CLUSTER_NAME-acm-obs \
--policy-document file://$SCRATCH_DIR/s3-policy.json \
--query 'Policy.Arn' --output text)
echo $S3_POLICY
    Copy to Clipboard Toggle word wrap

  5. TrustPolicy JSON ファイルを作成します。以下のコマンドを実行します。 

    {
 "Version": "$TRUST_POLICY_VERSION",
 "Statement": [
   {
     "Effect": "Allow",
     "Principal": {
       "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
     },
     "Action": "sts:AssumeRoleWithWebIdentity",
     "Condition": {
       "StringEquals": {
         "${OIDC_PROVIDER}:sub": [
           "system:serviceaccount:${NAMESPACE}:observability-thanos-query",
           "system:serviceaccount:${NAMESPACE}:observability-thanos-store-shard",
           "system:serviceaccount:${NAMESPACE}:observability-thanos-compact",
           "system:serviceaccount:${NAMESPACE}:observability-thanos-rule",
           "system:serviceaccount:${NAMESPACE}:observability-thanos-receive"
         ]
       }
     }
   }
 ]
}
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを使用して、AWS Prometheus と CloudWatch のロールを作成します。 

    S3_ROLE=$(aws iam create-role \
  --role-name "$CLUSTER_NAME-acm-obs-s3" \
  --assume-role-policy-document file://$SCRATCH_DIR/TrustPolicy.json \
  --query "Role.Arn" --output text)
echo $S3_ROLE
    Copy to Clipboard Toggle word wrap

  7. ポリシーをロールにアタッチします。以下のコマンドを実行します。 

    aws iam attach-role-policy \
  --role-name "$CLUSTER_NAME-acm-obs-s3" \
  --policy-arn $S3_POLICY
    Copy to Clipboard Toggle word wrap

    シークレットは、次のファイルのようになる場合があります。config セクションでは signature_version2: false が指定されており、access_key と secret_key は指定されていません。 

    apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  thanos.yaml: |
    type: s3
    config:
      bucket: $S3_BUCKET
      endpoint: s3.$REGION.amazonaws.com
      signature_version2: false
    Copy to Clipboard Toggle word wrap
  8. MultiClusterObservability カスタムリソースの作成 セクションの説明に従って、MultiClusterObservability カスタムリソースにサービスアカウントアノテーションを指定します。

  9. 以下のコマンドを使用して、クラウドプロバイダーの S3 アクセスキーおよび秘密鍵を取得します。シークレットの base64 文字列のデコード、編集、エンコードが必要です。

    1. クラウドプロバイダーの S3 アクセスキーを編集およびデコードするには、次のコマンドを実行します。 

      YOUR_CLOUD_PROVIDER_ACCESS_KEY=$(oc -n open-cluster-management-observability get secret <object-storage-secret> -o jsonpath="{.data.thanos\.yaml}" | base64 --decode | grep access_key | awk '{print $2}')
      Copy to Clipboard Toggle word wrap

    2. クラウドプロバイダーのアクセスキーを表示するには、次のコマンドを実行します。 

      echo $YOUR_CLOUD_PROVIDER_ACCESS_KEY
      Copy to Clipboard Toggle word wrap

    3. クラウドプロバイダーの秘密鍵を編集およびデコードするには、次のコマンドを実行します。 

      YOUR_CLOUD_PROVIDER_SECRET_KEY=$(oc -n open-cluster-management-observability get secret <object-storage-secret> -o jsonpath="{.data.thanos\.yaml}" | base64 --decode | grep secret_key | awk '{print $2}')
      Copy to Clipboard Toggle word wrap
    4. クラウドプロバイダーの秘密鍵を表示するには、次のコマンドを実行します。 
    echo $YOUR_CLOUD_PROVIDER_SECRET_KEY
    Copy to Clipboard Toggle word wrap

  10. 次のデプロイメントとステートフルセットの Pod をチェックして、可観測性が有効になっていることを確認します。次の情報が表示される場合があります。 

    observability-thanos-query (deployment)
observability-thanos-compact (statefulset)
observability-thanos-receive-default  (statefulset)
observability-thanos-rule   (statefulset)
observability-thanos-store-shard-x  (statefulsets)
    Copy to Clipboard Toggle word wrap
1.3.2.3. MultiClusterObservability カスタムリソースの作成
リンクのコピー

MultiClusterObservability カスタムリソースを使用して、さまざまなコンポーネントの永続ボリュームのストレージサイズを指定します。MultiClusterObservability カスタムリソースの最初の作成時にストレージサイズを設定する必要があります。デプロイ後にストレージサイズ値を更新すると、ストレージクラスが動的ボリューム拡張をサポートしている場合にのみ変更が反映されます。詳細は、Red Hat OpenShift Container Platform ドキュメントの 永続ボリュームの拡張 を参照してください。

次の手順を実行して、ハブクラスターに MultiClusterObservability カスタムリソースを作成します。

  1. multiclusterobservability_cr.yaml という名前の MultiClusterObservability カスタムリソースの YAML ファイルを作成します。

    可観測性については、以下のデフォルト YAML ファイルを確認してください。 

    apiVersion: observability.open-cluster-management.io/v1beta2
kind: MultiClusterObservability
metadata:
  name: observability
spec:
  observabilityAddonSpec: {}
  storageConfig:
    metricObjectStorage:
      name: thanos-object-storage
      key: thanos.yaml
    Copy to Clipboard Toggle word wrap

    advanced セクションで retentionConfig パラメーターの値を変更する必要がある場合があります。詳細は、Thanos Downsampling resolution and retention を参照してください。マネージドクラスターの数によっては、ステートフルセットのストレージの量を更新する必要がある場合があります。S3 バケットが STS トークンを使用するように設定されている場合は、S3 ロールで STS を使用するようにサービスアカウントにアノテーションを付けます。次の設定を表示します。 

    spec:
  advanced:
    compact:
       serviceAccountAnnotations:
           eks.amazonaws.com/role-arn: $S3_ROLE
    store:
       serviceAccountAnnotations:
          eks.amazonaws.com/role-arn: $S3_ROLE
    rule:
       serviceAccountAnnotations:
          eks.amazonaws.com/role-arn: $S3_ROLE
    receive:
       serviceAccountAnnotations:
          eks.amazonaws.com/role-arn: $S3_ROLE
    query:
       serviceAccountAnnotations:
          eks.amazonaws.com/role-arn: $S3_ROLE
    Copy to Clipboard Toggle word wrap

    詳細は、可観測性 API を参照してください。

  2. インフラストラクチャーマシンセットにデプロイするには、MultiClusterObservability YAML の nodeSelector を更新して、セットのラベルを設定する必要があります。YAML の内容は以下のようになります。 

      nodeSelector:
    node-role.kubernetes.io/infra: ""
    Copy to Clipboard Toggle word wrap

    詳細は、インフラストラクチャーマシンセットの作成 を参照してください。

  3. 以下のコマンドを実行して可観測性 YAML をクラスターに適用します。 

    oc apply -f multiclusterobservability_cr.yaml
    Copy to Clipboard Toggle word wrap

    注記： デフォルトでは、MultiClusterObservability カスタムリソースの storageConfig.storageClass フィールドを定義しない場合、プラットフォームのデフォルト StorageClass フィールドが MultiClusterObservability リソースの storageConfig セクションに入力されます。たとえば、AWS のデフォルトの storageClass は gp2 に設定されます。

  4. 次のコマンドを実行して、デフォルトの storageClass を確認します。 

    oc get storageClass
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    NAME                PROVISIONER       RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2-csi             ebs.csi.aws.com   Delete          WaitForFirstConsumer   true                   151m
gp3-csi (default)   ebs.csi.aws.com   Delete          WaitForFirstConsumer   true                   151m
    Copy to Clipboard Toggle word wrap
  5. Grafana ダッシュボードを起動して可観測性サービスが有効になっていることを検証し、データが入力されていることを確認します。
  6. コンソールの 概要 ページまたは クラスター ページから、コンソールヘッダーの近くにある Grafana リンク をクリックします。

  7. multicluster-observability-operator デプロイメントにアクセスして、multicluster-observability-operator Pod が multiclusterhub-operator デプロイメントによってデプロイされていることを確認します。以下のコマンドを実行します。 

    oc get deploy multicluster-observability-operator -n open-cluster-management --show-labels
    Copy to Clipboard Toggle word wrap

    次のような結果が表示される場合があります。 

    NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE   LABELS
multicluster-observability-operator   1/1     1            1           35m   installer.name=multiclusterhub,installer.namespace=open-cluster-management
    Copy to Clipboard Toggle word wrap

  8. リソースに関連付けられているラベルについて multicluster-observability-operator デプロイメントの labels セクションを表示します。labels セクションには次の詳細が含まれる場合があります。 

     labels:
    installer.name: multiclusterhub
    installer.namespace: open-cluster-management
    Copy to Clipboard Toggle word wrap
  9. 注記: 可観測性データを収集しないように特定のマネージドクラスターを除外するには、クラスターに observability: disabled クラスターラベルを追加します。

可観測性サービスを有効化します。可観測性サービスを有効にすると、次の機能が開始されます。

  • マネージドクラスターからのアラートマネージャーはすべて、Red Hat Advanced Cluster Management ハブクラスターに転送されます。

  • Red Hat Advanced Cluster Management ハブクラスターに接続されたマネージドクラスターはすべて、アラートを Red Hat Advanced Cluster Management の可観測性サービスに送信できます。Red Hat Advanced Cluster Management Alertmanager を設定して、重複を排除してグループ化し、アラートをメール、PagerDuty、または OpsGenie などの適切なレシーバー統合にルーティングすることができます。アラートの通知解除や抑制にも対応できます。

    注記: Red Hat Advanced Cluster Management ハブクラスターへのアラート転送機能は、サポートされている OpenShift Container Platform バージョンのマネージドクラスターでのみサポートされます。可観測性を有効にして Red Hat Advanced Cluster Management をインストールすると、アラートが自動的にハブクラスターに転送されます。詳細は、送信アラート を参照してください。

1.3.3. Red Hat OpenShift Container Platform コンソールからの可観測性の有効化
リンクのコピー

オプションで、Red Hat OpenShift Container Platform コンソールから可観測性を有効にし、open-cluster-management-observability という名前のプロジェクトを作成します。以下の手順を実行します。

  1. open-cluster-management-observability プロジェクトで、multiclusterhub-operator-pull-secret という名前のイメージプルシークレットを作成します。
  2. open-cluster-management-observability プロジェクトに thanos-object-storage という名前のオブジェクトストレージシークレットを作成します。
  3. オブジェクトストレージシークレットの詳細を入力し、Create をクリックします。シークレットの例を表示するには、可観測性の有効化 セクションの手順 4 を参照してください。
  4. MultiClusterObservability カスタムリソースインスタンスを作成します。Observability components are deployed and running のメッセージが表示されると、OpenShift Container Platform から可観測性サービスが正常に有効化されています。
1.3.3.1. Thanos バージョンの検証
リンクのコピー

Thanos がクラスターにデプロイされたら、コマンドラインインターフェイス (CLI) から Thanos のバージョンを確認します。

ハブクラスターにログインした後、可観測性 Pod で次のコマンドを実行して Thanos バージョンを受け取ります。 

thanos --version
Copy to Clipboard Toggle word wrap

Thanos のバージョンが表示されます。

1.3.4. 可観測性の無効化
リンクのコピー

可観測性を無効にして、Red Hat Advanced Cluster Management ハブクラスターでデータ収集を停止します。

1.3.4.1. すべてのクラスターで可観測性を無効にする
リンクのコピー

すべてのマネージドクラスターで可観測性コンポーネントを削除して、可観測性を無効にします。

enableMetrics を false に設定して、multicluster-observability-operator リソースを更新します。更新されたリソースは、以下のような変更内容になります。 

spec:
  imagePullPolicy: Always
  imagePullSecret: multiclusterhub-operator-pull-secret
  observabilityAddonSpec:
1 

    enableMetrics: false
2 

  workers:
3
Copy to Clipboard Toggle word wrap
1
observabilityAddonSpec パラメーターを使用して、Observability アドオンが有効になっているすべてのマネージドクラスターのグローバル設定を定義します。
2
enableMetrics パラメーターを使用して、Observability アドオンが有効になっていて、メトリクスをハブクラスターサーバーにプッシュできることを示します。
3
テクノロジープレビュー: workers パラメーターを使用して、メトリクスコレクタープロセスの内部ワーカーの数を増やします。マネージドクラスター上の Prometheus に対して内部ワーカーが分割 /federate エンドポイントリクエストを送信し、ハブクラスター上の Thanos に個別のリモート書き込みリクエストを送信します。
1.3.4.2. 単一クラスターで可観測性を無効にする
リンクのコピー

特定のマネージドクラスターの可観測性コンポーネントを削除して可観測性を無効にします。以下の手順を実行します。

  1. managedclusters.cluster.open-cluster-management.io のカスタムリソースに observability: disabled ラベルを追加します。

  2. Red Hat Advanced Cluster Management コンソールの Clusters ページから、指定したクラスターに observability=disabled ラベルを追加します。

    注記: 可観測性コンポーネントが含まれるマネージドクラスターをデタッチすると、metrics-collector デプロイメントが削除されます。

1.3.5. 可観測性の削除
リンクのコピー

MultiClusterObservability カスタムリソースを削除すると、可観測性サービスが無効化され、アンインストールされます。OpenShift Container Platform コンソールナビゲーションから、Operators > Installed Operators > Advanced Cluster Manager for Kubernetes の順に選択します。MultiClusterObservability カスタムリソースを削除します。

1.3.6. 関連情報
リンクのコピー

1.4. 可観測性設定のカスタマイズ
リンクのコピー

可観測性を有効にした後、環境の特定のニーズに合わせて可観測性設定をカスタマイズします。可観測性サービスが収集するクラスターフリートデータを管理および表示します。

必要なアクセス権: クラスター管理者

1.4.1. カスタムルールの作成
リンクのコピー

可観測性リソースに、Prometheus レコードルール および アラートルール を追加して、可観測性インストールのカスタムルールを作成します。

高価な式を事前計算するには、Prometheus の記録ルール機能を使用してアラート条件を作成し、外部サービスにアラートを送信する方法に基づいて通知を送信します。結果は新たな時系列のセットとして保存されます。以下の例を参照して、thanos-ruler-custom-rules Config Map 内にカスタムアラートルールを作成します。

  • CPU 使用率が定義した値を超えたときに通知を受け取るには、次のカスタムアラートルールを作成します。 

    data:
  custom_rules.yaml: |
    groups:
      - name: cluster-health
        rules:
        - alert: ClusterCPUHealth-jb
          annotations:
            summary: Notify when CPU utilization on a cluster is greater than the defined utilization limit
            description: "The cluster has a high CPU usage: {{ $value }} core for {{ $labels.cluster }} {{ $labels.clusterID }}."
          expr: |
            max(cluster:cpu_usage_cores:sum) by (clusterID, cluster, prometheus) > 0
          for: 5s
          labels:
            cluster: "{{ $labels.cluster }}"
            prometheus: "{{ $labels.prometheus }}"
            severity: critical
    Copy to Clipboard Toggle word wrap

    注記:

    • カスタムルールを更新すると、observability-thanos-rule Pod が自動的に再起動します。
    • 設定には、複数のルールを作成できます。
    • デフォルトのアラートルールは、open-cluster-management-observability namespace の observability-thanos-rule-default-rules config map にあります。

  • Pod のコンテナーメモリーキャッシュの合計を取得するためのカスタム記録ルールを作成するには、次のカスタムルールを作成します。 

    data:
  custom_rules.yaml: |
    groups:
      - name: container-memory
        rules:
        - record: pod:container_memory_cache:sum
          expr: sum(container_memory_cache{pod!=""}) BY (pod, container)
    Copy to Clipboard Toggle word wrap

    注記: config map に変更を加えた後、設定は自動的に再読み込みされます。この設定は、observability-thanos-rule サイドカー内の config-reload により、設定が再読み込みされます。

アラートルールが正しく機能していることを確認するには、Grafana ダッシュボードに移動し、Explore ページを選択して、ALERTS にクエリーを実行します。アラートを作成した場合、アラートは Grafana でのみ使用できます。

1.4.2. カスタムメトリクスの追加
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes を使用してリモートクラスターからのメトリクスを監視するには、そのメトリクスがプラットフォームまたはユーザーワークロードメトリクスとしてエクスポートされているかどうかを確認します。メトリクスタイプを確認するには、次の 3 つの方法のいずれかを使用します。

  • 監視対象とするソリューションのドキュメントでメトリクスタイプを確認します。
  • 製品のサポートに問い合わせてメトリクスタイプを確認します。

  • 監視対象リソースの ServiceMonitor が使用するアノテーションを確認して、メトリクスタイプを確認します。

    • プラットフォームメトリクスは、operator.prometheus.io/controller-id: openshift-platform-monitoring/prometheus-operator を使用します。
    • ユーザーワークロードメトリクスは、operator.prometheus.io/controller-id: openshift-user-workload-monitoring/prometheus-operator を使用します。

また、コンソールで Observe > Targets に移動し、右上の Source フィルターから Platform または User を選択することで、ServiceMonitor を見つけることもできます。

注記: Source フィルターは、メトリクスのリストではなく、サービスモニターまたはターゲットの情報を提供します。

メトリクスがプラットフォームの場合は、プラットフォームメトリクスの追加 に進んでください。メトリクスがユーザーワークロードの場合は、ユーザーワークロードメトリクスの追加 に進んでください。

1.4.2.1. プラットフォームメトリクスの追加
リンクのコピー

ハブクラスターの open-cluster-management-observability namespace 内に ConfigMap を作成することで、プラットフォームメトリクスを監視できます。名前として observability-metrics-custom-allowlist を使用します。プラットフォームメトリクスを監視するために使用できる次の ConfigMap の例を参照してください。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: observability-metrics-custom-allowlist
  namespace: open-cluster-management-observability
  data:
  metrics_list.yaml: |
    names:
1 

      - node_memory_MemTotal_bytes
        recording_rules:
2 

      - record: apiserver_request_duration_seconds:histogram_quantile_90
        expr: histogram_quantile(0.90,sum(rate(apiserver_request_duration_seconds_bucket {job=\"apiserver\", verb!=\"WATCH\"}[5m])) by (verb,le))
Copy to Clipboard Toggle word wrap
1
オプション: マネージドクラスターから収集するカスタムメトリクスの名前を追加します。
2
オプション: expr と record パラメーターのペアに値を 1 つ追加して、クエリー式を定義します。

収集するメトリクスの名前は、マネージドクラスターの record パラメーターで定義した名前と同じです。クエリー式を実行すると、メトリクス値の結果が得られます。1 つのセクションまたは両方のセクションを使用できます。これは、モニタリングが有効なすべてのクラスターに当てはまります。

1 つのマネージドクラスターからのみカスタムメトリクスを収集する場合は、次の例を使用して、マネージドクラスターの open-cluster-management-addon-observability namespace 内で config map を適用します。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: observability-metrics-custom-allowlist
  namespace: open-cluster-management-addon-observability
  data:
  metrics_list.yaml: |
    names:
1 

      - node_memory_MemTotal_bytes
        recording_rules:
2 

      - record: apiserver_request_duration_seconds:histogram_quantile_90
        expr: histogram_quantile(0.90,sum(rate(apiserver_request_duration_seconds_bucket{job="apiserver", verb!="WATCH"}[5m])) by (verb,le))
Copy to Clipboard Toggle word wrap
1
オプション: マネージドクラスターから収集するカスタムメトリクスの名前を追加します。
2
オプション: expr と record パラメーターのペアに値を 1 つだけ入力して、クエリー式を定義します。

収集するメトリクスの名前は、マネージドクラスターの record パラメーターで定義した名前と同じです。クエリー式を実行すると、メトリクス値の結果が得られます。1 つのセクションまたは両方のセクションを使用できます。

1.4.2.2. ユーザーワークロードメトリクスの追加
リンクのコピー

メトリクスの取得対象とする namespace 内のマネージドクラスターで設定を指定することで、ユーザーワークロードメトリクスを監視できます。名前は observability-metrics-custom-allowlist である必要があります。形式は次の例と同じである必要があります。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: observability-metrics-custom-allowlist
  namespace: <monitored_namespace>
1 

data:
  uwl_metrics_list.yaml:
    names:
      - <sample_metrics>
2
Copy to Clipboard Toggle word wrap
1
メトリクスの取得対象とする namespace を追加します。
2
config map データの値を YAML 形式で追加します。test namespace から収集するメトリクス名のリストを names セクションに追加します。config map を作成すると、可観測性コレクターはメトリクスを収集し、ターゲット namespace からハブクラスターにプッシュします。

前の例では、namespace monitored_namespace からのユーザーワークロードメトリクス sample_metrics を監視します。代わりに、open-cluster-management-addon-observability namespace で設定を作成すると、マネージドクラスターのすべての namespace からメトリクスが収集されます。

1.4.2.3. デフォルトメトリクスの削除
リンクのコピー

マネージドクラスターから特定のメトリクスのデータを収集したくない場合は、observability-metrics-custom-allowlist.yaml ファイルからメトリクスを削除します。メトリクスを削除すると、マネージドクラスターからメトリクスデータが収集されなくなります。デフォルトのメトリクスを削除するには、次の手順を実行します。

  1. 以下のコマンドを使用して、mco observability が有効になっていることを確認します。 

    oc get mco observability -o yaml
    Copy to Clipboard Toggle word wrap

  2. metrics_list.yaml パラメーターにデフォルトのメトリクスの名前を追加します。メトリクス名の先頭にハイフン - を付けます。次のメトリクスの例を参照してください。 

    -cluster_infrastructure_provider
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドで、open-cluster-management-observability namespace に observability-metrics-custom-allowlist config map を作成します。 

    oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
    Copy to Clipboard Toggle word wrap
  4. 可観測性サービスがマネージドクラスターから特定のメトリクスを収集していないことを確認します。Grafana ダッシュボードからメトリクスをクエリーしても、メトリクスは表示されません。

1.4.3. 保持の詳細設定の追加
リンクのコピー

必要に応じて各可観測性コンポーネントの保持を更新するには、advanced 設定セクションを追加します。以下の手順を実行します。

  1. 次のコマンドを使用して、MultiClusterObservability カスタムリソースを編集します。 

    oc edit mco observability -o yaml
    Copy to Clipboard Toggle word wrap

  2. ファイルに advanced セクションを追加します。YAML ファイルは以下の内容のようになります。 

    spec:
  advanced:
    retentionConfig:
      blockDuration: 2h
      deleteDelay: 48h
      retentionInLocal: 24h
      retentionResolutionRaw: 365d
      retentionResolution5m: 365d
      retentionResolution1h: 365d
    receive:
      resources:
        limits:
          memory: 4096Gi
      replicas: 3
    Copy to Clipboard Toggle word wrap

    注記:

    • advanced 設定に追加できるすべてのパラメーターの説明は、Observability API ドキュメントを参照してください。
    • すべての解像度レベル (retentionResolutionRaw、retentionResolution5m、retentionResolution1h など) のデフォルトの保持期間は 365 日 (365d) です。MultiClusterObservability spec.advanced.retentionConfig パラメーターで、解像度保持の明示的な値を設定する必要があります。

  3. 以前のバージョンからアップグレードし、そのバージョン保持設定を保持する場合は、前述の設定を追加します。以下の手順を実行します。

    1. 次のコマンドを実行して、MultiClusterObservability リソースに移動します。 

      oc edit mco observability
      Copy to Clipboard Toggle word wrap
    2. spec.advanced.retentionConfig パラメーターで、次の設定を適用します。 
    spec:
  advanced:
    retentionConfig:
      retentionResolutionRaw: 365d
      retentionResolution5m: 365d
      retentionResolution1h: 365d
    Copy to Clipboard Toggle word wrap

1.4.4. シングルノード OpenShift クラスターの動的メトリクス
リンクのコピー

動的メトリクス収集では、特定の条件に基づいて自動的にメトリクスを収集できます。デフォルトでは、シングルノードの OpenShift クラスターは Pod およびコンテナーのリソースメトリクスを収集しません。シングルノードの OpenShift クラスターが特定のレベルのリソース消費に達すると、定義された詳細なメトリクスが動的に収集されます。一定期間にわたってクラスターリソースの消費量が常にしきい値を下回ると、詳細なメトリクスの収集が停止します。

メトリクスは、収集ルールによって指定されたマネージドクラスターの条件に基づいて動的に収集されます。これらのメトリクスは動的に収集されるため、次の Red Hat Advanced Cluster Management Grafana ダッシュボードにはデータが表示されません。収集ルールがアクティブ化され、対応するメトリクスが収集されると、収集ルールが起動している期間のデータが次のパネルに表示されます。

  • Kubernetes/コンピューティングリソース/namespace (Pod)
  • Kubernetes/コンピューティングリソース/namespace (ワークロード)
  • Kubernetes/コンピューティングリソース/ノード (Pod)
  • Kubernetes/コンピューティングリソース/Pod
  • Kubernetes/コンピューティングリソース/ワークロード収集ルールには次の条件が含まれます。
  • 動的に収集するメトリクスのセット。
  • PromQL 式として記述された条件。
  • コレクションの間隔。true に設定する必要があります。
  • 収集ルールを評価する必要のあるクラスターを選択するための一致式。

デフォルトでは、コレクションルールは、30 秒ごとにマネージドクラスターで継続的に評価されるか、特定の間隔で評価されます。コレクションの間隔と時間間隔の最小値が優先されます。収集ルールの条件が for 属性で指定された期間持続すると、収集ルールが開始され、ルールで指定されたメトリクスがマネージドクラスターに自動的に収集されます。メトリクスの収集は、収集ルールの条件がマネージドクラスターに存在しなくなった後、開始してから少なくとも 15 分後に自動的に停止します。

収集ルールは、collect_rules という名前のパラメーターセクションとしてグループ化され、グループとして有効または無効にできます。Red Hat Advanced Cluster Management インストールには、コレクションルールグループ (HighCPUUsage および HighMemoryUsage) のデフォルトコレクションルール SNOResourceUsage が含まれます。HighCPUUsage コレクションルールは、ノードの CPU 使用率が 70% を超えると開始されます。HighMemoryUsage 収集ルールは、シングルノード OpenShift クラスターの全体的なメモリー使用率が使用可能なノードメモリーの 70% を超えると開始されます。現在、上記のしきい値は固定されており、変更できません。収集ルールが for 属性で指定された間隔を超えて開始すると、システムが dynamic_metrics セクションで指定されたメトリクスの収集を自動的に開始します。

次の YAML ファイルに含まれる collect_rules セクションの動的メトリクスのリストを参照してください。 

collect_rules:
  - group: SNOResourceUsage
    annotations:
      description: >
        By default, a {sno} cluster does not collect pod and container resource metrics. Once a {sno} cluster
        reaches a level of resource consumption, these granular metrics are collected dynamically.
        When the cluster resource consumption is consistently less than the threshold for a period of time,
        collection of the granular metrics stops.
    selector:
      matchExpressions:
        - key: clusterType
          operator: In
          values: ["{sno}"]
    rules:
    - collect: SNOHighCPUUsage
      annotations:
        description: >
          Collects the dynamic metrics specified if the cluster cpu usage is constantly more than 70% for 2 minutes
      expr: (1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))) * 100 > 70
      for: 2m
      dynamic_metrics:
        names:
          - container_cpu_cfs_periods_total
          - container_cpu_cfs_throttled_periods_total
          - kube_pod_container_resource_limits
          - kube_pod_container_resource_requests
          - namespace_workload_pod:kube_pod_owner:relabel
          - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate
          - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate
    - collect: SNOHighMemoryUsage
      annotations:
        description: >
          Collects the dynamic metrics specified if the cluster memory usage is constantly more than 70% for 2 minutes
      expr: (1 - sum(:node_memory_MemAvailable_bytes:sum) / sum(kube_node_status_allocatable{resource=\"memory\"})) * 100 > 70
      for: 2m
      dynamic_metrics:
        names:
          - kube_pod_container_resource_limits
          - kube_pod_container_resource_requests
          - namespace_workload_pod:kube_pod_owner:relabel
        matches:
          - __name__="container_memory_cache",container!=""
          - __name__="container_memory_rss",container!=""
          - __name__="container_memory_swap",container!=""
          - __name__="container_memory_working_set_bytes",container!=""
Copy to Clipboard Toggle word wrap

以下の例のように、collect_rules.group は custom-allowlist で無効にできます。collect_rules.group を無効にすると、メトリクスの収集が以前の動作に戻ります。これらのメトリクスは、指定された間隔で定期的に収集されます。 

collect_rules:
  - group: -SNOResourceUsage
Copy to Clipboard Toggle word wrap

データは、ルールの開始時のみ Grafana に表示されます。

1.4.5. コンソールからの MultiClusterObservability カスタムリソースレプリカの更新
リンクのコピー

ワークロードが増加する場合は、可観測性 Pod のレプリカ数を増やします。ハブクラスターから Red Hat OpenShift Container Platform コンソールに移動します。MultiClusterObservability カスタムリソースを見つけて、レプリカを変更するコンポーネントの replicas パラメーター値を更新します。更新した YAML は以下のようになります。 

spec:
   advanced:
      receive:
         replicas: 6
Copy to Clipboard Toggle word wrap

mco observability カスタムリソース内のパラメーターの詳細は、可観測性 API ドキュメントを参照してください。

1.4.6. 永続ボリュームおよび永続ボリューム要求の増減
リンクのコピー

永続ボリュームと永続ボリューム要求を増減して、ストレージクラス内のストレージの量を変更します。以下の手順を実行します。

  1. ストレージクラスがボリュームの拡張をサポートしている場合は、MultiClusterObservability カスタムリソースを更新して、永続ボリュームのサイズを増やします。

  2. 永続ボリュームのサイズを小さくするには、永続ボリュームを使用している Pod を削除し、永続ボリュームを削除して再作成します。永続ボリュームでデータが失われる可能性があります。以下の手順を実行します。

    1. MultiClusterObservability カスタムリソースにアノテーション mco-pause: "true" を追加して、MultiClusterObservability Operator を一時停止します。

    2. 目的のコンポーネントのステートフルセットまたはデプロイメントを探します。レプリカ数を 0 に変更します。これによりシャットダウンが開始され、データの損失を避けるために、該当する場合はローカルデータがアップロードされます。たとえば、Thanos Receive ステートフルセットの名前は observability-thanos-receive-default で、デフォルトでは 3 つのレプリカがあります。したがって、次の永続ボリューム要求を探します。

      • data-observability-thanos-receive-default-0
      • data-observability-thanos-receive-default-1
      • data-observability-thanos-receive-default-2
    3. 必要なコンポーネントによって使用される永続ボリュームおよび永続ボリューム要求を削除します。
    4. MultiClusterObservability カスタムリソースで、コンポーネントの設定のストレージサイズを、ストレージサイズフィールドで必要な量に編集します。接頭辞にはコンポーネントの名前が付いています。
    5. 以前に追加したアノテーションを削除して MultiClusterObservability Operator の一時停止を解除します。
    6. Operator を一時停止した後に調整を開始するには、multicluster-observability-operator および observatorium-operator Pod を削除します。Pod はすぐに再作成され、調整されます。
  3. MultiClusterObservability カスタムリソースをチェックして、永続ボリュームとボリューム要求が更新されていることを確認します。

1.4.7. ルート証明書のカスタマイズ
リンクのコピー

OpenShift Container Platform ルート認証をカスタマイズする場合は、ルートを alt_names セクションに追加する必要があります。OpenShift Container Platform ルートにアクセスできるようにするには、alertmanager.apps.<domainname>、observatorium-api.apps.<domainname>、rbac-query-proxy.apps.<domainname> の情報を追加します。

詳細は、ガバナンスドキュメントの alertmanager ルートの証明書の置き換え を参照してください。

注記: ユーザーは証明書のローテーションおよび更新を行います。

1.4.8. オブジェクトストアにアクセスするための証明書のカスタマイズ
リンクのコピー

認証局を含む Secret リソースを作成し、MultiClusterObservability カスタムリソースを設定することで、監視オブジェクトストアとの安全な接続を設定できます。以下の手順を実行します。

  1. オブジェクトストア接続を検証するには、次のコマンドを使用して、認証局を含むファイルに Secret オブジェクトを作成します。 

    oc create secret generic <tls_secret_name> --from-file=ca.crt=<path_to_file> -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap
    1. あるいは、次の YAML を適用してシークレットを作成することもできます。 
    apiVersion: v1
kind: Secret
metadata:
  name: <tls_secret_name>
  namespace: open-cluster-management-observability
type: Opaque
data:
  ca.crt: <base64_encoded_ca_certificate>
    Copy to Clipboard Toggle word wrap

    オプション: 相互 TLS を有効にする場合は、前のシークレットに public.crt キーと private.key キーを追加する必要があります。

  2. 次のコマンドを使用して、metricObjectStorage セクションに TLS シークレットの詳細を追加します。 

    oc edit mco observability -o yaml
    Copy to Clipboard Toggle word wrap

    ファイルは次の YAML のようになります。 

    metricObjectStorage:
  key: thanos.yaml
  name: thanos-object-storage
  tlsSecretName: tls-certs-secret
    1 
    
  tlsSecretMountPath: /etc/<s3-directory>/certs
    2
    Copy to Clipboard Toggle word wrap
    1
    tlsSecretName の値は、以前に作成した Secret オブジェクトの名前です。
    2
    tlsSecretMountPath パラメーターに定義された /etc/<s3-directory>/certs/ パスは、Observability コンポーネント内で証明書がマウントされる場所を指定します。このパスは次のステップに必要です。

  3. 証明書の詳細を含む http_config.tls_config セクションを追加して、thanos-object-storage シークレットの thanos.yaml 定義を更新します。以下の例を参照してください。必要に応じて値を置き換えます。 

    thanos.yaml: |
   type: s3
   config:
     bucket: <bucket-name>
     endpoint: <s3.port>
     insecure: false
    1 
    
     access_key: <s3-access>
     secret_key: <s3-secret>
     http_config:
       tls_config:
         ca_file: /etc/<s3-directory>/certs/ca.crt
    2 
    
         insecure_skip_verify: false
    Copy to Clipboard Toggle word wrap
    1
    HTTPS を有効にするには、insecure パラメーターを false に設定します。
    2
    ca_file パラメーターのパスは、MultiClusterObservability カスタムリソースの tlsSecretMountPath と一致させる必要があります。ca.crt は、<tls_secret_name> Secret リソース内のキーと一致させる必要があります。

    オプション: 相互 TLS を有効にする場合は、tls_config セクションに cert_file キーと key_file キーを追加する必要があります。以下の例を参照してください。必要に応じて値を置き換えます。 

     thanos.yaml: |
    type: s3
    config:
      bucket: <bucket-name>
      endpoint: <s3.port>
      insecure: false
      access_key: <s3-access>
      secret_key: <s3-secret>
      http_config:
        tls_config:
          ca_file: /etc/<s3-directory>/certs/ca.crt
    1 
    
          cert_file: /etc/<s3-directory>/certs/public.crt
          key_file: /etc/<s3-directory>/certs/private.key
          insecure_skip_verify: false
    Copy to Clipboard Toggle word wrap
    1
    ca_file、cert_file、および key_file のパスは、MultiClusterObservability カスタムリソースの tlsSecretMountPath と一致させる必要があります。ca.crt、public.crt、private.crt は、tls_secret_name> Secret リソース内のそれぞれのキーと一致させる必要があります。

  4. オブジェクトストアにアクセスできることを確認するには、Pod がデプロイされていることを確認します。以下のコマンドを実行します。 

    oc -n open-cluster-management-observability get pods -l app.kubernetes.io/name=thanos-store
    Copy to Clipboard Toggle word wrap

1.4.9. 可観測性アドオンのプロキシー設定
リンクのコピー

マネージドクラスターからの通信が HTTP および HTTPS プロキシーサーバー経由でハブクラスターにアクセスできるようにプロキシー設定を指定します。通常、アドオンでは、ハブクラスターとマネージドクラスターの間で HTTP および HTTPS プロキシーサーバーをサポートする特別な設定は必要ありません。ただし、可観測性アドオンを有効にしている場合は、プロキシー設定を完了する必要があります。

1.4.10. 前提条件
リンクのコピー

  • ハブクラスターがある。
  • ハブクラスターとマネージドクラスター間のプロキシー設定が有効にしている。

可観測性アドオンのプロキシー設定を指定するには、以下の手順を実行します。

  1. ハブクラスターのクラスター namespace に移動します。

  2. spec.proxyConfig パラメーターを追加して、プロキシー設定を使用して AddOnDeploymentConfig リソースを作成します。以下は、YAML の例です。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: <addon-deploy-config-name>
  namespace: <managed-cluster-name>
spec:
  agentInstallNamespace: open-cluster-management-addon-observability
  proxyConfig:
    httpsProxy: "http://<username>:<password>@<ip>:<port>"
    1 
    
    noProxy: ".cluster.local,.svc,172.30.0.1"
    2
    Copy to Clipboard Toggle word wrap
    1
    このフィールドには、HTTP プロキシーまたは HTTPS プロキシーのいずれかを指定できます。
    2
    kube-apiserver の IP アドレスを含めます。

  3. マネージドクラスターで IP アドレスを取得するには、以下のコマンドを実行します。 

    oc -n default describe svc kubernetes | grep IP:
    Copy to Clipboard Toggle word wrap

  4. ManagedClusterAddOn リソースに移動し、作成した AddOnDeploymentConfig リソースを参照して更新します。以下は、YAML の例です。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: observability-controller
  namespace: <managed-cluster-name>
spec:
  installNamespace: open-cluster-management-addon-observability
  configs:
  - group: addon.open-cluster-management.io
    resource: addondeploymentconfigs
    name: <addon-deploy-config-name>
    namespace: <managed-cluster-name>
    Copy to Clipboard Toggle word wrap

  5. プロキシー設定を検証します。プロキシー設定が正常に設定されている場合、マネージドクラスター上の可観測性アドオンエージェントによってデプロイされたメトリクスコレクターが、データをハブクラスターに送信します。以下の手順を実行します。

    1. ハブクラスターに移動し、Grafana ダッシュボードでマネージドクラスターに移動します。
    2. プロキシー設定のメトリクスを表示します。

1.4.11. 可観測性アドオンのプロキシー設定の無効化
リンクのコピー

開発に必要な変更がある場合は、ハブクラスターとマネージドクラスターに設定した可観測性アドオンのプロキシー設定を無効にすることが必要な場合があります。可観測性アドオンのプロキシー設定はいつでも無効にできます。以下の手順を実行します。

  1. ManagedClusterAddOn リソースに移動します。
  2. 参照される AddOnDeploymentConfig リソースを削除します。

ロードバランサーまたはリザーブプロキシーを使用するときに、マネージドクラスターがハブクラスターとの通信に使用する Observatorium API および Alertmanager URL をカスタマイズして、すべての Red Hat Advanced Cluster Management 機能を維持できます。URL をカスタマイズするには、次の手順を実行します。

  1. MultiClusterObservability spec の advanced セクションに URL を追加します。以下の例を参照してください。 
spec:
  advanced:
    customObservabilityHubURL: <yourURL>
    customAlertmanagerHubURL: <yourURL>
Copy to Clipboard Toggle word wrap

注記:

  • HTTPS URL のみがサポートされます。URL に https:// を追加しない場合、スキームは自動的に追加されます。
  • customObservabilityHubURL spec に、リモート書き込み API の標準パス /api/metrics/v1/default/api/v1/receive を含めることができます。パスを含めない場合、Observability サービスは実行時にパスを自動的に追加します。

  • カスタム Observability ハブクラスター URL に使用する中間コンポーネントは MTLS 認証に依存しているため、TLS 終端を使用できません。カスタム Alertmanager ハブクラスター URL は、独自の既存の証明書手順を使用して中間コンポーネントの TLS 終端をサポートします。

    1. customObservabilityHubURL を使用している場合は、次のテンプレートを使用してルートオブジェクトを作成します。<intermediate_component_url> を中間コンポーネントの URL に置き換えます。 
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: proxy-observatorium-api
  namespace: open-cluster-management-observability
spec:
  host: <intermediate_component_url>
  port:
    targetPort: public
  tls:
    insecureEdgeTerminationPolicy: None
    termination: passthrough
  to:
    kind: Service
    name: observability-observatorium-api
    weight: 100
  wildcardPolicy: None
Copy to Clipboard Toggle word wrap
  1. customAlertmanagerHubURL を使用している場合は、次のテンプレートを使用してルートオブジェクトを作成します。<intermediate_component_url> を中間コンポーネントの URL に置き換えます。 
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: alertmanager-proxy
  namespace: open-cluster-management-observability
spec:
  host: <intermediate_component_url>
  path: /api/v2
  port:
    targetPort: oauth-proxy
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: reencrypt
  to:
    kind: Service
    name: alertmanager
    weight: 100
  wildcardPolicy: None
Copy to Clipboard Toggle word wrap

1.4.13. 詳細な RBAC の設定 (テクノロジープレビュー)
リンクのコピー

クラスター内の特定 namespace へのメトリクスアクセスを制限するには、詳細なロールベースアクセス制御 (RBAC) を使用します。詳細な RBAC を使用すると、アクセス権が付与された namespace のメトリクスのみの表示をアプリケーションチームに許可することができます。

ハブクラスターのユーザーのメトリクスアクセス制御は、ハブクラスター上で設定する必要があります。このハブクラスターでは、ManagedCluster カスタムリソースによってすべてのマネージドクラスターが表されます。RBAC を設定し、許可する namespace を選択するには、ManagedCluster カスタムリソースで指定されているルールとアクション動詞を使用します。

たとえば、my-awesome-app という名前のアプリケーションがあり、このアプリケーションが devcluster1 と devcluster2 という 2 つの異なるマネージドクラスター上にあるとします。どちらのクラスターも AwesomeAppNS namespace にあります。my-awesome-app-admins という名前の admin ユーザーグループがあり、このユーザーグループが、ハブクラスター上のこれら 2 つの namespace からのメトリクスにのみアクセスできるように制限するとします。

この例では、詳細な RBAC を使用してユーザーグループのアクセスを制限するために、次の手順を実行します。

  1. メトリクスにアクセスする権限を持つ ClusterRole リソースを定義します。リソースは次の YAML のようになります。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: awesome-app-metrics-role
rules:
 - apiGroups:
     - "cluster.open-cluster-management.io"
   resources:
     - managedclusters:
    1 
    
   resourceNames:
    2 
    
     - devcluster1
     - devcluster2
   verbs:
    3 
    
     - metrics/AwesomeAppNS
    Copy to Clipboard Toggle word wrap
    1
    マネージドクラスターのパラメーター値を表します。
    2
    マネージドクラスターのリストを表します。
    3
    マネージドクラスターの namespace を表します。

  2. グループ my-awesome-app-admins を awesome-app-metrics-role の ClusterRole リソースにバインドする ClusterRoleBinding リソースを定義します。リソースは次の YAML のようになります。 

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: awesome-app-metrics-role-binding
subjects:
 - kind: Group
   apiGroup: rbac.authorization.k8s.io
   name: my-awesome-app-admins
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: awesome-app-metrics-role
    Copy to Clipboard Toggle word wrap

これらの手順を完了すると、my-awesome-app-admins のユーザーが Grafana コンソールにログインするときに、次の制限が適用されます。

  • フリートレベルのデータを要約したダッシュボードのデータがユーザーに表示されません。
  • ユーザーは、ClusterRole リソースで指定されているマネージドクラスターと namespace のみを選択できます。

異なるタイプのユーザーアクセスを設定するには、namespace 内の異なるマネージドクラスターを表す個別の ClusterRoles および ClusterRoleBindings リソースを定義します。

1.4.14. 関連情報
リンクのコピー

1.5. 可観測性の使用
リンクのコピー

可観測性サービスを使用して、フリート全体のクラスターの使用率を表示します。

必要なアクセス権: クラスター管理者

1.5.1. 可観測性 API を使用したメトリクスのクエリー
リンクのコピー

ネットワーク接続の双方のアイデンティティーを検証する相互 TLS を使用してエンドポイントにアクセスするには、外部可観測性 API を使用して Red Hat OpenShift Container Platform rbac-query-proxy ルート経由でメトリクスのクエリーを実行します。rbac-query-proxy ルートのクエリーを取得するには、次の手順を実行します。

  1. 以下のコマンドを使用して、ルートの詳細を取得できます。 

    oc get route rbac-query-proxy -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap

  2. OpenShift Container Platform OAuth アクセストークンを使用して rbac-query-proxy ルートにアクセスするには、次のコマンドを実行してトークンを取得します。トークンは、namespace を取得するパーミッションがあるユーザーまたはサービスアカウントと関連付ける必要があります。 

    MY_TOKEN=$(oc whoami --show-token)
    Copy to Clipboard Toggle word wrap

  3. openshift-ingress ルートにアクセスするには、デフォルトの CA 証明書を取得し、tls.crt キーの内容をローカルファイルに保存します。以下のコマンドを実行します。 

    oc -n openshift-ingress get secret router-certs-default -o jsonpath="{.data.tls\.crt}" | base64 -d > ca.crt
    Copy to Clipboard Toggle word wrap

    注意: ハブクラスターが OpenShift Service on AWS で実行している場合、router-certs-default シークレットは存在しません。代わりに、デフォルトの Ingress コントローラーオブジェクトで spec.defaultCertificate.name が指す CA 証明書を使用します。tls.crt キーの内容をローカルファイルに保存します。以下の手順を実行します。

    1. 次のコマンドを実行して、spec.defaultCertificate.name の名前を取得します。 

      SECRET_NAME=$(oc get ingresscontroller default -n openshift-ingress-operator -o jsonpath=" {.spec.defaultCertificate.name}")
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、シークレットから証明書を抽出します。 

      oc get secret $SECRET_NAME -n openshift-ingress -o jsonpath=" {.data.tls\.crt}" | base64 -d > ca.crt
      Copy to Clipboard Toggle word wrap

  4. API からメトリクスのクエリーを実行するには、次のコマンドを実行します。 

    curl --cacert ./ca.crt -H "Authorization: Bearer {TOKEN}" https://{PROXY_ROUTE_URL}/api/v1/query?query={QUERY_EXPRESSION}
    Copy to Clipboard Toggle word wrap

    注記: QUERY_EXPRESSION は標準の Prometheus クエリー式です。たとえば、前述のコマンドの URL を https://{PROXY_ROUTE_URL}/api/v1/query?query=cluster_infrastructure_provider に置き換えて、メトリクス cluster_infrastructure_provider のクエリーを実行します。詳細は、Prometheus のクエリー を参照してください。

  5. rbac-query-proxy ルートにカスタム証明書を設定する場合は、rbac-query-proxy ルート の証明書の置き換え を参照してください。
1.5.1.1. 外部エンドポイントへのメトリクスのエクスポート
リンクのコピー

リアルタイムで Prometheus Remote-Write 仕様をサポートするには、メトリクスを外部エンドポイントにエクスポートします。メトリクスを外部エンドポイントにエクスポートするには、次の手順を実行します。

  1. open-cluster-management-observability namespace の外部エンドポイントのアクセス情報を使用して、外部エンドポイントの Kubernetes シークレットを作成します。次のシークレットの例を表示します。 

    apiVersion: v1
kind: Secret
metadata:
  name: victoriametrics
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  ep.yaml: |
    1 
    
    url: http://victoriametrics:8428/api/v1/write
    2 
    
    http_client_config:
    3 
    
      basic_auth:
    4 
    
        username: test
    5 
    
        password: test
    6 
    
      tls_config:
    7 
    
        secret_name:
    8 
    
        ca_file_key:
    9 
    
        cert_file_key:
    10 
    
        key_file_key:
    11 
    
        insecure_skip_verify:
    12
    Copy to Clipboard Toggle word wrap
    1
    ep.yaml パラメーターはコンテンツのキーであり、次のステップの MultiClusterObservability カスタムリソースで使用されます。現在、可観測性は、セキュリティーチェックなしで、Basic 認証を使用するか、TLS を有効にしてエンドポイントにメトリクスをエクスポートする方法をサポートしています。サポートされているパラメーターの完全なリストは、次の表を参照してください。
    2
    url パラメーターは、必須の、外部エンドポイント URL です。値を文字列として入力します。
    3
    http_client_config パラメーターは、オプションの、HTTP クライアントの高度な設定です。
    4
    basic_auth パラメーターは、オプションの、Basic 認証用の HTTP クライアント設定です。
    5
    username パラメーターは、オプションの、基本認可のユーザー名です。値を文字列として入力します。
    6
    password は、オプションの、基本認可のパスワードです。値を文字列として入力します。
    7
    tls_config パラメーターは、オプションの、TLS の HTTP クライアント設定です。
    8
    secret_name パラメーターは、必須の、証明書が含まれるシークレットの名前です。値を文字列として入力します。
    9
    ca_file_key パラメーターは、必須の、シークレット内の CA 証明書のキーです。このパラメーターは、insecure_skip_verify パラメーターが true に設定されている場合に限りオプションとなります。値を文字列として入力します。
    10
    cert_file_key パラメーターは、必須の、シークレット内のクライアント証明書のキーです。値を文字列として入力します。
    11
    key_file_key パラメーターは、必須の、シークレット内のクライアントキーのキーです。値を文字列として入力します。
    12
    insecure_skip_verify パラメーターは、オプションであり、ターゲット証明書の検証をスキップするために使用されます。値をブール値として入力します。

  2. エクスポートする外部エンドポイントのリストを追加するには、MultiClusterObservability カスタムリソースに writeStorage パラメーターを追加します。以下の例を参照してください。 

    spec:
  storageConfig:
    writeStorage:
    1 
    
    - key: ep.yaml
      name: victoriametrics
    Copy to Clipboard Toggle word wrap
    1
    各アイテムには、name と key の 2 つの属性が含まれています。Name は、エンドポイントアクセス情報を含む Kubernetes シークレットの名前であり、key はシークレット内のコンテンツのキーです。リストに複数のアイテムを追加すると、メトリクスは複数の外部エンドポイントにエクスポートされます。

  3. メトリクスのエクスポートが有効になった後、acm_remote_write_requests_total メトリクスを確認して、メトリクスのエクスポートのステータスを表示します。

    1. ハブクラスターの OpenShift Container Platform コンソールから、Observe セクションの Metrics をクリックして Metrics ページに移動します。
    2. 次に、acm_remote_write_requests_total メトリクスにクエリーを実行します。このメトリクスの値は、1 つの Observatorium API インスタンス上の 1 つの外部エンドポイントに対する特定のレスポンスを持つリクエストの合計数です。name ラベルは、外部エンドポイントの名前です。code ラベルは、メトリクスエクスポートの HTTP リクエストのリターンコードです。

1.5.2. ダッシュボードを使用したデータの表示および調査
リンクのコピー

ハブクラスターから Grafana にアクセスして、マネージドクラスターからデータを表示します。特定のアラートを照会して、そのクエリーのフィルターを追加できます。

たとえば、単一ノードの OpenShift クラスターから cluster_infrastructure_provider アラートを確認するには、cluster_infrastructure_provider{clusterType="SNO"} のクエリー式を使用します。

注記: シングルノードのマネージドクラスターで可観測性が有効になっている場合は、ObservabilitySpec.resources.CPU.limits パラメーターを設定しないでください。CPU 制限を設定すると、可観測性 Pod がマネージドクラスターの容量にカウントされます。追加リソース セクションの 管理ワークロードのパーティショニング を参照してください。

1.5.2.1. 履歴データの表示
リンクのコピー

履歴データをクエリーする場合は、クエリーパラメーターオプションを手動で設定して、ダッシュボードから表示されるデータの量を制御します。以下の手順を実行します。

  1. ハブクラスターから、コンソールヘッダーにある Grafana link を選択します。
  2. Edit Panel を選択して、クラスターダッシュボードを編集します。
  3. Grafana のクエリーフロントエンドデータソースから、Query タブをクリックします。
  4. $datasource を選択します。
  5. より多くのデータを表示する場合は、Step パラメーターセクションの値を増やします。Step パラメーターセクションが空の場合は、自動的に計算されます。
  6. Custom query parameters フィールドを見つけて、max_source_resolution=auto を選択します。
  7. データが表示されていることを確認するには、Grafana ページを更新します。

Grafana ダッシュボードからクエリーデータが表示されます。

1.5.2.2. Red Hat Advanced Cluster Management ダッシュボードの表示
リンクのコピー

Red Hat Advanced Cluster Management 可観測性サービスを有効にすると、3 つのダッシュボードが利用可能になります。次に示すダッシュボードの説明を確認してください。

  • Alert Analysis: マネージドクラスターフリート内で生成されているアラートの概要を示すダッシュボード。
  • Clusters by Alert: アラート名でフィルタリングできるアラートダッシュボード。
  • Alerts by Cluster: クラスターでフィルタリングし、クラスター環境内で発生したアラート、または保留中のアラートのリアルタイムデータを表示できるアラートダッシュボード。
1.5.2.3. etcd テーブルの表示
リンクのコピー

Grafana のハブクラスターダッシュボードから etcd テーブルを表示して、データストアとしての etcd の安定性を確認することもできます。ハブクラスターから Grafana リンクを選択して、ハブクラスターから収集された etcd テーブルデータを表示します。マネージドクラスターの Leader election changes が表示されます。

1.5.2.4. Kubernetes API サーバーダッシュボードの表示
リンクのコピー

過去 7 日間または 30 日間のターゲットとする サービスレベル目標 (SLO) 値を超過または達成しているクラスターの合計数、問題のあるクラスターと問題のないクラスター、および API サーバー要求期間を確認するには、次のオプションを使用して Kubernetes API サーバーダッシュボードを表示します。

  • Grafana のハブクラスターダッシュボードから、Kubernetes API サービスレベルの概要を表示します。

    1. Grafana ダッシュボードに移動します。
    2. Kubernetes > Service-Level Overview > API Server を選択して、管理ダッシュボードメニューにアクセスします。Fleet Overview および Top Cluster の詳細が表示されます。

  • Grafana のハブクラスターダッシュボードから Kubernetes API サービスレベルの概要テーブルを表示して、過去 7 日間または 30 日間のエラーバジェット、残りのダウンタイム、トレンドを確認します。

    1. ハブクラスターから Grafana ダッシュボードに移動します。
    2. Kubernetes > Service-Level Overview > API Server を選択して、管理ダッシュボードメニューにアクセスします。Fleet Overview および Top Cluster の詳細が表示されます。
1.5.2.5. OpenShift Virtualization ダッシュボードの表示
リンクのコピー

Red Hat OpenShift Virtualization ダッシュボードを表示すると、OpenShift Virtualization Operator がインストールされている各クラスターの包括的な分析情報を確認できます。アクティブな OpenShift Virtualization アラートと Hyperconverged Cluster Operator の状態によって決定される Operator の状態が表示されます。さらに、実行中の仮想マシンの数と各クラスターの Operator のバージョンも表示されます。

ダッシュボードには、Operator の健全性に影響を与えるアラートもリスト表示されます。また、Operator の健全性に影響を与えないアラートも含め、すべての OpenShift Virtualization アラートが別途表示されます。ダッシュボードは、クラスター名、Operator の健全性アラート、健全性へのアラートの影響、アラートの重大度でフィルタリングできます。

1.5.3. 関連情報
リンクのコピー

1.5.4. Grafana ダッシュボードの使用
リンクのコピー

Grafana ダッシュボードを使用して、ハブクラスターとマネージドクラスターのメトリクスを表示します。Grafana アラートダッシュボードに表示されるデータは、マネージドクラスターから発信される alerts メトリクスに依存します。alerts メトリクスは、ハブクラスター上の Red Hat Advanced Cluster Management アラートマネージャーにアラートを転送するマネージドクラスターには影響しません。したがって、メトリクスとアラートには異なる伝播メカニズムがあり、それぞれ別のコードパスに従います。

Grafana アラートダッシュボードにデータが表示されている場合でも、マネージドクラスターアラートが Red Hat Advanced Cluster Management ハブクラスターアラートマネージャーに正常に転送されているという保証はありません。メトリクスがマネージドクラスターから伝播されている場合は、Grafana アラートダッシュボードにデータが表示されます。

開発ニーズに合わせて Grafana ダッシュボードを使用するには、以下を実行します。

1.5.4.1. Grafana 開発者インスタンスの設定
リンクのコピー

grafana-dev インスタンスを作成して、Grafana ダッシュボードを設計できます。必ず最新の grafana-dev インスタンスを使用してください。

Grafana 開発者インスタンスを設定するには、以下の手順を実行します。

  1. open-cluster-management/multicluster-observability-operator/ リポジトリーのクローンを作成し、tools フォルダーにあるスクリプトを実行できるようにします。

  2. setup-grafana-dev.sh を実行して、Grafana インスタンスを設定します。スクリプトを実行すると、secret/grafana-dev-config、deployment.apps/grafana-dev、service/grafana-dev、ingress.extensions/grafana-dev、persistentvolumeclaim/grafana-dev のリソースが作成されます。 

    ./setup-grafana-dev.sh --deploy
secret/grafana-dev-config created
deployment.apps/grafana-dev created
service/grafana-dev created
serviceaccount/grafana-dev created
clusterrolebinding.rbac.authorization.k8s.io/open-cluster-management:grafana-crb-dev created
route.route.openshift.io/grafana-dev created
persistentvolumeclaim/grafana-dev created
oauthclient.oauth.openshift.io/grafana-proxy-client-dev created
deployment.apps/grafana-dev patched
service/grafana-dev patched
route.route.openshift.io/grafana-dev patched
oauthclient.oauth.openshift.io/grafana-proxy-client-dev patched
clusterrolebinding.rbac.authorization.k8s.io/open-cluster-management:grafana-crb-dev patched
    Copy to Clipboard Toggle word wrap

  3. switch-to-grafana-admin.sh スクリプトを使用して、ユーザーロールを Grafana 管理者に切り替えます。

    1. Grafana の URL https://grafana-dev-open-cluster-management-observability.{OPENSHIFT_INGRESS_DOMAIN} を選択し、ログインします。

    2. 次に、以下のコマンドを実行して、切り替えユーザーを Grafana 管理者として追加します。たとえば、kubeadmin を使用してログインしたら、以下のコマンドを実行します。 

      ./switch-to-grafana-admin.sh kube:admin
User <kube:admin> switched to be grafana admin
      Copy to Clipboard Toggle word wrap

Grafana 開発者インスタンを設定します。

1.5.4.1.1. Grafana のバージョン検証
リンクのコピー

コマンドラインインターフェイス (CLI) または Grafana ユーザーインターフェイスから Grafana のバージョンを検証します。

ハブクラスターにログインした後、observabilty-grafana Pod ターミナルにアクセスします。以下のコマンドを実行します。 

grafana-cli
Copy to Clipboard Toggle word wrap

現在クラスター環境内にデプロイされている Grafana のバージョンが表示されます。

Grafana ダッシュボードの Manage タブに移動することもできます。ページの最後までスクロールすると、バージョンリストがあります。

1.5.4.2. Grafana ダッシュボードの設計
リンクのコピー

Grafana インスタンスを設定したら、ダッシュボードを設計できます。Grafana コンソールを更新し、ダッシュボードを設計するには、以下の手順を実行します。

  1. Grafana コンソールのナビゲーションパネルから Create アイコンを選択してダッシュボードを作成します。Dashboard を選択し、Add new panel をクリックします。
  2. New Dashboard/Edit Panel ビューで、Query タブを選択します。
  3. データソースセレクターから Observatorium を選択し、PromQL クエリーを入力してクエリーを設定します。
  4. Grafana ダッシュボードヘッダーから、ダッシュボードヘッダーにある Save アイコンをクリックします。
  5. 説明的な名前を追加し、Save をクリックします。
1.5.4.2.1. ConfigMap での Grafana ダッシュボードの設計
リンクのコピー

ConfigMap を使用して、Grafana ダッシュボードを設計します。generate-dashboard-configmap-yaml.sh スクリプトを使用してダッシュボードの ConfigMap を生成し、ローカルで ConfigMap を保存できます。 

./generate-dashboard-configmap-yaml.sh "Your Dashboard Name"
Save dashboard <your-dashboard-name> to ./your-dashboard-name.yaml
Copy to Clipboard Toggle word wrap

前述のスクリプトを実行するパーミッションがない場合は、以下の手順を実行します。

  1. ダッシュボードを選択し、Dashboard 設定 アイコンをクリックします。
  2. ナビゲーションパネルから JSON Model アイコンをクリックします。
  3. ダッシュボード JSON データをコピーし、data セクションに貼り付けます。

  4. name を、$your-dashboard-name に置き換えます。data.$your-dashboard-name.json.$$your_dashboard_json の uid フィールドに Universally Unique Identifier (UUID) を入力します。uuidegen などのプログラムを使用して UUID を作成できます。ConfigMap は、以下のファイルのようになります。 

    kind: ConfigMap
apiVersion: v1
metadata:
  name: $your-dashboard-name
  namespace: open-cluster-management-observability
  labels:
    grafana-custom-dashboard: "true"
data:
  $your-dashboard-name.json: |-
    $your_dashboard_json
    Copy to Clipboard Toggle word wrap

    注記:

    • ダッシュボードが grafana-dev インスタンス内に作成されている場合は、ダッシュボードの名前を取得して、スクリプトで引数として渡すことができます。たとえば、Demo Dashboard という名前のダッシュボードが grafana-dev インスタンスに作成されます。CLI から、次のスクリプトを実行できます。 

      ./generate-dashboard-configmap-yaml.sh "Demo Dashboard"
      Copy to Clipboard Toggle word wrap

      スクリプトを実行すると、次のメッセージが表示される場合があります。 

      Save dashboard <demo-dashboard> to ./demo-dashboard.yaml
      Copy to Clipboard Toggle word wrap

    • ダッシュボードが General フォルダーにない場合は、この ConfigMap の annotations セクションでフォルダー名を指定できます。 

      annotations:
  observability.open-cluster-management.io/dashboard-folder: Custom
      Copy to Clipboard Toggle word wrap

      ConfigMap の更新が完了したら、インストールしてダッシュボードを Grafana インスタンスにインポートできます。

CLI または OpenShift Container Platform コンソールから YAML を適用して、YAML ファイルが作成されていることを確認します。open-cluster-management-observability namespace 内に ConfigMap が作成されます。CLI から次のコマンドを実行します。 

oc apply -f demo-dashboard.yaml
Copy to Clipboard Toggle word wrap

OpenShift Container Platform コンソールから、demo-dashboard.yaml ファイルを使用して、ConfigMap を作成します。ダッシュボードは Custom フォルダーにあります。

1.5.4.3. Grafana 開発者インスタンスのアンインストール
リンクのコピー

インスタンスをアンインストールすると、関連するリソースも削除されます。以下のコマンドを実行します。 

./setup-grafana-dev.sh --clean
secret "grafana-dev-config" deleted
deployment.apps "grafana-dev" deleted
serviceaccount "grafana-dev" deleted
route.route.openshift.io "grafana-dev" deleted
persistentvolumeclaim "grafana-dev" deleted
oauthclient.oauth.openshift.io "grafana-proxy-client-dev" deleted
clusterrolebinding.rbac.authorization.k8s.io "open-cluster-management:grafana-crb-dev" deleted
Copy to Clipboard Toggle word wrap
1.5.4.4. 関連情報
リンクのコピー

1.5.5. Grafana でマネージドクラスターラベルを使用する
リンクのコピー

マネージドクラスターラベルを有効にして、Grafana ダッシュボードで使用できるようにします。ハブクラスターで可観測性が有効になっている場合は、observability-managed-cluster-label-allowlist ConfigMap が open-cluster-management-observability namespace に作成されます。ConfigMap には、observabilty-rbac-query-proxy Pod によって維持されるマネージドクラスターラベルのリストが含まれており、ACM - Cluster Overview Grafana ダッシュボード内からフィルタリングするラベル名のリストを入力します。デフォルトでは、可観測性は observability-managed-cluster-label-allowlist ConfigMap のラベルのサブセットを無視します。

クラスターがマネージドクラスターフリートにインポートされるか、変更されると、observability-rbac-query-proxy Pod は、マネージドクラスターラベルを参照して変更を監視し、observability-managed-cluster-label-allowlist ConfigMap を自動的に更新して、変更を反映させます。ConfigMap には、ignore_labels または labels リストに含まれる一意のラベル名のみが含まれます。observability-managed-cluster-label-allowlist ConfigMap は次の YAML ファイルのようになる場合があります。 

data:
  managed_cluster.yaml: |
    ignore_labels:
1 

      - clusterID
      - cluster.open-cluster-management.io/clusterset
      - feature.open-cluster-management.io/addon-application-manager
      - feature.open-cluster-management.io/addon-cert-policy-controller
      - feature.open-cluster-management.io/addon-cluster-proxy
      - feature.open-cluster-management.io/addon-config-policy-controller
      - feature.open-cluster-management.io/addon-governance-policy-framework
      - feature.open-cluster-management.io/addon-iam-policy-controller
      - feature.open-cluster-management.io/addon-observability-controller
      - feature.open-cluster-management.io/addon-search-collector
      - feature.open-cluster-management.io/addon-work-manager
      - installer.name
      - installer.namespace
      - local-cluster
      - name
    labels:
2 

      - cloud
      - vendor
Copy to Clipboard Toggle word wrap

+ <1> ConfigMap の ignore_labels キーリストにリストされているラベルはすべて、ACM - Clusters Overview Grafana ダッシュボードのドロップダウンフィルターから削除されます。<2> 有効になっているラベルは ACM - Clusters Overview Grafana ダッシュボードのドロップダウンフィルターに表示されます。値は、選択した label キー値に応じて、acm_managed_cluster_labels メトリクスから取得されます。

引き続き Grafana でのマネージドクラスターラベルの使用方法を確認してください。

1.5.5.1. マネージドクラスターラベルの追加
リンクのコピー

マネージドクラスターラベルを observability-managed-cluster-label-allowlist ConfigMap に追加すると、そのラベルは Grafana のフィルターオプションとして使用できるようになります。ハブクラスター、またはマネージドクラスターフリートに関連付けられているマネージドクラスターオブジェクトに一意のラベルを追加します。たとえば、ラベル department=finance をマネージドクラスターに追加すると、ConfigMap が更新され、次のように変更されます。 

data:
  managed_cluster.yaml: |
    ignore_labels:
      - clusterID
      - cluster.open-cluster-management.io/clusterset
      - feature.open-cluster-management.io/addon-application-manager
      - feature.open-cluster-management.io/addon-cert-policy-controller
      - feature.open-cluster-management.io/addon-cluster-proxy
      - feature.open-cluster-management.io/addon-config-policy-controller
      - feature.open-cluster-management.io/addon-governance-policy-framework
      - feature.open-cluster-management.io/addon-iam-policy-controller
      - feature.open-cluster-management.io/addon-observability-controller
      - feature.open-cluster-management.io/addon-search-collector
      - feature.open-cluster-management.io/addon-work-manager
      - installer.name
      - installer.namespace
      - local-cluster
      - name
    labels:
      - cloud
      - department
      - vendor
Copy to Clipboard Toggle word wrap
1.5.5.2. マネージドクラスターラベルの有効化
リンクのコピー

observability-managed-cluster-label-allowlist ConfigMap の ignore_labels リストからラベルを削除して、すでに無効になっているマネージドクラスターラベルを有効にします。

たとえば、local-cluster および name ラベルを有効にします。observability-managed-cluster-label-allowlist ConfigMap は、次の内容のようになる場合があります。 

data:
  managed_cluster.yaml: |
    ignore_labels:
      - clusterID
      - installer.name
      - installer.namespace
    labels:
      - cloud
      - vendor
      - local-cluster
      - name
Copy to Clipboard Toggle word wrap

クラスターラベルが確実に更新されるように、ConfigMap は 30 秒後に再同期します。ConfigMap を更新した後、open-cluster-management-observability namespace の observability-rbac-query-proxy Pod ログをチェックして、ラベルがリストされている場所を確認します。次の情報が Pod ログに表示される場合があります。 

enabled managedcluster labels: <label>
Copy to Clipboard Toggle word wrap

Grafana ダッシュボードから、ラベルが Label ドロップダウンメニューの値としてリストされていることを確認します。

1.5.5.3. マネージドクラスターラベルの無効化
リンクのコピー

Label ドロップダウンフィルターのリストからマネージドクラスターラベルを除外します。ラベル名を ignore_labels リストに追加します。たとえば、local-cluster と name を ignore_labels リストに戻すと、YAML は次のファイルのようになります。 

data:
  managed_cluster.yaml: |
    ignore_labels:
      - clusterID
      - installer.name
      - installer.namespace
      - local-cluster
      - name
    labels:
      - cloud
      - vendor
Copy to Clipboard Toggle word wrap

open-cluster-management-observability namespace の observability-rbac-query-proxy Pod ログをチェックして、ラベルがどこにリストされているかを確認します。次の情報が Pod ログに表示される場合があります。 

disabled managedcluster label: <label>
Copy to Clipboard Toggle word wrap
1.5.5.4. 関連情報
リンクのコピー

1.6. アラートの管理
リンクのコピー

ハブクラスターとマネージドクラスターの変更が通知されるように、可観測性サービスのアラートを受信および定義します。

1.6.1. 前提条件
リンクのコピー

  • ハブクラスターで可観測性を有効化する。
  • open-cluster-management-observability namespace 内のシークレットリソースに対する作成権限がある。
  • MultiClusterObservability リソースに対する編集権限がある。

1.6.2. Alertmanager の設定
リンクのコピー

メール、Slack、PagerDuty などの外部メッセージングツールを統合し、Alertmanager から通知を受信します。open-cluster-management-observability namespace で alertmanager-config シークレットを上書きして、統合を追加し、Alertmanager のルートを設定します。以下の手順を実行して、カスタムのレシーバールールを更新します。

  1. alertmanager-config シークレットからデータを抽出します。以下のコマンドを実行します。 

    oc -n open-cluster-management-observability get secret alertmanager-config --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml
    Copy to Clipboard Toggle word wrap

  2. 以下のコマンドを実行し、alertmanager.yaml ファイル設定を編集して保存します。 

    oc -n open-cluster-management-observability create secret generic alertmanager-config --from-file=alertmanager.yaml --dry-run -o=yaml |  oc -n open-cluster-management-observability replace secret --filename=-
    Copy to Clipboard Toggle word wrap

    更新したシークレットは以下の内容のようになります。 

    global
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@example.org'
  smtp_auth_username: 'alertmanager'
  smtp_auth_password: 'password'
templates:
- '/etc/alertmanager/template/*.tmpl'
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: team-X-mails
  routes:
  - match_re:
      service: ^(foo1|foo2|baz)$
    receiver: team-X-mails
    Copy to Clipboard Toggle word wrap

変更内容は、変更後すぐに適用されます。Alertmanager の例は、prometheus/alertmanager を参照してください。

1.6.2.1. Alertmanager Pod 内でのシークレットのマウント
リンクのコピー

任意のコンテンツを含む Secret リソースを作成して、そのリソースを alertmanager Pod 内にマウントして認可認証情報にアクセスすることができます。

Alertmanager 設定内のシークレットを参照するには、open-cluster-management-observability namespace 内に Secret リソースコンテンツを追加し、alertmanager Pod 内にコンテンツをマウントします。たとえば、TLS シークレットを作成してマウントするには、次の手順を実行します。

  1. TLS 証明書を使用して TLS シークレットを作成するには、次のコマンドを実行します。 

    oc create secret tls tls --cert=</path/to/cert.crt> --key=</path/to/cert.key> -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap

  2. tls シークレットを MultiClusterObservability リソースにマウントするには、それを advanced セクションに追加します。リソースは以下の内容のようになります。 

    ...
advanced:
 alertmanager:
   secrets: ['tls']
    Copy to Clipboard Toggle word wrap

  3. Alertmanager 設定内に tls シークレットの参照を追加するには、シークレットのパスを設定に追加します。リソースは、以下の設定のようになります。 

    tls_config:
 cert_file: '/etc/alertmanager/secrets/tls/tls.crt'
 key_file: '/etc/alertmanager/secrets/tls/tls.key'
    Copy to Clipboard Toggle word wrap

  4. シークレットが alertmanager Pod 内にあることを確認するには、次のコマンドを実行します。 

    oc -n open-cluster-management-observability get secret alertmanager-config --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml
    Copy to Clipboard Toggle word wrap

    YAML の内容は次のようになります。 

    "global":
  "http_config":
    "tls_config":
      "cert_file": "/etc/alertmanager/secrets/storyverify/tls.crt"
      "key_file": "/etc/alertmanager/secrets/storyverify/tls.key"
    Copy to Clipboard Toggle word wrap

  5. alertmanager.yaml 設定を alertmanager-config シークレットに保存するには、以下のコマンドを実行します。 

    oc -n open-cluster-management-observability create secret generic alertmanager-config --from-file=alertmanager.yaml --dry-run -o=yaml
    Copy to Clipboard Toggle word wrap

  6. 以前のシークレットを新しいシークレットに置き換えるには、次のコマンドを実行します。 

    oc -n open-cluster-management-observability replace secret --filename=-
    Copy to Clipboard Toggle word wrap

1.6.3. アラートの転送
リンクのコピー

可観測性を有効にした後には、OpenShift Container Platform マネージドクラスターからのアラートは自動的にハブクラスターに送信されます。alertmanager-config YAML ファイルを使用して、外部通知システムでアラートを設定できます。

alertmanager-config YAML ファイルの例を以下に示します。 

global:
  slack_api_url: '<slack_webhook_url>'

route:
  receiver: 'slack-notifications'
  group_by: [alertname, datacenter, app]

receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alerts'
    text: 'https://internal.myorg.net/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}'
Copy to Clipboard Toggle word wrap

アラート転送用のプロキシーを設定する場合は、alertmanager-config YAML ファイルに次の global エントリーを追加します。 

global:
  slack_api_url: '<slack_webhook_url>'
  http_config:
    proxy_url: http://****
Copy to Clipboard Toggle word wrap
1.6.3.1. マネージドクラスターのアラート転送の無効化
リンクのコピー

マネージドクラスターのアラート転送を無効にするには、次のアノテーションを MultiClusterObservability カスタムリソースに追加します。 

metadata:
      annotations:
        mco-disable-alerting: "true"
Copy to Clipboard Toggle word wrap

アノテーションを設定すると、マネージドクラスターのアラート転送設定が元に戻ります。openshift-monitoring namespace の ocp-monitoring-config config map に加えられた変更も元に戻ります。アノテーションを設定すると、ocp-monitoring-config config map が可観測性 Operator のエンドポイントによって管理または更新されなくなります。設定を更新すると、マネージドクラスターの Prometheus インスタンスが再起動します。

重要: メトリクス用の永続ボリュームを持つ Prometheus インスタンスがある場合、マネージドクラスターのメトリクスは失われ、Prometheus インスタンスが再起動されます。ハブクラスターからのメトリクスは影響を受けません。

変更が元に戻ると、cluster-monitoring-reverted という名前の ConfigMap が open-cluster-management-addon-observability namespace に作成されます。手動で追加された新しいアラート転送設定は、ConfigMap から元に戻りません。

ハブクラスターアラートマネージャーがマネージドクラスターアラートをサードパーティーのメッセージングツールに伝達していないことを確認します。前のセクション Alertmanager の設定 を参照してください。

1.6.4. アラートをサイレントにする
リンクのコピー

受信したくないアラートを追加します。アラート名、一致ラベル、または期間によってアラートをサイレントにすることができます。サイレントにしたいアラートを追加すると、ID が作成されます。サイレントにしたアラートの ID は、文字列 d839aca9-ed46-40be-84c4-dca8773671da のようになります。

アラートをサイレントにする方法は、引き続きお読みください。

  • Red Hat Advanced Cluster Management アラートをオフにするには、open-cluster-management-observability namespace の alertmanager Pod にアクセスできる必要があります。たとえば、SampleAlert をオフにするには、observability-alertmanager-0 Pod ターミナルで次のコマンドを実行します。 

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" alertname="SampleAlert"
    Copy to Clipboard Toggle word wrap

  • 複数の一致ラベルを使用してアラートをサイレントにします。次のコマンドは match-label-1 と match-label-2 を使用します。 

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" <match-label-1>=<match-value-1> <match-label-2>=<match-value-2>
    Copy to Clipboard Toggle word wrap

  • 特定の期間アラートをサイレントにする場合は、--duration フラグを使用します。次のコマンドを実行して、SampleAlert を 1 時間サイレントにします。 

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" --duration="1h" alertname="SampleAlert"
    Copy to Clipboard Toggle word wrap

    消音アラートの開始時刻または終了時刻を指定することもできます。次のコマンドを入力して、特定の開始時刻に SampleAlert をサイレントにします。 

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" --start="2023-04-14T15:04:05-07:00" alertname="SampleAlert"
    Copy to Clipboard Toggle word wrap

  • 作成されたサイレント化されたアラートをすべて表示するには、次のコマンドを実行します。 

    amtool silence --alertmanager.url="http://localhost:9093"
    Copy to Clipboard Toggle word wrap

  • アラートをサイレントにしたくない場合は、次のコマンドを実行してアラートのサイレントを終了します。 

    amtool silence expire --alertmanager.url="http://localhost:9093" "d839aca9-ed46-40be-84c4-dca8773671da"
    Copy to Clipboard Toggle word wrap

  • すべてのアラートをサイレントにするのを終了するには、次のコマンドを実行します。 

    amtool silence expire --alertmanager.url="http://localhost:9093" $(amtool silence query --alertmanager.url="http://localhost:9093" -q)
    Copy to Clipboard Toggle word wrap
1.6.4.1. 可観測性ストレージの移行
リンクのコピー

アラートサイレンサーを使用する場合は、サイレンサーを以前の状態のまま保持しながら、可観測性ストレージを移行できます。これを行うには、選択した StorageClass リソースを使用する新しい StatefulSets および PersistentVolumes (PV) リソースを作成して、Red Hat Advanced Cluster Management の可観測性ストレージを移行します。

注記: PV のストレージは、クラスターから収集されたメトリクスを保存するために使用されるオブジェクトストレージとは異なります。

StatefulSet と PV を使用して可観測性データを新しいストレージに移行すると、次のデータコンポーネントが保存されます。

  • Observatorium または Thanos: データを受信してオブジェクトストレージにアップロードします。一部のコンポーネントは PV にデータを保存します。このデータは、Observatorium または Thanos が起動時にオブジェクトストレージを自動的に再生成するため、このデータを失っても影響はありません。
  • Alertmanager: サイレント化されたアラートのみを保存します。これらのサイレントアラートを保持する場合は、そのデータを新しい PV に移行する必要があります。

可観測性ストレージを移行するには、次の手順を実行します。

  1. MultiClusterObservability で、.spec.storageConfig.storageClass フィールドを新しいストレージクラスに設定します。
  2. PersistentVolumeClaim を削除しても以前の PersistentVolumes のデータが保持されるようにするために、既存のすべての PersistentVolumes に移動します。
  3. reclaimPolicy を "Retain": `oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' に変更します。
  4. オプション: データの損失を回避するには、Migrate persistent data to another Storage Class in DG 8 Operator in OCP 4 を参照してください。

  5. 次の StatefulSet の場合、StatefulSet と PersistentVolumeClaim の両方を削除します。

    1. alertmanager-db-observability-alertmanager-<REPLICA_NUMBER>
    2. data-observability-thanos-<COMPONENT_NAME>
    3. data-observability-thanos-receive-default
    4. data-observability-thanos-store-shard
    5. 重要: 新しい StatefulSet を作成するには、MultiClusterObservability Operator Pod を削除してから再作成する必要がある場合があります。
  6. 同じ名前で正しい StorageClass を使用して新しい PersistentVolumeClaim を再作成します。
  7. 古い PersistentVolume を参照する新しい PersistentVolumeClaim を作成します。
  8. 新しい StatefulSet と PersistentVolumes が、選択した新しい StorageClass を使用していることを確認します。

1.6.5. アラートの抑制
リンクのコピー

重大度の低い Red Hat Advanced Cluster Management アラートをクラスター全体でグローバルに抑制します。アラートを抑制するには、open-cluster-management-observability namespace の alertmanager-config で抑制ルールを定義します。

抑制ルールは、既存のマッチャーの別のセットと一致する一連のパラメーター一致がある場合にアラートをミュートします。ルールを有効にするには、ターゲットアラートとソースアラートの両方で、equal リスト内のラベル名のラベル値が同じである必要があります。inhibit_rules は次のようになります。 

global:
  resolve_timeout: 1h
inhibit_rules:
1 

  - equal:
      - namespace
    source_match:
2 

      severity: critical
    target_match_re:
      severity: warning|info
Copy to Clipboard Toggle word wrap
1 1
inhibit_rules パラメーターセクションは、同じ namespace のアラートを検索するために定義されています。critical アラートがネームスペース内で開始し、その namespace に重大度レベルの warning または info を含む他のアラートがある場合は、critical アラートのみが Alertmanager レシーバーにルーティングされます。一致するものがあった場合、次のアラートが表示される場合があります。 
ALERTS{alertname="foo", namespace="ns-1", severity="critical"}
ALERTS{alertname="foo", namespace="ns-1", severity="warning"}
Copy to Clipboard Toggle word wrap
2 2
source_match パラメーターと target_match_re パラメーターの値が一致しない場合、アラートはレシーバーにルーティングされます。 
ALERTS{alertname="foo", namespace="ns-1", severity="critical"}
ALERTS{alertname="foo", namespace="ns-2", severity="warning"}
Copy to Clipboard Toggle word wrap
  • Red Hat Advanced Cluster Management で抑制されたアラートを表示するには、次のコマンドを入力します。 
amtool alert --alertmanager.url="http://localhost:9093" --inhibited
Copy to Clipboard Toggle word wrap

1.6.6. 関連情報
リンクのコピー

第2章 Red Hat Insights での可観測性の使用
リンクのコピー

Red Hat Insights は、Red Hat Advanced Cluster Management 可観測性と統合されており、クラスター内の既存の問題や発生しうる問題を特定できるように有効化されています。Red Hat Insights は、安定性、パフォーマンス、ネットワーク、およびセキュリティーリスクの特定、優先順位付け、および解決に役立ちます。Red Hat OpenShift Container Platform は、OpenShift Cluster Manager を使用してクラスターのヘルスモニタリングを提供します。OpenShift Cluster Manager は、クラスターのヘルス、使用状況、サイズの情報を匿名で累積して収集します。詳細は、Red Hat Insights の製品ドキュメント を参照してください。

OpenShift クラスターを作成またはインポートすると、マネージドクラスターからの匿名データは自動的に Red Hat に送信されます。この情報を使用してクラスターのヘルス情報を提供する insights を作成します。Red Hat Advanced Cluster Management 管理者は、このヘルス情報を使用して重大度に基づいてアラートを作成できます。

必要なアクセス権限: クラスターの管理者

2.1. 前提条件
リンクのコピー

2.2. Insight PolicyReports の管理
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes PolicyReports は、insights-client で生成される違反です。PolicyReports は、インシデント管理システムに送信されるアラートの定義および設定に使用されます。違反がある場合には、PolicyReport からのアラートはインシデント管理システムに送信されます。

2.2.1. Insight ポリシーレポートの検索
リンクのコピー

マネージドクラスター全体で、違反した特定の insight PolicyReport を検索できます。以下の手順を実行します。

  1. Red Hat Advanced Cluster Management ハブクラスターにログインします。
  2. ナビゲーションメニューから Search を選択します。

  3. kind:PolicyReport のクエリーを入力します。

    注記: PolicyReport 名はクラスターの名前と同じになります。

  4. インサイトポリシー違反とカテゴリーを使用してクエリーを指定できます。PolicyReport 名を選択すると、関連付けられたクラスターの Details ページにリダイレクトされます。Insights サイドバーが自動的に表示されます。

  5. 検索サービスが無効になり、insight を検索する必要がある場合は、ハブクラスターから以下のコマンドを実行します。 

    oc get policyreport --all-namespaces
    Copy to Clipboard Toggle word wrap

2.2.2. コンソールから特定された問題の表示
リンクのコピー

特定のクラスターで特定された問題を表示できます。以下の手順を実行します。

  1. Red Hat Advanced Cluster Management クラスターにログインします。
  2. ナビゲーションメニューから Overview を選択します。
  3. Cluster issues の概要カードを確認してください。重大度リンクを選択すると、その重大度に関連付けられている PolicyReports が表示されます。クラスターの問題の詳細と重大度は、Search ページに表示されます。重大度に関連付けられており、1 つ以上の問題があるポリシーレポートが表示されます。
  4. ポリシーレポートを選択して、Cluster ページからクラスターの詳細を表示します。Status カードには、ノード、アプリケーション、ポリシー違反 および 特定された問題 に関する情報が表示されます。

  5. 詳細を表示するには、特定された問題の数 を選択します。Identified issues カードは、Red Hat Insights からの情報を表します。Identified issues のステータスには、重大度による問題数が表示されます。問題の対応レベルは、Critical、Major、Low、および Warning の重大度に分類されます。

    1. または、ナビゲーションメニューから Clusters を選択できます。
    2. テーブルからマネージドクラスターを選択して、詳細情報を表示します。
    3. Status カードから、特定された問題の数を表示します。
  6. 発生する可能性のある問題数を選択して、Potential issue サイドパネルから、重大度チャートと、その問題に対して推奨される修復を表示します。検索機能を使用して、推奨される修復を検索することもできます。修復オプションは、脆弱性の 説明、脆弱性に関連する カテゴリー、および 全体的なリスク を表示します。

  7. 脆弱性へのリンクをクリックすると、修復する方法 と脆弱性の 理由 の手順を表示します。

    注記: 問題を解決すると、Red Hat Insights が 30 分ごとに受信され、Red Hat Insights は 2 時間ごとに更新されます。

  8. PolicyReport からアラートメッセージを送信したコンポーネントを確認してください。

    1. Governance ページに移動し、特定の PolicyReport を選択します。
    2. Status タブを選択し、View details リンクをクリックして PolicyReport YAML ファイルを表示します。
    3. source パラメーターを見つけます。このパラメーターにより、違反を送信したコンポーーネントが通知されます。値オプションは grc および insights です。

2.2.3. 更新リスク予測の表示
リンクのコピー

マネージドクラスターを更新する際の潜在的なリスクを表示します。以下の手順を実行します。

  1. ターゲットのマネージドクラスターにログインします。
  2. Overview ページに移動します。
  3. Powered by Insights セクションでは、重大度別にリストされた、予測リスクのあるクラスターの割合を表示できます。
  4. 重大度の番号を選択すると、Clusters ページからクラスターのリストが表示されます。
  5. 必要なクラスターを選択し、Actions ドロップダウンボタンをクリックします。
  6. アップグレードのリスクを表示するには、クラスターのアップグレード をクリックします。
  7. クラスターのアップグレード モーダルから、アップグレードリスク の列を見つけて、リスクの数のリンクをクリックすると、Hybrid Cloud Console で情報が表示されます。

2.3. 関連情報
リンクのコピー

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat