第13章 モニタリング関連の問題のトラブルシューティング
コアプラットフォームおよびユーザー定義プロジェクトのモニタリングに関する一般的な問題のトラブルシューティング手順を参照してください。
13.1. ユーザー定義のプロジェクトメトリクスが使用できない理由の調査
ServiceMonitor
リソースを使用すると、ユーザー定義プロジェクトでサービスによって公開されるメトリクスの使用方法を判別できます。ServiceMonitor
リソースを作成している場合で、メトリクス UI に対応するメトリクスが表示されない場合は、この手順で説明されるステップを実行します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。 - ユーザー定義のプロジェクトのモニタリングを有効にし、設定している。
-
ServiceMonitor
リソースを作成している。
手順
サービスおよび
ServiceMonitor
リソース設定で、対応するラベルの一致を確認 します。サービスに定義されたラベルを取得します。以下の例では、
ns1
プロジェクトのprometheus-example-app
サービスをクエリーします。$ oc -n ns1 get service prometheus-example-app -o yaml
出力例
labels: app: prometheus-example-app
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
リソースラベルを確認できます。
openshift-user-workload-monitoring
プロジェクトの Prometheus Operator のログを検査します。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
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
OpenShift Container Platform Web コンソール UI の Metrics targets ページで、エンドポイントのターゲットステータスを確認 します。
-
OpenShift Container Platform の Web コンソールにログインし、管理者 パースペクティブの Observe
Targets に移動します。 - リストでメトリクスのエンドポイントを探し、Status 列でターゲットのステータスを確認します。
- Status が Down の場合、エンドポイントの URL をクリックすると、そのメトリクスターゲットの Target Details ページで詳細情報を見ることができます。
-
OpenShift Container Platform の Web コンソールにログインし、管理者 パースペクティブの Observe
openshift-user-workload-monitoring
プロジェクトで Prometheus Operator のデバッグレベルのロギングを設定 します。openshift-user-workload-monitoring
プロジェクトでuser-workload-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
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 # ...
-
変更を適用するためにファイルを保存します。影響を受ける
prometheus-operator
Pod は自動的に再デプロイされます。 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 によって行われるすべての呼び出しが表示されます。
prometheus-operator
Pod が実行されていることを確認します。$ oc -n openshift-user-workload-monitoring get pods
注記認識されない Prometheus Operator の
loglevel
値が config map に含まれる場合、prometheus-operator
Pod が正常に再起動されない可能性があります。-
デバッグログを確認し、Prometheus Operator が
ServiceMonitor
リソースを使用しているかどうかを確認します。ログで他の関連するエラーの有無を確認します。
関連情報
- ユーザー定義のワークロードモニタリング config map の作成
-
ServiceMonitor
またはPodMonitor
の作成方法の詳細は、サービスのモニター法の指定 を参照してください。 - メトリクスターゲットに関する詳細情報の取得 を参照してください。