第14章 モニタリング関連の問題のトラブルシューティング
14.1. ユーザー定義のメトリックが利用できない理由の調査
ServiceMonitor
リソースを使用すると、ユーザー定義プロジェクトでサービスによって公開されるメトリックの使用方法を判別できます。ServiceMonitor
リソースを作成している場合で、メトリック UI に対応するメトリックが表示されない場合は、この手順で説明されるステップを実行します。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできます。 -
OpenShift CLI (
oc
) がインストールされている。 - ユーザー定義のワークロードのモニタリングを有効にし、設定している。
-
user-workload-monitoring-config
ConfigMap
オブジェクトを作成している。 -
ServiceMonitor
リソースを作成している。
手順
サービスおよび
ServiceMonitor
リソース設定で、対応するラベルの一致を確認 します。サービスに定義されたラベルを取得します。以下の例では、
ns1
プロジェクトのprometheus-example-app
サービスをクエリーします。$ oc -n ns1 get service prometheus-example-app -o yaml
出力例
labels: app: prometheus-example-app
ServiceMonitor
リソース設定のmatchLabels
app
ラベルが直前のステップのラベルの出力と一致することを確認します。$ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
出力例
apiVersion: v1 kind: Service # ... 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 # ...
変更を適用するためにファイルを保存します。
注記openshift-user-workload-monitoring
プロジェクトのprometheus-operator
は、ログレベルの変更時に自動的に再起動します。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
値が設定マップに含まれる場合、prometheus-operator
Pod が正常に再起動されない可能性があります。-
デバッグログを確認し、Prometheus Operator が
ServiceMonitor
リソースを使用しているかどうかを確認します。ログで他の関連するエラーの有無を確認します。
関連情報
- ユーザー定義のワークロードモニタリング設定マップの作成
-
ServiceMonitor
またはPodMonitor
の作成方法についての詳細は、サービスのモニター法の指定 を参照してください。 - Administrator パースペクティブでメトリックターゲットにアクセスする を参照してください。