This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.1.2. モニタリングスタックの設定
OpenShift Container Platform 4 よりも前のバージョンでは、 Prometheus クラスターモニタリングスタックは Ansible インベントリーファイルで設定されていました。そのため、スタックは利用可能な設定オプションのサブセットを Ansible 変数として公開し、スタックは OpenShift Container Platform のインストール前に設定していました。
OpenShift Container Platform 4 では、Ansible は OpenShift Container Platform をインストールするのに使用される主要なテクノロジーではなくなりました。インストールプログラムは、インストールの前に大幅に限定された設定オプションのみを提供します。ほとんどの OpenShift フレームワークコンポーネント (Prometheus クラスターモニタリングスタックを含む) の設定はインストール後に行われます。
このセクションでは、サポートされている設定内容を説明し、モニタリングスタックの設定方法を示し、いくつかの一般的な設定シナリオを示します。
前提条件
- モニタリングスタックには、追加のリソース要件があります。詳細は、「 Cluster Monitoring Operator のスケーリング」を 参照し、十分なリソースがあることを確認してください。
1.2.1. メンテナンスとサポート リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform モニタリングの設定は、本書で説明されているオプションを使用して行う方法がサポートされている方法です。サポートされていない他の設定は使用しないでください。設定のパラダイムが Prometheus リリース間で変更される可能性があり、このような変更には、設定のすべての可能性が制御されている場合のみ適切に対応できます。本セクションで説明されている設定以外の設定を使用する場合、cluster-monitoring-operator が差分を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態へすべてを元に戻します。
明示的にサポート対象外とされているケースには、以下が含まれます。
-
追加の
ServiceMonitor
オブジェクトをopenshift-*
namespace に作成する。これにより、クラスターモニタリング Prometheus インスタンスの収集ターゲットが拡張されます。これは、対応不可能な競合および負荷の差異を生じさせる可能性があるため、Prometheus のセットアップが不安定になる可能性があります。 -
予期しない
ConfigMap
オブジェクトまたはPrometheusRule
オブジェクトの作成。これにより、クラスターモニタリング Prometheus インスタンスに追加のアラートおよび記録ルールが組み込まれます。 - スタックのリソースの変更。Prometheus Monitoring Stack スタックは、そのリソースが常に期待される状態にあることを確認します。これらが変更される場合、スタックはこれらをリセットします。
- 目的に合わせてスタックのリソースを使用する。Prometheus クラスターモニタリングスタックによって作成されるリソースは、後方互換性の保証がないために他のリソースで使用されることは意図されていません。
- クラスターモニタリング Operator によるモニタリングスタックの調整を停止する。
- 新規アラートルールの追加。
- モニタリングスタック Grafana インスタンスの変更。
1.2.2. クラスターモニタリング ConfigMap の作成 リンクのコピーリンクがクリップボードにコピーされました!
Prometheus クラスターモニタリングスタックを設定するには、クラスターモニタリング ConfigMap を作成する必要があります。
前提条件
-
インストール済みの
oc
CLI ツール - クラスターの管理者権限
手順
cluster-monitoring-config
ConfigMap オブジェクトが存在するかどうかを確認します。oc -n openshift-monitoring get configmap cluster-monitoring-config
$ oc -n openshift-monitoring get configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 存在しない場合は、これを作成します。
oc -n openshift-monitoring create configmap cluster-monitoring-config
$ oc -n openshift-monitoring create configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-monitoring-config
ConfigMap の編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow data
セクションを作成します (存在していない場合)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.3. クラスターモニタリングスタックの設定 リンクのコピーリンクがクリップボードにコピーされました!
ConfigMap を使用して Prometheus クラスターモニタリングスタックを設定することができます。ConfigMap はクラスターモニタリング Operator を設定し、その後にスタックのコンポーネントが設定されます。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を、
data/config.yaml
の下に値とキーのペア<component_name>: <component_configuration>
として配置します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <component>
および<configuration_for_the_component>
を随時置き換えます。たとえば、Prometheus の Persistent Volume Claim (永続ボリューム要求、PVC) を設定するために、この ConfigMap を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、prometheusK8s は Prometheus コンポーネントを定義し、続く行ではその設定を定義します。
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
1.2.4. 設定可能なモニタリングコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、設定可能なモニタリングコンポーネントと、ConfigMap でコンポーネントを指定するために使用されるキーを示しています。
コンポーネント | キー |
---|---|
Prometheus Operator |
|
Prometheus |
|
Alertmanager 0.14.0 |
|
kube-state-metrics |
|
openshift-state-metrics |
|
Grafana |
|
Telemeter クライアント |
|
Prometheus アダプター |
|
この一覧では、Prometheus および Alertmanager のみが多数の設定オプションを持ちます。通常、その他のすべてのコンポーネントは指定されたノードにデプロイされるように nodeSelector
フィールドのみを提供します。
1.2.5. モニタリングコンポーネントの異なるノードへの移動 リンクのコピーリンクがクリップボードにコピーされました!
モニタリングスタックコンポーネントのいずれかを指定されたノードに移動できます。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンポーネントの
nodeSelector
制約をdata/config.yaml
に指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <component>
を適宜置き換え、<node_key>: <node_value>
を、宛先ノードを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。
たとえば、コンポーネントを
foo: bar
というラベルが付けられたノードに移動するには、以下を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新しい設定の影響を受けるコンポーネントは新しいノードに自動的に移動します。
追加リソース
-
nodeSelector
制約についての詳細は、Kubernetes ドキュメント を参照してください。
1.2.6. モニタリングコンポーネントへの容認 (Toleration) の割り当て リンクのコピーリンクがクリップボードにコピーされました!
容認をモニタリングスタックのコンポーネントに割り当て、それらをテイントされたノードに移動することができます。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンポーネントの
tolerations
を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <component>
および<toleration_specification>
を随時置き換えます。たとえば、
oc adm taint nodes node1 key1=value1:NoSchedule
のテイントにより、スケジューラーがfoo: bar
ノードに Pod を配置するのを防ぎます。alertmanagerMain
コンポーネントを、そのテイントを無視して、foo: bar
にalertmanagerMain
を配置するには、通常以下の容認を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新しいコンポーネントの配置設定が自動的に適用されます。
追加リソース
- テイントおよび容認 (Toleration) については、OpenShift Container Platform ドキュメントを参照してください。
- テイントおよび容認 (Toleration) については、Kubernetes ドキュメントを参照してください。
1.2.7. 永続ストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリューム (PV) に保存され、Pod の再起動または再作成後も維持されます。これは、メトリクスデータまたはアラートデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、永続ストレージを設定することを強く推奨します。IO デマンドが高いため、ローカルストレージを使用することが有利になります。
「設定可能な推奨のストレージ技術」を参照してください。
前提条件
- ディスクが一杯にならないように、十分なローカル永続ストレージを確保します。必要な永続ストレージは Pod 数によって異なります。永続ストレージのシステム要件については、「Prometheus データベースのストレージ要件」を参照してください。
- Persistent Volume Claim (永続ボリューム要求、PVC) で要求される永続ボリューム (PV) が利用できる状態にあることを確認する必要があります。各レプリカに 1 つの PV が必要です。 Prometheus には 2 つのレプリカがあり、Alertmanager には 3 つのレプリカがあるため、モニタリングスタック全体をサポートするには、合計で 5 つの PV が必要になります。PV は、ローカルストレージ Operator で利用できる必要があります。動的にプロビジョニングされるストレージを有効にすると、この設定は適用されません。
- ストレージのブロックタイプを使用します。
- ローカル永続ストレージを設定します。
1.2.7.1. ローカル Persistent Volume Claim(永続ボリューム要求、PVC)の設定 リンクのコピーリンクがクリップボードにコピーされました!
Prometheus または Alertmanager で永続ボリューム (PV) を使用するには、まず Persistent Volume Claim (永続ボリューム要求、PVC) を設定する必要があります。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap を編集します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンポーネントの PVC 設定を
data/config.yaml
の下に配置します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow volumeClaimTemplate
の指定方法については、PersistentVolumeClaims についての Kubernetes ドキュメント を参照してください。たとえば、Prometheus のローカル永続ストレージを要求する PVC を設定するには、以下を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、ローカルストレージ Operator によって作成されるストレージクラスは
local-storage
と呼ばれます。Alertmanager のローカル永続ストレージを要求する PVC を設定するには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動され、新規ストレージ設定が適用されます。
1.2.7.2. Prometheus メトリクスデータの保持期間の編集 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、Prometheus クラスターモニタリングスタックは、Prometheus データの保持期間を 15 日間に設定します。この保持期間は、データ削除のタイミングを調整するために変更できます。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保持期間の設定を
data/config.yaml
に配置します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <time_specification>
を、ms
(ミリ秒)、s
(秒)、m
(分)、h
(時間)、d
(日)、w
(週)、またはy
(年) が直後に続く数字に置き換えます。たとえば、保持期間を 24 時間に設定するには、以下を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
1.2.8. Alertmanager の設定 リンクのコピーリンクがクリップボードにコピーされました!
Prometheus Alertmanager は、以下を含む受信アラートを管理するコンポーネントです。
- アラートの非通知 (silence)
- アラートの抑制 (inhibition)
- アラートの集約 (aggregation)
- アラートの安定した重複排除
- アラートのグループ化
- メール、PagerDuty、および HipChat などの受信手段によるグループ化されたアラート通知の送信
1.2.8.1. Alertmanager のデフォルト設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Monitoring Alertmanager クラスターのデフォルト設定:
OpenShift Container Platform モニタリングには、継続的に実行される Watchdog アラートが同梱されます。Alertmanager は、たとえば PagerDuty などの通知プロバイダーに、Watchdog アラートの通知を繰り返し送信します。プロバイダーは通常、Watchdog アラートの受信を停止する際に管理者に通知するよう設定されます。このメカニズムは、Prometheus の継続的な運用、および Alertmanager と通知プロバイダー間の継続的な通信を可能にします。
1.2.8.2. カスタム Alertmanager 設定の適用 リンクのコピーリンクがクリップボードにコピーされました!
alertmanager-main
シークレットを openshift-monitoring
namespace 内で編集して、デフォルトの Alertmanager 設定を上書きできます。
前提条件
-
JSON データを処理するための
jq
ツールがインストールされていること
手順
現在アクティブな Alertmanager 設定をファイル
alertmanager.yaml
に出力します。oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml
$ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイル
alertmanager.yaml
の設定を新規設定に変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、この一覧では通知用に PagerDuty を設定しています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定では、
example-app
サービスで発生する、重大度がcritical
のアラートが、team-frontend-page
レシーバーを使用して送信されます。 つまり、これらのアラートは選択された送信先に対して設定されます。新規設定をファイルで適用します。
oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run -o=yaml | oc -n openshift-monitoring replace secret --filename=-
$ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run -o=yaml | oc -n openshift-monitoring replace secret --filename=-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
追加リソース
- PagerDuty についての詳細は、PagerDuty の公式サイトを参照してください。
-
service_key
を取得する方法については、『PagerDuty Prometheus Integration Guide 』を参照してください。 - 各種のアラートレシーバー経由でアラートを設定する方法については、「Alertmanager configuration」を参照してください。
1.2.8.3. アラートルール リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、OpenShift Container Platform クラスター モニタリングには事前に定義されたアラートルールのセットが同梱されます。
以下に留意してください。
- デフォルトのアラートルールは OpenShift Container Platform クラスター用に使用され、それ以外の目的では使用されません。たとえば、クラスターの永続ボリュームについてのアラートを取得できますが、カスタム namespace の永続ボリュームについてのアラートは取得できません。
- 現時点で、カスタムアラートルールを追加することはできません。
- 一部のアラートルールには同じ名前が付けられています。これは意図的な理由によるものです。それらは同じイベントについてのアラートを送信しますが、それぞれ異なるしきい値、重大度、およびそれらの両方が設定されます。
- 抑制ルールを使用すると、高い重大度のアラートが発生する場合に重大度の低いアラートが抑制されます。
1.2.8.4. 有効なアラートルールのアクションの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
現時点でクラスターに適用されるアラートルールを一覧表示できます。
手順
必要なポート転送を設定します。
oc -n openshift-monitoring port-forward svc/prometheus-operated 9090
$ oc -n openshift-monitoring port-forward svc/prometheus-operated 9090
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 有効なアラートルールおよびそれらのプロパティーが含まれる JSON オブジェクトを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
追加リソース
- Alertmanager ドキュメントを参照してください。
次のステップ
- クラスターアラートの管理
- リモート正常性レポートを確認し、必要な場合はこれをオプトアウトします。