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

手順

1. サービスおよび ServiceMonitor リソース設定で、対応するラベルの一致を確認 します。

   1. サービスに定義されたラベルを取得します。以下の例では、ns1 プロジェクトの prometheus-example-app サービスをクエリーします。

      $ oc -n ns1 get service prometheus-example-app -o yaml

      出力例

        labels:
          app: prometheus-example-app

   2. ServiceMonitor リソース設定の matchLabels 定義が、直前の手順のラベルの出力と一致することを確認します。次の例では、ns1 プロジェクトの prometheus-example-monitor サービスモニターをクエリーします。

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      出力例

      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

      注記

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

2. openshift-user-workload-monitoring プロジェクトの Prometheus Operator のログを検査します。

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

      $ oc -n openshift-user-workload-monitoring get pods

      出力例

      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

   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

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

      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

3. OpenShift Container Platform Web コンソール UI の Metrics targets ページで、エンドポイントのターゲットステータスを確認 します。

   1. OpenShift Container Platform の Web コンソールにログインし、管理者 パースペクティブの Observe → Targets に移動します。
   2. リストでメトリックのエンドポイントを探し、Status 列でターゲットのステータスを確認します。
   3. Status が Down の場合、エンドポイントの URL をクリックすると、そのメトリクスターゲットの Target Details ページで詳細情報を見ることができます。

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

   2. prometheusOperator の logLevel: debug を data/config.yaml に追加し、ログレベルを debug に設定します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug
      # ...

   3. 変更を適用するためにファイルを保存します。

      注記

      openshift-user-workload-monitoring プロジェクトの prometheus-operator は、ログレベルの変更時に自動的に再起動します。

   4. debug ログレベルが openshift-user-workload-monitoring プロジェクトの prometheus-operator デプロイメントに適用されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      出力例

              - --log-level=debug

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

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

      $ oc -n openshift-user-workload-monitoring get pods

      注記

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

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

手順

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

   • 次のクエリーを実行すると、過去 1 時間に最も多くの時系列データを作成したジョブを 10 個特定して、時系列のチャーンを正確に特定できます。

     topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))

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={.spec.host})

   2. 次のコマンドを実行して認証トークンを抽出します。

      $ TOKEN=$(oc whoami -t)

   3. 次のコマンドを実行して、Prometheus の TSDB ステータスをクエリーします。

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"

      出力例

      "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},
      ...