可観測性

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

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

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

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

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

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

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

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

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

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: # The ObservabilityAddonSpec defines the global settings for all managed clusters which have observability add-on enabled
    enableMetrics: false #indicates the observability addon push metrics to hub server

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

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

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

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

metrics_list.yaml ファイルにメトリクスを追加して、マネージドクラスターから収集します。以下の手順を実行します。

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

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

メトリックは、コレクションルールで指定されたマネージドクラスターの状態に基づいて動的に収集されます。これらのメトリックは動的に収集されるため、以下の Red Hat Advanced Cluster Management Grafana ダッシュボードではデータは表示されません。コレクションルールがアクティブになり、対応するメトリックが収集されると、以下のパネルには、コレクションルールが開始される期間のデータが表示されます。

デフォルトでは、コレクションルールは、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!=""

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

collect_rules:
  - group: -SNOResourceUsage

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

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

spec:
   advanced:
      receive:
         replicas: 6

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

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

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

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

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

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

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

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

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

クラスター内の特定 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 リソースを定義します。

可観測性には、外部 API があり、OpenShift ルート (rbac-query-proxy) を使用してメトリックをクエリーできます。rbac-query-proxy ルートのクエリーを取得するには、以下のオプションを参照してください。

可観測性用の proxy-byo-cert シークレットを作成するには、次の手順を実行します。

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

ハブクラスターから 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: 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

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

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 を参照してください。

可観測性を有効にした後には、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://****

metadata:
      annotations:
        mco-disable-alerting: "true"

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

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

重大度の低い 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

クラスターから収集される Kubernetes リソースを定義するには、search-collector-config config map を作成します。以下の手順を実行します。

検索結果と制限をカスタマイズします。カスタマイズを実行するには、次のタスクを完了します。

検索ボックス にテキスト値を入力すると、名前や namespace などのプロパティーからのその値が含まれる結果が表示されます。空白を含むクエリーはサポートされていません。

検索結果をさらに絞り込むには、検索にプロパティーセレクターを追加します。プロパティーに関連する値を組み合わせて、検索範囲をより正確に指定できます。たとえば、cluster:dev red と検索すると、dev クラスター内で "red" の文字列と一致する結果が返されます。

検索でクエリーを作成するには、次の手順を実行します。

マネージドクラスターから Kubernetes オブジェクトを収集するために、検索が有効になっているすべてのマネージドクラスターで klusterlet-addon-search Pod が実行されます。このデプロイメントは、open-cluster-management-agent-addon namespace で実行されます。多数のリソースを持つマネージドクラスターでは、klusterlet-addon-search デプロイメントが機能するために、より多くのメモリーが必要になる場合があります。

マネージドクラスター内の klusterlet-addon-search Pod のリソース要件は、Red Hat Advanced Cluster Management ハブクラスター内の ManagedClusterAddon カスタムリソースで指定できます。マネージドクラスターごとに、マネージドクラスター名を持つ namespace があります。以下の手順を実行します。

アノテーションはマネージドクラスターのリソース要件をオーバーライドし、新しいリソース要件で Pod を自動的に再起動します。

注記: コンソールで API Explorer を使用して、マネージドクラスターに定義されているすべてのリソースを検出できます。oc api-resourcesコマンドを実行しても、すべてのリソースを検出できます。

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

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

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