Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第34章 クラスターメトリクスの有効化

34.1. 概要
リンクのコピー

kubelet はメトリクスを公開しますが、これは Heapster によって収集され、バックエンドに保存されます。

OpenShift Container Platform 管理者は、すべてのコンテナーとコンポーネントから収集したクラスターのメトリクスを 1 つのユーザーインターフェースで表示できます。これらのメトリクスは、Horizontal Pod Autoscaler によるスケーリングのタイミングと方法の決定にも使用されます。

このトピックでは、Hawkular Metric をメトリクスエンジンとして使用した例について説明します。このエンジンはデータを Cassandra データベースに永続的に保存します。これが設定されると、CPU、メモリー、ネットワークベースのメトリクスを OpenShift Container Platform Web コンソールから表示できるようになり、Horizontal Pod Autoscaler で使用できるようになります。

Heapster はマスターサーバーからすべてのノードの一覧を取得して、/stats エンドポイントから各ノードへ個別に通信します。ここから、Heapster は CPU、メモリー、ネットワーク使用状況のメトリクスを収集して、Hawkular Metrics にエクスポートします。

kubelet で利用できるストレージボリュームメトリクスは、/stats エンドポイントからは利用できません。ただし、/metrics エンドポイントからは利用できます。詳細は、Prometheus 経由の OpenShift Container Platform メトリクスについて参照してください。

Web コンソールで個々の Pod を参照すると、メモリーと CPU に個別のスパークラインチャートが表示されます。表示される時間範囲は選択可能で、これらのチャートは 30 秒ごとに自動更新されます。Pod に複数のコンテナーがある場合は、メトリクスを表示する特定のコンテナーを選択します。

リソース制限がプロジェクトに定義されている場合、各 Pod のドーナツチャートも表示できます。ドーナツチャートはリソース制限に対する使用量を示します。たとえば、145 Available of 200 MiB は、ドーナツチャートでは 55 MiB Used と表示されます。

34.2. 作業を開始する前に
リンクのコピー

Ansible Playbook はクラスターメトリクスのデプロイとアップグレードに使用できます。通常インストール (Advanced installation) のセクションに精通しておくようにしてください。Ansible を使用するための予備知識や、設定に関する情報が記載されています。クラスターメトリクスのさまざまな領域を設定するためのパラメーターが Ansible インベントリーファイルに追加されています。

以下に示すセクションでは、デフォルト値を変更するために Ansible インベントリーファイルに追加できる各種の領域とパラメーターを説明します。

34.3. メトリクスプロジェクト
リンクのコピー

自動スケールを機能させるには、クラスターメトリクスのコンポーネントを openshift-infra プロジェクトにデプロイする必要があります。とくに Horizontal Pod Autoscaler はこのプロジェクトを使用して Heapster サービスを検出し、それをメトリクスの取得に使用します。メトリクスプロジェクトは、openshift_metrics_project をインベントリーファイルに追加することで変更できます。

34.4. メトリクスデータストレージ
リンクのコピー

メトリクスデータは、永続ストレージまたは一時的な Pod ボリュームのいずれかに保存できます。

34.4.1. 永続ストレージ
リンクのコピー

OpenShift Container Platform クラスターメトリクスを永続ストレージと共に実行すると、メトリクスは永続ボリュームに保存され、再起動または再作成される Pod を維持できます。これは、メトリクスデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、メトリクス Pod に永続ストレージを設定することを強く推奨します。

Cassandra ストレージのサイズ要件は Pod 数に依存します。セットアップで十分なサイズ要件を確保し、ディスクが一杯にならないように使用状況を監視するのは、管理者の責任です。永続ボリューム要求のサイズは openshift_metrics_cassandra_pvc_size ansible variable で指定され、デフォルトは 10 GB に設定されています。

動的にプロビジョニングされた永続ボリュームを使用する場合は、インベントリーファイルで openshift_metrics_cassandra_storage_type 変数を dynamic に設定します。

34.4.2. クラスターメトリクスの容量計画
リンクのコピー

openshift_metrics Ansible ロールを実行した後、oc get pods の出力は以下のようになります。 

 # oc get pods -n openshift-infra
 NAME                                READY             STATUS      RESTARTS          AGE
 hawkular-cassandra-1-l5y4g          1/1               Running     0                 17h
 hawkular-metrics-1t9so              1/1               Running     0                 17h
 heapster-febru                      1/1               Running     0                 17h
Copy to Clipboard Toggle word wrap

OpenShift Container Platform メトリクスは Cassandra データベースを使用して保存されます。このデータベースはopenshift_metrics_cassandra_limits_memory: 2G の設定でデプロイされます。この値は Cassandra の開始スクリプトで決定される空きメモリー容量に応じてさらに調整できます。この値はほとんどの OpenShift Container Platform メトリクスインストールに対応しますが、クラスターメトリクスをデプロイする前に、環境変数を使用して MAX_HEAP_SIZE と ヒープの新しい生成サイズ HEAP_NEWSIZE を Cassandra Dockerfile で変更できます。

デフォルトで、メトリクスデータは 7 日間保存されます。7 日が経過すると、Cassandra は最も古いメトリクスデータのパージを開始します。削除された Pod とプロジェクトのメトリクスデータは自動的にはパージされません。7 日を超えたデータのみが削除されます。

例34.1 10 のノードと 1000 の Pod による累積データ

10 のノードと 1000 の Pod を含むテストシナリオでは、24 時間で 2.5 GB のメトリクスデータが累積されました。このため、このシナリオでのメトリクスデータの容量計画の計算式は以下のようになります。

(((2.5 × 109) ÷ 1000) ÷ 24) ÷ 106 = ~0.125 MB/hour per pod.

例34.2 120 のノードと 10000 の Pod による累積データ

120 のノードと 10000 の Pod を含むテストシナリオでは、24 時間で 25 GB のメトリクスデータが累積されました。このため、このシナリオにおけるメトリクスデータの容量計画の計算式は以下のようになります。

(((11.410 × 109) ÷ 1000) ÷ 24) ÷ 106 = 0.475 MB/hour

 1000 の Pod10000 の Pod

24 時間で累積される Cassandra ストレージデータ (デフォルトのメトリクスパラメーター)

2.5 GB

11.4 GB

openshift_metrics_duration の 7 日間および openshift_metrics_resolution の 30 秒間というデフォルト値を維持する場合、Cassandra Pod の週次のストレージ要件は以下のようになります。

 1000 の Pod10000 の Pod

7 日間で累積される Cassandra ストレージデータ (デフォルトのメトリクスパラメーター)

20 GB

90 GB

先の表では、予期せずモニタリングされた Pod 使用量のバッファーとして、予期されたストレージ容量に対して予備の 10% が追加されています。

警告

Cassandra の永続化ボリュームに十分な空き容量がなくなると、データ損失が発生します。

クラスターメトリクスを永続ストレージと共に使用するには、永続ボリュームに ReadWriteOnce アクセスモードが設定されていることを確認します。このモードがアクティブではない場合、Persistent Volume Claim (永続ボリューム要求) は永続ボリュームを特定できず、Cassandra の開始に失敗します。

永続ストレージをメトリックコンポーネントと併用するには、十分なサイズの永続ボリュームがあることを確認します。Persistent Volume Claim (永続ボリューム要求) の作成は OpenShift Ansible openshift_metrics ロールによって処理されます。

OpenShift Container Platform メトリクスは、動的にプロビジョニングされた永続ボリュームもサポートします。この機能を OpenShift Container Platform メトリクスで使用するには、openshift_metrics_cassandra_storage_type の値を dynamic に設定する必要があります。EBS、GCE、Cinder ストレージバックエンドを使用すると永続ボリュームを動的にプロビジョニングできます。

パフォーマンスの設定とクラスターメトリクス Pod のスケーリングについては、「Scaling Cluster Metrics」のトピックを参照してください。

表34.1 クラスター内のノード/Pod の数に基づく Cassandra データベースのストレージ要件
ノード数Pod 数Cassandra ストレージの増加率1 日あたりの Cassandra ストレージの増加量1 週間あたりの Cassandra ストレージの増加量

210

10500

1 時間あたり 500 MB

15 GB

75 GB

990

11000

1 時間あたり 1 GB

30 GB

210 GB

上記の計算では、ストレージ要件が計算値を超過しないようにするためのオーバーヘッドとして、予期されたサイズのおよそ 20% が追加されています。

METRICS_DURATION と METRICS_RESOLUTION の値がデフォルト (それぞれ 7 日間と 15 秒間) に維持されている場合、1 週間の Cassandra ストレージサイズ要件を上記の値に設定することを問題なく計画できるでしょう。

警告

OpenShift Container Platform メトリクスは、メトリクスデータのデータストアとして Cassandra データベースを使用するので、メトリクス設定のプロセスで USE_PERSISTANT_STORAGE=true に設定した場合には、NFS でネットワークストレージの上層に PV がデフォルトで配置されます。ただし、Cassandra ドキュメントにあるように、ネットワークストレージと、Cassandra を組み合わせて使用することは推奨していません。

既知の問題と制限

テストの結果として、heapster メトリクスコンポーネントは最大 25,000 の Pod を処理できることが確認されています。Pod 数がこの数を超過すると、Heapster のメトリクス処理が遅くなり始め、メトリクスグラフが表示されなくなる可能性があります。Heapster がメトリクスを収集できる Pod 数を増加する作業と、メトリクスを収集する代替ソリューションのアップストリーム開発が進められています。

34.4.3. 非永続ストレージ
リンクのコピー

OpenShift Container Platform クラスターメトリクスを非永続ストレージと共に実行すると、Pod の削除時に、保存されていたすべてのメトリクスが削除されます。クラスターメトリクスは非永続データで実行する方がはるかに容易ですが、非永続データで実行すると永続的なデータが損失するリスクが伴います。ただし、メトリクスはコンテナーが再起動されても存続します。

非永続ストレージを使用するためには、インベントリーファイルで openshift_metrics_cassandra_storage_type 変数を emptyDir に設定する必要があります。

注記

非永続ストレージを使用している場合、メトリクスデータは、Cassandra Pod が実行されるノード上の /var/lib/origin/openshift.local.volumes/pods に書き込まれます。/var にメトリクスを保存するために十分な空き容量があることを確認してください。

34.5. メトリクス Ansible ロール
リンクのコピー

OpenShift Container Platform の Ansible openshift_metrics ロールは、Configuring Ansible インベントリーファイルにある変数を使用して、すべてのメトリクスコンポーネントを設定し、デプロイします。

34.5.1. メトリクス Ansible 変数の指定
リンクのコピー

OpenShift Ansible に含まれる openshift_metrics ロールはクラスターメトリクスをデプロイするタスクを定義します。以下は、上書きが必要な場合にインベントリーファイルに追加できるロール変数の一覧です。

表34.2 Ansible 変数
変数説明

openshift_metrics_install_metrics

true の場合にメトリクスをデプロイします。そうでない場合はアンデプロイします。

openshift_metrics_start_cluster

コンポーネントをデプロイした後にメトリクスクラスターを起動します。

openshift_metrics_image_prefix

コンポーネントイメージのプレフィックス。openshift3/ose-metrics-cassandra:v3.9 で、プレフィックス openshift/ose- を設定します。

openshift_metrics_image_version

コンポーネントイメージのバージョン。たとえば、openshift3/ose-metrics-cassandra:v3.9.11 でバージョンを v3.9.11 に設定し、常に最新の 3.9 イメージを取得するには v3.9 に設定します。

openshift_metrics_startup_timeout

再起動を試行する前に Hawkular Metrics および Heapster が起動するまでの時間 (秒単位)。

openshift_metrics_duration

メトリクスがパージされるまで保管される日数。

openshift_metrics_resolution

メトリクスが収集される頻度。数値と時間を示す識別子である秒 (s)、分 (m)、時間 (h) で定義されます。

openshift_metrics_cassandra_pvc_prefix

Cassandra に作成される Persistent Volume Claim (永続ボリューム要求) のプレフィックス。プレフィックスには 1 から始まる連番が付加されます。

openshift_metrics_cassandra_pvc_size

各 Cassandra ノードの Persistent Volume Claim (永続ボリューム要求) のサイズ。

openshift_metrics_cassandra_storage_class_name

明示的にストレージクラスを設定する場合には、openshift_metrics_cassandra_storage_type を emptydir または dynamic に設定しないでください。

openshift_metrics_cassandra_storage_type

emptyDir を一時ストレージとして使用します (テスト用)。pv を永続ボリュームとして使用します。これはインストール前に作成する必要があります。または dynamic を動的永続ボリュームとして使用します。

openshift_metrics_cassandra_replicas

メトリクススタックの Cassandra ノードの数。この値は Cassandra レプリケーションコントローラーの数を指定します。

openshift_metrics_cassandra_limits_memory

Cassandra Pod のメモリー制限。たとえば、値 2Gi にすると Cassandra のメモリーは 2 GB に制限されます。この値は開始スクリプトによって、スケジュールされているノードの空きメモリー容量に基づいてさらに調整できます。

openshift_metrics_cassandra_limits_cpu

Cassandra Pod の CPU 制限。値 4000m (4000 ミリコア) の場合、Cassandra は 4 基の CPU に制限されます。

openshift_metrics_cassandra_requests_memory

Cassandra Pod について要求するメモリー量。値 2Gi の場合、2 GB のメモリーが要求されます。

openshift_metrics_cassandra_requests_cpu

Cassandra Pod の CPU 要求。値 4000m (4000 ミリコア) の場合、4 基の CPU が要求されます。

openshift_metrics_cassandra_storage_group

Cassandra に使用される補助ストレージグループ。

openshift_metrics_cassandra_nodeselector

必要な既存のノードセレクターを設定して、Pod が特定のラベルを持つノードに配置されるようにします。たとえば、{"region":"infra"} とします。

openshift_metrics_hawkular_ca

Hawkular 証明書に署名するための認証局 (CA) ファイル (オプション)。

openshift_metrics_hawkular_cert

Hawkular メトリクスへのルートを再暗号化するために使用される証明書ファイル。証明書にはルートに使用されるホスト名を含める必要があります。これが指定されない場合、デフォルトのルーター証明書が使用されます。

openshift_metrics_hawkular_key

Hawkular 証明書で使用されるキーファイル。

openshift_metrics_hawkular_limits_memory

Hawkular Pod を制限するためのメモリー量。値 2Gi の場合、Hawkular Pod は 2 GB のメモリーに制限されます。この値は開始スクリプトで、スケジュールされているノードの空きメモリー容量に基づいてさらに調整できます。

openshift_metrics_hawkular_limits_cpu

Hawkular Pod の CPU 制限。値 4000m (4000 ミリコア) の場合、Hawkular Pod は 4 基の CPU に制限されます。

openshift_metrics_hawkular_replicas

Hawkular メトリクスのレプリカの数。

openshift_metrics_hawkular_requests_memory

Hawkular Pod について要求するメモリー量。値 2Gi の場合、2 GB のメモリーが要求されます。

openshift_metrics_hawkular_requests_cpu

Hawkular Pod の CPU 要求。値 4000m (4000 ミリコア) の場合、4 基の CPU が要求されます。

openshift_metrics_hawkular_nodeselector

必要な既存のノードセレクターを設定して、Pod が特定のラベルを持つノードに配置されるようにします。たとえば、{"region":"infra"} とします。

openshift_metrics_heapster_allowed_users

許可する CN のカンマ区切りの一覧。デフォルトで、OpenShift サービスプロキシーが接続できるように設定されます。Horizontal Pod Autoscaling を適切に機能させるには、上書きする際に system:master-proxy を一覧に追加します。

openshift_metrics_heapster_limits_memory

Heapster Pod を制限するメモリー量。値 2Gi の場合、Heapster Pod は 2 GB のメモリーに制限されます。

openshift_metrics_heapster_limits_cpu

Heapster Pod の CPU 制限。値 4000m (4000 ミリコア) の場合、Heapster Pod は 4 基の CPU に制限されます。

openshift_metrics_heapster_requests_memory

Heapster Pod について要求するメモリー量。値 2Gi の場合、2 GB のメモリーが要求されます。

openshift_metrics_heapster_requests_cpu

Heapster Pod の CPU 要求。値 4000m (4000 ミリコア) の場合、4 基の CPU が要求されます。

openshift_metrics_heapster_standalone

Heapster のみをデプロイします。Hawkular Metrics や Cassandra コンポーネントはデプロイされません。

openshift_metrics_heapster_nodeselector

必要な既存のノードセレクターを設定して、Pod が特定のラベルを持つノードに配置されるようにします。たとえば、{"region":"infra"} とします。

openshift_metrics_install_hawkular_agent

Hawkular OpenShift Agent (HOSA) をインストールするには true に設定します。インストールから HOSA を削除するには false に設定します。HOSA を使用すると Pod からカスタムメトリクスを収集できます。このコンポーネントは現在テクノロジープレビュー中であり、デフォルトではインストールされません。

openshift_metrics_hawkular_hostname

Hawkular Metrics ルートのホスト名を使用するので、openshift_metrics Ansible ロールを実行する場合に設定します。この値は、完全修飾ドメイン名と対応している必要があります。

注記

OpenShift Container Platform 上での Hawkular OpenShift Container Platform Agent はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は Red Hat の実稼働サービスレベルアグリーメント (SLA) ではサポートされておらず、機能的にも完全でない可能性があります。また、Red Hat はテクノロジープレビュー機能を実稼働環境での使用することを推奨していません。この機能を使用することで、今後発売される製品の機能に対して早期アクセスが可能となるため、お客様は機能をテストしたり、開発プロセス中にフィードバックを提供することができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

要求と制限を指定する方法の詳細については、「コンピュートリソース」を参照してください。

Cassandra で永続ストレージを使用している場合、openshift_metrics_cassandra_pvc_size 変数を使用してクラスターに十分なディスクサイズを設定することは管理者の責任です。また、管理者はディスクが一杯にならないようにディスク使用量を監視する必要もあります。

警告

Cassandra の永続化ボリュームの領域が不足するとデータが損失します。

その他のすべての変数はオプションで、詳細なカスタマイズが可能です。たとえば、Kubernetes マスターを https://kubernetes.default.svc:443 で使用できないカスタムインストールでは、代わりに openshift_metrics_master_url パラメーターを使用して値を指定できます。特定のバージョンのメトリクスコンポーネントをデプロイするには、openshift_metrics_image_version 変数を変更します。

警告

latest を openshift_metrics_image_version で使用しないことを強く推奨します。latest バージョンは使用できる最新のバージョンに対応し、現在実行している OpenShift Container Platform で機能しない新しいバージョンが導入された場合に問題が発生します。

34.5.2. シークレットの使用
リンクのコピー

OpenShift Container Platform Ansible openshift_metrics ロールは、コンポーネント間で使用する自己署名証明書を自動生成し、re-encrypt ルートを生成して Hawkular Metrics サービスを公開します。このルートによって Web コンソールで Hawkular Metrics サービスにアクセスできます。

Web コンソールを実行するブラウザーがこのルート経由の接続を信頼するには、ルートの証明書を信頼する必要があります。これは、信頼された認証局によって署名されたユーザー固有の証明書を提供することで実行できます。openshift_metrics ロールによって、ユーザー固有の証明書を指定でき、この証明書がルートの作成時に使用されます。

ユーザー固有の証明書を提供しない場合、ルーターのデフォルト証明書が使用されます。

34.5.2.1. ユーザー固有の証明書の提供
リンクのコピー

ユーザー固有の証明書を提供し、re-encrypt ルートで使用するには、openshift_metrics_hawkular_cert、openshift_metrics_hawkular_key、openshift_metrics_hawkular_ca 変数をインベントリーファイルで設定します。

hawkular-metrics.pem 値には .pem 形式の証明書を含める必要があります。この pem ファイルに hawkular-metrics-ca.cert シークレット経由で署名した認証局の証明書を提供することも必要です。

詳細については、re-encrypt ルートに関するマニュアルを参照してください。

34.6. メトリックコンポーネントのデプロイ
リンクのコピー

すべてのメトリックコンポーネントのデプロイと設定は OpenShift Container Platform Ansible で処理されるので、すべてを 1 つのステップでデプロイできます。

以下の例では、デフォルトパラメーターを使用して、メトリクスのデプロイ時に永続ストレージを使用する場合の方法と使用しない場合の方法を示しています。

重要

Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。

重要

アップストリームの Kubernetes ルールに応じて、eth0 のデフォルトインターフェースでのみメトリクスを収集できます。

例34.3 永続ストレージを使用するデプロイ

以下のコマンドでは、Hawkular Metrics ルートを hawkular-metrics.example.com を使用し、永続ストレージを使用してデプロイされるように設定します。

十分な容量を備えた永続ボリュームを用意してください。 

$ ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-metrics/config.yml \
   -e openshift_metrics_install_metrics=True \
   -e openshift_metrics_hawkular_hostname=hawkular-metrics.example.com \
   -e openshift_metrics_cassandra_storage_type=pv
Copy to Clipboard Toggle word wrap

例34.4 永続ストレージを使用しないデプロイ

以下のコマンドでは、Hawkular Metrics ルートを hawkular-metrics.example.com を使用し、永続ストレージを使用しないでデプロイするように設定します。 

$ ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-metrics/config.yml \
   -e openshift_metrics_install_metrics=True \
   -e openshift_metrics_hawkular_hostname=hawkular-metrics.example.com
Copy to Clipboard Toggle word wrap
警告

これは永続ストレージを使用しないでデプロイされるため、メトリックデータが損失する可能性があります。

34.6.1. メトリクスの診断
リンクのコピー

メトリクススタックの状態の評価に使用できるメトリクス用の診断があります。メトリクスの診断を実行するには、以下のコマンドを実行します。 

$ oc adm diagnostics MetricsApiProxy
Copy to Clipboard Toggle word wrap

34.7. メトリクスのパブリック URL の設定
リンクのコピー

OpenShift Container Platform Web コンソールは、Hawkular Metrics サービスから受信したデータを使用してグラフを表示します。Hawkular Metrics サービスにアクセスする URL は、マスター webconsole-config configmap ファイルでmetricsPublicURL オプションを使用して設定する必要があります。この URL は メトリクスコンポーネントのデプロイメント時に使用される openshift_metrics_hawkular_hostname インベントリー変数で作成されるルートに対応します。

注記

openshift_metrics_hawkular_hostname はコンソールにアクセスするブラウザーで解決できる必要があります。

たとえば、openshift_metrics_hawkular_hostname が hawkular-metrics.example.com に対応する場合、webconsole-config configmap ファイルに以下の変更を行う必要があります。 

clusterInfo:
  ...
  metricsPublicURL: "https://hawkular-metrics.example.com/hawkular/metrics"
Copy to Clipboard Toggle word wrap

webconsole-config configmap ファイルを更新し、保存した後に、OpenShift Container Platform インスタンスを再起動する必要があります。

OpenShift Container Platform サーバーが再び稼働すると、メトリクスが Pod 概要のページに表示されます。

Important

自己署名証明書を使用している場合、Hawkular Metrics サービスはコンソールとは別のホスト名でホストされ、別の証明書を使用することに注意してください。場合によっては、ブラウザータブを明示的に開いて metricsPublicURL に指定される値を直接参照して、この証明書を受け入れる必要があります。

これを回避するには、お使いのブラウザーで許可されるように設定された証明書を使用します。

34.8. Hawkular Metrics への直接アクセス
リンクのコピー

メトリクスに直接アクセスし、これを管理するには、Hawkular Metrics API を使用します。

注記

API から Hawkular Metrics にアクセスした場合は、読み取り操作しか実行できません。メトリクスの書き込みはデフォルトで無効にされています。個々のユーザーがメトリクスの書き込みも実行できるようにするには、openshift_metrics_hawkular_user_write_access 変数を true に設定する必要があります。

ただし、デフォルトの設定を使用して Heapster からのみメトリクスを入力ことを推奨します。書き込みアクセスが有効になると、どのユーザーもメトリクスをシステムに書き込めるようになり、これがパフォーマンスに影響を及ぼし、Cassandra のディスク使用量が予期せずに増加する可能性があります。

Hawkular Metrics のマニュアルでは、API の使用方法を説明していますが、OpenShift Container Platform で使用するように設定されたバージョンの Hawkular Metrics とは処理方法に多少の違いがあります。

34.8.1. OpenShift Container Platform プロジェクトと Hawkular テナント
リンクのコピー

Hawkular Metrics はマルチテナントアプリケーションで、OpenShift Container Platform 内のプロジェクトが Hawkular Metrics 内のテナントに対応するように設定されます。

このため、MyProject という名前のプロジェクトのメトリクスにアクセスする場合は、Hawkular-Tenant ヘッダーを MyProject に設定する必要があります。

また、_system という名前の特殊なテナントもあり、これにはシステムレベルのメトリクスが含まれています。これにアクセスするには、cluster-reader または cluster-admin レベルの権限が必要です。

34.8.2. 承認
リンクのコピー

Hawkular Metrics サービスは、ユーザーを OpenShift Container Platform に対して認証し、ユーザーがアクセスしようとしているプロジェクトに対するアクセスを持つかどうかを判別します。

Hawkular Metrics はクライアントからベアラートークンを受け取り、SubjectAccessReview を使用して、OpenShift Container Platform サーバーでトークンを検証します。ユーザーがプロジェクトに対する適切な読み取り権限を持つ場合、ユーザーはこのプロジェクトのメトリクスを読み取ることができます。_system テナントについては、このテナントからの読み取りを要求するユーザーには、cluster-reader パーミッションがなければなりません。

Hawkular Metrics API にアクセスする場合、ベアラートークンは Authorization ヘッダーに渡す必要があります。

34.9. OpenShift Container Platform クラスターメトリクス Pod のスケーリング
リンクのコピー

クラスターメトリクス機能のスケーリングに関する情報は、『Scaling and Performance Guide』に記載されています。

34.10. 集計されるロギングとの統合
リンクのコピー

Hawkular Alert は Aggregated Logging の Elasticsearch に接続して、ログイベントに応答できるようにする必要があります。デフォルトで、Hawkular は起動時にデフォルトの場所にある Elasticsearch を見つけようとします (namespace logging、Pod logging-es)。Aggregated Logging が Hawkular の後にインストールされた場合、新規 Elasticsearch サーバーを認識できるようにするには Hawkular Metrics Pod の再起動が必要になる場合があります。統合が適切に設定されていない場合は、これについて以下のようなメッセージが出され、Hawkular ブートログに明示的に記録されます。 

Failed to import the logging certificate into the store. Continuing, but the
logging integration might fail.
Copy to Clipboard Toggle word wrap

または、以下が表示されます。 

Could not get the logging secret! Status code: 000. The Hawkular Alerts
integration with Logging might not work properly.
Copy to Clipboard Toggle word wrap

この機能はバージョン 3.7.0 以降で使用できます。以下のようなエントリーのログをチェックして、ロギングを利用できるかどうか確認します。 

Retrieving the Logging's CA and adding to the trust store, if Logging is
available.
Copy to Clipboard Toggle word wrap

34.11. クリーンアップ
リンクのコピー

OpenShift Container Platform Ansible openshift_metrics ロールによってデプロイされたものはすべて、以下の手順を実行して削除できます。 

$ ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-metrics/config.yml \
   -e openshift_metrics_install_metrics=False
Copy to Clipboard Toggle word wrap

34.12. OpenShift Container Platform 上の Prometheus
リンクのコピー

Prometheus はスタンドアロンでオープンソースシステムの、モニタリングおよびアラートツールキットです。Prometheus を使用すると、OpenShift Container Platform システムリソースのメトリクスとアラートを視覚化できます。

重要

OpenShift Container Platform 上での Prometheus はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

34.12.1. Prometheus ロール変数の設定
リンクのコピー

Prometheus ロールは以下を作成します。

  • openshift-metrics namespace
  • Prometheus clusterrolebinding およびサービスアカウント
  • OAuth プロキシーの背後の Prometheus、Alertmanager および Alert Buffer をステートフルセットとして備えた Prometheus Pod
  • Prometheus と prometheus-alerts ConfigMaps
  • Prometheus と Prometheus Alerts サービスおよび直接ルート

Prometheus デプロイメントはデフォルトで有効にされます。openshift_prometheus_state を absent に設定してこれをアンインストールします。以下は例になります。 

# openshift_prometheus_state=absent
Copy to Clipboard Toggle word wrap

以下のロール変数を設定して、Prometheus をインストールし、設定します。

表34.3 Prometheus 変数
変数説明

openshift_prometheus_state

デフォルト値は present です。これにより、Prometheus のインストールまたは更新が行われます。Prometheus をアンインストールするには、absent に設定します。

openshift_prometheus_namespace

コンポーネントがデプロイされるプロジェクト namespace。デフォルトは openshift-metrics に設定されます。例: openshift_prometheus_namespace=${USER_PROJECT}

openshift_prometheus_node_selector

Prometheus がデプロイされるノードのセレクターです。デフォルトは node-role.kubernetes.io/infra=true に設定されます。

openshift_prometheus_storage_kind

Prometheus の PV を作成するために設定します。例: openshift_prometheus_storage_kind=nfs

openshift_prometheus_alertmanager_storage_kind

Alertmanager の PV を作成するために設定します。例: openshift_prometheus_alertmanager_storage_kind=nfs

openshift_prometheus_alertbuffer_storage_kind

Alert Buffer の PV を作成するために設定します。例: openshift_prometheus_alertbuffer_storage_kind=nfs

openshift_prometheus_storage_type

Prometheus の PVC を作成するために設定します。例: openshift_prometheus_storage_type=pvc

openshift_prometheus_alertmanager_storage_type

Alertmanager の PVC を作成するために設定します。例: openshift_prometheus_alertmanager_storage_type=pvc

openshift_prometheus_alertbuffer_storage_type

Alert Buffer の PVC を作成するために設定します。例: openshift_prometheus_alertbuffer_storage_type=pvc

openshift_prometheus_additional_rules_file

追加の Prometheus ルールファイル。デフォルトでnull に設定されます。

34.12.2. Ansible インストーラーを使用した Prometheus のデプロイ
リンクのコピー

重要

Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。

Ansible インストーラーは、Prometheus をデプロイするデフォルトの方法です。

Playbook を実行します。 

$ ansible-playbook -vvv -i ${INVENTORY_FILE} playbooks/openshift-prometheus/config.yml
Copy to Clipboard Toggle word wrap
注記

node-role.kubernetes.io/infra=true のラベルの付いたノードがあることを確認します。このラベルは openshift_prometheus_node_selector のデフォルト値です。他のノードセレクターを使用する必要がある場合は、「ノードセレクターを使用したデプロイ」を参照してください。

34.12.2.1. Prometheus をデプロイする他の方法
リンクのコピー

ノードセレクターを使用したデプロイ

Prometheus をデプロイするノードにラベルを付けます。 

# oc adm label node/$NODE ${KEY}=${VALUE}
Copy to Clipboard Toggle word wrap

Ansible とコンテナーリソースを使って Prometheus をデプロイします。 

# Set node selector for prometheus
openshift_prometheus_node_selector={"${KEY}":"${VALUE}"}
Copy to Clipboard Toggle word wrap

Playbook を実行します。 

$ ansible-playbook -vvv -i ${INVENTORY_FILE} playbooks/openshift-prometheus/config.yml
Copy to Clipboard Toggle word wrap

デフォルト以外の namespace を使用したデプロイ

namespace を特定します。 

# Set non-default openshift_prometheus_namespace
openshift_prometheus_namespace=${USER_PROJECT}
Copy to Clipboard Toggle word wrap

Playbook を実行します。 

$ ansible-playbook -vvv -i ${INVENTORY_FILE} playbooks/openshift-prometheus/config.yml
Copy to Clipboard Toggle word wrap

34.12.2.2. Prometheus Web UI へのアクセス
リンクのコピー

Prometheus サーバーは localhost:9090 で Web UI を自動的に公開します。Prometheus Web UI にはview ロールでアクセスできます。

34.12.2.3. Prometheus での OpenShift Container Platform の設定
リンクのコピー

Prometheus のストレージ関連の変数

Prometheus の各コンポーネント (Prometheus、Alertmanager、Alert Buffer、OAuth プロキシーを含む) を使用して、対応するロール変数を設定して PV 要求を設定できます。以下は例になります。 

openshift_prometheus_storage_type: pvc
openshift_prometheus_alertmanager_pvc_name: alertmanager
openshift_prometheus_alertbuffer_pvc_size: 10G
openshift_prometheus_pvc_access_modes: [ReadWriteOnce]
Copy to Clipboard Toggle word wrap

Prometheus アラートルールファイル変数

追加のルール変数へのパスを設定すると、アラートルールを含む外部ファイルを追加できます。 

openshift_prometheus_additional_rules_file: <PATH>
Copy to Clipboard Toggle word wrap

ファイルは、Prometheus アラートルールの形式に準拠する必要があります。以下の例では、クラスターノードの 1 つがダウンしている時にアラートを送信するルールを設定しています。 

groups:
- name: example-rules
  interval: 30s # defaults to global interval
  rules:
  - alert: Node Down
    expr: up{job="kubernetes-nodes"} == 0
    for: 10m
1 

    annotations:
      miqTarget: "ContainerNode"
      severity: "HIGH"
      message: "{{ '{{' }}{{ '$labels.instance' }}{{ '}}' }} is down"
Copy to Clipboard Toggle word wrap
1
オプションの for の値は、この要素に関するアラートを送信する前に Prometheus が待機する時間を指定します。たとえば、10m に設定すると、Prometheus は、この問題が発生してからアラートを送信するまで 10 分待ちます。

リソース制限を制御する Prometheus 変数

Prometheus の各コンポーネント (Prometheus、Alertmanager、Alert Buffer、OAuth プロキシーを含む) を使用して、対応するロール変数を設定することで、CPU、メモリー制限および要求を指定できます。以下は例になります。 

openshift_prometheus_alertmanager_limits_memory: 1Gi
openshift_prometheus_oauth_proxy_cpu_requests: 100m
Copy to Clipboard Toggle word wrap

詳細については、「OpenShift Prometheus」を参照してください。

注記

openshift_metrics_project: openshift-infra がインストールされると、メトリクスは http://${POD_IP}:7575/metrics エンドポイントから収集できるようになります。

34.12.3. Prometheus 経由の OpenShift Container Platform メトリクス
リンクのコピー

システムの状態は、システムが出力するメトリクスによって測定できます。このセクションでは、ストレージサブシステムおよびクラスターの健全性を識別する現行のメトリクスと提案されているメトリクスについて説明します。

34.12.3.1. 現行のメトリクス
リンクのコピー

このセクションでは、現時点の Kubernetes のストレージサブシステムから出力されるメトリクスについて説明します。

クラウドプロバイダー API 呼び出しメトリクス

このメトリクスは、すべての cloudprovider API 呼び出しの成功と失敗の時刻と回数を報告します。これらのメトリクスには aws_attach_time と aws_detach_time が含まれています。出力されるメトリクスのタイプはヒストグラムであるため、Prometheus はこれらのメトリクスについての合計、カウント、バケットメトリクスも生成します。

GCE からの cloudprovider メトリクスの概要のサンプル:

cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
Copy to Clipboard Toggle word wrap

AWS からの cloudprovider メトリクスの概要のサンプル:

cloudprovider_aws_api_request_duration_seconds { request = "attach_volume"}
cloudprovider_aws_api_request_duration_seconds { request = "detach_volume"}
cloudprovider_aws_api_request_duration_seconds { request = "create_tags"}
cloudprovider_aws_api_request_duration_seconds { request = "create_volume"}
cloudprovider_aws_api_request_duration_seconds { request = "delete_volume"}
cloudprovider_aws_api_request_duration_seconds { request = "describe_instance"}
cloudprovider_aws_api_request_duration_seconds { request = "describe_volume"}
Copy to Clipboard Toggle word wrap

詳細は、「Cloud Provider (specifically GCE and AWS) metrics for Storage API calls」を参照してください。

ボリューム操作のメトリクス

これらのメトリクスは、ストレージ操作が開始されてからの所要時間を報告します。これらのメトリクスはプラグインレベルで操作時間を追跡しますが、goroutine の実行時間や内部キューからピックアップされる操作にかかった時間は除外されます。これらのメトリクスのタイプはヒストグラムです。

ボリューム操作メトリクスの概要のサンプル

storage_operation_duration_seconds { volume_plugin = "aws-ebs", operation_name = "volume_attach" }
storage_operation_duration_seconds { volume_plugin = "aws-ebs", operation_name = "volume_detach" }
storage_operation_duration_seconds { volume_plugin = "glusterfs", operation_name = "volume_provision" }
storage_operation_duration_seconds { volume_plugin = "gce-pd", operation_name = "volume_delete" }
storage_operation_duration_seconds { volume_plugin = "vsphere", operation_name = "volume_mount" }
storage_operation_duration_seconds { volume_plugin = "iscsi" , operation_name = "volume_unmount" }
storage_operation_duration_seconds { volume_plugin = "aws-ebs", operation_name = "unmount_device" }
storage_operation_duration_seconds { volume_plugin = "cinder" , operation_name = "verify_volumes_are_attached" }
storage_operation_duration_seconds { volume_plugin = "<n/a>" , operation_name = "verify_volumes_are_attached_per_node" }
Copy to Clipboard Toggle word wrap

詳細は、「Volume operation metrics」を参照してください。

ボリューム統計メトリクス

これらのメトリクスは通常、PVC の使用状況の統計を報告します (空き領域に対する使用中の領域など)。出力されるメトリクスのタイプはゲージです。

表34.4 ボリューム統計メトリクス
メトリクス種別ラベル/タグ

volume_stats_capacityBytes

ゲージ

namespace,persistentvolumeclaim,persistentvolume=

volume_stats_usedBytes

ゲージ

namespace=<persistentvolumeclaim-namespace> persistentvolumeclaim=<persistentvolumeclaim-name> persistentvolume=<persistentvolume-name>

volume_stats_availableBytes

ゲージ

namespace=<persistentvolumeclaim-namespace> persistentvolumeclaim=<persistentvolumeclaim-name> persistentvolume=

volume_stats_InodesFree

ゲージ

namespace=<persistentvolumeclaim-namespace> persistentvolumeclaim=<persistentvolumeclaim-name> persistentvolume=<persistentvolume-name>

volume_stats_Inodes

ゲージ

namespace=<persistentvolumeclaim-namespace> persistentvolumeclaim=<persistentvolumeclaim-name> persistentvolume=<persistentvolume-name>

volume_stats_InodesUsed

ゲージ

namespace=<persistentvolumeclaim-namespace> persistentvolumeclaim=<persistentvolumeclaim-name> persistentvolume=<persistentvolume-name>

34.12.4. Prometheus のアンデプロイ
リンクのコピー

Prometheus をアンデプロイするには、以下のコマンドを実行します。 

$ ansible-playbook -vvv -i ${INVENTORY_FILE} playbooks/openshift-prometheus/config.yml -e openshift_prometheus_state=absent
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat