検索

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

download PDF

OpenShift Container Platform には、コアプラットフォームコンポーネントのモニターリングを提供する事前に設定され、事前にインストールされた自己更新型のモニターリングスタックが含まれます。OpenShift Container Platform 4.7 では、クラスター管理者はオプションでユーザー定義プロジェクトのモニターリングを有効にできます。

独自のメトリクスが利用できない場合や、Prometheus が多くのディスク領域を消費している場合、以下の手順を実行できます。

7.11.1. ユーザー定義のメトリクスが利用できない理由の調査

ServiceMonitor リソースを使用すると、ユーザー定義プロジェクトでサービスによって公開されるメトリクスの使用方法を判別できます。ServiceMonitor リソースを作成している場合で、メトリクス UI に対応するメトリクスが表示されない場合は、この手順で説明されるステップを実行します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ユーザー定義のワークロードのモニタリングを有効にし、設定している。
  • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • ServiceMonitor リソースを作成している。

手順

  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 app ラベルが直前のステップのラベルの出力と一致することを確認します。

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

      出力例

      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. Prometheus UI でプロジェクトのターゲットステータスを直接確認します。

    1. openshift-user-workload-monitoring プロジェクトで Prometheus インスタンスへのポート転送を確立します。

      $ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090
    2. Web ブラウザーで http://localhost:9090/targets を開き、 Prometheus UI でプロジェクトのターゲットのステータスを直接確認します。ターゲットに関連するエラーメッセージがあるかどうかを確認します。
  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. prometheusOperatorlogLevel: debugdata/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 値が設定マップに含まれる場合、prometheus-operator Pod が正常に再起動されない可能性があります。

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

関連情報

7.11.2. Prometheus が大量のディスク領域を消費している理由の特定

開発者は、キーと値のペアの形式でメトリクスの属性を定義するためにラベルを作成できます。使用できる可能性のあるキーと値のペアの数は、属性について使用できる可能性のある値の数に対応します。数が無制限の値を持つ属性は、バインドされていない属性と呼ばれます。たとえば、customer_id 属性は、使用できる値が無限にあるため、バインドされていない属性になります。

割り当てられるキーと値のペアにはすべて、一意の時系列があります。ラベルに多数のバインドされていない値を使用すると、作成される時系列の数が指数関数的に増加する可能性があります。これは Prometheus のパフォーマンスに影響する可能性があり、多くのディスク領域を消費する可能性があります。

Prometheus が多くのディスクを消費する場合、以下の手段を使用できます。

  • 収集される 収集サンプルの数を確認 します。
  • Prometheus UI での時系列データベース (TSDB) のステータスを確認 して、最も多くの時系列ラベルを作成するラベルについて確認できます。これには、クラスター管理者の権限が必要です。
  • ユーザー定義メトリクスに割り当てられるバインドされていない属性の数を減らすことで、作成される一意の時系列の数を減らします

    注記

    使用可能な値の制限されたセットにバインドされる属性を使用すると、可能なキーと値のペアの組み合わせの数が減ります。

  • ユーザー定義プロジェクト間で 収集可能なサンプル数の数に制限を適用します。これには、クラスター管理者の権限が必要です。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. Administrator パースペクティブで、Monitoring Metrics に移動します。
  2. Expression フィールドで、以下の Prometheus Query Language (PromQL) クエリーを実行します。これにより、収集サンプルの数が最も多い 10 メトリクスが返されます。

    topk(10,count by (job)({__name__=~".+"}))
  3. 予想されるよりも多くの収集サンプルを持つメトリクスに割り当てられたバインドされていないラベル値の数を調査します。

    • メトリクスがユーザー定義のプロジェクトに関連する場合、ワークロードに割り当てられたメトリクスのキーと値のペアを確認します。これらのライブラリーは、アプリケーションレベルで Prometheus クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
    • メトリクスが OpenShift Container Platform のコアプロジェクトに関連する場合、Red Hat サポートケースを Red Hat カスタマーポータル で作成してください。
  4. Prometheus UI で TSDB ステータスを確認します。

    1. Administrator パースペクティブで、Networking Routes に移動します。
    2. Project: 一覧で openshift-monitoring プロジェクトを選択します。
    3. prometheus-k8s 行の URL を選択し、Prometheus UI のログインページを開きます。
    4. Log in with OpenShift を選択し、OpenShift Container Platform 認証情報を使用してログインします。
    5. Prometheus UI で、Status TSDB Status に移動します。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.