7.11. モニターリング関連の問題の調査
OpenShift Container Platform には、コアプラットフォームコンポーネントのモニターリングを提供する事前に設定され、事前にインストールされた自己更新型のモニターリングスタックが含まれます。OpenShift Container Platform 4.7 では、クラスター管理者はオプションでユーザー定義プロジェクトのモニターリングを有効にできます。
独自のメトリクスが利用できない場合や、Prometheus が多くのディスク領域を消費している場合、以下の手順を実行できます。
7.11.2. Prometheus が大量のディスク領域を消費している理由の特定
開発者は、キーと値のペアの形式でメトリクスの属性を定義するためにラベルを作成できます。使用できる可能性のあるキーと値のペアの数は、属性について使用できる可能性のある値の数に対応します。数が無制限の値を持つ属性は、バインドされていない属性と呼ばれます。たとえば、customer_id
属性は、使用できる値が無限にあるため、バインドされていない属性になります。
割り当てられるキーと値のペアにはすべて、一意の時系列があります。ラベルに多数のバインドされていない値を使用すると、作成される時系列の数が指数関数的に増加する可能性があります。これは Prometheus のパフォーマンスに影響する可能性があり、多くのディスク領域を消費する可能性があります。
Prometheus が多くのディスクを消費する場合、以下の手段を使用できます。
- 収集される 収集サンプルの数を確認 します。
- Prometheus UI での時系列データベース (TSDB) のステータスを確認 して、最も多くの時系列ラベルを作成するラベルについて確認できます。これには、クラスター管理者の権限が必要です。
ユーザー定義メトリクスに割り当てられるバインドされていない属性の数を減らすことで、作成される一意の時系列の数を減らします。
注記使用可能な値の制限されたセットにバインドされる属性を使用すると、可能なキーと値のペアの組み合わせの数が減ります。
- ユーザー定義プロジェクト間で 収集可能なサンプル数の数に制限を適用します。これには、クラスター管理者の権限が必要です。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
-
Administrator パースペクティブで、Monitoring
Metrics に移動します。 Expression フィールドで、以下の Prometheus Query Language (PromQL) クエリーを実行します。これにより、収集サンプルの数が最も多い 10 メトリクスが返されます。
topk(10,count by (job)({__name__=~".+"}))
予想されるよりも多くの収集サンプルを持つメトリクスに割り当てられたバインドされていないラベル値の数を調査します。
- メトリクスがユーザー定義のプロジェクトに関連する場合、ワークロードに割り当てられたメトリクスのキーと値のペアを確認します。これらのライブラリーは、アプリケーションレベルで Prometheus クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
- メトリクスが OpenShift Container Platform のコアプロジェクトに関連する場合、Red Hat サポートケースを Red Hat カスタマーポータル で作成してください。
Prometheus UI で TSDB ステータスを確認します。
-
Administrator パースペクティブで、Networking
Routes に移動します。 -
Project: 一覧で
openshift-monitoring
プロジェクトを選択します。 -
prometheus-k8s
行の URL を選択し、Prometheus UI のログインページを開きます。 - Log in with OpenShift を選択し、OpenShift Container Platform 認証情報を使用してログインします。
-
Prometheus UI で、Status
TSDB Status に移動します。
-
Administrator パースペクティブで、Networking
関連情報
- 収集サンプルの制限を設定し、関連するアラートルールを作成する方法についての詳細は、ユーザー定義プロジェクトの収集サンプル制限の設定 を参照してください。