1.2. モニタリングスタックの設定

OpenShift Container Platform 4 よりも前のバージョンでは、 Prometheus クラスターモニタリングスタックは Ansible インベントリーファイルで設定されていました。そのため、スタックは利用可能な設定オプションのサブセットを Ansible 変数として公開し、スタックは OpenShift Container Platform のインストール前に設定していました。

OpenShift Container Platform 4 では、Ansible は OpenShift Container Platform をインストールするのに使用される主要なテクノロジーではなくなりました。インストールプログラムは、インストールの前に大幅に限定された設定オプションのみを提供します。ほとんどの OpenShift フレームワークコンポーネント (Prometheus クラスターモニタリングスタックを含む) の設定はインストール後に行われます。

このセクションでは、サポートされている設定内容を説明し、モニタリングスタックの設定方法を示し、いくつかの一般的な設定シナリオを示します。

前提条件

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 ツール
  • クラスターの管理者権限

手順

  1. cluster-monitoring-config ConfigMap オブジェクトが存在するかどうかを確認します。

    $ oc -n openshift-monitoring get configmap cluster-monitoring-config
  2. 存在しない場合は、これを作成します。

    $ oc -n openshift-monitoring create configmap cluster-monitoring-config
  3. cluster-monitoring-config ConfigMap の編集を開始します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  4. 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 セクションに設定されていること。

手順

  1. cluster-monitoring-config ConfigMap の編集を開始します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. 設定を、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 コンポーネントを定義し、続く行ではその設定を定義します。

  3. 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。

1.2.4. 設定可能なモニタリングコンポーネント

以下の表は、設定可能なモニタリングコンポーネントと、ConfigMap でコンポーネントを指定するために使用されるキーを示しています。

表1.2 設定可能なモニタリングコンポーネント

コンポーネントキー

Prometheus Operator

prometheusOperator

Prometheus

prometheusK8s

Alertmanager 0.14.0

alertmanagerMain

kube-state-metrics

kubeStateMetrics

openshift-state-metrics

openshiftStateMetrics

Grafana

grafana

Telemeter クライアント

telemeterClient

Prometheus アダプター

k8sPrometheusAdapter

この一覧では、Prometheus および Alertmanager のみが多数の設定オプションを持ちます。通常、その他のすべてのコンポーネントは指定されたノードにデプロイされるように nodeSelector フィールドのみを提供します。

1.2.5. モニタリングコンポーネントの異なるノードへの移動

モニタリングスタックコンポーネントのいずれかを指定されたノードに移動できます。

前提条件

  • cluster-monitoring-config ConfigMap オブジェクトが data/config.yaml セクションに設定されていること。

手順

  1. cluster-monitoring-config ConfigMap の編集を開始します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. コンポーネントの 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
        openshiftStateMetrics:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
  3. 変更を適用するためにファイルを保存します。新しい設定の影響を受けるコンポーネントは新しいノードに自動的に移動します。

追加リソース

1.2.6. モニタリングコンポーネントへの容認 (Toleration) の割り当て

容認をモニタリングスタックのコンポーネントに割り当て、それらをテイントされたノードに移動することができます。

前提条件

  • cluster-monitoring-config ConfigMap オブジェクトが data/config.yaml セクションに設定されていること。

手順

  1. cluster-monitoring-config ConfigMap の編集を開始します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. コンポーネントの tolerations を指定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        <component>:
          tolerations:
            <toleration_specification>

    <component> および <toleration_specification> を随時置き換えます。

    たとえば、oc adm taint nodes node1 key1=value1:NoSchedule のテイントにより、スケジューラーが foo: bar ノードに Pod を配置するのを防ぎます。alertmanagerMain コンポーネントを、そのテイントを無視して、foo: baralertmanagerMain を配置するには、通常以下の容認を使用します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          nodeSelector:
            foo: bar
          tolerations: - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule"
  3. 変更を適用するためにファイルを保存します。新しいコンポーネントの配置設定が自動的に適用されます。

追加リソース

1.2.7. 永続ストレージの設定

クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリューム (PV) に保存され、Pod の再起動または再作成後も維持されます。これは、メトリクスデータまたはアラートデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、永続ストレージを設定することを強く推奨します。IO デマンドが高いため、ローカルストレージを使用することが有利になります。

重要

設定可能な推奨のストレージ技術」を参照してください。

前提条件

  • ディスクが一杯にならないように、十分なローカル永続ストレージを確保します。必要な永続ストレージは Pod 数によって異なります。永続ストレージのシステム要件については、「Prometheus データベースのストレージ要件」を参照してください。
  • Persistent Volume Claime (永続ボリューム要求、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 セクションに設定されていること。

手順

  1. cluster-monitoring-config ConfigMap を編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. コンポーネントの 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_prefix>
            spec:
              storageClassName: <storage_class>
              resources:
                requests:
                  storage: <amount_of_storage>

    volumeClaimTemplate の指定方法については、PersistentVolumeClaims についての Kubernetes ドキュメント を参照してください。

    たとえば、Prometheus のローカル永続ストレージを要求する PVC を設定するには、以下を使用します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          volumeClaimTemplate:
            metadata:
              name: localpvc
            spec:
              storageClassName: local-storage
              resources:
                requests:
                  storage: 40Gi

    上記の例では、ローカルストレージ Operator によって作成されるストレージクラスは local-storageと呼ばれます。

    Alertmanager のローカル永続ストレージを要求する PVC を設定するには、以下を実行します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          volumeClaimTemplate:
            metadata:
              name: localpvc
            spec:
              storageClassName: local-storage
              resources:
                requests:
                  storage: 40Gi
  3. 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動され、新規ストレージ設定が適用されます。

1.2.7.2. Prometheus メトリクスデータの保持期間の編集

デフォルトで、Prometheus クラスターモニタリングスタックは、Prometheus データの保持期間を 15 日間に設定します。この保持期間は、データ削除のタイミングを調整するために変更できます。

前提条件

  • cluster-monitoring-config ConfigMap オブジェクトが data/config.yaml セクションに設定されていること。

手順

  1. cluster-monitoring-config ConfigMap の編集を開始します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. 保持期間の設定を 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
  3. 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。

1.2.8. Alertmanager の設定

Prometheus Alertmanager は、以下を含む受信アラートを管理するコンポーネントです。

  • アラートの非通知 (silence)
  • アラートの抑制 (inhibition)
  • アラートの集約 (aggregation)
  • アラートの安定した重複排除
  • アラートのグループ化
  • メール、PagerDuty、および HipChat などの受信手段によるグループ化されたアラート通知の送信

1.2.8.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 アラートが同梱されます。Alertmanager は、たとえば PagerDuty などの通知プロバイダーに、Watchdog アラートの通知を繰り返し送信します。プロバイダーは通常、Watchdog アラートの受信を停止する際に管理者に通知するよう設定されます。このメカニズムは、Prometheus の継続的な運用、および Alertmanager と通知プロバイダー間の継続的な通信を可能にします。

1.2.8.2. カスタム Alertmanager 設定の適用

alertmanager-main シークレットを openshift-monitoring namespace 内で編集して、デフォルトの Alertmanager 設定を上書きできます。

前提条件

  • JSON データを処理するための jq ツールがインストールされていること

手順

  1. 現在アクティブな Alertmanager 設定をファイル alertmanager.yaml に出力します。

    $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml
  2. ファイル alertmanager.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>
    1
    service は、アラートを発生させるサービスを指定します。
    2
    <your_matching_rules> はターゲットアラートを指定します。
    3
    receiver は、アラートに使用する受信手段を指定します。

    たとえば、この一覧では通知用に PagerDuty を設定しています。

    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 レシーバーを使用して送信されます。 つまり、これらのアラートは選択された送信先に対して設定されます。

  3. 新規設定をファイルで適用します。

    $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run -o=yaml |  oc -n openshift-monitoring replace secret --filename=-

追加リソース

1.2.8.3. アラートルール

デフォルトで、OpenShift Container Platform クラスター モニタリングには事前に定義されたアラートルールのセットが同梱されます。

以下に留意してください。

  • デフォルトのアラートルールは OpenShift Container Platform クラスター用に使用され、それ以外の目的では使用されません。たとえば、クラスターの永続ボリュームについてのアラートを取得できますが、カスタム namespace の永続ボリュームについてのアラートは取得できません。
  • 現時点で、カスタムアラートルールを追加することはできません。
  • 一部のアラートルールには同じ名前が付けられています。これは意図的な理由によるものです。それらは同じイベントについてのアラートを送信しますが、それぞれ異なるしきい値、重大度、およびそれらの両方が設定されます。
  • 抑制ルールを使用すると、高い重大度のアラートが発生する場合に重大度の低いアラートが抑制されます。

1.2.8.4. 有効なアラートルールのアクションの一覧表示

現時点でクラスターに適用されるアラートルールを一覧表示できます。

手順

  1. 必要なポート転送を設定します。

    $ oc -n openshift-monitoring port-forward svc/prometheus-operated 9090
  2. 有効なアラートルールおよびそれらのプロパティーが含まれる 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",
        ...

追加リソース

次のステップ


このページには機械翻訳が使用されている場合があります (詳細はこちら)。