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

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

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

    注意: ハブクラスターが 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}")
    2. 次のコマンドを実行して、シークレットから証明書を抽出します。

      oc get secret $SECRET_NAME -n openshift-ingress -o jsonpath=" {.data.tls\.crt}" | base64 -d > ca.crt
  4. API からメトリクスのクエリーを実行するには、次のコマンドを実行します。

    curl --cacert ./ca.crt -H "Authorization: Bearer {TOKEN}" https://{PROXY_ROUTE_URL}/api/v1/query?query={QUERY_EXPRESSION}

    注記: 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
    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
    1
    各アイテムには、namekey の 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.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-configdeployment.apps/grafana-devservice/grafana-devingress.extensions/grafana-devpersistentvolumeclaim/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
  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

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

1.5.4.1.1. Grafana のバージョン検証

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

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

grafana-cli

現在クラスター環境内にデプロイされている 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

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

  1. ダッシュボードを選択し、Dashboard 設定 アイコンをクリックします。
  2. ナビゲーションパネルから JSON Model アイコンをクリックします。
  3. ダッシュボード JSON データをコピーし、data セクションに貼り付けます。
  4. name を、$your-dashboard-name に置き換えます。data.$your-dashboard-name.json.$$your_dashboard_jsonuid フィールドに 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

    注記:

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

      ./generate-dashboard-configmap-yaml.sh "Demo Dashboard"

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

      Save dashboard <demo-dashboard> to ./demo-dashboard.yaml
    • ダッシュボードが General フォルダーにない場合は、この ConfigMap の annotations セクションでフォルダー名を指定できます。

      annotations:
        observability.open-cluster-management.io/dashboard-folder: Custom

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

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

oc apply -f demo-dashboard.yaml

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

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

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

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

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

enabled managedcluster labels: <label>

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

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

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

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

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

disabled managedcluster label: <label>

1.5.5.4. 関連情報

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る