第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
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 の Pod | 10000 の Pod | |
|---|---|---|
|
24 時間で累積される Cassandra ストレージデータ (デフォルトのメトリクスパラメーター) |
2.5 GB |
11.4 GB |
openshift_metrics_duration の 7 日間および openshift_metrics_resolution の 30 秒間というデフォルト値を維持する場合、Cassandra Pod の週次のストレージ要件は以下のようになります。
| 1000 の Pod | 10000 の 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」のトピックを参照してください。
| ノード数 | 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 ロールはクラスターメトリクスをデプロイするタスクを定義します。以下は、上書きが必要な場合にインベントリーファイルに追加できるロール変数の一覧です。
| 変数 | 説明 |
|---|---|
|
|
|
|
|
コンポーネントをデプロイした後にメトリクスクラスターを起動します。 |
|
|
コンポーネントイメージのプレフィックス。 |
|
|
コンポーネントイメージのバージョン。たとえば、 |
|
|
再起動を試行する前に Hawkular Metrics および Heapster が起動するまでの時間 (秒単位)。 |
|
|
メトリクスがパージされるまで保管される日数。 |
|
|
メトリクスが収集される頻度。数値と時間を示す識別子である秒 (s)、分 (m)、時間 (h) で定義されます。 |
|
|
Cassandra に作成される Persistent Volume Claim (永続ボリューム要求) のプレフィックス。プレフィックスには 1 から始まる連番が付加されます。 |
|
|
各 Cassandra ノードの Persistent Volume Claim (永続ボリューム要求) のサイズ。 |
|
|
明示的にストレージクラスを設定する場合には、 |
|
|
|
|
|
メトリクススタックの Cassandra ノードの数。この値は Cassandra レプリケーションコントローラーの数を指定します。 |
|
|
Cassandra Pod のメモリー制限。たとえば、値 |
|
|
Cassandra Pod の CPU 制限。値 |
|
|
Cassandra Pod について要求するメモリー量。値 |
|
|
Cassandra Pod の CPU 要求。値 |
|
|
Cassandra に使用される補助ストレージグループ。 |
|
|
必要な既存のノードセレクターを設定して、Pod が特定のラベルを持つノードに配置されるようにします。たとえば、 |
|
|
Hawkular 証明書に署名するための認証局 (CA) ファイル (オプション)。 |
|
|
Hawkular メトリクスへのルートを再暗号化するために使用される証明書ファイル。証明書にはルートに使用されるホスト名を含める必要があります。これが指定されない場合、デフォルトのルーター証明書が使用されます。 |
|
|
Hawkular 証明書で使用されるキーファイル。 |
|
|
Hawkular Pod を制限するためのメモリー量。値 |
|
|
Hawkular Pod の CPU 制限。値 |
|
|
Hawkular メトリクスのレプリカの数。 |
|
|
Hawkular Pod について要求するメモリー量。値 |
|
|
Hawkular Pod の CPU 要求。値 |
|
|
必要な既存のノードセレクターを設定して、Pod が特定のラベルを持つノードに配置されるようにします。たとえば、 |
|
|
許可する CN のカンマ区切りの一覧。デフォルトで、OpenShift サービスプロキシーが接続できるように設定されます。Horizontal Pod Autoscaling を適切に機能させるには、上書きする際に |
|
|
Heapster Pod を制限するメモリー量。値 |
|
|
Heapster Pod の CPU 制限。値 |
|
|
Heapster Pod について要求するメモリー量。値 |
|
|
Heapster Pod の CPU 要求。値 |
|
|
Heapster のみをデプロイします。Hawkular Metrics や Cassandra コンポーネントはデプロイされません。 |
|
|
必要な既存のノードセレクターを設定して、Pod が特定のラベルを持つノードに配置されるようにします。たとえば、 |
|
|
Hawkular OpenShift Agent (HOSA) をインストールするには |
|
|
Hawkular Metrics ルートのホスト名を使用するので、 |
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
例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
これは永続ストレージを使用しないでデプロイされるため、メトリックデータが損失する可能性があります。
34.6.1. メトリクスの診断
メトリクススタックの状態の評価に使用できるメトリクス用の診断があります。メトリクスの診断を実行するには、以下のコマンドを実行します。
$ oc adm diagnostics MetricsApiProxy
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"
webconsole-config configmap ファイルを更新し、保存した後に、OpenShift Container Platform インスタンスを再起動する必要があります。
OpenShift Container Platform サーバーが再び稼働すると、メトリクスが Pod 概要のページに表示されます。
自己署名証明書を使用している場合、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.
または、以下が表示されます。
Could not get the logging secret! Status code: 000. The Hawkular Alerts integration with Logging might not work properly.
この機能はバージョン 3.7.0 以降で使用できます。以下のようなエントリーのログをチェックして、ロギングを利用できるかどうか確認します。
Retrieving the Logging's CA and adding to the trust store, if Logging is available.
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
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-metricsnamespace -
Prometheus
clusterrolebindingおよびサービスアカウント - OAuth プロキシーの背後の Prometheus、Alertmanager および Alert Buffer をステートフルセットとして備えた Prometheus Pod
-
Prometheus と
prometheus-alertsConfigMaps - Prometheus と Prometheus Alerts サービスおよび直接ルート
Prometheus デプロイメントはデフォルトで有効にされます。openshift_prometheus_state を absent に設定してこれをアンインストールします。以下は例になります。
# openshift_prometheus_state=absent
以下のロール変数を設定して、Prometheus をインストールし、設定します。
| 変数 | 説明 |
|---|---|
|
|
デフォルト値は |
|
|
コンポーネントがデプロイされるプロジェクト namespace。デフォルトは |
|
|
Prometheus がデプロイされるノードのセレクターです。デフォルトは |
|
|
Prometheus の PV を作成するために設定します。例: |
|
|
Alertmanager の PV を作成するために設定します。例: |
|
|
Alert Buffer の PV を作成するために設定します。例: |
|
|
Prometheus の PVC を作成するために設定します。例: |
|
|
Alertmanager の PVC を作成するために設定します。例: |
|
|
Alert Buffer の PVC を作成するために設定します。例: |
|
|
追加の Prometheus ルールファイル。デフォルトで |
34.12.2. Ansible インストーラーを使用した Prometheus のデプロイ
Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。
Ansible インストーラーは、Prometheus をデプロイするデフォルトの方法です。
Playbook を実行します。
$ ansible-playbook -vvv -i ${INVENTORY_FILE} playbooks/openshift-prometheus/config.yml
node-role.kubernetes.io/infra=true のラベルの付いたノードがあることを確認します。このラベルは openshift_prometheus_node_selector のデフォルト値です。他のノードセレクターを使用する必要がある場合は、「ノードセレクターを使用したデプロイ」を参照してください。
34.12.2.1. Prometheus をデプロイする他の方法
ノードセレクターを使用したデプロイ
Prometheus をデプロイするノードにラベルを付けます。
# oc adm label node/$NODE ${KEY}=${VALUE}Ansible とコンテナーリソースを使って Prometheus をデプロイします。
# Set node selector for prometheus
openshift_prometheus_node_selector={"${KEY}":"${VALUE}"}Playbook を実行します。
$ ansible-playbook -vvv -i ${INVENTORY_FILE} playbooks/openshift-prometheus/config.ymlデフォルト以外の namespace を使用したデプロイ
namespace を特定します。
# Set non-default openshift_prometheus_namespace
openshift_prometheus_namespace=${USER_PROJECT}Playbook を実行します。
$ ansible-playbook -vvv -i ${INVENTORY_FILE} playbooks/openshift-prometheus/config.yml34.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]
Prometheus アラートルールファイル変数
追加のルール変数へのパスを設定すると、アラートルールを含む外部ファイルを追加できます。
openshift_prometheus_additional_rules_file: <PATH>
ファイルは、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"- 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
詳細については、「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"}
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"}
詳細は、「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" }
詳細は、「Volume operation metrics」を参照してください。
ボリューム統計メトリクス
これらのメトリクスは通常、PVC の使用状況の統計を報告します (空き領域に対する使用中の領域など)。出力されるメトリクスのタイプはゲージです。
| メトリクス | 種別 | ラベル/タグ |
|---|---|---|
|
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