1.4. 可観測性のカスタマイズ


可観測性サービスが収集するデータのカスタマイズ、管理、および表示については、以下のセクションを参照してください。

must-gather コマンドで可観測性リソース用に作成される新規情報についてのログを収集します。詳細は、トラブルシューティング ドキュメントの Must-gather セクションを参照してください。

1.4.1. カスタムルールの作成

可観測性リソースに、Prometheus レコードルール および アラートルール を追加して、可観測性インストールのカスタムルールを作成します。詳細は、Prometheus configuration を参照してください。

  • レコードルールでは、必要に応じてコストの掛かる式を事前に計算するか、コンピュートできます。結果は新たな時系列のセットとして保存されます。
  • アラートルールでは、アラートを外部サービスに送信する方法に基づいてアラート条件を指定する機能を提供します。

Prometheus でカスタムルールを定義してアラート条件を作成し、通知を外部メッセージングサービスに送信します。注記: カスタムルールを更新すると、observability-thanos-rule Pod は自動的に再起動されます。

open-cluster-management-observability namespace に thanos-ruler-custom-rules という名前の ConfigMap を作成します。以下の例のように、キーは custom_rules.yaml という名前を指定する必要があります。設定には、複数のルールを作成できます。

  • デフォルトでは、同梱のアラートルールは open-cluster-management-observability namespace の thanos-ruler-default-rules ConfigMap に定義されます。

    たとえば、CPU の使用状況が定義値を超えた場合に通知するカスタムのアラートルールを作成できます。YAML の内容は以下のようになります。

    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
  • thanos-ruler-custom-rules ConfigMap 内にカスタムの録画ルールを作成することもできます。

    たとえば、Pod のコンテナーメモリーキャッシュの合計を取得できるようにする記録ルールを作成することができます。YAML の内容は以下のようになります。

    data:
      custom_rules.yaml: |
        groups:
          - name: container-memory
            recording_rules:
            - record: pod:container_memory_cache:sum
              expr: sum(container_memory_cache{pod!=""}) BY (pod, container)

    注記: これが最初の新規カスタムルールである場合には、すぐに作成されます。ConfigMap に変更が加えられると、設定は自動的に再読み込みされます。この設定は、observability-thanos-ruler サイドカー内の config-reload により再読み込みされます。

アラートルールが適切に機能していることを確認するには、Grafana ダッシュボードを起動し、Explore ページに移動し、ALERTS にクエリーを実行します。アラートは、アラートが開始された場合に Grafana でのみ利用できます。

1.4.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
  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=-

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

    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

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

1.4.3. カスタムメトリクスの追加

metrics_list.yaml ファイルにメトリクスを追加して、マネージドクラスターから収集されるようにします。

カスタムメトリクスを追加する前に、oc get mco observability -o yaml コマンドで、mco observability が有効になっていることを確認します。status.conditions.message の メッセージが Observability components are deployed and running となっていることを確認します。

observability-metrics-custom-allowlist.yaml という名前のファイルを作成し、metrics_list.yaml パラメーターにカスタムメトリックの名前を追加します。ConfigMap の YAML は、以下の内容のようになります。

kind: ConfigMap
apiVersion: v1
metadata:
  name: observability-metrics-custom-allowlist
data:
  metrics_list.yaml: |
    names:
      - node_memory_MemTotal_bytes
    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))
  • names セクションで、マネージドクラスターから収集されるカスタムメトリクスの名前を追加します。
  • rules セクションで、パラメーターペア exprrecord に値を 1 つだけ入力し、クエリー式を定義します。メトリクスは、マネージドクラスターの record パラメーターで定義される名前で収集されます。クエリー式の実行後の結果が、メトリックの値として返されます。
  • namesrules セクションはオプションです。セクションのいずれかまたは両方を使用できます。

oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml のコマンドで、open-cluster-management-observability namespace に observability-metrics-custom-allowlist ConfigMap を作成します。

Grafana ダッシュボードから Explore ページからメトリックをクエリーし、カスタムメトリックからのデータが収集されていることを確認します。独自のダッシュボードでカスタムメトリクスを使用することもできます。ダッシュボードの表示に関する詳細は、Grafana ダッシュボードの設計 を参照してください。

1.4.4. デフォルトメトリクスの削除

マネージドクラスターで特定のメトリック用にデータを収集しない場合は、observability-metrics-custom-allowlist.yaml ファイルからメトリックを削除します。メトリックを削除すると、メトリックデータはマネージドクラスターでは収集されません。前述したように、mco observability が有効になっていることを確認します。

メトリック名の先頭にハイフン - を指定して metrics_list.yaml パラメーターにデフォルトのメトリック名を追加します。例: -cluster_infrastructure_provider

oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml のコマンドで、open-cluster-management-observability namespace に observability-metrics-custom-allowlist ConfigMap を作成します。

特定のメトリックがマネージドクラスターから収集されていないことを確認します。Grafana ダッシュボードからメトリックをクエリーしても、メトリックは表示されません。

1.4.5. 外部エンドポイントへのメトリックのエクスポート

可観測性をカスタマイズして、Prometheus Remote Write プロトコルをリアルタイムでサポートする外部エンドポイントにメトリックをエクスポートできます。詳細は、Prometheus Remote Write プロトコル を参照してください。

1.4.5.1. 外部エンドポイントの Kubernetes シークレットの作成

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

apiVersion: v1
kind: Secret
metadata:
  name: victoriametrics
  namespace: open-cluster-management-observability
type: Opaque
stringData:
  ep.yaml: |
    url: http://victoriametrics:8428/api/v1/write
    http_client_config:
      basic_auth:
        username: test
        password: test

ep.yaml はコンテンツのキーであり、次のステップの multiclusterobservability CR で使用されます。現在、可観測性は、セキュリティーチェックなし、基本認証、または tls の有効化を使用して、エンドポイントへのメトリックのエクスポートをサポートしています。サポートされているパラメーターの完全なリストについては、次の表を参照してください。

Expand
名前説明スキーマ

url
required

外部エンドポイントの URL。

string

http_client_config
optional

HTTP クライアントの高度な設定。

HttpClientConfig

HttpClientConfig

Expand
名前説明スキーマ

basic_auth
optional

基本認証用の HTTP クライアント設定。

BasicAuth

tls_config
optional

TLS の HTTP クライアント設定。

TLSConfig

BasicAuth

Expand
名前説明スキーマ

username
任意

基本認証のユーザー名。

string

password
optional

基本認証用のパスワード。

string

TLSConfig

Expand

名前

説明

スキーマ

secret_name
required

証明書を含むシークレットの名前。

string

ca_file_key
optional

シークレットの CA 証明書のキー (insecure_skip_verify が true に設定されている場合のみオプション)。

string

cert_file_key
required

シークレット内のクライアント証明書のキー。

string

key_file_key
required

シークレットのクライアントキーのキー。

string

insecure_skip_verify
optional

ターゲット証明書の検証をスキップするパラメーター。

ブール型

1.4.5.2. MultiClusterObservability CR の更新

Kubernetes シークレットを作成した後、multiclusterobservability CR を更新して、spec.storageConfig パラメーターに writeStorage を追加する必要があります。以下の例を参照してください。

spec:
  storageConfig:
    writeStorage:
    - key: ep.yaml
      name: victoriametrics

writeStorage の値はリストです。メトリクスを 1 つの外部エンドポイントにエクスポートする場合は、リストにアイテムを追加できます。リストに複数のアイテムを追加すると、メトリクスは複数の外部エンドポイントにエクスポートされます。各アイテムには、namekey の 2 つの属性が含まれています。Name は、エンドポイントアクセス情報を含む Kubernetes シークレットの名前であり、key はシークレット内のコンテンツのキーです。次の説明表を参照してください

1.4.5.3. メトリックエクスポートのステータスの表示

メトリクスのエクスポートを有効にした後、acm_remote_write_requests_total メトリクスをチェックすることにより、メトリクスのエクスポートのステータスを表示できます。ハブクラスターの OpenShift コンソールから、Observe セクションの Metrics をクリックして、Metrics ページに移動します。

次に、acm_remote_write_requests_total メトリックをクエリーします。そのメトリックの値は、1 つの observatorium API インスタンスで、1 つの外部エンドポイントに対する特定の応答を持つリクエストの総数です。name ラベルは、外部エンドポイントの名前です。code ラベルは、メトリクスエクスポートの HTTP リクエストのリターンコードです。

1.4.6. 詳細 設定の追加

advanced 設定セクションを追加して、必要に応じて可観測性コンポーネントごとに保持内容を更新します。

MultiClusterObservability CR を編集し、oc edit mco observability -o yaml コマンドで advanced セクションを追加します。YAML ファイルは以下の内容のようになります。

spec:
  advanced:
    retentionConfig:
      blockDuration: 2h
      deleteDelay: 48h
      retentionInLocal: 24h
      retentionResolutionRaw: 30d
      retentionResolution5m: 180d
      retentionResolution1h: 0d
    receive:
      resources:
        limits:
          memory: 4096Gi
      replicas: 3

advanced 設定に追加できるすべてのパラメーターの説明は、Observability API を参照してください。

1.4.7. コンソールからの multiclusterobservability CR レプリカの更新

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

spec:
   advanced:
      receive:
         replicas: 6

observability CR 内のパラメーターの詳細は、Observability API を参照してください。

1.4.8. アラートの転送

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

詳細は、Prometheus Alertmanager のドキュメント を参照してください。

1.4.8.1. マネージドクラスターの転送アラートの無効化

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

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

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

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

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

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

1.4.9. アラートをサイレントにする

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

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

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

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" alertname="SampleAlert"
  • 複数の一致ラベルを使用してアラートをサイレントにします。次のコマンドは match-label-1match-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>
  • 特定の期間アラートをサイレントにする場合は、--duration フラグを使用します。次のコマンドを実行して、SampleAlert を 1 時間サイレントにします。

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

    消音アラートの開始時刻または終了時刻を指定することもできます。次のコマンドを入力して、特定の開始時刻に 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"
  • 作成されたサイレント化されたアラートをすべて表示するには、次のコマンドを実行します。

    amtool silence --alertmanager.url="http://localhost:9093"
  • アラートをサイレントにしたくない場合は、次のコマンドを実行してアラートのサイレントを終了します。

    amtool silence expire --alertmanager.url="http://localhost:9093" "d839aca9-ed46-40be-84c4-dca8773671da"
  • すべてのアラートをサイレントにするのを終了するには、次のコマンドを実行します。

    amtool silence expire --alertmanager.url="http://localhost:9093" $(amtool silence query --alertmanager.url="http://localhost:9093" -q)

1.4.10. アラートの抑制

重大度の低い 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
1
hibit_rules パラメーターセクションは、同じ namespace のアラートを検索するために定義されています。critical アラートがネームスペース内で開始し、その namespace に重大度レベルの warning または info を含む他のアラートがある場合は、critical アラートのみが AlertManager レシーバーにルーティングされます。一致するものがあった場合、次のアラートが表示される場合があります。
ALERTS{alertname="foo", namespace="ns-1", severity="critical"}
ALERTS{alertname="foo", namespace="ns-1", severity="warning"}
2
source_match パラメーターと target_match_re パラメーターの値が一致しない場合、アラートはレシーバーにルーティングされます。
ALERTS{alertname="foo", namespace="ns-1", severity="critical"}
ALERTS{alertname="foo", namespace="ns-2", severity="warning"}
  • Red Hat Advanced Cluster Management で抑制されたアラートを表示するには、次のコマンドを入力します。

    amtool alert --alertmanager.url="http://localhost:9093" --inhibited

1.4.11. ルート認定のカスタマイズ

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

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

1.4.11.1. オブジェクトストアにアクセスするための証明書のカスタマイズ

オブジェクトストアにアクセスするための証明書をカスタマイズできます。オブジェクトストアシークレットに証明書を追加して、http_config セクションを編集します。以下の例を参照してください。

 thanos.yaml: |
    type: s3
    config:
      bucket: "thanos"
      endpoint: "minio:9000"
      insecure: false
      access_key: "minio"
      secret_key: "minio123"
      http_config:
        tls_config:
          ca_file: /etc/minio/certs/ca.crt
          insecure_skip_verify: false

open-cluster-management-observability namespace にシークレットを指定する必要があります。シークレットには、前のシークレットの例で定義した ca.crt が含まれている必要があります。相互 TLS を有効にする場合は、前のシークレットで public.crt および private.key を提供する必要があります。以下の例を参照してください。

 thanos.yaml: |
    type: s3
    config:
      ...
      http_config:
        tls_config:
          ca_file: /etc/minio/certs/ca.crt
          cert_file: /etc/minio/certs/public.crt
          key_file: /etc/minio/certs/private.key
          insecure_skip_verify: false

MultiClusterObservability CR でシークレット名、TLSSecretName パラメーターを設定することもできます。シークレット名が tls-certs-secret である次の例を表示します。

metricObjectStorage:
      key: thanos.yaml
      name: thanos-object-storage
      tlsSecretName: tls-certs-secret

このシークレットは、オブジェクトストアにアクセスする必要のあるすべてのコンポーネントにマウントでき、次のコンポーネントが含まれます: receiverstorerulercompact

1.4.12. データの表示および展開

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

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

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

1.4.12.1. etcd テーブルの表示

Grafana のハブクラスターダッシュボードから etcd テーブルを表示し、データストアとしての etcd の安定性を確認します。

ハブクラスターから Grafana リンクを選択して、ハブクラスターから収集された etcd テーブルデータを表示します。マネージドクラスターの Leader election changes が表示されます。

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

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

過去 7 日間または 30 日間のターゲットとする サービスレベル目標 (SLO) 値を超えるか、満たしているクラスターの合計数、オフラインクラスター、および API サーバー要求の期間を表示します。

1.4.12.3. Kubernetes API サーバーダッシュボードのクラスターサービスレベルの概要の表示

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

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

過去 7 日間または 30 日間のエラーとなっている予算、残りのダウンタイム、および傾向を表示します。

1.4.13. 可観測性の無効化

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

1.4.13.1. すべてのクラスターで可観測性を無効にする

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

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

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

1.4.13.2. 単一クラスターで可観測性を無効にする

特定のマネージドクラスターの可観測性コンポーネントを削除して可観測性を無効にします。managedclusters.cluster.open-cluster-management.io のカスタムリソースに observability: disabled ラベルを追加します。

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

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

可観測性サービスを使用したコンソールでのデータの監視に関する詳細は、環境の監視の紹介 を参照してください。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る