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

手順

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. ServiceMonitor および PodMonitor リソースに openshift.io/user-monitoring=false ラベルが 割り当てられていない ことを確認します。次の例では、prometheus-example-monitor サービスモニターをチェックします。

      $ oc -n ns1 get servicemonitor prometheus-example-monitor --show-labels | grep 'openshift.io/user-monitoring=false'

      Copy to Clipboard Toggle word wrap

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

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

      $ oc label namespace ns1 'openshift.io/user-monitoring-'

      Copy to Clipboard Toggle word wrap

      リソースからラベルを削除する例

      $ oc -n ns1 label servicemonitor prometheus-example-monitor '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. Red Hat OpenShift Service on AWS Web コンソールの Metrics targets ページで、エンドポイントのターゲットステータスを確認します。

   1. Red Hat OpenShift Service on AWS Web コンソールにログインし、Observe Targets に移動します。
   2. リストでメトリクスのエンドポイントを探し、Status 列でターゲットのステータスを確認します。
   3. Status が Down の場合、エンドポイントの 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. 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
      # ...

      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 リソースを使用しているかどうかを確認します。ログで他の関連するエラーの有無を確認します。

手順

1. Red Hat OpenShift Service on AWS Web コンソールで、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 クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
   • メトリクスがコアの Red Hat OpenShift Service on AWS プロジェクトに関連している場合 は、Red Hat Customer Portal で Red Hat サポートケースを作成します。

4. 以下の手順に従い、dedicated-admin としてログインし、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