第7章 モニタリング関連の問題のトラブルシューティング

手順

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

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

      $ oc get namespace ns1 --show-labels | grep 'openshift.io/user-monitoring=false'

      注記

      ユーザーワークロードのプロジェクトに設定されるデフォルトのラベルは、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'

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

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

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

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

      $ oc -n ns1 label servicemonitor prometheus-example-monitor 'openshift.io/user-monitoring-'

      出力例

      namespace/ns1 unlabeled

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

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

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

      出力例

        labels:
          app: prometheus-example-app

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

      $ 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 リソースラベルを確認できます。

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

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

   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. 変更を適用するためにファイルを保存します。影響を受ける 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"

      出力例

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