Observability

オブザーバビリティーサービスは、コミュニティーからのオープンソースのオブザーバビリティーツールを使用します。製品オブザーバビリティーサービスに含まれるツールの説明を以下に示します。

Oberservability が Red Hat Advanced Cluster Management for Kubernetes 2.16 で使用するコンポーネントバージョンは、次のリストを参照してください。

次の図は、オブザーバビリティーのコンポーネントを示しています。

オブザーバビリティーアーキテクチャーのコンポーネントには次の項目が含まれます。

重要: 永続ストレージにローカルボリュームを使用するローカルストレージ Operator またはストレージクラスを使用しないでください。再起動後に Pod が別のノードで再起動されると、データが失われる可能性があります。これが発生すると、Pod はノード上のローカルストレージにアクセスできなくなります。データの損失を回避するために、receive Pod および rules 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 が必要です。次の表を参照します。

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

オブザーバビリティーとインテグレーションコンポーネントの詳細は、次のトピックを参照してください。

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

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

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

oc -n open-cluster-management-observability get cm observability-metrics-allowlist -o yaml

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

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

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

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

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

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

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

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

      - node_memory_MemTotal_bytes
    recording_rules: 

      - 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))

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

      - node_memory_MemTotal_bytes
        recording_rules: 

      - 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))

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

data:
  uwl_metrics_list.yaml:
    names:
      - <sample_metrics> 

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!=""

collect_rules:
  - group: -SNOResourceUsage

大規模なデプロイメントでのパフォーマンスを向上させるには、複数のワーカーで並行してメトリクスを収集するように metrics-collector を設定できます。デフォルト設定では、単一のワーカーを使用してメトリクスをフェデレートします。メトリクス収集プロセスのワーカー数を増やすと、内部ワーカーが、マネージドクラスター上の Prometheus に対するエンドポイントリクエストを、シャーディング /federate できるようになります。

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

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

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

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

オブザーバビリティーリソースに、Prometheus レコードルール および アラートルール を追加して、オブザーバビリティーインストールのカスタムルールを作成します。

計算コストの高い式を事前計算するには、Prometheus の記録ルール機能を使用してアラート条件を作成し、外部サービスにアラートを送信する方法に基づいて通知を送信します。結果は新たな時系列のセットとして保存されます。

thanos-ruler-custom-rules config map 内にカスタムアラートルールを作成するには、次の手順を実行します。

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

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

spec:
   advanced:
      receive:
         replicas: 6

mco observability カスタムリソース内のパラメーターの詳細は、オブザーバビリティー API ドキュメントを参照してください。

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

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

spec:
  advanced:
    customObservabilityHubURL: <yourURL>
    customAlertmanagerHubURL: <yourURL>

注記:

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

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

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

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

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

粒度の細かい RBAC を使用してユーザーグループのアクセスを制限するには、次の手順を実行します。

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

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

MultiClusterObservability カスタムリソースを作成してオブザーバビリティーサービスを有効にします。オブザーバビリティーを有効にする前に、オブザーバビリティー Pod の容量要求 を参照してください。

注記:

オブザーバビリティーサービスを有効にするには、以下の手順を実行します。

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

thanos --version

オブザーバビリティーを無効にして、Red Hat Advanced Cluster Management ハブクラスターでデータ収集を停止します。

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

    enableMetrics: false 

  workers: 1

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

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

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

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

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

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

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

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

grafana-cli

./generate-dashboard-configmap-yaml.sh "Your Dashboard Name"
Save dashboard <your-dashboard-name> to ./your-dashboard-name.yaml

oc apply -f demo-dashboard.yaml

./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

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: 

      - 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-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
      - vendor

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

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

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-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

data:
  managed_cluster.yaml: |
    ignore_labels:
      - clusterID
      - installer.name
      - installer.namespace
    labels:
      - cloud
      - vendor
      - local-cluster
      - name

enabled managedcluster labels: <label>

data:
  managed_cluster.yaml: |
    ignore_labels:
      - clusterID
      - installer.name
      - installer.namespace
      - local-cluster
      - name
    labels:
      - cloud
      - vendor

disabled managedcluster label: <label>

アラートを管理するには、次の認証情報を持ち、次のアクションを完了する必要があります。

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

シークレットを変更すると、変更はただちに適用されます。Alertmanager の例は、prometheus/alertmanager を参照してください。

Kubernetes Secret リソースを通じて認証情報をセキュアかつ管理可能な状態に保つことで、Alertmanager から Slack、メール、PagerDuty などのサードパーティーのエンドポイントへのセキュアな外部通信を有効にします。認可認証情報にアクセスするには、alertmanager Pod 内にマウントできる任意のコンテンツを含む Secret リソースを作成できます。

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

オブザーバビリティーを有効にすると、OpenShift Container Platform マネージドクラスターからのアラートは、ハブクラスターの Alertmanager に自動的に送信されます。デフォルトでは、すべてのプラットフォームアラートがハブクラスターの Alertmanager に送信されます。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 }}'

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

global:
  slack_api_url: '<slack_webhook_url>'
  http_config:
    proxy_url: http://****

ユーザーワークロードアラートを転送する場合、アラートは Thanos ルーラーではなく、ユーザーワークロード Prometheus インスタンスによって処理される必要があります。PrometheusRule リソースの次の例を参照してください。

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus

マネージドクラスターのアラート転送を無効にするには、MultiClusterObservability カスタムリソースに mco-disable-alerting: "true" アノテーションを追加します。mco-disable-alerting: "true" アノテーションを設定すると、プラットフォームおよびユーザーワークロードアラートは、いずれもハブクラスターの Alertmanager に転送されません。マネージドクラスターの転送設定は元に戻ります。

openshift-monitoring namespace の cluster-monitoring-config config map への設定の更新が元に戻されます。アノテーションを設定すると、cluster-monitoring-config config map が observability operator エンドポイントによって管理または更新されなくなります。設定を更新すると、マネージドクラスター上のプラットフォームおよびユーザーワークロードの Prometheus インスタンスが両方とも再起動します。以下の手順を実行します。

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

マネージドクラスターのユーザーワークロードアラート転送を無効にするには、MultiClusterObservability カスタムリソースに mco-disable-uwl-alerting: "true" アノテーションを追加します。アノテーションを設定すると、ハブクラスター上の Alertmanager へのユーザーワークロードアラートの転送は停止し、プラットフォームアラートは引き続き Alertmanager に転送されます。

アノテーションを設定すると、user-workload-monitoring-config config map は Observability Operator エンドポイントによって管理または更新されなくなります。設定を更新すると、マネージドクラスター上のユーザーワークロード Prometheus インスタンスが再起動されます。

次のコマンドを実行して、mco-disable-uwl-alerting アノテーションを "true" に設定します。

oc annotate MultiClusterObservability observability mco-disable-uwl-alerting=true

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

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

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

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

StatefulSets と PV を使用してオブザーバビリティーデータを新しいストレージに移行すると、次のデータコンポーネントが保存されます。

オブザーバビリティーストレージを移行するには、次の手順を実行します。

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

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

global:
  resolve_timeout: 1h
inhibit_rules:

  - equal:
      - namespace
    source_match:

      severity: critical
    target_match_re:
      severity: warning|info

RightSizingRecommendation を実装すると、設定したリソース設定とリアルタイムの CPU およびメモリー使用量との比較を表示できます。オブザーバビリティーサービスを有効にすると、namespace の RightSizingRecommendation 機能がデフォルトで有効になります。ハブクラスター上の MultiClusterObservability カスタムリソースを編集することで、この機能を無効にできます。

RightSizingRecommendation 機能は、以下のリソースを使用します。

必要なアクセス権限: 編集

RightSizingRecommendation をカスタマイズして、namespace の CPU およびメモリーリソースを最適化します。rs-namespace-config ConfigMap リソースを編集します。

必要なアクセス権限: 編集

以下の手順を実行します。

仮想化に RightSizingRecommendation を使用すると、マネージドクラスター全体で過剰にプロビジョニングされている、または十分に活用されていない仮想マシンリソースを特定できます。オブザーバビリティーサービスを有効にすると、RightSizingRecommendation 機能がデフォルトで有効になります。ハブクラスター上の MultiClusterObservability カスタムリソースを編集することで、この機能を無効にできます。

RightSizingRecommendation 機能は、以下のリソースを使用します。

必要なアクセス権限: 編集

RightSizingRecommendation 仕様をカスタマイズすることで、仮想マシンの CPU およびメモリーリソースを最適化できます。MultiClusterObservability リソースを編集します。

マネージドクラスター監視ワークロードは、Cluster Observability Operator の Prometheus Operator と Prometheus Agent を使用します。マルチクラスターオブザーバビリティーアドオンは、マネージドクラスター上の Red Hat OpenShift Cluster Observabililty Operator に含まれる既存の obo-prometheus-operator を使用して、Prometheus カスタムリソースを調整します。obo-prometheus-operator が存在しない場合、マルチクラスターオブザーバビリティーアドオンは、設定済みの agentInstallNamespace 内に obo-prometheus-operator をデプロイします。

マルチクラスターオブザーバビリティーアドオンと Cluster Observability Operator はどちらも、ScrapeConfig および PrometheusAgent リソースに対して monitoring.rhobs API グループを共通して使用します。

OpenShift Container Platform クラスターではないその他のマネージドクラスターの場合、以下のリソースがデプロイされます。

注記: OpenShift Container Platform 以外のクラスターの場合、他のマネージドクラスターのクラスター ID は、マネージドクラスターの id.k8s.io クレームを使用しますが、現在のエンドポイント Operator はクラスター名を使用します。

デフォルトのリソース設定を指定して、マネージドクラスターの監視動作を制御できます。プラットフォームの監視と機能的なダッシュボードを実現するために、PrometheusAgent、ScrapeConfig、PrometheusRule のデフォルトのリソースが自動的に作成されます。各 API の説明は以下のとおりです。

デフォルトでは、マルチクラスターオブザーバビリティーアドオンは、マネージドクラスターからプラットフォームメトリクスを収集します。ScrapeConfig リソースのセットは、自動的に生成され、すべてのマネージドクラスターにデプロイされます。ClusterManagementAddOn リソース内で参照するすべての配置には、ScrapeConfig 設定が自動的に適用されます。プラットフォームワークロードダッシュボードには、デフォルトの ScrapeConfig リソースを使用します。

以下のデフォルトプラットフォームメトリクスが収集されます。

マルチクラスターオブザーバビリティーアドオンの健全性ステータスは、ManagedClusterAddOn リソースを通じて報告されます。OpenShift Container Platform コンソールでは、マネージドクラスターごとに、ManagedClusterResource が Fleet Management ビューに表示されます。一部のリソースがデプロイされていない場合、またはプラットフォームの PrometheusAgent リソースが実行されていない場合、ステータスは低下します。

注: OpenShift Container Platform のバージョン 4.20 より前のバージョンでは、Cluster スイッチャーから All Clusters を選択してください。

以下の警告ルールは、すべてのマネージドクラスターにプッシュされます。

ハブクラスターでマルチクラスターオブザーバビリティーアドオンを有効にして、プラットフォームとユーザーのワークロードに関するメトリクスを設定してください。プラットフォームワークロードの有効化は必須ですが、ユーザーワークロードの有効化は任意です。

platform と userWorkloads の仕様を有効にすると、MultiClusterObservability Operator は、マネージドクラスターへのメトリクスコレクターのデプロイを停止し、open-cluster-management-observability namespace に multicluster-observability-addon-manager をデプロイします。multicluster-observability-addon-manager は、ハブクラスターで定義された PrometheusAgent リソースに基づいて、新しいメトリクスコレクターをデプロイします。

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

マルチクラスターオブザーバビリティーアドオンのデフォルトのメトリクス固有 API を設定します。ClusterManagementAddon リソースで新しい配置を参照すると、multicluster-observability-addon-manager は自動的に特定のデフォルトの PrometheusAgent リソースを作成します。multicluster-observability-addon-manager は関連する Placement 設定に PrometheusAgent リソース参照を追加します。

配置によって作成される PrometheusAgent リソースは 1 つですが、デフォルトの ScrapeConfigs と PrometheusRules はすべての配置で共通です。PrometheusAgent、ScrapeConfigs、および PrometheusRules リソースは、マルチクラスターオブザーバビリティーアドオンのデフォルトの設定リソースです。

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

ScrapeConfig リソースを設定して、マネージドクラスターから収集する独自のカスタムメトリクスを追加できます。ScrapeConfig は、対応するマネージドクラスターにデプロイするために、ClusterManagementAddOn リソースの Placement 設定に追加する必要があります。各マネージドクラスター上の Prometheus Operator は、新しい ScrapeConfig リソースを PrometheusAgent リソースに追加します。

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

マルチクラスターオブザーバビリティーアドオンにカスタムメトリクスを追加するには、以下の手順を実行してください。

マネージドクラスター上の Red Hat OpenShift Cluster Observability Operator から、ユーザーワークロードをフェデレーションします。デフォルトでは、ユーザーワークロードメトリクスは、OpenShift Container Platform クラスター上の Prometheus user-workload から統合されます。

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

設定のラベルを変更して、収集しているデフォルトのメトリクスを変更または削除できます。ScrapeConfig リソースごとに設定のラベルを変更するか、PrometheusAgent リソースの remoteWrite 設定でグローバルにラベルを変更します。

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

外部メトリクスエンドポイントを設定するには、カスタムの remoteWrite 仕様を PrometheusAgents リソースに追加します。remoteWrite 仕様を設定すると、マネージドクラスターはメトリクスを外部エンドポイントに直接送信します。

デフォルトのメトリクスのラベルを変更して、関連するマルチクラスターオブザーバビリティーアドオンの設定を更新します。マネージドクラスターからメトリクスをエクスポートして、マネージドクラスターとハブクラスター間のネットワーク分断発生時における回復力を最大 2 時間向上させます。

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

マルチクラスターオブザーバビリティーのアラート転送を設定して、マネージドクラスターからオブザーバビリティースタックのアラートマネージャーにアラートを送信するようにします。デフォルトでは、マルチクラスターオブザーバビリティーアドオンは、マネージドクラスター上の Prometheus からのアラートをハブクラスターの Alertmanager に送信するように設定されていません。

マルチクラスターオブザーバビリティーアドオンを使用する際にアラート転送を設定するためのポリシーを作成します。

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

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

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