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 create configmap cluster-monitoring-config
cluster-monitoring-config
ConfigMap の編集を開始します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
data
セクションを作成します (存在していない場合)。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |
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
設定を、
data/config.yaml
の下に値とキーのペア<component_name>: <component_configuration>
として配置します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | component: configuration for the component
<component>
および<configuration for the component>
を随時置き換えます。たとえば、Prometheus の Persistent Volume Claim (永続ボリューム要求、PVC) を設定するために、この ConfigMap を作成します。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: volumeClaimTemplate: spec: storageClassName: fast volumeMode: filesystem resources: requests: storage: 40Gi
ここで、prometheusK8s は Prometheus コンポーネントを定義し、続く行ではその設定を定義します。
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
1.2.4. 設定可能なモニタリングコンポーネント
以下の表は、設定可能なモニタリングコンポーネントと、ConfigMap でコンポーネントを指定するために使用されるキーを示しています。
コンポーネント | キー |
---|---|
Prometheus Operator |
|
Prometheus |
|
Alertmanager 0.14.0 |
|
kube-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
コンポーネントの
nodeSelector
制約をdata/config.yaml
に指定します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | component: nodeSelector: node key: node value node key: node value ...
<component>
を適宜置き換え、<node key>: <node value>
を、宛先ノードを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。
たとえば、コンポーネントを
foo: bar
というラベルが付けられたノードに移動するには、以下を使用します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusOperator: nodeSelector: foo: bar prometheusK8s: nodeSelector: foo: bar alertmanagerMain: nodeSelector: foo: bar kubeStateMetrics: nodeSelector: foo: bar grafana: nodeSelector: foo: bar telemeterClient: nodeSelector: foo: bar k8sPrometheusAdapter: nodeSelector: foo: bar
- 変更を適用するためにファイルを保存します。新しい設定の影響を受けるコンポーネントは新しいノードに自動的に移動します。
追加リソース
-
nodeSelector
制約についての詳細は、Kubernetes ドキュメント を参照してください。
1.2.6. 永続ストレージの設定
クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリュームに保存され、Pod の再起動または再作成後も維持されます。これは、メトリクスデータまたはアラートデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、永続ストレージを設定することを強く推奨します。
「設定可能な推奨のストレージ技術」を参照してください。
前提条件
- ディスクが一杯にならないように十分な永続ストレージを確保します。必要な永続ストレージは Pod 数によって異なります。永続ストレージのシステム要件については、「Prometheus データベースのストレージ要件」を参照してください。
- 動的にプロビジョニングされるストレージを有効にしない場合、Persistent Volume Claime (永続ボリューム要求、PVC) で要求される永続ボリューム (PV) が利用できる状態にあることを確認する必要があります。Prometheus には 2 つのレプリカがあり、Alertmanager には 3 つのレプリカがあるため、モニタリングスタック全体をサポートするには、合計で 5 つの PV が必要になります。
- ストレージのブロックタイプを使用します。
1.2.6.1. Persistent Volume Claim (永続ボリューム要求) の設定
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
コンポーネントの PVC 設定を
data/config.yaml
の下に配置します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | component: volumeClaimTemplate: metadata: name: PVC name spec: storageClassName: storage class resources: requests: storage: 40Gi
volumeClaimTemplate
の指定方法については、PersistentVolumeClaims についての Kubernetes ドキュメント を参照してください。たとえば、設定された OpenShift Container Platform ブロック PV を Prometheus の永続ストレージとして要求する PVC を設定するには、以下を使用します。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: storageClassName: gluster-block resources: requests: storage: 40Gi
さらに、設定された OpenShift Container Platform ブロック PV を Alertmanager の永続ストレージとして要求する PVC を設定するには、以下を使用できます。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: storageClassName: gluster-block resources: requests: storage: 40Gi
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動され、新規ストレージ設定が適用されます。
1.2.6.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
保持期間の設定を
data/config.yaml
に配置します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: time specification
<time specification>
を、ms
(ミリ秒)、s
(秒)、m
(分)、h
(時)、d
(日)、w
(週)、またはy
(年) が直後に続く数字に置き換えます。たとえば、保持期間を 24 時間に設定するには、以下を使用します。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: 24h
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
1.2.7. Alertmanager の設定
Prometheus Alertmanager は、以下を含む受信アラートを管理するコンポーネントです。
- アラートの非通知 (silence)
- アラートの抑制 (inhibition)
- アラートの集約 (aggregation)
- アラートの安定した重複排除
- アラートのグループ化
- メール、PagerDuty、および HipChat などの受信手段によるグループ化されたアラート通知の送信
1.2.7.1. Alertmanager のデフォルト設定
OpenShift Container Platform Monitoring Alertmanager クラスターのデフォルト設定:
global: resolve_timeout: 5m route: group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: default routes: - match: alertname: Watchdog repeat_interval: 5m receiver: watchdog receivers: - name: default - name: watchdog
OpenShift Container Platform モニタリングには、モニターする側のインフラストラクチャーの可用性を確保するために常にデフォルトでトリガーされる「Watchdog アラート」機能が同梱されています。
1.2.7.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
ファイル
alertmanager.yaml
の設定を新規設定に変更します。data: config.yaml: | global: resolve_timeout: 5m route: group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: default routes: - match: alertname: Watchdog repeat_interval: 5m receiver: watchdog - match: service: _your service_ 1 routes: - match: _your matching rules_ 2 receiver: _receiver_ 3 receivers: - name: default - name: watchdog - name: _receiver_ _receiver configuration_
たとえば、この一覧では通知用に PagerDuty を設定しています。
data: config.yaml: | global: resolve_timeout: 5m route: group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: default routes: - match: alertname: Watchdog repeat_interval: 5m receiver: watchdog - match: service: example-app routes: - match: severity: critical receiver: team-frontend-page receivers: - name: default - name: watchdog - name: team-frontend-page pagerduty_configs: - service_key: "your-key"
この設定では、
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=-
追加リソース
- PagerDuty についての詳細は、PagerDuty の公式サイトを参照してください。
-
service_key
を取得する方法については、『PagerDuty Prometheus Integration Guide 』を参照してください。 - 各種のアラートレシーバー経由でアラートを設定する方法については、「Alertmanager configuration」を参照してください。
1.2.7.3. アラートルール
デフォルトで、OpenShift Container Platform クラスター モニタリングには事前に定義されたアラートルールのセットが同梱されます。
以下に留意してください。
- デフォルトのアラートルールは OpenShift Container Platform クラスター用に使用され、それ以外の目的では使用されません。たとえば、クラスターの永続ボリュームについてのアラートを取得できますが、カスタム namespace の永続ボリュームについてのアラートは取得できません。
- 現時点で、カスタムアラートルールを追加することはできません。
- 一部のアラートルールには同じ名前が付けられています。これは意図的な理由によるものです。それらは同じイベントについてのアラートを送信しますが、それぞれ異なるしきい値、重大度、およびそれらの両方が設定されます。
- 抑制ルールを使用すると、高い重大度のアラートが発生する場合に重大度の低いアラートが抑制されます。
1.2.7.4. 有効なアラートルールのアクションの一覧表示
現時点でクラスターに適用されるアラートルールを一覧表示できます。
手順
必要なポート転送を設定します。
$ oc -n openshift-monitoring port-forward svc/prometheus-operated 9090
有効なアラートルールおよびそれらのプロパティーが含まれる JSON オブジェクトを取得します。
$ curl -s http://localhost:9090/api/v1/rules | jq '[.data.groups[].rules[] | select(.type=="alerting")]' [ { "name": "ClusterOperatorDown", "query": "cluster_operator_up{job=\"cluster-version-operator\"} == 0", "duration": 600, "labels": { "severity": "critical" }, "annotations": { "message": "Cluster operator {{ $labels.name }} has not been available for 10 mins. Operator may be down or disabled, cluster will not be kept up to date and upgrades will not be possible." }, "alerts": [], "health": "ok", "type": "alerting" }, { "name": "ClusterOperatorDegraded", ...
追加リソース
- Alertmanager ドキュメントを参照してください。
次のステップ
- クラスターアラートの管理
- Telemetry について確認してください。必要な場合はこれからオプトアウトしてください。