7.11. モニタリング関連の問題の調査


OpenShift Container Platform には、コアプラットフォームコンポーネントのモニタリングを提供する事前に設定され、事前にインストールされた自己更新型のモニタリングスタックが含まれます。OpenShift Container Platform 4.14 では、クラスター管理者はオプションでユーザー定義プロジェクトのモニタリングを有効にできます。

次の問題が発生した場合は、このセクションの手順に従ってください。

  • 独自のメトリクスが利用できない。
  • Prometheus が大量のディスク容量を消費している。
  • Prometheus に対して KubePersistentVolumeFillingUp アラートが発生している。

7.11.1. ユーザー定義のプロジェクトメトリクスが使用できない理由の調査

ServiceMonitor リソースを使用すると、ユーザー定義プロジェクトでサービスによって公開されるメトリクスの使用方法を判別できます。ServiceMonitor リソースを作成している場合で、メトリクス UI に対応するメトリクスが表示されない場合は、この手順で説明されるステップを実行します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ユーザー定義プロジェクトのユーザー定義のプロジェクトのモニタリングを有効にして設定した。
  • ServiceMonitor リソースを作成した。

手順

  1. プロジェクトがユーザーワークロードの監視から除外されていないことを確認します。次の例では、ns1 プロジェクトを使用します。

    1. プロジェクトに openshift.io/user-monitoring=false ラベルが 割り当てられていない ことを確認します。

      $ oc get namespace ns1 --show-labels | grep 'openshift.io/user-monitoring=false'
      Copy to Clipboard Toggle word wrap
      注記

      ユーザーワークロードのプロジェクトに設定されるデフォルトのラベルは、openshift.io/user-monitoring=true です。ただし、ラベルは手動で適用しない限り表示されません。

    2. ラベルが割り当てられている場合は、ラベルを削除します。

      プロジェクトからラベルを削除する例

      $ oc label namespace ns1 'openshift.io/user-monitoring-'
      Copy to Clipboard Toggle word wrap

      出力例

      namespace/ns1 unlabeled
      Copy to Clipboard Toggle word wrap

  2. サービスと ServiceMonitor リソース設定の対応するラベルが一致していることを確認します。次の例では、prometheus-example-app サービス、prometheus-example-monitor サービスモニター、および ns1 プロジェクトを使用します。

    1. サービスに定義されたラベルを取得します。

      $ oc -n ns1 get service prometheus-example-app -o yaml
      Copy to Clipboard Toggle word wrap

      出力例

        labels:
          app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

    2. ServiceMonitor リソース設定の matchLabels 定義が、直前の手順のラベルの出力と一致することを確認します。

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
      Copy to Clipboard Toggle word wrap

      出力例

      apiVersion: v1
      kind: ServiceMonitor
      metadata:
        name: prometheus-example-monitor
        namespace: ns1
      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

      注記

      プロジェクトの表示権限を持つ開発者として、サービスおよび ServiceMonitor リソースラベルを確認できます。

  3. openshift-user-workload-monitoring プロジェクトで Prometheus Operator のログを調べます。

    1. openshift-user-workload-monitoring プロジェクトの Pod をリスト表示します。

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m
      Copy to Clipboard Toggle word wrap

    2. prometheus-operator Pod の prometheus-operator コンテナーからログを取得します。以下の例では、Pod は prometheus-operator-776fcbbd56-2nbfm になります。

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator
      Copy to Clipboard Toggle word wrap

      サービスモニターに問題がある場合、ログには以下のようなエラーが含まれる可能性があります。

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload
      Copy to Clipboard Toggle word wrap
  4. OpenShift Container Platform Web コンソール UI の Metrics targets ページで、エンドポイントのターゲットステータスを確認します。

    1. OpenShift Container Platform の Web コンソールにログインし、管理者 パースペクティブの Observe Targets に移動します。
    2. リストでメトリクスのエンドポイントを探し、Status 列でターゲットのステータスを確認します。
    3. StatusDown の場合、エンドポイントの URL をクリックすると、そのメトリクスターゲットの Target Details ページで詳細情報を見ることができます。
  5. openshift-user-workload-monitoring プロジェクトで Prometheus Operator のデバッグレベルのロギングを設定します。

    1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      Copy to Clipboard Toggle word wrap
    2. prometheusOperatorlogLevel: debugdata/config.yaml に追加し、ログレベルを debug に設定します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug
      # ...
      Copy to Clipboard Toggle word wrap
    3. 変更を適用するためにファイルを保存します。影響を受ける prometheus-operator Pod は自動的に再デプロイされます。
    4. debug ログレベルが openshift-user-workload-monitoring プロジェクトの prometheus-operator デプロイメントに適用されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"
      Copy to Clipboard Toggle word wrap

      出力例

              - --log-level=debug
      Copy to Clipboard Toggle word wrap

      デバッグレベルのロギングでは、Prometheus Operator によって行われるすべての呼び出しが表示されます。

    5. prometheus-operator Pod が実行されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap
      注記

      認識されない Prometheus Operator の loglevel 値が config map に含まれる場合、prometheus-operator Pod が正常に再起動されない可能性があります。

    6. デバッグログを確認し、Prometheus Operator が ServiceMonitor リソースを使用しているかどうかを確認します。ログで他の関連するエラーの有無を確認します。

7.11.2. Prometheus が大量のディスク領域を消費している理由の特定

開発者は、キーと値のペアの形式でメトリクスの属性を定義するためにラベルを作成できます。使用できる可能性のあるキーと値のペアの数は、属性について使用できる可能性のある値の数に対応します。数が無制限の値を持つ属性は、バインドされていない属性と呼ばれます。たとえば、customer_id 属性は、使用できる値が無限にあるため、バインドされていない属性になります。

割り当てられるキーと値のペアにはすべて、一意の時系列があります。ラベルに多数のバインドされていない値を使用すると、作成される時系列の数が指数関数的に増加する可能性があります。これは Prometheus のパフォーマンスに影響する可能性があり、多くのディスク領域を消費する可能性があります。

Prometheus が多くのディスクを消費する場合、以下の手段を使用できます。

  • どのラベルが最も多くの時系列データを作成しているか詳しく知るには、Prometheus HTTP API を使用して時系列データベース (TSDB) のステータスを確認 します。これを実行するには、クラスター管理者権限が必要です。
  • 収集されている スクレイプサンプルの数を確認 します。
  • ユーザー定義メトリクスに割り当てられるバインドされていない属性の数を減らすことで、作成される一意の時系列の数を減らします

    注記

    使用可能な値の制限されたセットにバインドされる属性を使用すると、可能なキーと値のペアの組み合わせの数が減ります。

  • ユーザー定義のプロジェクト全体で スクレイピングできるサンプルの数に制限を適用 します。これには、クラスター管理者の権限が必要です。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. Administrator パースペクティブで、Observe Metrics に移動します。
  2. Expression フィールドに、Prometheus Query Language (PromQL) クエリーを入力します。次のクエリー例は、ディスク領域の消費量の増加につながる可能性のある高カーディナリティメトリクスを識別するのに役立ちます。

    • 次のクエリーを実行すると、スクレイプサンプルの数が最も多いジョブを 10 個特定できます。

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
      Copy to Clipboard Toggle word wrap
    • 次のクエリーを実行すると、過去 1 時間に最も多くの時系列データを作成したジョブを 10 個特定して、時系列のチャーンを正確に特定できます。

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
      Copy to Clipboard Toggle word wrap
  3. 想定よりもサンプルのスクレイプ数が多いメトリクスに割り当てられたラベルで、値が割り当てられていないものの数を確認します。

    • メトリクスがユーザー定義のプロジェクトに関連する場合、ワークロードに割り当てられたメトリクスのキーと値のペアを確認します。これらのライブラリーは、アプリケーションレベルで Prometheus クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
    • メトリクスが OpenShift Container Platform のコアプロジェクトに関連する場合、Red Hat サポートケースを Red Hat カスタマーポータル で作成してください。
  4. クラスター管理者としてログインしてから、次の手順に従い Prometheus HTTP API を使用して TSDB ステータスを確認します。

    1. 次のコマンドを実行して、Prometheus API ルート URL を取得します。

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath='{.status.ingress[].host}')
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して認証トークンを抽出します。

      $ TOKEN=$(oc whoami -t)
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを実行して、Prometheus の TSDB ステータスのクエリーを実行します。

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"
      Copy to Clipboard Toggle word wrap

      出力例

      "status": "success","data":{"headStats":{"numSeries":507473,
      "numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
      "maxTime":1712257935346},"seriesCountByMetricName":
      [{"name":"etcd_request_duration_seconds_bucket","value":51840},
      {"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
      ...
      Copy to Clipboard Toggle word wrap

7.11.3. Prometheus に対する KubePersistentVolumeFillingUp アラートの解決

クラスター管理者は、Prometheus に対してトリガーされている KubePersistentVolumeFillingUp アラートを解決できます。

openshift-monitoring プロジェクトの prometheus-k8s-* Pod によって要求された永続ボリューム (PV) の合計残り容量が 3% 未満になると、重大アラートが発生します。これにより、Prometheus の動作異常が発生する可能性があります。

注記

KubePersistentVolumeFillingUp アラートは 2 つあります。

  • 重大アラート: マウントされた PV の合計残り容量が 3% 未満になると、severity="critical" ラベルの付いたアラートがトリガーされます。
  • 警告アラート: マウントされた PV の合計空き容量が 15% 未満になり、4 日以内にいっぱいになると予想される場合、severity="warning" ラベルの付いたアラートがトリガーされます。

この問題に対処するには、Prometheus 時系列データベース (TSDB) のブロックを削除して、PV 用のスペースを増やすことができます。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、すべての TSDB ブロックのサイズを古いものから新しいものの順にリスト表示します。

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \
    1
    
    -c prometheus --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \
    2
    
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'cd /prometheus/;du -hs $(ls -dtr */ | grep -Eo "[0-9|A-Z]{26}")'
    Copy to Clipboard Toggle word wrap
    1 2
    <prometheus_k8s_pod_name> は、KubePersistentVolumeFillingUp アラートの説明に記載されている Pod に置き換えます。

    出力例

    308M    01HVKMPKQWZYWS8WVDAYQHNMW6
    52M     01HVK64DTDA81799TBR9QDECEZ
    102M    01HVK64DS7TRZRWF2756KHST5X
    140M    01HVJS59K11FBVAPVY57K88Z11
    90M     01HVH2A5Z58SKT810EM6B9AT50
    152M    01HV8ZDVQMX41MKCN84S32RRZ1
    354M    01HV6Q2N26BK63G4RYTST71FBF
    156M    01HV664H9J9Z1FTZD73RD1563E
    216M    01HTHXB60A7F239HN7S2TENPNS
    104M    01HTHMGRXGS0WXA3WATRXHR36B
    Copy to Clipboard Toggle word wrap

  2. 削除できるブロックとその数を特定し、ブロックを削除します。次のコマンド例は、prometheus-k8s-0 Pod から最も古い 3 つの Prometheus TSDB ブロックを削除します。

    $ oc debug prometheus-k8s-0 -n openshift-monitoring \
    -c prometheus --image=$(oc get po -n openshift-monitoring prometheus-k8s-0 \
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'ls -latr /prometheus/ | egrep -o "[0-9|A-Z]{26}" | head -3 | \
    while read BLOCK; do rm -r /prometheus/$BLOCK; done'
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、マウントされた PV の使用状況を確認し、十分な空き容量があることを確認します。

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \
    1
    
    --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \
    2
    
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') -- df -h /prometheus/
    Copy to Clipboard Toggle word wrap
    1 2
    <prometheus_k8s_pod_name> は、KubePersistentVolumeFillingUp アラートの説明に記載されている Pod に置き換えます。

    次の出力例は、prometheus-k8s-0 Pod によって要求されるマウントされた PV に、63% の空き容量が残っていることを示しています。

    出力例

    Starting pod/prometheus-k8s-0-debug-j82w4 ...
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme0n1p4  40G   15G  40G  37% /prometheus
    
    Removing debug pod ...
    Copy to Clipboard Toggle word wrap

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat