Menu Close

モニタリング

OpenShift Container Platform 4.10

OpenShift Container Platform でのモニタリングスタックの設定および使用

概要

本書では、OpenShift Container Platform で Prometheus モニタリングスタックを設定し、使用する方法について説明します。

第1章 モニタリングの概要

1.1. OpenShift Container Platform モニタリングについて

OpenShift Container Platform には、コアプラットフォームコンポーネントのモニタリングを提供する事前に設定され、事前にインストールされた自己更新型のモニタリングスタックが含まれます。また、ユーザー定義プロジェクトのモニタリングを有効 にするオプションもあります。

クラスター管理者は、サポートされている設定で モニタリングスタックを設定 できます。OpenShift Container Platform は、追加設定が不要のモニタリングのベストプラクティスを提供します。

クラスター管理者にクラスターの問題について即時に通知するアラートのセットがデフォルトで含まれます。OpenShift Container Platform Web コンソールのデフォルトのダッシュボードには、クラスターの状態をすぐに理解できるようにするクラスターのメトリクスの視覚的な表示が含まれます。OpenShift Container Platform Web コンソールを使用して、メトリクスの表示と管理アラート、および モニタリングダッシュボードの確認 することができます。

OpenShift Container Platform Web コンソールの Observe セクションでは、metricsalertsmonitoring dashboardsmetrics targets などのモニターリング機能にアクセスして管理できます。

OpenShift Container Platform のインストール後に、クラスター管理者はオプションでユーザー定義プロジェクトのモニタリングを有効にできます。この機能を使用することで、クラスター管理者、開発者、および他のユーザーは、サービスと Pod を独自のプロジェクトでモニターする方法を指定できます。クラスター管理者は、Troubleshooting monitoring issues で、Prometheus によるユーザーメトリックの使用不可やディスクスペースの大量消費などの一般的な問題に対する回答を見つけることができます。

1.2. モニタリングスタックについて

OpenShift Container Platform モニタリングスタックは、Prometheus オープンソースプロジェクトおよびその幅広いエコシステムをベースとしています。モニタリングスタックには、以下のコンポーネントが含まれます。

  • デフォルトのプラットフォームモニタリングコンポーネント。プラットフォームモニタリングコンポーネントのセットは、OpenShift Container Platform のインストール時にデフォルトで openshift-monitoring プロジェクトにインストールされます。これにより、Kubernetes サービスを含む OpenShift Container Platform のコアコンポーネントのモニタリング機能が提供されます。デフォルトのモニタリングスタックは、クラスターのリモートのヘルスモニタリングも有効にします。これらのコンポーネントは、以下の図の Installed by default (デフォルトのインストール) セクションで説明されています。
  • ユーザー定義のプロジェクトをモニターするためのコンポーネント。オプションでユーザー定義プロジェクトのモニタリングを有効にした後に、追加のモニタリングコンポーネントは openshift-user-workload-monitoring プロジェクトにインストールされます。これにより、ユーザー定義プロジェクトのモニタリング機能が提供されます。これらのコンポーネントは、以下の図の User (ユーザー) セクションで説明されています。

1.2.1. デフォルトのモニタリングコンポーネント

デフォルトで、OpenShift Container Platform 4.10 モニタリングスタックには、以下のコンポーネントが含まれます。

表1.1 デフォルトのモニタリングスタックコンポーネント

コンポーネント説明

クラスターモニタリング Operator

Cluster Monitoring Operator (CMO) は、モニタリングスタックの中心的なコンポーネントです。Prometheus インスタンスである Thanos Querier、Telemeter Client、およびメトリクスターゲットをデプロイおよび管理し、それらが最新の状態であることを確認します。CMO は Cluster Version Operator (CVO) によってデプロイされます。

Prometheus Operator

openshift-monitoring プロジェクトの Prometheus Operator(PO)は、プラットフォーム Prometheus インスタンスおよび Alertmanager インスタンスを作成し、設定し、管理します。また、Kubernetes ラベルのクエリーに基づいてモニタリングターゲットの設定を自動生成します。

Prometheus

Prometheus は、OpenShift Container Platform モニタリングスタックのベースとなるモニタリングシステムです。Prometheus は Time Series を使用するデータベースであり、メトリクスのルール評価エンジンです。Prometheus は処理のためにアラートを Alertmanager に送信します。

Prometheus アダプター

Prometheus アダプター (上記の図の PA) は、Prometheus で使用する Kubernetes ノードおよび Pod クエリーを変換します。変換されるリソースメトリクスには、CPU およびメモリーの使用率メトリクスが含まれます。Prometheus アダプターは、Horizontal Pod Autoscaling のクラスターリソースメトリクス API を公開します。Prometheus アダプターは oc adm top nodes および oc adm top pods コマンドでも使用されます。

Alertmanager

Alertmanager サービスは、Prometheus から送信されるアラートを処理します。また、Alertmanager は外部の通知システムにアラートを送信します。

kube-state-metrics エージェント

kube-state-metrics エクスポーターエージェント (上記の図の KSM) は、Kubernetes オブジェクトを Prometheus が使用できるメトリクスに変換します。

openshift-state-metrics エージェント

OpenShift Container Platform 固有のリソースのメトリクスを追加すると、openshift-state-metrics エクスポーター (上記の図の OSM) は kube-state-metrics に対して拡張します。

node-exporter エージェント

node-exporter エージェント (上記の図の NE) はクラスター内のすべてのノードについてのメトリクスを収集します。node-exporter エージェントはすべてのノードにデプロイされます。

Thanos Querier

Thanos Querier は、単一のマルチテナントインターフェースで、OpenShift Container Platform のコアメトリクスおよびユーザー定義プロジェクトのメトリクスを集約し、これらの重複を排除します。

Grafana

Grafana 解析プラットフォームは、メトリクスの分析および可視化のためのダッシュボードを提供します。モニタリングスタックおよびダッシュボードと共に提供される Grafana インスタンスは読み取り専用です。

Telemeter クライアント

Telemeter Client は、クラスターのリモートヘルスモニタリングを容易にするために、プラットフォーム Prometheus インスタンスから Red Hat にデータのサブセクションを送信します。

モニタリグスタックのすべてのコンポーネントはスタックによってモニターされ、OpenShift Container Platform の更新時に自動的に更新されます。

注記

モニタリングスタックのすべてのコンポーネントは、クラスター管理者が一元的に設定する TLS セキュリティープロファイル設定を使用します。TLS セキュリティー設定を使用するモニタリングスタックコンポーネントを設定する場合、コンポーネントはグローバル OpenShift Container Platform apiservers.config.openshift.io/cluster リソースの tlsSecurityProfile フィールドにすでに存在する TLS セキュリティープロファイル設定を使用します。

1.2.2. デフォルトのモニタリングターゲット

スタック自体のコンポーネントに加え、デフォルトのモニタリングスタックは以下をモニターします。

  • CoreDNS
  • Elasticsearch(ロギングがインストールされている場合)
  • etcd
  • Fluentd(ロギングがインストールされている場合)
  • HAProxy
  • イメージレジストリー
  • Kubelets
  • Kubernetes API サーバー
  • Kubernetes controller manager
  • Kubernetes scheduler
  • Metering(メータリングがインストールされている場合)
  • OpenShift API サーバー
  • OpenShift Controller Manager
  • Operator Lifecycle Manager (OLM)
注記

各 OpenShift Container Platform コンポーネントはそれぞれのモニタリング設定を行います。OpenShift Container Platform コンポーネントのモニタリングに関する問題については、Bugzilla で一般的なモニタリングコンポーネントについてではなく、特定のコンポーネントに対してバグを報告してください。

他の OpenShift Container Platform フレームワークのコンポーネントもメトリクスを公開する場合があります。詳細については、それぞれのドキュメントを参照してください。

1.2.3. ユーザー定義プロジェクトをモニターするためのコンポーネント

OpenShift Container Platform 4.10 には、ユーザー定義プロジェクトでサービスおよび Pod をモニターできるモニタリングスタックのオプションの拡張機能が含まれています。この機能には、以下のコンポーネントが含まれます。

表1.2 ユーザー定義プロジェクトをモニターするためのコンポーネント

コンポーネント説明

Prometheus Operator

openshift-user-workload-monitoring プロジェクトの Prometheus Operator (PO) は、同じプロジェクトで Prometheus および Thanos Ruler インスタンスを作成し、設定し、管理します。

Prometheus

Prometheus は、ユーザー定義のプロジェクト用にモニタリング機能が提供されるモニタリングシステムです。Prometheus は処理のためにアラートを Alertmanager に送信します。

Thanos Ruler

Thanos Ruler は、別のプロセスとしてデプロイされる Prometheus のルール評価エンジンです。OpenShift Container Platform 4.10 では、Thanos Ruler はユーザー定義プロジェクトをモニタリングするためのルールおよびアラート評価を提供します。

注記

上記の表のコンポーネントは、モニタリングがユーザー定義のプロジェクトに対して有効にされた後にデプロイされます。

モニタリグスタックのすべてのコンポーネントはスタックによってモニターされ、OpenShift Container Platform の更新時に自動的に更新されます。

1.2.4. ユーザー定義プロジェクトのターゲットのモニタリング

モニタリングがユーザー定義プロジェクトについて有効にされている場合には、以下をモニターできます。

  • ユーザー定義プロジェクトのサービスエンドポイント経由で提供されるメトリクス。
  • ユーザー定義プロジェクトで実行される Pod。

1.3. 関連情報

1.4. 次のステップ

第2章 モニタリングスタックの設定

OpenShift Container Platform 4 インストールプログラムは、インストール前の少数の設定オプションのみを提供します。ほとんどの OpenShift Container Platform フレームワークコンポーネント (クラスターモニタリングスタックを含む) の設定はインストール後に行われます。

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

2.1. 前提条件

  • モニタリングスタックには、追加のリソース要件があります。コンピューティングリソースの推奨事項については、Cluster Monitoring Operator のスケーリング を参照し、十分なリソースがあることを確認してください。

2.2. モニタリングのメンテナンスおよびサポート

OpenShift Container Platform モニタリングの設定は、本書で説明されているオプションを使用して行う方法がサポートされている方法です。サポートされていない他の設定は使用しないでください。設定のパラダイムが Prometheus リリース間で変更される可能性があり、このような変更には、設定のすべての可能性が制御されている場合のみ適切に対応できます。本セクションで説明されている設定以外の設定を使用する場合、cluster-monitoring-operator が差分を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態へすべてをリセットします。

2.2.1. モニタリングのサポートに関する考慮事項

以下の変更は明示的にサポートされていません。

  • 追加の ServiceMonitorPodMonitor、および PrometheusRule オブジェクトを openshift-* および kube-* プロジェクトに作成します。
  • openshift-monitoring または openshift-user-workload-monitoring プロジェクトにデプロイされるリソースまたはオブジェクト変更OpenShift Container Platform モニタリングスタックによって作成されるリソースは、後方互換性の保証がないために他のリソースで使用されることは意図されていません。

    注記

    Alertmanager 設定は、openshift-monitoring プロジェクトにシークレットリソースとしてデプロイされます。Alertmanager の追加ルートを設定するには、そのシークレットをデコードし、変更し、その後にエンコードする必要があります。この手順は、前述のステートメントに対してサポートされる例外です。

  • スタックのリソースの変更。OpenShift Container Platform モニタリングスタックは、そのリソースが常に期待される状態にあることを確認します。これらが変更される場合、スタックはこれらをリセットします。
  • ユーザー定義ワークロードの openshift-*、および kube-* プロジェクトへのデプロイ。これらのプロジェクトは Red Hat が提供するコンポーネント用に予約され、ユーザー定義のワークロードに使用することはできません。
  • モニタリングスタック Grafana インスタンスの変更
  • カスタム Prometheus インスタンスの OpenShift Container Platform へのインストール
  • Prometheus Operator での Probe カスタムリソース定義 (CRD) による現象ベースのモニタリングの有効化
  • Prometheus Operator での AlertmanagerConfig CRD を使用した Alertmanager 設定の変更
注記

メトリクス、記録ルールまたはアラートルールの後方互換性を保証されません。

2.2.2. Operator のモニタリングについてのサポートポリシー

モニタリング Operator により、OpenShift Container Platform モニタリングリソースの設定およびテスト通りに機能することを確認できます。Operator の Cluster Version Operator (CVO) コントロールがオーバーライドされる場合、Operator は設定の変更に対応せず、クラスターオブジェクトの意図される状態を調整したり、更新を受信したりしません。

Operator の CVO コントロールのオーバーライドはデバッグ時に役立ちますが、これはサポートされず、クラスター管理者は個々のコンポーネントの設定およびアップグレードを完全に制御することを前提としています。

Cluster Version Operator のオーバーライド

spec.overrides パラメーターを CVO の設定に追加すると、管理者はコンポーネントについての CVO の動作にオーバーライドの一覧を追加できます。コンポーネントについて spec.overrides[].unmanaged パラメーターを true に設定すると、クラスターのアップグレードがブロックされ、CVO のオーバーライドが設定された後に管理者にアラートが送信されます。

Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
警告

CVO のオーバーライドを設定すると、クラスター全体がサポートされていない状態になり、モニタリングスタックをその意図された状態に調整されなくなります。これは Operator に組み込まれた信頼性の機能に影響を与え、更新が受信されなくなります。サポートを継続するには、オーバーライドを削除した後に、報告された問題を再現する必要があります。

2.3. モニタリングスタックの設定の準備

モニタリング設定マップを作成し、更新してモニタリングスタックを設定できます。

2.3.1. クラスターモニタリング設定マップの作成

OpenShift Container Platform のコアモニタリングコンポーネントを設定するには、cluster-monitoring-config ConfigMap オブジェクトを openshift-monitoring プロジェクトに作成する必要があります。

注記

変更を cluster-monitoring-config ConfigMap オブジェクトに保存すると、openshift-monitoring プロジェクトの Pod の一部またはすべてが再デプロイされる可能性があります。これらのコンポーネントが再デプロイするまで時間がかかる場合があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc -n openshift-monitoring get configmap cluster-monitoring-config
  2. ConfigMap オブジェクトが存在しない場合:

    1. 以下の YAML マニフェストを作成します。以下の例では、このファイルは cluster-monitoring-config.yaml という名前です。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
    2. 設定を適用して ConfigMap を作成します。

      $ oc apply -f cluster-monitoring-config.yaml

2.3.2. ユーザー定義のワークロードモニタリング設定マップの作成

ユーザー定義プロジェクトをモニターするコンポーネントを設定するには、user-workload-monitoring-config ConfigMap オブジェクトを openshift-user-workload-monitoring プロジェクトに作成する必要があります。

注記

変更を user-workload-monitoring-config ConfigMap オブジェクトに保存すると、openshift-user-workload-monitoring プロジェクトの Pod の一部またはすべてが再デプロイされる可能性があります。これらのコンポーネントが再デプロイするまで時間がかかる場合があります。ユーザー定義プロジェクトのモニタリングを最初に有効にする前に設定マップを作成し、設定することができます。これにより、Pod を頻繁に再デプロイする必要がなくなります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc -n openshift-user-workload-monitoring get configmap user-workload-monitoring-config
  2. user-workload-monitoring-config ConfigMap オブジェクトが存在しない場合:

    1. 以下の YAML マニフェストを作成します。以下の例では、このファイルは user-workload-monitoring-config.yaml という名前です。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
    2. 設定を適用して ConfigMap を作成します。

      $ oc apply -f user-workload-monitoring-config.yaml
      注記

      user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

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

OpenShift Container Platform 4.10 では、cluster-monitoring-config または user-workload-monitoring-config ConfigMap オブジェクトを使用して、モニタリングスタックを設定できます。設定マップはクラスターモニタリング Operator (CMO) を設定し、その後にスタックのコンポーネントが設定されます。

前提条件

  • OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ConfigMap オブジェクトを編集します。

    • OpenShift Container Platform のコアモニタリングコンポーネントを設定するには、以下を実行します。

      1. openshift-monitoring プロジェクトで 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> を随時置き換えます。

        以下の ConfigMap オブジェクトの例は、Prometheus の永続ボリューム要求 (PVC) を設定します。これは、OpenShift Container Platform のコアコンポーネントのみをモニターする Prometheus インスタンスに関連します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s: 1
              volumeClaimTemplate:
               spec:
                 storageClassName: fast
                 volumeMode: Filesystem
                 resources:
                   requests:
                     storage: 40Gi
        1
        Prometheus コンポーネントを定義し、後続の行はその設定を定義します。
    • ユーザー定義のプロジェクトをモニターするコンポーネントを設定するには、以下を実行します。

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. 設定を、data/config.yaml の下に値とキーのペア <component_name>: <component_configuration> として追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              <configuration_for_the_component>

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

        以下の ConfigMap オブジェクトの例は、Prometheus のデータ保持期間および最小コンテナーリソース要求を設定します。これは、ユーザー定義のプロジェクトのみをモニターする Prometheus インスタンスに関連します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus: 1
              retention: 24h 2
              resources:
                requests:
                  cpu: 200m 3
                  memory: 2Gi 4
        1
        Prometheus コンポーネントを定義し、後続の行はその設定を定義します。
        2
        ユーザー定義プロジェクトをモニターする Prometheus インスタンスについて 24 時間のデータ保持期間を設定します。
        3
        Prometheus コンテナーの 200 ミリコアの最小リソース要求を定義します。
        4
        Prometheus コンテナーのメモリーの 2 GiB の最小 Pod リソース要求を定義します。
        注記

        Prometheus 設定マップコンポーネントは、 cluster-monitoring-config ConfigMap オブジェクトで prometheusK8s と呼ばれ、 user-workload-monitoring-config ConfigMap オブジェクトで prometheus と呼ばれます。

  2. ファイルを保存して、変更を ConfigMap オブジェクトに適用します。新規設定の影響を受けた Pod は自動的に再起動されます。

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

関連情報

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

以下の表は、設定可能なモニタリングコンポーネントと、cluster-monitoring-config および user-workload-monitoring-config ConfigMap オブジェクトでコンポーネントを指定するために使用されるキーを示しています。

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

コンポーネントcluster-monitoring-config 設定マップキーuser-workload-monitoring-config 設定マップキー

Prometheus Operator

prometheusOperator

prometheusOperator

Prometheus

prometheusK8s

prometheus

Alertmanager

alertmanagerMain

 

kube-state-metrics

kubeStateMetrics

 

openshift-state-metrics

openshiftStateMetrics

 

Grafana

grafana

 

Telemeter クライアント

telemeterClient

 

Prometheus アダプター

k8sPrometheusAdapter

 

Thanos Querier

thanosQuerier

 

Thanos Ruler

 

thanosRuler

注記

Prometheus キーは、cluster-monitoring-config ConfigMapprometheusK8s と呼ばれ、user-workload-monitoring-config ConfigMap オブジェクトで prometheus と呼ばれています。

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

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

前提条件

  • OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ConfigMap オブジェクトを編集します。

    • OpenShift Container Platform のコアプロジェクトをモニターするコンポーネントを移行するには、以下を実行します。

      1. openshift-monitoring プロジェクトで 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> を、宛先ノードのグループを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。

        コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。

        重要

        モニタリングコンポーネントの多くは、高可用性を維持するために、クラスターの異なるノード間で複数の Pod を使用してデプロイされます。モニタリングコンポーネントをラベル付きノードに移動する際には、コンポーネントの耐障害性を維持するために十分な数の一致するノードが利用可能であることを確認します。1 つのラベルのみが指定されている場合は、複数の別々のノードにコンポーネントに関連するすべての Pod を分散するために、十分な数のノードにそのラベルが含まれていることを確認します。または、複数のラベルを指定することもできます。その場合は、それぞれのラベルを個々のノードに関連付けます。

        注記

        nodeSelector の制約を設定した後にモニタリングコンポーネントが Pending 状態のままである場合、Pod ログでテイントおよび容認に関連するエラーの有無を確認します。

        たとえば、OpenShift Container Platform のコアプロジェクトのモニタリングコンポーネントを、 nodename: controlplane1nodename: worker1nodename: worker2、および nodename: worker2 のラベルが付けられた特定のノードに移行するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: controlplane1
            prometheusK8s:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            alertmanagerMain:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            kubeStateMetrics:
              nodeSelector:
                nodename: worker1
            grafana:
              nodeSelector:
                nodename: worker1
            telemeterClient:
              nodeSelector:
                nodename: worker1
            k8sPrometheusAdapter:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            openshiftStateMetrics:
              nodeSelector:
                nodename: worker1
            thanosQuerier:
              nodeSelector:
                nodename: worker1
                nodename: worker2
    • ユーザー定義プロジェクトをモニターするコンポーネントを移動するには、以下を実行します。

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. コンポーネントの nodeSelector 制約を data/config.yaml に指定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              nodeSelector:
                <node_key>: <node_value>
                <node_key>: <node_value>
                <...>

        <component> を適宜置き換え、<node_key>: <node_value> を、宛先ノードを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。

        コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。

        重要

        モニタリングコンポーネントの多くは、高可用性を維持するために、クラスターの異なるノード間で複数の Pod を使用してデプロイされます。モニタリングコンポーネントをラベル付きノードに移動する際には、コンポーネントの耐障害性を維持するために十分な数の一致するノードが利用可能であることを確認します。1 つのラベルのみが指定されている場合は、複数の別々のノードにコンポーネントに関連するすべての Pod を分散するために、十分な数のノードにそのラベルが含まれていることを確認します。または、複数のラベルを指定することもできます。その場合は、それぞれのラベルを個々のノードに関連付けます。

        注記

        nodeSelector の制約を設定した後もモニタリングコンポーネントが Pending 状態のままになっている場合は、Pod ログでテイントおよび容認に関連するエラーの有無を確認します。

        たとえば、ユーザー定義プロジェクトのモニタリングコンポーネントを nodename: worker1nodename: worker2、および nodename: worker2 のラベルが付けられた特定のワーカーノードに移行するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: worker1
            prometheus:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            thanosRuler:
              nodeSelector:
                nodename: worker1
                nodename: worker2
  2. 変更を適用するためにファイルを保存します。新しい設定の影響を受けるコンポーネントは新しいノードに自動的に移動します。

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

関連情報

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

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

前提条件

  • OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ConfigMap オブジェクトを編集します。

    • 容認をコア OpenShift Container Platform プロジェクトをモニターするコンポーネントに割り当てるには、以下を実行します。

      1. openshift-monitoring プロジェクトで 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 は、キーが key1 で、値が value1node1 にテイントを追加します。これにより、容認がテイントに設定されていない限り、モニタリングコンポーネントが node1 に Pod をデプロイするのを防ぎます。以下の例は、サンプルのテイントを容認するように alertmanagerMain コンポーネントを設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"
    • ユーザー定義プロジェクトをモニターするコンポーネントに容認を割り当てるには、以下を実行します。

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

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

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

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

        たとえば、oc adm taint nodes node1 key1=value1:NoSchedule は、キーが key1 で、値が value1node1 にテイントを追加します。これにより、モニタリングコンポーネントが node1 に Pod をデプロイするのを防ぎます。ただし、そのテイントに対して許容値が設定されている場合を除きます。以下の例では、サンプルのテイントを容認するように thanosRuler コンポーネントを設定します。

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

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

関連情報

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

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

注記

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

2.8.1. 永続ストレージの前提条件

  • ディスクが一杯にならないように、十分なローカル永続ストレージを確保します。必要な永続ストレージは Pod 数によって異なります。永続ストレージのシステム要件については、Prometheus データベースのストレージ要件 を参照してください。
  • 永続ボリューム要求 (PVC) で要求される永続ボリューム (PV) が利用できる状態にあることを確認する必要があります。各レプリカに 1 つの PV が必要です。Prometheus には 2 つのレプリカがあり、Alertmanager には 3 つのレプリカがあるため、モニタリングスタック全体をサポートするには、合計で 5 つの PV が必要になります。PV は、ローカルストレージ Operator で利用できる必要があります。動的にプロビジョニングされるストレージを有効にすると、この設定は適用されません。
  • ストレージのブロックタイプを使用します。
  • ローカル永続ストレージを設定します。

    注記

    永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Prometheus は raw ブロックボリュームを使用できません。

2.8.2. ローカ永続ボリューム要求 (PVC) の設定

モニタリングコンポーネントが永続ボリューム (PV) を使用できるようにするには、永続ボリューム要求 (PVC) を設定する必要があります。

前提条件

  • OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ConfigMap オブジェクトを編集します。

    • OpenShift Container Platform のコアプロジェクトをモニターするコンポーネントの PVC を設定するには、以下を実行します。

      1. openshift-monitoring プロジェクトで 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:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

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

        以下の例では、OpenShift Container Platform のコアコンポーネントをモニターする Prometheus インスタンスのローカル永続ストレージを要求する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                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:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 10Gi
    • ユーザー定義プロジェクトをモニターするコンポーネントの PVC を設定するには、以下を実行します。

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. コンポーネントの PVC 設定を data/config.yaml の下に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

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

        以下の例では、ユーザー定義プロジェクトをモニターする Prometheus インスタンスのローカル永続ストレージを要求する PVC を設定します。

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

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

        以下の例では、Thanos Ruler のローカル永続ストレージを要求する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 10Gi
        注記

        thanosRuler コンポーネントのストレージ要件は、評価されルールの数や、各ルールが生成するサンプル数により異なります。

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

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

2.8.3. Prometheus メトリクスデータの保持期間の変更

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

前提条件

  • OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ConfigMap オブジェクトを編集します。

    • OpenShift Container Platform のコアプロジェクトをモニターする Prometheus インスタンスの保持時間を変更するには、以下を実行します。

      1. openshift-monitoring プロジェクトで 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 (年) が直後に続く数字に置き換えます。

        以下の例では、OpenShift Container Platform のコアコンポーネントをモニターする Prometheus インスタンスの保持期間を 24 時間に設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: 24h
    • ユーザー定義のプロジェクトをモニターする Prometheus インスタンスの保持時間を変更するには、以下を実行します。

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. 保持期間の設定を data/config.yaml に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: <time_specification>

        <time_specification> を、ms (ミリ秒)、s (秒)、m (分)、h (時間)、d (日)、w (週)、または y (年) が直後に続く数字に置き換えます。

        以下の例では、ユーザー定義プロジェクトをモニターする Prometheus インスタンスの保持期間を 24 時間に設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: 24h
  2. 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

2.9. リモート書き込みストレージの設定

リモート書き込みストレージを設定して、Prometheusが取り込んだメトリックをリモートシステムに送信して長期保存できるようにします。これを行っても、Prometheus がメトリクスを保存する方法や期間には影響はありません。

前提条件

  • OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。
  • リモート書き込み互換性のあるエンドポイント(Thanos)を設定し、エンドポイント URL を把握している。リモート書き込み機能と互換性のないエンドポイントの情報ては、Prometheus リモートエンドポイントおよびストレージについてのドキュメント を参照してください。
  • リモート書き込みエンドポイントに認証情報を設定している。

    注意

    セキュリティリスクを軽減するには、暗号化されていないHTTPを使用するか、認証を使用せずに、エンドポイントにメトリックを送信しないようにします。

手順

  1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml/prometheusK8sremoteWrite: セクションを追加します。
  3. このセクションにエンドポイント URL および認証情報を追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          remoteWrite:
          - url: "https://remote-write.endpoint"
            <endpoint_authentication_credentials>

    endpoint_authentication_credentials の場合には、エンドポイントの認証情報を置き換えます。現時点で、サポートされている認証方法は Basic 認証(basicAuth)およびクライアント TLS(tlsConfig)認証です。

    • 以下の例では、Basic 認証を設定します。

      basicAuth:
        username:
          <usernameSecret>
        password:
          <passwordSecret>

      <usernameSecret> および <passwordSecret> は随時置き換えます。

      以下の例では、nameremoteWriteAuthkeyuserpassword を指定した Basic 認証です。これらの値には、エンドポイント認証情報が含まれます。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          prometheusK8s:
            remoteWrite:
            - url: "https://remote-write.endpoint"
              basicAuth:
                username:
                  name: remoteWriteAuth
                  key: user
                password:
                  name: remoteWriteAuth
                  key: password
    • 以下の例では、クライアント TLS 認証を設定します。

      tlsConfig:
        ca:
          <caSecret>
        cert:
          <certSecret>
        keySecret:
          <keySecret>

      それに応じて、<caSecret><certSecret> および <keySecret> を置き換えます。

      以下の例では、name 値に selfsigned-mtls-bundleca key 値に ca.crtcert key 値に client.crtkeySecret key 値に client.key を使用した TLS 認証設定を示します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          prometheusK8s:
            remoteWrite:
            - url: "https://remote-write.endpoint"
              tlsConfig:
                ca:
                  secret:
                    name: selfsigned-mtls-bundle
                    key: ca.crt
                cert:
                  secret:
                    name: selfsigned-mtls-bundle
                    key: client.crt
                keySecret:
                  name: selfsigned-mtls-bundle
                  key: client.key
  4. 認証クレデンシャルの後に、書き込みの再ラベル設定値を追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          remoteWrite:
          - url: "https://remote-write.endpoint"
            <endpoint_authentication_credentials>
            <write_relabel_configs>

    <write_relabel_configs> は、リモートエンドポイントに送信する必要のあるメトリクスの書き込みラベル一覧に置き換えます。

    以下の例では、my_metric という単一のメトリックを転送する方法を紹介します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          remoteWrite:
          - url: "https://remote-write.endpoint"
            writeRelabelConfigs:
            - sourceLabels: [__name__]
              regex: 'my_metric'
              action: keep

    書き込み再ラベル設定オプションについては、Prometheus relabel_config documentation を参照してください。

  5. 必要な場合は、以下のように name および namespace metadata の値を変更して、ユーザー定義のプロジェクトをモニターする Prometheus インスタンスのリモート書き込みを設定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          remoteWrite:
          - url: "https://remote-write.endpoint"
            <endpoint_authentication_credentials>
            <write_relabel_configs>
    注記

    Prometheus 設定マップコンポーネントは、 cluster-monitoring-config ConfigMap オブジェクトで prometheusK8s と呼ばれ、 user-workload-monitoring-config ConfigMap オブジェクトで prometheus と呼ばれます。

  6. ファイルを保存して、変更を ConfigMap オブジェクトに適用します。新規設定の影響を受けた Pod は自動的に再起動します。

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    モニタリング ConfigMap オブジェクトへの変更を保存すると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。また、変更を保存すると、そのプロジェクトで実行中のモニタリングプロセスも再起動する可能性があります。

関連情報

2.10. ユーザー定義プロジェクトでバインドされていないメトリクス属性の影響の制御

開発者は、キーと値のペアの形式でメトリクスの属性を定義するためにラベルを作成できます。使用できる可能性のあるキーと値のペアの数は、属性について使用できる可能性のある値の数に対応します。数が無制限の値を持つ属性は、バインドされていない属性と呼ばれます。たとえば、customer_id 属性は、使用できる値が無限にあるため、バインドされていない属性になります。

割り当てられるキーと値のペアにはすべて、一意の時系列があります。ラベルに多数のバインドされていない値を使用すると、作成される時系列の数が指数関数的に増加する可能性があります。これは Prometheus のパフォーマンスに影響する可能性があり、多くのディスク領域を消費する可能性があります。

クラスター管理者は、以下の手段を使用して、ユーザー定義プロジェクトでのバインドされていないメトリクス属性の影響を制御できます。

  • ユーザー定義プロジェクトで、ターゲット収集ごとに 受け入れ可能なサンプル数を制限 します。
  • ターゲットを収集できない場合や、収集サンプルのしきい値に達する際に実行される アラートを作成 します。
注記

収集サンプルを制限すると、多くのバインドされていない属性をラベルに追加して問題が発生するのを防ぐことができます。さらに開発者は、メトリクスに定義するバインドされていない 属性の数を制限することにより、根本的な原因を防ぐことができます。使用可能な値の制限されたセットにバインドされる属性を使用すると、可能なキーと値のペアの組み合わせの数が減ります。

2.10.1. ユーザー定義プロジェクトの収集サンプル制限の設定

ユーザー定義プロジェクトで、ターゲット収集ごとに受け入れ可能なサンプル数を制限できます。

警告

サンプル制限を設定すると、制限に達した後にそのターゲット収集についての追加のサンプルデータは取り込まれません。

前提条件

  • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
  • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. enforcedSampleLimit 設定を data/config.yaml に追加し、ユーザー定義プロジェクトのターゲットの収集ごとに受け入れ可能なサンプルの数を制限できます。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          enforcedSampleLimit: 50000 1
    1
    このパラメーターが指定されている場合は、値が必要です。この enforcedSampleLimit の例では、ユーザー定義プロジェクトのターゲット収集ごとに受け入れ可能なサンプル数を 50,000 に制限します。
  3. 変更を適用するためにファイルを保存します。制限は自動的に適用されます。

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更が user-workload-monitoring-config ConfigMap オブジェクトに保存されると、openshift-user-workload-monitoring プロジェクトの Pod および他のリソースは再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

2.10.2. 収集サンプルアラートの作成

以下の場合に通知するアラートを作成できます。

  • ターゲットを収集できず、指定された for の期間利用できない
  • 指定された for の期間、収集サンプルのしきい値に達するか、またはこの値を上回る

前提条件

  • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • enforcedSampleLimit を使用して、ユーザー定義プロジェクトのターゲット収集ごとに受け入れ可能なサンプル数を制限している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ターゲットがダウンし、実行されたサンプル制限に近づく際に通知するアラートを指定して YAML ファイルを作成します。この例のファイルは monitoring-stack-alerts.yaml という名前です。

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      labels:
        prometheus: k8s
        role: alert-rules
      name: monitoring-stack-alerts 1
      namespace: ns1 2
    spec:
      groups:
      - name: general.rules
        rules:
        - alert: TargetDown 3
          annotations:
            message: '{{ printf "%.4g" $value }}% of the {{ $labels.job }}/{{ $labels.service
              }} targets in {{ $labels.namespace }} namespace are down.' 4
          expr: 100 * (count(up == 0) BY (job, namespace, service) / count(up) BY (job,
            namespace, service)) > 10
          for: 10m 5
          labels:
            severity: warning 6
        - alert: ApproachingEnforcedSamplesLimit 7
          annotations:
            message: '{{ $labels.container }} container of the {{ $labels.pod }} pod in the {{ $labels.namespace }} namespace consumes {{ $value | humanizePercentage }} of the samples limit budget.' 8
          expr: scrape_samples_scraped/50000 > 0.8 9
          for: 10m 10
          labels:
            severity: warning 11
    1
    アラートルールの名前を定義します。
    2
    アラートルールをデプロイするユーザー定義のプロジェクトを指定します。
    3
    TargetDown アラートは、 for の期間にターゲットを収集できないか、または利用できない場合に実行されます。
    4
    TargetDown アラートが実行される場合に出力されるメッセージ。
    5
    アラートが実行される前に、TargetDown アラートの条件がこの期間中 true である必要があります。
    6
    TargetDown アラートの重大度を定義します。
    7
    ApproachingEnforcedSamplesLimit アラートは、指定された for の期間に定義された収集サンプルのしきい値に達するか、またはこの値を上回る場合に実行されます。
    8
    ApproachingEnforcedSamplesLimit アラートの実行時に出力されるメッセージ。
    9
    ApproachingEnforcedSamplesLimit アラートのしきい値。この例では、ターゲット収集ごとのサンプル数が実行されたサンプル制限 50000 の 80% を超えるとアラートが実行されます。アラートが実行される前に、for の期間も経過している必要があります。式 scrape_samples_scraped/<number> > <threshold><number>user-workload-monitoring-config ConfigMap オブジェクトで定義される enforcedSampleLimit 値に一致する必要があります。
    10
    アラートが実行される前に、ApproachingEnforcedSamplesLimit アラートの条件がこの期間中 true である必要があります。
    11
    ApproachingEnforcedSamplesLimit アラートの重大度を定義します。
  2. 設定をユーザー定義プロジェクトに適用します。

    $ oc apply -f monitoring-stack-alerts.yaml

第3章 外部 alertmanager インスタンスの設定

OpenShift Container Platform モニタリングスタックには、Prometheus からのアラートのルートなど、ローカルの Alertmanager インスタンスが含まれます。openshift-monitoring または user-workload-monitoring-config プロジェクトのいずれかで cluster-monitoring-config設定マップを設定して外部 Alertmanager インスタンスを追加できます。

複数のクラスターに同じ外部 Alertmanager 設定を追加し、クラスターごとにローカルインスタンスを無効にする場合には、単一の外部 Alertmanager インスタンスを使用して複数のクラスターのアラートルーティングを管理できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • openshift-monitoring プロジェクトで OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMapを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-configConfigMapオブジェクトを作成している。

手順

  1. ConfigMap オブジェクトを編集します。

    • OpenShift Container Platform のコアプロジェクトのルーティングアラート用に追加の Alertmanager を設定するには、以下を実行します。

      1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap を編集します。

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml/prometheusK8sadditionalAlertmanagerConfigs: セクションを追加します。
      3. このセクションに別の Alertmanager 設定の詳細情報を追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              additionalAlertmanagerConfigs:
              - <alertmanager_specification>

        <alertmanager_specification> は、追加の Alertmanager インスタンスの認証およびその他の設定の詳細を置き換えます。現時点で、サポートされている認証方法はベアラートークン(bearerToken)およびクライアント TLS(tlsConfig)です。以下の設定マップは、クライアント TLS 認証でベアラートークンを使用して追加の Alertmanager を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              additionalAlertmanagerConfigs:
              - scheme: https
                pathPrefix: /
                timeout: "30s"
                apiVersion: v1
                bearerToken:
                  name: alertmanager-bearer-token
                  key: token
                tlsConfig:
                  key:
                    name: alertmanager-tls
                    key: tls.key
                  cert:
                    name: alertmanager-tls
                    key: tls.crt
                  ca:
                    name: alertmanager-tls
                    key: tls.ca
                staticConfigs:
                - external-alertmanager1-remote.com
                - external-alertmanager1-remote2.com
    • ユーザー定義プロジェクトでルーティングアラート用に追加の Alertmanager インスタンスを設定するには、以下を実行します

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config 設定マップを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml/ の下に <component>/additionalAlertmanagerConfigs: セクションを追加します。
      3. このセクションに別の Alertmanager 設定の詳細情報を追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              additionalAlertmanagerConfigs:
              - <alertmanager_specification>

        <component> には、サポート対象の外部 Alertmanager コンポーネント(prometheus または thanosRuler)2つの内、いずれかに置き換えます。

        <alertmanager_specification> は、追加の Alertmanager インスタンスの認証およびその他の設定の詳細を置き換えます。現時点で、サポートされている認証方法はベアラートークン(bearerToken)およびクライアント TLS(tlsConfig)です。以下の設定マップは、ベアラートークンおよびクライアント TLS 認証を指定した Thanos Ruler を使用して追加の Alertmanager を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
           thanosRuler:
             additionalAlertmanagerConfigs:
            - scheme: https
              pathPrefix: /
              timeout: "30s"
              apiVersion: v1
              bearerToken:
                name: alertmanager-bearer-token
                key: token
              tlsConfig:
                key:
                  name: alertmanager-tls
                  key: tls.key
                cert:
                  name: alertmanager-tls
                  key: tls.crt
                ca:
                  name: alertmanager-tls
                  key: tls.ca
              staticConfigs:
              - external-alertmanager1-remote.com
              - external-alertmanager1-remote2.com
        注記

        user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

  2. ファイルを保存して、変更を ConfigMap オブジェクトに適用します。新しいコンポーネントの配置設定が自動的に適用されます。

3.1. 追加ラベルの時系列 (time series) およびアラートへの割り当て

Prometheus の外部ラベル機能を使用して、カスタムラベルを、Prometheus から出るすべての時系列およびアラートに割り当てることができます。

前提条件

  • OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ConfigMap オブジェクトを編集します。

    • カスタムラベルを、OpenShift Container Platform のコアプロジェクトをモニターする Prometheus インスタンスから出るすべての時系列およびアラートに割り当てるには、以下を実行します。

      1. openshift-monitoring プロジェクトで 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:
              externalLabels:
                <key>: <value> 1
        1
        <key>: <value> をキーと値のペアのマップに置き換えます。ここで、<key> は新規ラベルの一意の名前で、<value> はその値になります。
        警告

        prometheus または prometheus_replica は予約され、上書きされるため、これらをキー名として使用しないでください。

        たとえば、リージョンおよび環境に関するメタデータをすべての時系列およびアラートに追加するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              externalLabels:
                region: eu
                environment: prod
    • カスタムラベルを、ユーザー定義のプロジェクトをモニターする Prometheus インスタンスから出るすべての時系列およびアラートに割り当てるには、以下を実行します。

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml の下にすべてのメトリクスについて追加する必要のあるラベルのマップを定義します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              externalLabels:
                <key>: <value> 1
        1
        <key>: <value> をキーと値のペアのマップに置き換えます。ここで、<key> は新規ラベルの一意の名前で、<value> はその値になります。
        警告

        prometheus または prometheus_replica は予約され、上書きされるため、これらをキー名として使用しないでください。

        注記

        openshift-user-workload-monitoring プロジェクトでは、Prometheus はメトリクスを処理し、Thanos Ruler はアラートおよび記録ルールを処理します。user-workload-monitoring-config ConfigMap オブジェクトで prometheusexternalLabels を設定すると、すべてのルールではなく、メトリクスの外部ラベルのみが設定されます。

        たとえば、リージョンおよび環境に関するメタデータをすべての時系列およびユーザー定義プロジェクトに関連するアラートに追加するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              externalLabels:
                region: eu
                environment: prod
  2. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

関連情報

3.2. モニタリングコンポーネントのログレベルの設定

Alertmanager、Prometheus Operator、Prometheus、Alertmanager および Thanos Querier および Thanos Ruler のログレベルを設定できます。

cluster-monitoring-config および user-workload-monitoring-configConfigMap オブジェクトの該当するコンポーネントには、以下のログレベルを適用することができます。

  • debug:デバッグ、情報、警告、およびエラーメッセージをログに記録します。
  • info:情報、警告およびエラーメッセージをログに記録します。
  • warn:警告およびエラーメッセージのみをログに記録します。
  • error:エラーメッセージのみをログに記録します。

デフォルトのログレベルは info です。

前提条件

  • openshift-monitoring プロジェクトで Alertmanager、Prometheus Operator、Prometheus、または Thanos Querier のログレベルを設定する場合には、以下を実行します

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • openshift-user-workload-monitoring プロジェクトで Prometheus Operator、Prometheus、または Thanos Ruler のログレベルを設定する場合には、以下を実行します。

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ConfigMap オブジェクトを編集します。

    • openshift-monitoring プロジェクトのコンポーネントのログレベルを設定するには、以下を実行します。

      1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. コンポーネントの logLevel: <log_level>data/config.yaml の下に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2
        1
        ログレベルを適用するモニタリングコンポーネント。
        2
        コンポーネントに適用するログレベル。
    • openshift-user-workload-monitoring プロジェクトのコンポーネントのログレベルを設定するには、以下を実行します。

      1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. コンポーネントの logLevel: <log_level>data/config.yaml の下に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2
        1
        ログレベルを適用するモニタリングコンポーネント。
        2
        コンポーネントに適用するログレベル。
  2. 変更を適用するためにファイルを保存します。ログレベルの変更を適用する際に、コンポーネントの Pod は自動的に再起動します。

    注記

    user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

  3. 関連するプロジェクトでデプロイメントまたは Pod 設定を確認し、ログレベルが適用されていることを確認します。以下の例では、openshift-user-workload-monitoring プロジェクトの prometheus-operator デプロイメントでログレベルを確認します。

    $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

    出力例

            - --log-level=debug

  4. コンポーネントの Pod が実行中であることを確認します。以下の例は、openshift-user-workload-monitoring プロジェクトの Pod のステータスを一覧表示します。

    $ oc -n openshift-user-workload-monitoring get pods
    注記

    認識されない loglevel 値が ConfigMap オブジェクトに含まれる場合は、コンポーネントの Pod が正常に再起動しない可能性があります。

3.3. Prometheus のクエリログファイルの有効化

エンジンによって実行されたすべてのクエリをログファイルに書き込むように Prometheus を設定できます。これは、デフォルトのプラットフォームモニタリングおよびユーザー定義のワークロードモニタリングに対して行うことができます。

重要

ログローテーションはサポートされていないため、問題のトラブルシューティングが必要な場合にのみ、この機能を一時的に有効にします。トラブルシューティングが終了したら、ConfigMapオブジェクトに加えた変更を元に戻してクエリログを無効にし、機能を有効にします。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • openshift-monitoring プロジェクトで Prometheus のクエリログファイル機能を有効にしている場合:

    • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • openshift-user-workload-monitoring プロジェクトで Prometheus のクエリログファイル機能を有効にしている場合:

    • cluster-admin ロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。

手順

  • openshift-monitoring プロジェクトで Prometheus のクエリログファイルを設定するには:

    1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

      $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
    2. data/config.yamlの下のprometheusK8squeryLogFile: <path> を追加します:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          prometheusK8s:
            queryLogFile: <path> 1
      1
      クエリがログに記録されるファイルへのフルパス。
    3. 変更を適用するためにファイルを保存します。

      警告

      monitoring config map への変更を保存すると、関連プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

    4. コンポーネントの Pod が実行中であることを確認します。次のコマンドの例は、openshift-monitoringプロジェクトの Pod のステータスを一覧表示します。

      $ oc -n openshift-monitoring get pods
    5. クエリログを読みます。

      $ oc -n openshift-monitoring exec prometheus-k8s-0 -- cat <path>
      重要

      ログに記録されたクエリ情報を確認した後、config map の設定を元に戻します。

  • openshift-user-workload-monitoringプロジェクトで Prometheus のクエリログファイルを設定するには:

    1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    2. data/config.yaml の下の prometheusqueryLogFile: <path> を追加します:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus:
            queryLogFile: <path> 1
      1
      クエリがログに記録されるファイルへのフルパス。
    3. 変更を適用するためにファイルを保存します。

      注記

      user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

      警告

      monitoring config map への変更を保存すると、関連プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

    4. コンポーネントの Pod が実行中であることを確認します。以下の例は、openshift-user-workload-monitoring プロジェクトの Pod のステータスを一覧表示します。

      $ oc -n openshift-user-workload-monitoring get pods
    5. クエリログを読みます。

      $ oc -n openshift-user-workload-monitoring exec prometheus-user-workload-0 -- cat <path>
      重要

      ログに記録されたクエリ情報を確認した後、config map の設定を元に戻します。

関連情報

3.4. Thanos Querier のクエリーロギングの有効化

openshift-monitoring プロジェクトのデフォルトのプラットフォームモニタリングの場合、Cluster Monitoring Operator を有効にして Thanos Querier によって実行されるすべてのクエリーをログに記録できます。

重要

ログローテーションはサポートされていないため、問題のトラブルシューティングが必要な場合にのみ、この機能を一時的に有効にします。トラブルシューティングが終了したら、ConfigMapオブジェクトに加えた変更を元に戻してクエリログを無効にし、機能を有効にします。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-configConfigMap オブジェクトを作成している。

手順

openshift-monitoring プロジェクトで Thanos Querier のクエリーロギングを有効にすることができます。

  1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. 以下の例のように thanosQuerier セクションを data/config.yaml に追加し、値を追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        thanosQuerier:
          enableRequestLogging: <value> 1
          logLevel: <value> 2
    1
    ロギングを有効にするには、値を true に設定し、ロギングを無効にするには false を設定します。デフォルト値は false です。
    2
    この値は debuginfowarn、または error に設定します。logLevel に値が存在しない場合、ログレベルはデフォルトで error に設定されます。
  3. 変更を適用するためにファイルを保存します。

    警告

    monitoring config map への変更を保存すると、関連プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

検証

  1. Thanos Querier Pod が実行されていることを確認します。次のコマンドの例は、openshift-monitoringプロジェクトの Pod のステータスを一覧表示します。

    $ oc -n openshift-monitoring get pods
  2. 以下のサンプルコマンドをモデルとして使用して、テストクエリーを実行します。

    $ token=`oc sa get-token prometheus-k8s -n openshift-monitoring`
    $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?query=cluster_version'
  3. 以下のコマンドを実行してクエリーログを読み取ります。

    $ oc -n openshift-monitoring logs <thanos_querier_pod_name> -c thanos-query
    注記

    thanos-querier Pod は高可用性 (HA) Pod であるため、1 つの Pod でのみログを表示できる可能性があります。

  4. ログに記録されたクエリー情報を確認したら、設定マップで enableRequestLogging の値を false に変更してクエリーロギングを無効にします。

関連情報

第4章 Prometheus アダプターの監査ログレベルの設定

デフォルトのプラットフォームモニタリングでは、Prometheus アダプターの監査ログレベルを設定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-configConfigMap オブジェクトを作成している。

手順

デフォルトの openshift-monitoring プロジェクトで Prometheus アダプターの監査ログレベルを設定できます。

  1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. k8sPrometheusAdapter/audit セクションに profile:data/config.yaml の下に追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        k8sPrometheusAdapter:
          audit:
            profile: <audit_log_level> 1
    1
    Prometheus アダプターに適用する監査ログレベル。
  3. profile: パラメーターに以下のいずれかの値を使用して、監査ログレベルを設定します。

    • None: イベントをログに記録しません。
    • Metadata: ユーザー、タイムスタンプなど、リクエストのメタデータのみをログに記録します。リクエストテキストと応答テキストはログに記録しないでください。metadata はデフォルトの監査ログレベルです。
    • Request: メタデータと要求テキストのみをログに記録しますが、応答テキストはログに記録しません。このオプションは、リソース以外の要求には適用されません。
    • RequestResponse: イベントのメタデータ、要求テキスト、および応答テキストをログに記録します。このオプションは、リソース以外の要求には適用されません。
  4. 変更を適用するためにファイルを保存します。変更を適用すると、Prometheus Adapter 用の Pod が自動的に再起動します。

    警告

    変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

検証

  1. 設定マップの k8sPrometheusAdapter/audit/profile で、ログレベルを Request に設定し、ファイルを保存します。
  2. Prometheus アダプターの Pod が実行されていることを確認します。以下の例は、openshift-monitoring プロジェクトの Pod のステータスを一覧表示します。

    $ oc -n openshift-monitoring get pods
  3. 監査ログレベルと監査ログファイルのパスが正しく設定されていることを確認します。

    $ oc -n openshift-monitoring get deploy prometheus-adapter -o yaml

    出力例

    ...
      - --audit-policy-file=/etc/audit/request-profile.yaml
      - --audit-log-path=/var/log/adapter/audit.log

  4. 正しいログレベルが openshift-monitoring プロジェクトの prometheus-adapter デプロイメントに適用されていることを確認します。

    $ oc -n openshift-monitoring exec deploy/prometheus-adapter -c prometheus-adapter -- cat /etc/audit/request-profile.yaml

    出力例

    "apiVersion": "audit.k8s.io/v1"
    "kind": "Policy"
    "metadata":
      "name": "Request"
    "omitStages":
    - "RequestReceived"
    "rules":
    - "level": "Request"

    注記

    ConfigMap オブジェクトで Prometheus アダプターに認識されない profile 値を入力すると、Prometheus アダプターには変更が加えられず、Cluster Monitoring Operator によってエラーがログに記録されます。

  5. Prometheus アダプターの監査ログを確認します。

    $ oc -n openshift-monitoring exec -c <prometheus_adapter_pod_name> -- cat /var/log/adapter/audit.log

関連情報

4.1. デフォルトの Grafana デプロイメントの無効化

デフォルトでは、読み取り専用の Grafana インスタンスは、クラスターメトリクスを表示するダッシュボードのコレクションと共にデプロイされます。Grafana インスタンスは、ユーザー側で設定できません。

Grafana デプロイメントを無効にすると、関連するリソースがクラスターから削除されます。これらのダッシュボードを必要とせずに、クラスターのリソースを節約するには、以下を行うことができます。ただし、引き続き Web コンソールに含まれるメトリクスおよびダッシュボードを表示できます。Grafana はいつでも再度有効化することができます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. grafana コンポーネントの enabled: falsedata/config.yaml の下に追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        grafana:
          enabled: false
  3. 変更を適用するためにファイルを保存します。リソースは、変更を適用したら、自動的に削除されます。

    警告

    この変更により、Prometheus および Thanos Querier など、一部のコンポーネントが生成されます。これにより、「永続ストレージの設定」のセクションの手順が完了していない場合に、収集されたメトリクスが失われる可能性があります。

  4. Grafana Pod が実行されていないことを確認します。以下の例は、openshift-monitoring プロジェクトの Pod のステータスを一覧表示します。

    $ oc -n openshift-monitoring get pods
    注記

    これらの Pod を終了するまでに数分かかる場合があります。

関連情報

4.2. ローカル Alertmanager の無効化

PrometheusインスタンスからのアラートをルーティングするローカルAlertmanagerは、OpenShift ContainerPlatformモニタリングスタックのopenshift-monitoringプロジェクトではデフォルトで有効になっています。

ローカル Alertmanager を必要としない場合、openshift-monitoring プロジェクトでcluster-monitoring-config 設定マップを指定して無効にできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-configConfigMapを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap を編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml の下に、alertmanagerMain コンポーネントの enabled: false を追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          enabled: false
  3. 変更を適用するためにファイルを保存します。Alertmanager インスタンスは、この変更を適用すると自動的に無効にされます。

4.3. 次のステップ

第5章 ユーザー定義プロジェクトのモニタリングの有効化

OpenShift Container Platform 4.10 では、デフォルトのプラットフォームのモニタリングに加えて、ユーザー定義プロジェクトのモニタリングを有効にできます。追加のモニターリングソリューションを必要とせずに、Open Shift Container Platform で独自のプロジェクトをモニターリングできます。この機能を使用することで、コアプラットフォームコンポーネントおよびユーザー定義プロジェクトのモニタリングが一元化されます。

注記

カスタム Prometheus インスタンスおよび Operator Lifecycle Manager (OLM) でインストールされる Prometheus Operator では、ユーザー定義のワークロードモニタリングが有効である場合にこれに関する問題が生じる可能性があります。カスタム Prometheus インスタンスは OpenShift Container Platform ではサポートされません。

5.1. ユーザー定義プロジェクトのモニタリングの有効化

クラスター管理者は、クラスターモニタリング ConfigMap オブジェクト に enableUserWorkload: trueフィールドを設定し、ユーザー定義プロジェクトのモニタリングを有効にできます。

重要

OpenShift Container Platform 4.10 では、ユーザー定義プロジェクトのモニタリングを有効にする前に、カスタム Prometheus インスタンスを削除する必要があります。

注記

OpenShift Container Platform のユーザー定義プロジェクトのモニタリングを有効にするには、cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる必要があります。これにより、クラスター管理者は任意で、ユーザー定義のプロジェクトをモニターするコンポーネントを設定するパーミッションをユーザーに付与できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-monitoring-configConfigMap オブジェクトを作成している。
  • オプションで user-workload-monitoring-config ConfigMapopenshift-user-workload-monitoring プロジェクトに作成している。ユーザー定義プロジェクトをモニターするコンポーネントの ConfigMap に設定オプションを追加できます。

    注記

    設定の変更を user-workload-monitoring-config ConfigMap に保存するたびに、openshift-user-workload-monitoring プロジェクトの Pod が再デプロイされます。これらのコンポーネントが再デプロイするまで時間がかかる場合があります。ユーザー定義プロジェクトのモニタリングを最初に有効にする前に ConfigMap オブジェクトを作成し、設定することができます。これにより、Pod を頻繁に再デプロイする必要がなくなります。

手順

  1. cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. enableUserWorkload: truedata/config.yaml の下に追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true 1
    1
    true に設定すると、enableUserWorkload パラメーターはクラスター内のユーザー定義プロジェクトのモニタリングを有効にします。
  3. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトのモニタリングは自動的に有効になります。

    警告

    変更が cluster-monitoring-config ConfigMap オブジェクトに保存されると、openshift-monitoring プロジェクトの Pod および他のリソースは再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

  4. prometheus-operatorprometheus-user-workload および thanos-ruler-user-workload Pod が openshift-user-workload-monitoring プロジェクトで実行中であることを確認します。Pod が起動するまでに少し時間がかかる場合があります。

    $ oc -n openshift-user-workload-monitoring get pod

    出力例

    NAME                                   READY   STATUS        RESTARTS   AGE
    prometheus-operator-6f7b748d5b-t7nbg   2/2     Running       0          3h
    prometheus-user-workload-0             4/4     Running       1          3h
    prometheus-user-workload-1             4/4     Running       1          3h
    thanos-ruler-user-workload-0           3/3     Running       0          3h
    thanos-ruler-user-workload-1           3/3     Running       0          3h

5.2. ユーザーに対するユーザー定義のプロジェクトをモニターするパーミッションの付与

クラスター管理者は、すべての OpenShift Container Platform のコアプロジェクトおよびユーザー定義プロジェクトをモニターできます。

クラスター管理者は、開発者およびその他のユーザーに、独自のプロジェクトをモニターするパーミッションを付与できます。特権は、以下のモニタリングロールのいずれかを割り当てることで付与されます。

  • monitoring-rules-view ロールは、プロジェクトの PrometheusRule カスタムリソースへの読み取りアクセスを提供します。
  • monitoring-rules-edit ロールは、プロジェクトの PrometheusRule カスタムリソースを作成し、変更し、削除するパーミッションをユーザーに付与します。
  • monitoring-edit ロールは、monitoring-rules-edit ロールと同じ特権を付与します。さらに、ユーザーはサービスまたは Pod の新規の収集 ターゲットを作成できます。このロールを使用すると、ServiceMonitor および PodMonitor リソースを作成し、変更し、削除することもできます。

また、ユーザー定義のプロジェクトをモニターするコンポーネントを設定するパーミッションをユーザーに付与することもできます。

  • openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールにより、user-workload-monitoring-config ConfigMap オブジェクトを編集できます。このロールを使用して、ConfigMap オブジェクトを編集し、ユーザー定義のワークロードモニタリング用に Prometheus、Prometheus Operator、および Thanos Ruler を設定できます。

また、ユーザー定義プロジェクトのアラートルーティングを設定するパーミッションをユーザーに付与することもできます。

  • alert-routing-edit ロールは、プロジェクトの AlertmanagerConfig カスタムリソースを作成、更新、および削除するパーミッションをユーザーに付与します。

このセクションでは、OpenShift Container Platform Web コンソールまたは CLI を使用してこれらのロールを割り当てる方法について説明します。

5.2.1. Web コンソールを使用したユーザーパーミッションの付与

OpenShift Container Platform Web コンソールを使用して、独自のプロジェクトをモニターするパーミッションをユーザーに付与できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • ロールを割り当てるユーザーアカウントがすでに存在している。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、User ManagementRole BindingsCreate Binding に移動します。
  2. Binding Typeで、「Namespace Role Binding」タイプを選択します。
  3. Name フィールドに、ロールバインディングの名前を入力します。
  4. Namespace フィールドで、アクセスを付与するユーザー定義プロジェクトを選択します。

    重要

    モニタリングロールは、Namespace フィールドで適用するプロジェクトにバインドされます。この手順を使用してユーザーに付与するパーミッションは、選択されたプロジェクトにのみ適用されます。

  5. Role Name 一覧で、monitoring-rules-viewmonitoring-rules-edit、または monitoring-edit を選択します。
  6. Subject セクションで、User を選択します。
  7. Subject Name フィールドにユーザーの名前を入力します。
  8. Create を選択して、ロールバインディングを適用します。

5.2.2. CLI を使用したユーザーパーミッションの付与

OpenShift CLI (oc) を使用して、独自のプロジェクトをモニターするパーミッションをユーザーに付与できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • ロールを割り当てるユーザーアカウントがすでに存在している。
  • OpenShift CLI (oc) がインストールされている。

手順

  • プロジェクトのユーザーにモニタリングロールを割り当てます。

    $ oc policy add-role-to-user <role> <user> -n <namespace> 1
    1
    <role>monitoring-rules-viewmonitoring-rules-edit、または monitoring-edit に置き換えます。
    重要

    選択したすべてのロールは、クラスター管理者が特定のプロジェクトにバインドする必要があります。

    たとえば、<role>monitoring-edit に、<user>johnsmith に、<namespace>ns1 に置き換えます。これにより、ユーザー johnsmith に、メトリクスコレクションをセットアップし、ns1 namespace にアラートルールを作成するパーミッションが割り当てられます。

5.3. ユーザーに対するユーザー定義プロジェクトのモニタリングを設定するためのパーミッションの付与

ユーザーに対して、ユーザー定義プロジェクトのモニタリングを設定するためのパーミッションを付与できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • ロールを割り当てるユーザーアカウントがすでに存在している。
  • OpenShift CLI (oc) がインストールされている。

手順

  • user-workload-monitoring-config-edit ロールを openshift-user-workload-monitoring プロジェクトのユーザーに割り当てます。

    $ oc -n openshift-user-workload-monitoring adm policy add-role-to-user \
      user-workload-monitoring-config-edit <user> \
      --role-namespace openshift-user-workload-monitoring

5.4. カスタムアプリケーションについてのクラスター外からのメトリクスへのアクセス

独自のサービスをモニタリングする際に、コマンドラインから Prometheus 統計をクエリーする方法を説明します。クラスター外からモニタリングデータにアクセスするには、thanos-querier ルートを使用します。

前提条件

  • 独自のサービスをデプロイしている。ユーザー定義プロジェクトのモニタリングの有効化手順に従ってください。

手順

  1. トークンを展開して Prometheus に接続します。

    $ SECRET=`oc get secret -n openshift-user-workload-monitoring | grep  prometheus-user-workload-token | head -n 1 | awk '{print $1 }'`
    $ TOKEN=`echo $(oc get secret $SECRET -n openshift-user-workload-monitoring -o json | jq -r '.data.token') | base64 -d`
  2. ルートホストを展開します。

    $ THANOS_QUERIER_HOST=`oc get route thanos-querier -n openshift-monitoring -o json | jq -r '.spec.host'`
  3. コマンドラインで独自のサービスのメトリクスをクエリーします。以下に例を示します。

    $ NAMESPACE=ns1
    $ curl -X GET -kG "https://$THANOS_QUERIER_HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}" -H "Authorization: Bearer $TOKEN"

    出力には、アプリケーション Pod が起動していた期間が表示されます。

    出力例

    {"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up","endpoint":"web","instance":"10.129.0.46:8080","job":"prometheus-example-app","namespace":"ns1","pod":"prometheus-example-app-68d47c4fb6-jztp2","service":"prometheus-example-app"},"value":[1591881154.748,"1"]}]}}

5.5. モニタリングからのユーザー定義のプロジェクトを除く

ユーザー定義のプロジェクトは、ユーザーワークロード監視から除外できます。これを実行するには、単に openshift.io/user-monitoring ラベルに false を指定して、プロジェクトの namespace に追加します。

手順

  1. ラベルをプロジェクト namespace に追加します。

    $ oc label namespace my-project 'openshift.io/user-monitoring=false'
  2. モニタリングを再度有効にするには、namespace からラベルを削除します。

    $ oc label namespace my-project 'openshift.io/user-monitoring-'
    注記

    プロジェクトにアクティブな監視ターゲットがあった場合、ラベルを追加した後、Prometheusがそれらのスクレイピングを停止するまでに数分かかる場合があります。

5.6. ユーザー定義プロジェクトのモニタリングの無効化

ユーザー定義プロジェクトのモニタリングを有効にした後に、クラスターモニタリング ConfigMap オブジェクトに enableUserWorkload: false を設定してこれを再度無効にできます。

注記

または、enableUserWorkload: true を削除して、ユーザー定義プロジェクトのモニタリングを無効にできます。

手順

  1. cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
    1. data/config.yamlenableUserWorkload:false に設定します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          enableUserWorkload: false
  2. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトのモニタリングは自動的に無効になります。
  3. prometheus-operatorprometheus-user-workload および thanos-ruler-user-workload Pod が openshift-user-workload-monitoring プロジェクトで終了していることを確認します。これには少し時間がかかる場合があります。

    $ oc -n openshift-user-workload-monitoring get pod

    出力例

    No resources found in openshift-user-workload-monitoring project.

注記

openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config ConfigMap オブジェクトは、ユーザー定義プロジェクトのモニタリングが無効にされている場合は自動的に削除されません。これにより、ConfigMap で作成した可能性のあるカスタム設定を保持されます。

5.7. 次のステップ

第6章 ユーザー定義プロジェクトのアラートルーティングの有効化

重要

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

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

OpenShift Container Platform 4.10 では、クラスター管理者がユーザー定義プロジェクトのアラートルーティングを有効にできます。

6.1. ユーザー定義プロジェクトのアラートルーティングについて

クラスター管理者は、ユーザー定義プロジェクトのアラートルーティングを有効にできます。有効にした後、ユーザーが、ユーザー定義プロジェクトのアラートルーティングを設定できるようにすることができます。次に、ユーザーは AlertmanagerConfig オブジェクトを作成または編集して、ユーザー定義のアラートルーティングを作成し、設定できます。

ユーザーが、ユーザー定義プロジェクトのアラートルーティングを定義した後、ユーザー定義のアラートは openshift-monitoring namespace の alertmanager-main Pod にルーティングされます。

ユーザー定義プロジェクトのアラートルーティングに関する以下の制限および機能に注意してください。

  • ユーザー定義のアラートルールの場合、ユーザー定義のルーティングはリソースが定義される namespace に対してスコープ指定されます。たとえば、namespace ns1 のルーティング設定は、同じ namespace の PrometheusRules リソースにのみ適用されます。
  • Cluster Monitoring Operator(CMO)は、ユーザー定義のアラート専用の 2 つ目の Alertmanager サービスをデプロイしません。クラスター管理者は、カスタムシークレットまたは OpenShift Container Platform Web コンソールを使用して、引き続きメインの Alertmanager 設定を定義します。
  • namespace がユーザー定義のモニタリングから除外される場合、namespace の AlertmanagerConfig リソースは、Alertmanager 設定の一部ではなくなります。

6.2. ユーザー定義プロジェクトのアラートルーティングの有効化

ユーザー定義プロジェクトのアラートルーティングを有効にできます。これを実行することで、alert-routing-edit ロールを持つユーザーが、Alertmanager でユーザー定義プロジェクトのアラートルーティングおよびレシーバーを設定できるようにします。

前提条件

  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. enableUserAlertmanagerConfig: truedata/config.yamlalertmanagerMain キーの下に追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true
        alertmanagerMain:
          enableUserAlertmanagerConfig: true 1
    1
    true に設定すると、enableUserAlertmanagerConfig パラメーターはクラスター内のユーザー定義プロジェクトのアラートルーティングを有効にします。
  3. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトのアラートルーティングは自動的に有効にされます。

6.3. ユーザー定義プロジェクトのアラートルーティングを設定するためのユーザーへのパーミッションの付与

ユーザー定義プロジェクトのアラートルーティングを設定するパーミッションをユーザーに付与できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • ロールを割り当てるユーザーアカウントがすでに存在している。
  • OpenShift CLI (oc) がインストールされている。
  • ユーザー定義プロジェクトのモニタリングを有効にしている。

手順

  • ユーザー定義プロジェクトのユーザーに alert-routing-edit ロールを割り当てます。

    $ oc -n <namespace> adm policy add-role-to-user alert-routing-edit <user> 1
    1
    <namespace>の場合は、ユーザー定義プロジェクトの代わりに namespace を使用します (例: ns1)。<user> の場合は、ロールを割り当てるアカウントの代わりにユーザー名を使用します。

6.4. ユーザー定義プロジェクトのアラートルーティングの無効化

ユーザー定義プロジェクトのアラートルーティングを有効にしている場合は、これを無効にすることができます。これを実行することで、alert-routing-edit ロールを持つユーザーが Alertmanager でユーザー定義プロジェクトのアラートルーティングを設定できないようにします。

注記

ユーザー定義プロジェクトのアラートルーティングはデフォルトで無効になっています。この機能がまだ有効になっていない場合は、無効にする必要はありません。

前提条件

  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • ユーザー定義プロジェクトのアラートルーティングを有効にしている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yamlalertmanagerMain キー配下で enableUserAlertmanagerConfig の値を false に変更します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true
        alertmanagerMain:
          enableUserAlertmanagerConfig: false 1
    1
    false に設定されている場合、enableUserAlertmanagerConfig パラメーターは、クラスター内のユーザー定義プロジェクトのアラートルーティングを無効にします。
  3. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトのアラートルーティングは自動的に無効になります。

6.5. 次のステップ

第7章 メトリクスの管理

メトリクスを使用すると、クラスターコンポーネントおよび独自のワークロードのパフォーマンスをモニターできます。

7.1. メトリクスについて

OpenShift Container Platform 4.10 では、クラスターコンポーネントは、サービスエンドポイントを介して公開されたメトリクスをスクレイピングすることでモニターされます。ユーザー定義プロジェクトのメトリクスのコレクションを設定することもできます。

Prometheus クライアントライブラリーをアプリケーションレベルで使用することで、独自のワークロードに指定するメトリクスを定義できます。

OpenShift Container Platform では、メトリクスは /metrics の正規名の下に HTTP サービスエンドポイント経由で公開されます。curl クエリーを http://<endpoint>/metrics に対して実行して、サービスの利用可能なすべてのメトリクスを一覧表示できます。たとえば、prometheus-example-app サンプルサービスへのルートを公開し、以下を実行して利用可能なすべてのメトリクスを表示できます。

$ curl http://<example_app_endpoint>/metrics

出力例

# HELP http_requests_total Count of all HTTP requests
# TYPE http_requests_total counter
http_requests_total{code="200",method="get"} 4
http_requests_total{code="404",method="get"} 2
# HELP version Version information about this binary
# TYPE version gauge
version{version="v0.1.0"} 1

関連情報

7.2. ユーザー定義プロジェクトのメトリクスコレクションの設定

ServiceMonitor リソースを作成して、ユーザー定義プロジェクトのサービスエンドポイントからメトリクスを収集できます。これは、アプリケーションが Prometheus クライアントライブラリーを使用してメトリクスを /metrics の正規の名前に公開していることを前提としています。

このセクションでは、ユーザー定義のプロジェクトでサンプルサービスをデプロイし、次にサービスのモニター方法を定義する ServiceMonitor リソースを作成する方法を説明します。

7.2.1. サンプルサービスのデプロイ

ユーザー定義のプロジェクトでサービスのモニタリングをテストするには、サンプルサービスをデプロイすることができます。

手順

  1. サービス設定の YAML ファイルを作成します。この例では、prometheus-example-app.yaml という名前です。
  2. 以下のデプロイメントおよびサービス設定の詳細をファイルに追加します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: ns1
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: prometheus-example-app
      name: prometheus-example-app
      namespace: ns1
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: prometheus-example-app
      template:
        metadata:
          labels:
            app: prometheus-example-app
        spec:
          containers:
          - image: ghcr.io/rhobs/prometheus-example-app:0.4.1
            imagePullPolicy: IfNotPresent
            name: prometheus-example-app
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: prometheus-example-app
      name: prometheus-example-app
      namespace: ns1
    spec:
      ports:
      - port: 8080
        protocol: TCP
        targetPort: 8080
        name: web
      selector:
        app: prometheus-example-app
      type: ClusterIP

    この設定は、prometheus-example-app という名前のサービスをユーザー定義の ns1 プロジェクトにデプロイします。このサービスは、カスタム version メトリクスを公開します。

  3. 設定をクラスターに適用します。

    $ oc apply -f prometheus-example-app.yaml

    サービスをデプロイするには多少時間がかかります。

  4. Pod が実行中であることを確認できます。

    $ oc -n ns1 get pod

    出力例

    NAME                                      READY     STATUS    RESTARTS   AGE
    prometheus-example-app-7857545cb7-sbgwq   1/1       Running   0          81m

7.2.2. サービスのモニター方法の指定

サービスが公開するメトリクスを使用するには、OpenShift Container モニタリングを、/metrics エンドポイントからメトリクスを収集できるように設定する必要があります。これは、サービスのモニタリング方法を指定する ServiceMonitor カスタムリソース定義、または Pod のモニタリング方法を指定する PodMonitor CRD を使用して実行できます。前者の場合は Service オブジェクトが必要ですが、後者の場合は不要です。これにより、Prometheus は Pod によって公開されるメトリクスエンドポイントからメトリクスを直接収集することができます。

この手順では、ユーザー定義プロジェクトでサービスの ServiceMonitor リソースを作成する方法を説明します。

前提条件

  • cluster-admin ロールまたは monitoring-edit ロールを持つユーザーとしてクラスターにアクセスできる。
  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • この例では、prometheus-example-app サンプルサービスを ns1 プロジェクトにデプロイしている。

    注記

    prometheus-example-app サンプルサービスは TLS 認証をサポートしません。

手順

  1. ServiceMonitor リソース設定の YAML ファイルを作成します。この例では、ファイルは example-app-service-monitor.yaml という名前です。
  2. 以下の ServiceMonitor リソース設定の詳細を追加します。

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      labels:
        k8s-app: prometheus-example-monitor
      name: prometheus-example-monitor
      namespace: ns1
    spec:
      endpoints:
      - interval: 30s
        port: web
        scheme: http
      selector:
        matchLabels:
          app: prometheus-example-app

    これは、prometheus-example-app サンプルサービスによって公開されるメトリクスを収集する ServiceMonitor リソースを定義します。これには version メトリクスが含まれます。

    注記

    ユーザー定義の namespace の ServiceMonitor リソースは、同じ namespace のサービスのみを検出できます。つまり、ServiceMonitor リソースの namespaceSelector フィールドは常に無視されます。

  3. 設定をクラスターに適用します。

    $ oc apply -f example-app-service-monitor.yaml

    ServiceMonitor をデプロイするのに多少時間がかかります。

  4. ServiceMonitor リソースが実行中であることを確認できます。

    $ oc -n ns1 get servicemonitor

    出力例

    NAME                         AGE
    prometheus-example-monitor   81m

7.3. メトリクスのクエリー

OpenShift Container Platform モニタリングダッシュボードでは、Prometheus のクエリー言語 (PromQL) クエリーを実行し、プロットに可視化されるメトリクスを検査できます。この機能により、クラスターの状態と、モニターしているユーザー定義のワークロードに関する情報が提供されます。

クラスター管理者 は、すべての OpenShift Container Platform のコアプロジェクトおよびユーザー定義プロジェクトのメトリクスをクエリーできます。

開発者 として、メトリクスのクエリー時にプロジェクト名を指定する必要があります。選択したプロジェクトのメトリクスを表示するには、必要な権限が必要です。

7.3.1. クラスター管理者としてのすべてのプロジェクトのメトリクスのクエリー

クラスター管理者またはすべてのプロジェクトの表示パーミッションを持つユーザーとして、メトリクス UI ですべてのデフォルト OpenShift Container Platform およびユーザー定義プロジェクトのメトリクスにアクセスできます。

注記

クラスター管理者のみが、OpenShift Container Platform Monitoring で提供されるサードパーティーの UI にアクセスできます。

前提条件

  • cluster-admin ロールまたはすべてのプロジェクトの表示パーミッションを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift Container Platform Web コンソール内の Administrator パースペクティブで、ObserveMetrics を選択します。
  2. Insert Metric at Cursor を選択し、事前に定義されたクエリーの一覧を表示します。
  3. カスタムクエリーを作成するには、Prometheus クエリー言語 (PromQL) のクエリーを Expression フィールドに追加します。
  4. 複数のクエリーを追加するには、Add Query を選択します。
  5. クエリーを削除するには、クエリーの横にある kebab を選択してから Delete query を選択します。
  6. クエリーの実行を無効にするには、クエリーの横にある kebab を選択してから Disable query を選択します。
  7. Run Queries を選択し、作成したクエリーを実行します。クエリーからのメトリクスはプロットで可視化されます。クエリーが無効な場合、UI にはエラーメッセージが表示されます。

    注記

    大量のデータで動作するクエリーは、時系列グラフの描画時にタイムアウトするか、またはブラウザーをオーバーロードする可能性があります。これを回避するには、Hide graph を選択し、メトリクステーブルのみを使用してクエリーを調整します。次に、使用できるクエリーを確認した後に、グラフを描画できるようにプロットを有効にします。

  8. オプション: ページ URL には、実行したクエリーが含まれます。このクエリーのセットを再度使用できるようにするには、この URL を保存します。

関連情報

7.3.2. 開発者が行うユーザー定義プロジェクトのメトリクスのクエリー

ユーザー定義のプロジェクトのメトリクスには、開発者またはプロジェクトの表示パーミッションを持つユーザーとしてアクセスできます。

Developer パースペクティブには、選択したプロジェクトの事前に定義された CPU、メモリー、帯域幅、およびネットワークパケットのクエリーが含まれます。また、プロジェクトの CPU、メモリー、帯域幅、ネットワークパケットおよびアプリケーションメトリクスについてカスタム Prometheus Query Language (PromQL) クエリーを実行することもできます。

注記

開発者は Developer パースペクティブのみを使用でき、Administrator パースペクティブは使用できません。開発者は、1 度に 1 つのプロジェクトのメトリクスのみをクエリーできます。開発者はコアプラットフォームコンポーネント用の OpenShift Container Platform モニタリングで提供されるサードパーティーの UI にアクセスできません。その代わりとして、ユーザー定義プロジェクトにメトリクス UI を使用します。

前提条件

  • 開発者として、またはメトリクスで表示しているプロジェクトの表示パーミッションを持つユーザーとしてクラスターへのアクセスがある。
  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • ユーザー定義プロジェクトにサービスをデプロイしている。
  • サービスのモニター方法を定義するために、サービスの ServiceMonitor カスタムリソース定義 (CRD) を作成している。

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブから、ObserveMetrics を選択します。
  2. Project: 一覧でメトリクスで表示するプロジェクトを選択します。
  3. Select Query 一覧からクエリーを選択するか、Show PromQL を選択してカスタム PromQL クエリーを実行します。

    注記

    Developer パースペクティブでは、1 度に 1 つのクエリーのみを実行できます。

関連情報

関連情報

7.3.3. 視覚化されたメトリクスの使用

クエリーの実行後に、メトリクスが対話式プロットに表示されます。プロットの X 軸は時間を表し、Y 軸はメトリクスの値を表します。各メトリクスは、グラフ上の色付きの線で表示されます。プロットを対話的に操作し、メトリクスを参照できます。

手順

Administrator パースペクティブで、以下を行います。

  1. 最初に、有効な全クエリーの全メトリクスがプロットに表示されます。表示されるメトリクスを選択できます。

    注記

    デフォルトでは、クエリーテーブルに、すべてのメトリクスとその現在の値を一覧表示する拡張ビューが表示されます。˅ を選択すると、クエリーの拡張ビューを最小にすることができます。

    • クエリーからすべてのメトリクスを非表示にするには、クエリーの kebab をクリックし、Hide all series をクリックします。
    • 特定のメトリクスを非表示にするには、クエリーテーブルに移動し、メトリクス名の横にある色の付いた四角をクリックします。
  2. プロットをズームアップし、時間範囲を変更するには、以下のいずれかを行います。

    • プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。
    • 左上隅のメニューを使用して、時間範囲を選択します。
  3. 時間の範囲をリセットするには、Reset Zoom を選択します。
  4. 特定の時点のすべてのクエリーの出力を表示するには、その時点のプロットにてマウスのカーソルを保持します。クエリーの出力はポップアップに表示されます。
  5. プロットを非表示にするには、Hide Graph を選択します。

Developer パースペクティブ:

  1. プロットをズームアップし、時間範囲を変更するには、以下のいずれかを行います。

    • プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。
    • 左上隅のメニューを使用して、時間範囲を選択します。
  2. 時間の範囲をリセットするには、Reset Zoom を選択します。
  3. 特定の時点のすべてのクエリーの出力を表示するには、その時点のプロットにてマウスのカーソルを保持します。クエリーの出力はポップアップに表示されます。

関連情報

7.4. 次のステップ

第8章 メトリクスターゲットの管理

OpenShift Container Platform Monitoring は、データを公開されたサービスエンドポイントからスクレイピングし、ターゲットクラスターコンポーネントからメトリクスを収集します。

OpenShift Container Platform Web コンソールの Administrator パースペクティブでは、Metrics Targets ページを使用して、現在スクレイピングの対象となっているエンドポイントを表示、検索、およびフィルターリングできます。これは、問題の特定とトラブルシューティングに役立ちます。たとえば、ターゲットエンドポイントの現在のステータスを表示して、OpenShift Container Platform Monitoring がターゲットコンポーネントからメトリクスをスクレイピングできないのはいつなのかを確認できます。

Metrics Targets ページには、デフォルトの OpenShift Container Platform プロジェクトのターゲットとユーザー定義プロジェクトのターゲットが表示されます。

8.1. Administrator パースペクティブの Metrics Targets ページへのアクセス

OpenShift Container Platform Web コンソールの Administrator パースペクティブの Metrics Targets ページを表示できます。

前提条件

  • メトリクスターゲットを表示するプロジェクトの管理者としてクラスターにアクセスできる。

手順

  • Administrator パースペクティブで、ObserveTargets を選択します。Metrics Targets ページが開き、メトリクス用にスクレイピングされているすべてのサービスエンドポイントターゲットのリストが表示されます。

8.2. メトリクスターゲットの検索およびフィルタリング

メトリクスターゲットのリストは長くなる可能性があります。さまざまな条件に基づいて、これらのターゲットをフィルタリングして検索できます。

Administrator パースペクティブでは、Metrics Targets ページには、デフォルトの OpenShift Container Platform およびユーザー定義プロジェクトのターゲットに関する詳細が提供されます。このページには、ターゲットごとに以下の情報が一覧表示されます。

  • スクレイピングされるサービスエンドポイント URL
  • モニター対象の ServiceMonitor コンポーネント
  • ターゲットのアップまたはダウンステータス
  • namespace
  • 最後のスクレイプ時間
  • 最後のスクレイピングの継続期間

ターゲットの一覧をステータスおよびソース別にフィルタリングできます。以下のフィルタリングオプションが利用できます。

  • ステータス フィルター:

    • Up.ターゲットは現在 up で、メトリクスに対してアクティブにスクレイピングされています。
    • Down.ターゲットは現在 down しており、メトリクス用にスクレイピングされていません。
  • Source フィルター:

    • Platformプラットフォームレベルのターゲットは、デフォルトの OpenShift Container Platform プロジェクトにのみ関連します。これらのプロジェクトは OpenShift Container Platform のコア機能を提供します。
    • Userユーザーターゲットは、ユーザー定義プロジェクトに関連します。これらのプロジェクトはユーザーが作成したもので、カスタマイズすることができます。

検索ボックスを使用して、ターゲット名またはラベルでターゲットを見つけることもできます。検索ボックスメニューから Text または Label を選択して、検索を制限します。

8.3. ターゲットに関する詳細情報の取得

Target details ページで、メトリクスターゲットに関する詳細情報を表示できます。

前提条件

  • メトリクスターゲットを表示するプロジェクトの管理者としてクラスターにアクセスできる。

手順

Administrator パースペクティブのターゲットに関する詳細情報を表示するには、以下を実行します。

  1. OpenShift Container Platform Web コンソールを開き、ObserveTargets に移動します。
  2. オプション: Filter リストでフィルターを選択して、ステータスとソースでターゲットをフィルターします。
  3. オプション: 検索ボックスの横にある Text または Label フィールドを使用して、名前またはラベルでターゲットを検索します。
  4. オプション: 1 つ以上の EndpointStatusNamespaceLast Scrape、および Scrape Duration 列ヘッダーをクリックして、ターゲットを並べ替えます。
  5. ターゲットの Endpoint 列の URL をクリックし、Target details ページに移動します。このページには、以下を含むターゲットに関する情報が含まれます。

    • メトリクスのためにスクレイピングされているエンドポイント URL
    • 現在のターゲットのステータス (Up または Down)
    • namespace へのリンク
    • ServiceMonitor の詳細へのリンク
    • ターゲットに割り当てられたラベル
    • ターゲットがメトリクス用にスクレイピングされた直近の時間

8.4. 次のステップ

第9章 アラートの管理

OpenShift Container Platform 4.10 では、アラート UI を使用してアラート、サイレンス、およびアラートルールを管理できます。

  • アラートルールアラートルールには、クラスター内の特定の状態を示す一連の条件が含まれます。アラートは、これらの条件が true の場合にトリガーされます。アラートルールには、アラートのルーティング方法を定義する重大度を割り当てることができます。
  • Alertsアラートは、アラートルールで定義された条件が true の場合に発生します。アラートは、一連の状況が OpenShift Container Platform クラスター内で明確であることを示す通知を提供します。
  • サイレンス。サイレンスをアラートに適用し、アラートの条件が true の場合に通知が送信されることを防ぐことができます。初期通知後はアラートをミュートにして、根本的な問題の解決に取り組むことができます。
注記

アラート UI で利用可能なアラート、サイレンス、およびアラートルールは、アクセス可能なプロジェクトに関連付けられます。たとえば、cluster-administrator 権限でログインしている場合、アラート、サイレンス、およびアラートルールすべてにアクセスできます。

9.1. Administrator および Developer パースペクティブでのアラート UI へのアクセス

アラート UI は、OpenShift Container Platform Web コンソールの Administrator パースペクティブおよび Developer パースペクティブからアクセスできます。

  • Administrator パースペクティブで、ObserveAlerting を選択します。このパースペクティブのアラート UI の主なページには、AlertsSilences、および Alerting Rules という 3 つのページがあります。
  • Developer パースペクティブで、Observe<project_name>Alerts を選択します。このパースペクティブのアラートでは、サイレンスおよびアラートルールはすべて Alerts ページで管理されます。Alerts ページに表示される結果は、選択されたプロジェクトに固有のものです。
注記

Developer パースペクティブでは、Project: 一覧からアクセスできる OpenShift Container Platform のコアプロジェクトおよびユーザー定義プロジェクトを選択できます。ただし、cluster-admin 権限がない場合、OpenShift Container Platform のコアプロジェクトに関連するアラート、サイレンス、およびアラートルールは表示されません。

9.2. アラート、サイレンスおよびアラートルールの検索およびフィルター

アラート UI に表示されるアラート、サイレンス、およびアラートルールをフィルターできます。このセクションでは、利用可能なフィルターオプションのそれぞれについて説明します。

アラートフィルターについて

Administrator パースペクティブでは、アラート UI の Alerts ページに、デフォルトの OpenShift Container Platform プロジェクトおよびユーザー定義プロジェクトに関連するアラートの詳細が提供されます。このページには、各アラートの重大度、状態、およびソースの概要が含まれます。アラートが現在の状態に切り替わった時間も表示されます。

アラートの状態、重大度、およびソースでフィルターできます。デフォルトでは、FiringPlatform アラートのみが表示されます。以下では、それぞれのアラートフィルターオプションについて説明します。

  • Alert State フィルター:

    • Firingアラート条件が true で、オプションの for の期間を経過しているためにアラートが実行されます。アラートは、条件が true である限り継続して実行されます。
    • Pendingアラートはアクティブですが、アラート実行前のアラートルールに指定される期間待機します。
    • Silencedアラートは定義された期間についてサイレンスにされるようになりました。定義するラベルセレクターのセットに基づいてアラートを一時的にミュートします。一覧表示される値または正規表現のすべてに一致するアラートについては通知は送信されません。
  • Severity フィルター:

    • Criticalアラートをトリガーした状態は重大な影響を与える可能性があります。このアラートには、実行時に早急な対応が必要となり、通常は個人または緊急対策チーム (Critical Response Team) に送信先が設定されます。
    • Warningアラートは、問題の発生を防ぐために注意が必要になる可能性のある問題についての警告通知を提供します。通常、警告は早急な対応を要さないレビュー用にチケットシステムにルート指定されます。
    • Infoアラートは情報提供のみを目的として提供されます。
    • Noneアラートには重大度が定義されていません。
    • また、ユーザー定義プロジェクトに関連するアラートの重大度の定義を作成することもできます。
  • Source フィルター:

    • Platformプラットフォームレベルのアラートは、デフォルトの OpenShift Container Platform プロジェクトにのみ関連します。これらのプロジェクトは OpenShift Container Platform のコア機能を提供します。
    • Userユーザーアラートはユーザー定義のプロジェクトに関連します。これらのアラートはユーザーによって作成され、カスタマイズ可能です。ユーザー定義のワークロードモニタリングはインストール後に有効にでき、独自のワークロードへの可観測性を提供します。

サイレンスフィルターについて

Administrator パースペクティブでは、アラート UI の Silences ページには、デフォルトの OpenShift Container Platform およびユーザー定義プロジェクトのアラートに適用されるサイレンスについての詳細が示されます。このページには、それぞれのサイレンスの状態の概要とサイレンスが終了する時間の概要が含まれます。

サイレンス状態でフィルターを実行できます。デフォルトでは、Active および Pending のサイレンスのみが表示されます。以下は、それぞれのサイレンス状態のフィルターオプションについて説明しています。

  • Silence State フィルター:

    • Activeサイレンスはアクティブで、アラートはサイレンスが期限切れになるまでミュートされます。
    • Pendingサイレンスがスケジュールされており、アクティブな状態ではありません。
    • Expiredアラートの条件が true の場合、サイレンスが期限切れになり、通知が送信されます。

アラートルールフィルターについて

Administrator パースペクティブでは、アラート UI の Alerting Rules ページには、デフォルトの OpenShift Container Platform およびユーザー定義プロジェクトに関連するアラートルールの詳細が示されます。このページには、各アラートルールの状態、重大度およびソースの概要が含まれます。

アラート状態、重大度、およびソースを使用してアラートルールをフィルターできます。デフォルトでは、プラットフォームのアラートルールのみが表示されます。以下では、それぞれのアラートルールのフィルターオプションを説明します。

  • Alert State フィルター:

    • Firingアラート条件が true で、オプションの for の期間を経過しているためにアラートが実行されます。アラートは、条件が true である限り継続して実行されます。
    • Pendingアラートはアクティブですが、アラート実行前のアラートルールに指定される期間待機します。
    • Silencedアラートは定義された期間についてサイレンスにされるようになりました。定義するラベルセレクターのセットに基づいてアラートを一時的にミュートします。一覧表示される値または正規表現のすべてに一致するアラートについては通知は送信されません。
    • Not Firingアラートは実行されません。
  • Severity フィルター:

    • Criticalアラートルールで定義される状態は重大な影響を与える可能性があります。true の場合、これらの状態には早急な対応が必要です。通常、ルールに関連するアラートは個別または緊急対策チーム (Critical Response Team) に送信先が設定されます。
    • Warningアラートルールで定義される状態は、問題の発生を防ぐために注意を要する場合があります。通常、ルールに関連するアラートは早急な対応を要さないレビュー用にチケットシステムにルート指定されます。
    • Infoアラートルールは情報アラートのみを提供します。
    • Noneアラートルールには重大度が定義されていません。
    • ユーザー定義プロジェクトに関連するアラートルールのカスタム重大度定義を作成することもできます。
  • Source フィルター:

    • Platformプラットフォームレベルのアラートルールは、デフォルトの OpenShift Container Platform プロジェクトにのみ関連します。これらのプロジェクトは OpenShift Container Platform のコア機能を提供します。
    • Userユーザー定義のワークロードアラートルールは、ユーザー定義プロジェクトに関連します。これらのアラートルールはユーザーによって作成され、カスタマイズ可能です。ユーザー定義のワークロードモニタリングはインストール後に有効にでき、独自のワークロードへの可観測性を提供します。

Developer パースペクティブでのアラート、サイレンスおよびアラートルールの検索およびフィルター

Developer パースペクティブのアラート UI の「Alerts」ページでは、選択されたプロジェクトに関連するアラートとサイレンスを組み合わせたビューを提供します。規定するアラートルールへのリンクが表示されるアラートごとに提供されます。

このビューでは、アラートの状態と重大度でフィルターを実行できます。デフォルトで、プロジェクトへのアクセスパーミッションがある場合は、選択されたプロジェクトのすべてのアラートが表示されます。これらのフィルターは Administrator パースペクティブについて記載されているフィルターと同じです。

9.3. アラート、サイレンスおよびアラートルールについての情報の取得

アラート UI は、アラートおよびそれらを規定するアラートルールおよびサイレンスについての詳細情報を提供します。

前提条件

  • 開発者として、またはメトリクスで表示しているプロジェクトの表示パーミッションを持つユーザーとしてクラスターへのアクセスがある。

手順

Administrator パースペクティブでアラートについての情報を取得するには、以下を実行します。

  1. OpenShift Container Platform Web コンソールを開き、ObserveAlertingAlerts ページに移動します。
  2. オプション: 検索一覧で Name フィールドを使用し、アラートを名前で検索します。
  3. オプション: Filter 一覧でフィルターを選択し、アラートを状態、重大度およびソースでフィルターします。
  4. オプション: 1 つ以上の NameSeverityState、および Source 列ヘッダーをクリックし、アラートを並べ替えます。
  5. Alert Details ページに移動するためにアラートの名前を選択します。このページには、アラートの時系列データを示すグラフが含まれます。また、以下を含むアラートについての情報も含まれます。

    • アラートの説明
    • アラートに関連付けられたメッセージ
    • アラートに割り当てられるラベル
    • アラートを規定するアラートルールへのリンク
    • アラートが存在する場合のアラートのサイレンス

Administrator パースペクティブでサイレンスについての情報を取得するには、以下を実行します。

  1. ObserveAlertingSilences ページに移動します。
  2. オプション: Search by name フィールドを使用し、サイレンスを名前でフィルターします。
  3. オプション: Filter 一覧でフィルターを選択し、サイレンスをフィルターします。デフォルトでは、Active および Pending フィルターが適用されます。
  4. オプション: 1 つ以上の NameFiring Alerts、および State 列ヘッダーをクリックしてサイレンスを並べ替えます。
  5. Silence Details ページに移動するサイレンスの名前を選択します。このページには、以下の詳細が含まれます。

    • アラート仕様
    • 開始時間
    • 終了時間
    • サイレンス状態
    • 発生するアラートの数および一覧

Administrator パースペクティブでアラートルールについての情報を取得するには、以下を実行します。

  1. ObserveAlertingAlerting Rules ページに移動します。
  2. オプション: Filter 一覧でフィルターを選択し、アラートルールを状態、重大度およびソースでフィルターします。
  3. オプション: 1 つ以上の NameSeverityAlert State、および Source 列ヘッダーをクリックし、アラートルールを並べ替えます。
  4. アラートルールの名前を選択し、Alerting Rule Details ページに移動します。このページには、アラートルールに関する以下の情報が含まれます。

    • アラートルール名、重大度、および説明
    • アラートを発生させるための条件を定義する式
    • アラートを発生させるための条件が true である期間
    • アラートルールに規定される各アラートのグラフ。アラートを発生させる際に使用する値が表示されます。
    • アラートルールで規定されるすべてのアラートについての表

Developer パースペクティブでアラート、サイレンス、およびアラートルールについての情報を取得するには、以下を実行します。

  1. Observe<project_name>Alerts ページに移動します。
  2. アラート、サイレンス、またはアラートルールの詳細を表示します。

    • Alert Details を表示するには、アラート名の左側で > を選択し、一覧でアラートを選択します。
    • Silence Details を表示するには、Alert Details ページの Silenced By セクションでサイレンスを選択します。Silence Details ページには、以下の情報が含まれます。

      • アラート仕様
      • 開始時間
      • 終了時間
      • サイレンス状態
      • 発生するアラートの数および一覧
    • Alerting Rule Details を表示するには、Alerts ページのアラートの右側にある kebab メニューの View Alerting Rule を選択します。
注記

選択したプロジェクトに関連するアラート、サイレンスおよびアラートルールのみが Developer パースペクティブに表示されます。

9.4. アラートルールの管理

OpenShift Container Platform モニタリングには、デフォルトのアラートルールのセットが同梱されます。クラスター管理者は、デフォルトのアラートルールを表示できます。

OpenShift Container Platform 4.10 では、ユーザー定義プロジェクトでアラートルールを作成、表示、編集、および削除することができます。

アラートルールについての考慮事項

  • デフォルトのアラートルールは OpenShift Container Platform クラスター用に使用され、それ以外の目的では使用されません。
  • 一部のアラートルールには、複数の意図的に同じ名前が含まれます。それらは同じイベントについてのアラートを送信しますが、それぞれ異なるしきい値、重大度およびそれらの両方が設定されます。
  • 抑制 (inhibition) ルールは、高い重大度のアラートが実行される際に実行される低い重大度のアラートの通知を防ぎます。

9.4.1. ユーザー定義プロジェクトのアラートの最適化

アラートルールの作成時に以下の推奨事項を考慮して、独自のプロジェクトのアラートを最適化できます。

  • プロジェクト用に作成するアラートルールの数を最小限にします。影響を与える条件についてユーザーに通知するアラートルールを作成します。影響を与えない条件について数多くのアラートを生成すると、関連性のあるアラートを認識することはより困難になります。
  • 原因ではなく現象についてのアラートルールを作成します。根本的な原因に関係なく状態について通知するアラートルールを作成します。次に、原因を調査できます。アラートルールのそれぞれが特定の原因にのみ関連する場合に、さらに多くのアラートルールが必要になります。そのため、いくつかの原因は見落される可能性があります。
  • アラートルールを作成する前にプランニングを行います。重要な現象と、その発生時に実行するアクションを決定します。次に、現象別にアラートルールをビルドします。
  • クリアなアラートメッセージングを提供します。アラートメッセージに現象および推奨されるアクションを記載します。
  • アラートルールに重大度レベルを含めます。アラートの重大度は、報告される現象が生じた場合に取るべき対応によって異なります。たとえば、現象に個人または緊急対策チーム (Critical Response Team) による早急な対応が必要な場合、重大アラートをトリガーする必要があります。
  • アラートルーティングを最適化します。ルールがデフォルトの OpenShift Container Platform メトリクスをクエリーしない場合には、openshift-user-workload-monitoring プロジェクトの Prometheus インスタンスにアラートルールを直接デプロイします。これにより、アラートルールの待ち時間が短縮され、モニタリングコンポーネントへの負荷が最小限に抑えられます。

    警告

    ユーザー定義プロジェクトのデフォルトの OpenShift Container Platform メトリクスは、CPU およびメモリーの使用状況、帯域幅の統計、およびパケットレートについての情報を提供します。ルールを openshift-user-workload-monitoring プロジェクトの Prometheus インスタンスに直接ロート指定する場合、これらのメトリクスをアラートルールに含めることはできません。アラートルールの最適化は、ドキュメントを参照し、モニタリング用のアーキテクチャーの全体像を把握している場合にのみ使用してください。

関連情報

9.4.2. ユーザー定義プロジェクトのアラートルールの作成

ユーザー定義のプロジェクトについてアラートルールを作成できます。これらのアラートルールは、選択したメトリクスの値に基づいてアラートを実行します。

前提条件

  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • アラートルールを作成する必要のある namespace の monitoring-rules-edit ロールを持つユーザーとしてログインします。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. アラートルールの YAML ファイルを作成します。この例では、example-app-alerting-rule.yaml という名前です。
  2. アラートルール設定を YAML ファイルに追加します。以下は例になります。

    注記

    アラートルールの作成時に、同じ名前のルールが別のプロジェクトにある場合に、プロジェクトのラベルがこのアラートルールに対して適用されます。

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: example-alert
      namespace: ns1
    spec:
      groups:
      - name: example
        rules:
        - alert: VersionAlert
          expr: version{job="prometheus-example-app"} == 0

    この設定により、example-alert という名前のアラートルールが作成されます。アラートルールは、サンプルサービスによって公開される version メトリクスが 0 になるとアラートを実行します。

    重要

    ユーザー定義のアラートルールには、独自のプロジェクトおよびクラスターメトリクスのメトリクスを含めることができます。別のユーザー定義プロジェクトのメトリクスを含めることはできません。

    たとえば、ユーザー定義プロジェクトの ns1 のアラートルールには、ns1、および CPU およびメモリーメトリクスなどのクラスターメトリクスなどを含めることができます。ただし、ルールには ns2 からのメトリクスを含めることはできません。

    さらに、openshift-* コア OpenShift Container Platform プロジェクトのアラートルールは作成できません。デフォルトで OpenShift Container Platform モニタリングはこれらのプロジェクトのアラートルールのセットを提供します。

  3. 設定ファイルをクラスターに適用します。

    $ oc apply -f example-app-alerting-rule.yaml

    アラートルールの作成には多少時間がかかります。

9.4.3. プラットフォームメトリクスをクエリーしないアラートルールの待ち時間の短縮

ユーザー定義プロジェクトのアラートルールがデフォルトのクラスターメトリクスをクエリーしない場合、openshift-user-workload-monitoring プロジェクトの Prometheus インスタンスにルールを直接デプロイすることができます。これにより、Thanos Ruler が必要でない場合にこれをバイパスすることで、アラートルールの待ち時間が短縮されます。これは、モニタリングコンポーネントの全体的な負荷を最小限に抑えるのに役立ちます。

警告

ユーザー定義プロジェクトのデフォルトの OpenShift Container Platform メトリクスは、CPU およびメモリーの使用状況、帯域幅の統計、およびパケットレートについての情報を提供します。ルールを openshift-user-workload-monitoring プロジェクトの Prometheus インスタンスに直接デプロイする場合、これらのメトリクスをアラートルールに含めることはできません。本セクションで説明した手順は、ドキュメントを参照し、モニタリング用のアーキテクチャーの全体像を把握している場合にのみ使用してください。

前提条件

  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • アラートルールを作成する必要のある namespace の monitoring-rules-edit ロールを持つユーザーとしてログインします。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. アラートルールの YAML ファイルを作成します。この例では、example-app-alerting-rule.yaml という名前です。
  2. キーが openshift.io/prometheus-rule-evaluation-scope で、値が leaf-prometheus のラベルが含まれる YAML ファイルにアラートルール設定を追加します。以下は例になります。

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: example-alert
      namespace: ns1
      labels:
        openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus
    spec:
      groups:
      - name: example
        rules:
        - alert: VersionAlert
          expr: version{job="prometheus-example-app"} == 0

そのラベルがある場合、アラートルールは openshift-user-workload-monitoring プロジェクトの Prometheus インスタンスにデプロイされます。ラベルが存在しない場合、アラートルールは Theanos Ruler にデプロイされます。

  1. 設定ファイルをクラスターに適用します。

    $ oc apply -f example-app-alerting-rule.yaml

    アラートルールの作成には多少時間がかかります。

  • OpenShift Container Platform 4.10 モニタリングアーキテクチャーに関する詳細は、Monitoring overview を参照してください。

9.4.4. ユーザー定義プロジェクトのアラートルールへのアクセス

ユーザー定義プロジェクトのアラートルールを一覧表示するには、プロジェクトの monitoring-rules-view ロールが割り当てられている必要があります。

前提条件

  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • プロジェクトの monitoring-rules-view ロールを持つユーザーとしてログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. <project> でアラートルールを一覧表示できます。

    $ oc -n <project> get prometheusrule
  2. アラートルールの設定を一覧表示するには、以下を実行します。

    $ oc -n <project> get prometheusrule <rule> -o yaml

9.4.5. 単一ビューでのすべてのプロジェクトのアラートルールの一覧表示

クラスター管理者は、OpenShift Container Platform のコアプロジェクトおよびユーザー定義プロジェクトのアラートルールを単一ビューで一覧表示できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. Administrator パースペクティブで、ObserveAlertingAlerting Rules に移動します。
  2. Filter ドロップダウンメニューで、Platform および User ソースを選択します。

    注記

    Platform ソースはデフォルトで選択されます。

9.4.6. ユーザー定義プロジェクトのアラートルールの削除

ユーザー定義プロジェクトのアラートルールを削除できます。

前提条件

  • ユーザー定義プロジェクトのモニタリングを有効にしている。
  • アラートルールを作成する必要のある namespace の monitoring-rules-edit ロールを持つユーザーとしてログインします。
  • OpenShift CLI (oc) がインストールされている。

手順

  • <namespace> のルール <foo> を削除するには、以下を実行します。

    $ oc -n <namespace> delete prometheusrule <foo>

関連情報

9.5. サイレンスの管理

アラートの発生時にアラートについての通知の受信を停止するためにサイレンスを作成できます。根本的な問題を解決する際に、初回の通知後にアラートをサイレンスにすることが役に立つ場合があります。

サイレンスの作成時に、サイレンスをすぐにアクティブにするか、または後にアクティブにするかを指定する必要があります。また、サイレンスの有効期限を設定する必要もあります。

既存のサイレンスを表示し、編集し、期限切れにすることができます。

9.5.1. アラートをサイレンスにする

特定のアラート、または定義する仕様に一致するアラートのいずれかをサイレンスにすることができます。

前提条件

  • 開発者として、またはメトリクスで表示しているプロジェクトの edit パーミッションを持つユーザーとしてクラスターへのアクセスがある。

手順

特定のアラートをサイレンスにするには、以下を実行します。

  • Administrator パースペクティブで、以下を行います。

    1. OpenShift Container Platform Web コンソールの ObserveAlertingAlerts ページに移動します。
    2. サイレンスにする必要のあるアラートについて、右側の列で kebab を選択し、Silence Alert を選択します。Silence Alert フォームは、選択したアラートの事前に設定された仕様と共に表示されます。
    3. オプション: サイレンスを変更します。
    4. サイレンスを作成する前にコメントを追加する必要があります。
    5. サイレンスを作成するには、Silence を選択します。
  • Developer パースペクティブ:

    1. OpenShift Container Platform Web コンソールの Observe<project_name>Alerts ページに移動します。
    2. アラート名の左側にある > を選択して、アラートの詳細を展開します。拡張されたビューでアラートの名前を選択し、アラートの Alert Details ページを開きます。
    3. Silence Alert を選択します。Silence Alert フォームが、選択したアラートの事前に設定された仕様と共に表示されます。
    4. オプション: サイレンスを変更します。
    5. サイレンスを作成する前にコメントを追加する必要があります。
    6. サイレンスを作成するには、Silence を選択します。

Administrator パースペクティブにアラート仕様を作成してアラートのセットをサイレンスにするには、以下を実行します。

  1. OpenShift Container Platform Web コンソールの ObserveAlertingSilences ページに移動します。
  2. Create Silence を選択します。
  3. Create Silence フォームで、アラートのスケジュール、期間、およびラベルの詳細を設定します。また、サイレンスのコメントを追加する必要もあります。
  4. 直前の手順で入力したラベルセクターに一致するアラートのサイレンスを作成するには、Silence を選択します。

9.5.2. サイレンスの編集

サイレンスは編集することができます。 これにより、既存のサイレンスが期限切れとなり、変更された設定で新規のサイレンスが作成されます。

手順

Administrator パースペクティブでサイレンスを編集するには、以下を実行します。

  1. ObserveAlertingSilences ページに移動します。
  2. 変更するサイレンスについて、最後の列の kebab を選択し、Edit silence を選択します。

    または、サイレンスについて Silence Details ページで ActionsEdit Silence を選択できます。

  3. Edit Silence ページで変更を入力し、Silence を選択します。これにより、既存のサイレンスが期限切れとなり、選択された設定でサイレンスが作成されます。

Developer パースペクティブでサイレンスを編集するには、以下を実行します。

  1. Observe<project_name>Alerts ページに移動します。
  2. アラート名の左側にある > を選択して、アラートの詳細を展開します。拡張されたビューでアラートの名前を選択し、アラートの Alert Details ページを開きます。
  3. そのページの Silenced By セクションでサイレンスの名前を選択し、サイレンスの Silence Details ページに移動します。
  4. Silence Details ページに移動するサイレンスの名前を選択します。
  5. サイレンスについて、Silence Details ページで ActionsEdit Silence を選択します。
  6. Edit Silence ページで変更を入力し、Silence を選択します。これにより、既存のサイレンスが期限切れとなり、選択された設定でサイレンスが作成されます。

9.5.3. 有効期限切れにするサイレンス

サイレンスは有効期限切れにすることができます。サイレンスはいったん期限切れになると、永久に無効にされます。

手順

Administrator パースペクティブでサイレンスを期限切れにするには、以下を実行します。

  1. ObserveAlertingSilences ページに移動します。
  2. 変更するサイレンスについて、最後の列の kebab を選択し、Expire silence を選択します。

    または、サイレンスの Silence Details ページで ActionsExpire Silence を選択できます。

Developer パースペクティブでサイレンスを期限切れにするには、以下を実行します。

  1. Observe<project_name>Alerts ページに移動します。
  2. アラート名の左側にある > を選択して、アラートの詳細を展開します。拡張されたビューでアラートの名前を選択し、アラートの Alert Details ページを開きます。
  3. そのページの Silenced By セクションでサイレンスの名前を選択し、サイレンスの Silence Details ページに移動します。
  4. Silence Details ページに移動するサイレンスの名前を選択します。
  5. サイレンスの Silence Details ページで ActionsExpire Silence を選択します。

9.6. 外部システムへの通知の送信

OpenShift Container Platform 4.10 では、実行するアラートをアラート UI で表示できます。アラートは、デフォルトでは通知システムに送信されるように設定されません。以下のレシーバータイプにアラートを送信するように OpenShift Container Platform を設定できます。

  • PagerDuty
  • Webhook
  • Email
  • Slack

レシーバーへのアラートのルートを指定することにより、障害が発生する際に適切なチームに通知をタイムリーに送信できます。たとえば、重大なアラートには早急な対応が必要となり、通常は個人または緊急対策チーム (Critical Response Team) に送信先が設定されます。重大ではない警告通知を提供するアラートは、早急な対応を要さないレビュー用にチケットシステムにルート指定される可能性があります。

Watchdog アラートの使用によるアラートが機能することの確認

OpenShift Container Platform モニタリングには、継続的に実行される Watchdog アラートが含まれます。Alertmanager は、Watchdog のアラート通知を設定された通知プロバイダーに繰り返し送信します。通常、プロバイダーは Watchdog アラートの受信を停止する際に管理者に通知するように設定されます。このメカニズムは、Alertmanager と通知プロバイダー間の通信に関連する問題を迅速に特定するのに役立ちます。

9.6.1. アラートレシーバーの設定

アラートレシーバーを設定して、クラスターについての重要な問題について把握できるようにします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. Administrator パースペクティブで、AdministrationCluster SettingsConfigurationAlertmanager に移動します。

    注記

    または、通知ドロワーで同じページに移動することもできます。OpenShift Container Platform Web コンソールの右上にあるベルのアイコンを選択し、AlertmanagerReceiverNotConfigured アラートで Configure を選択します。

  2. ページの Receivers セクションで Create Receiver を選択します。
  3. Create Receiver フォームで、Receiver Name を追加し、一覧から Receiver Type を選択します。
  4. レシーバー設定を編集します。

    • PagerDuty receiver の場合:

      1. 統合のタイプを選択し、PagerDuty 統合キーを追加します。
      2. PagerDuty インストールの URL を追加します。
      3. クライアントおよびインシデントの詳細または重大度の指定を編集する場合は、Show advanced configuration を選択します。
    • Webhook receiver の場合:

      1. HTTP POST リクエストを送信するエンドポイントを追加します。
      2. デフォルトオプションを編集して解決したアラートを receiver に送信する場合は、Show advanced configuration を選択します。
    • メール receiver の場合:

      1. 通知を送信するメールアドレスを追加します。
      2. SMTP 設定の詳細を追加します。これには、通知の送信先のアドレス、メールの送信に使用する smarthost およびポート番号、SMTP サーバーのホスト名、および認証情報を含む詳細情報が含まれます。
      3. TLS が必要であるかどうかについて選択します。
      4. デフォルトオプションを編集して解決済みのアラートが receiver に送信されないようにしたり、メール通知設定の本体を編集する必要がある場合は、Show advanced configuration を選択します。
    • Slack receiver の場合:

      1. Slack Webhook の URL を追加します。
      2. 通知を送信する Slack チャネルまたはユーザー名を追加します。
      3. デフォルトオプションを編集して解決済みのアラートが receiver に送信されないようにしたり、アイコンおよびユーザー設定を編集する必要がある場合は、Show advanced configuration を選択します。チャネル名とユーザー名を検索し、これらをリンクするかどうかについて選択することもできます。
  5. デフォルトでは、実行されるすべてのセレクターに一致するラベルを持つアラートは receiver に送信されます。実行されるアラートのラベルの値を、それらが receiver に送信される前の状態に完全に一致させる必要がある場合は、以下を実行します。

    1. ルーティングラベル名と値をフォームの Routing Labels セクションに追加します。
    2. 正規表現を使用する場合は Regular Expression を選択します。
    3. Add Label を選択して、さらにルーティングラベルを追加します。
  6. Create を選択して receiver を作成します。

9.6.2. ユーザー定義プロジェクトのアラートルーティングの作成

重要

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

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

alert-routing-edit ロールが付与されている管理者以外のユーザーの場合は、ユーザー定義プロジェクトのアラートルーティングを作成または編集できます。

前提条件

  • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
  • クラスター管理者は、ユーザー定義プロジェクトのアラートルーティングを有効にしました。
  • アラートルーティングを作成する必要のあるプロジェクトの alert-routing-edit ロールを持つユーザーとしてログインしています。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. アラートルーティングの YAML ファイルを作成します。この手順の例では、example-app-alert-routing.yaml という名前のファイルを使用します。
  2. AlertmanagerConfig YAML 定義をファイルに追加します。以下に例を示します。

    apiVersion: monitoring.coreos.com/v1alpha1
    kind: AlertmanagerConfig
    metadata:
      name: example-routing
      namespace: ns1
    spec:
      route:
        receiver: default
        groupBy: [job]
      receivers:
      - name: default
        webhookConfigs:
        - url: https://example.org/post
    注記

    ユーザー定義のアラートルールの場合、ユーザー定義のルーティングはリソースが定義される namespace に対してスコープ指定されます。たとえば、namespace ns1AlertmanagerConfig オブジェクトで定義されるルーティング設定は、同じ namespace の PrometheusRules リソースにのみ適用されます。

  3. ファイルを保存します。
  4. リソースをクラスターに適用します。

    $ oc apply -f example-app-alert-routing.yaml

    この設定は Alertmanager Pod に自動的に適用されます。

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

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

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

CLI で Alertmanager 設定を変更するには、以下を実行します。

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

    $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > 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 は、アラートに使用する受信手段を指定します。

    以下の Alertmanager 設定例は、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 receiver を使用して送信されます。通常、これらのタイプのアラートは、個別または緊急対策チーム (Critical Response Team) に送信先が設定されます。

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

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

OpenShift Container Platform Web コンソールから Alertmanager 設定を変更するには、以下を実行します。

  1. Web コンソールの AdministrationCluster SettingsConfigurationAlertmanagerYAML ページに移動します。
  2. YAML 設定ファイルを変更します。
  3. Save を選択します。

関連情報

9.8. 次のステップ

第10章 モニタリングダッシュボードの確認

OpenShift Container Platform 4.10 は、クラスターコンポーネントおよびユーザー定義ワークロードの状態を理解するのに役立つ包括的なモニタリングダッシュボードのセットを提供します。

Administrator パースペクティブを使用して、以下を含む OpenShift Container Platform のコアコンポーネントのダッシュボードにアクセスします。

  • API パフォーマンス
  • etcd
  • Kubernetes コンピュートリソース
  • Kubernetes ネットワークリソース
  • Prometheus
  • クラスターおよびノードのパフォーマンスに関連する USE メソッドダッシュボード

図10.1 Administrator パースペクティブのダッシュボードの例

ダッシュボード管理者のモニタリング

Developer パースペクティブを使用して、選択されたプロジェクトの以下のアプリケーションメトリクスを提供する Kubernetes コンピュートリソースダッシュボードにアクセスします。

  • CPU usage (CPU の使用率)
  • メモリー使用量
  • 帯域幅に関する情報
  • パケットレート情報

図10.2 Developer パースペクティブのダッシュボードの例

ダッシュボード開発者の監視
注記

Developer パースペクティブでは、1 度に 1 つのプロジェクトのみのダッシュボードを表示できます。

10.1. クラスター管理者としてのモニタリングダッシュボードの確認

Administrator パースペクティブでは、OpenShift Container Platform クラスターのコアコンポーネントに関連するダッシュボードを表示できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、ObserveDashboards に移動します。
  2. Dashboard 一覧でダッシュボードを選択します。etcdPrometheus ダッシュボードなどの一部のダッシュボードは、選択時に追加のサブメニューを生成します。
  3. 必要に応じて、Time Range 一覧でグラフの時間範囲を選択します。

    • 事前定義済みの期間を選択します。
    • 時間範囲 一覧で カスタムの時間範囲 を選択して、カスタムの時間範囲を設定します。

      1. From および To の日付と時間を入力または選択します。
      2. Save をクリックして、カスタムの時間範囲を保存します。
  4. オプション: Refresh Interval を選択します。
  5. 特定の項目についての詳細情報を表示するには、ダッシュボードの各グラフにカーソルを合わせます。

10.2. 開発者が行うモニタリングダッシュボードの確認

Developer パースペクティブを使用して、選択したプロジェクトの Kubernetes コンピュートリソースダッシュボードを表示します。

前提条件

  • 開発者またはユーザーとしてクラスターにアクセスできる。
  • ダッシュボードを表示するプロジェクトの表示パーミッションがある。

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブで、ObserveDashboard に移動します。
  2. Project: ドロップダウンリストからプロジェクトを選択します。
  3. Dashboard ドロップダウンリストからダッシュボードを選択し、フィルターされたメトリクスを表示します。

    注記

    すべてのダッシュボードは、Kubernetes / Compute Resources / Namespace(Pod) を除く、選択時に追加のサブメニューを生成します。

  4. 必要に応じて、Time Range 一覧でグラフの時間範囲を選択します。

    • 事前定義済みの期間を選択します。
    • 時間範囲 一覧で カスタムの時間範囲 を選択して、カスタムの時間範囲を設定します。

      1. From および To の日付と時間を入力または選択します。
      2. Save をクリックして、カスタムの時間範囲を保存します。
  5. オプション: Refresh Interval を選択します。
  6. 特定の項目についての詳細情報を表示するには、ダッシュボードの各グラフにカーソルを合わせます。

10.3. 次のステップ

第11章 Bare Metal Event Relay を使用したベアメタルイベントのモニタリング

重要

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

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

11.1. ベアメタル イベント

Bare Metal Event Relay を使用して、OpenShift Container Platform クラスターで実行されるアプリケーションを、基礎となるベアメタルホストで生成されるイベントにサブスクライブします。Redfish サービスは、ノードでイベントをパブリッシュし、サブスクライブされたアプリケーションに高度なメッセージキューでイベントを送信します。

ベアメタルイベントは、Distributed Management Task Force (DMTF) のガイダンスに基づいて開発されたオープン Redfish 標準に基づいています。Redfish は、REST API を使用してセキュアな業界標準プロトコルを提供します。このプロトコルは、分散された、コンバージドまたはソフトウェア定義のリソースおよびインフラストラクチャーの管理に使用されます。

Redfish から公開されるハードウェア関連のイベントには、以下が含まれます。

  • 温度制限の違反
  • サーバーステータス
  • fan ステータス

Bare Metal Event Relay Operator をデプロイし、アプリケーションをサービスにサブスクライブして、ベアメタルイベントの使用を開始します。Bare Metal Event Relay Operator は Redfish ベアメタルイベントサービスのライフサイクルをインストールし、管理します。

注記

Bare Metal Event Relay は、ベアメタルインフラストラクチャーにプロビジョニングされる単一ノードクラスターの Redfish 対応デバイスでのみ機能します。

11.2. ベアメタルイベントの仕組み

Bare Metal Event Relay により、ベアメタルクラスターで実行されるアプリケーションが Redfish ハードウェアの変更や障害に迅速に対応することができます。たとえば、温度のしきい値の違反、fan の障害、ディスク損失、電源停止、メモリー障害などが挙げられます。これらのハードウェアイベントは、Advanced Message Queuing Protocol (AMQP) をベースとした信頼できる低レイテンシートランスポートチャネルを介して配信されます。メッセージングサービスのレイテンシーは 10 ミリ秒から 20 ミリ秒です。

Bare Metal Event Relay は、ハードウェアイベントにパブリッシュサブスクライブサービスを提供します。ここでは、複数のアプリケーションが REST API を使用してイベントをサブスクライブおよび消費できます。Bare Metal Event Relay は、Redfish OpenAPI v1.8 以降に準拠するハードウェアをサポートします。

11.2.1. Bare Metal Event Relay データフロー

以下の図は、ベアメタルイベントデータフローのサンプルを示しています。vDU は、ベアメタルイベントと対話するアプリケーションの例です。

図11.1 Bare Metal Event Relay データフロー

ベアメタルイベントデータフロー

11.2.1.1. Operator 管理の Pod

Operator はカスタムリソースを使用して、HardwareEvent CR を使用して Bare Metal Event Relay およびそのコンポーネントが含まれる Pod を管理します。

11.2.1.2. Bare Metal イベントリレー

起動時に、Bare Metal Event Relay は Redfish API をクエリーし、カスタムレジストリーを含むすべてのメッセージレジストリーをダウンロードします。その後、Bare Metal Event Relay は Redfish ハードウェアからサブスクライブされたイベントを受信し始めます。

Bare Metal Event Relay により、ベアメタルクラスターで実行されるアプリケーションが Redfish ハードウェアの変更や障害に迅速に対応することができます。たとえば、温度のしきい値の違反、fan の障害、ディスク損失、電源停止、メモリー障害などが挙げられます。イベントは HardwareEvent CR を使用してレポートされます。

11.2.1.3. クラウドネイティブイベント

クラウドネイティブイベント (CNE) は、イベントデータの形式を定義する REST API 仕様です。

11.2.1.4. CNCF CloudEvents

CloudEvents は、イベントデータの形式を定義するために Cloud Native Computing Foundation (CNCF) によって開発されたベンダーに依存しない仕様です。

11.2.1.5. AMQP ディスパッチルーター

ディスパッチルーターは、パブリッシャーとサブスクライバーの間でメッセージ配信サービスを行います。AMQP 1.0 qpid は、インターネットを介した信頼できる高パフォーマンスな完全対称メッセージングをサポートするオープン標準です。

11.2.1.6. クラウドイベントプロキシーサイドカー

クラウドイベントプロキシーサイドカーコンテナーイメージは ORAN API 仕様をベースとしており、ハードウェアイベントのパブリッシュサブスクライブイベントフレームワークを提供します。

11.2.2. サービスを解析する Redfish メッセージ

Bare Metal Event Relay は Redfish イベントを処理する他に、Message プロパティーなしでイベントのメッセージ解析を提供します。プロキシーは、起動時にハードウェアからベンダー固有のレジストリーを含むすべての Redfish メッセージブローカーをダウンロードします。イベントに Message プロパティーが含まれていない場合、プロキシーは Redfish メッセージレジストリーを使用して Message プロパティーおよび Resolution プロパティーを作成し、イベントをクラウドイベントフレームワークに渡す前にイベントに追加します。このサービスにより、Redfish イベントでメッセージサイズが小さくなり、送信レイテンシーが短縮されます。

11.2.3. CLI を使用した Bare Metal Event リレーのインストール

クラスター管理者は、CLI を使用して Bare Metal Event Relay Operator をインストールできます。

前提条件

  • RedFish 対応ベースボード管理コントローラー (BMC) を持つノードでベアメタルハードウェアにインストールされるクラスター。
  • OpenShift CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Bare Metal Event Relay の namespace を作成します。

    1. 以下の YAML を bare-metal-events-namespace.yaml ファイルに保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-bare-metal-events
        labels:
          name: openshift-bare-metal-events
          openshift.io/cluster-monitoring: "true"
    2. namespace CR を作成します。

      $ oc create -f bare-metal-events-namespace.yaml
  2. Bare Metal Event Relay Operator の Operator グループを作成します。

    1. 以下の YAML を bare-metal-events-operatorgroup.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: bare-metal-event-relay-group
        namespace: openshift-bare-metal-events
      spec:
        targetNamespaces:
        - openshift-bare-metal-events
    2. OperatorGroup CR を作成します。

      $ oc create -f bare-metal-events-operatorgroup.yaml
  3. Bare Metal Event Relay にサブスクライブします。

    1. 以下の YAML を bare-metal-events-sub.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bare-metal-event-relay-subscription
        namespace: openshift-bare-metal-events
      spec:
        channel: "stable"
        name: bare-metal-event-relay
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. Subscription CR を作成します。

      $ oc create -f bare-metal-events-sub.yaml

検証

Bare Metal Event Relay Operator がインストールされていることを確認するには、以下のコマンドを実行します。

$ oc get csv -n openshift-bare-metal-events -o custom-columns=Name:.metadata.name,Phase:.status.phase

出力例

Name                                                    Phase
bare-metal-event-relay.4.10.0-202206301927              Succeeded

11.2.4. Web コンソールを使用した Bare Metal Event リレーのインストール

クラスター管理者は、Web コンソールを使用して Bare Metal Event Relay Operator をインストールできます。

前提条件

  • RedFish 対応ベースボード管理コントローラー (BMC) を持つノードでベアメタルハードウェアにインストールされるクラスター。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. OpenShift Container Platform Web コンソールを使用して Bare Metal Event Relay をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から Bare Metal Event Relay を選択し、Install をクリックします。
    3. Install Operatorページで、Namespace を選択または作成し、openshift-bare-metal-events を選択して、Install をクリックします。

検証

オプション: 以下のチェックを実行して、Operator が正常にインストールされていることを確認できます。

  1. OperatorsInstalled Operators ページに切り替えます。
  2. StatusInstallSucceeded の状態で、Bare Metal Event Relay がプロジェクトに一覧表示されていることを確認します。

    注記

    インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

  • OperatorsInstalled Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
  • WorkloadsPods ページに移動し、プロジェクト namespace で Pod のログを確認します。

11.3. AMQ メッセージングバスのインストール

ノードのパブリッシャーとサブスクライバー間で Redfish ベアメタルイベント通知を渡すには、ノード上でローカルを実行するように AMQ メッセージングバスをインストールし、設定する必要があります。これは、クラスターで使用するために AMQ Interconnect Operator をインストールして行います。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

検証

  1. AMQ Interconnect Operator が利用可能で、必要な Pod が実行されていることを確認します。

    $ oc get pods -n amq-interconnect

    出力例

    NAME                                    READY   STATUS    RESTARTS   AGE
    amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
    interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

  2. 必要な bare-metal-event-relay ベアメタルイベントプロデューサー Pod が openshift-bare-metal-events namespace で実行されていることを確認します。

    $ oc get pods -n openshift-bare-metal-events

    出力例

    NAME                                                            READY   STATUS    RESTARTS   AGE
    hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl     2/2     Running   0          25s

11.4. クラスターノードの Redfish BMC ベアメタルイベントのサブスクライブ

クラスター管理者は、ノードの BMCEventSubscription カスタムリソース (CR) を作成し、イベント用の HardwareEvent CR を作成して BMC の Secret CR を作成して、クラスター内のノードで生成される Redfish BMC イベントにサブスクライブできます。

11.4.1. ベアメタルイベントのサブスクライブ

ベースボード管理コントローラー (BMC) を設定して、ベアメタルイベントを OpenShift Container Platform クラスターで実行されているサブスクライブされたアプリケーションに送信できます。Redfish ベアメタルイベントの例には、デバイス温度の増加やデバイスの削除が含まれます。REST API を使用して、アプリケーションをベアメタルイベントにサブスクライブします。

重要

BMCEventSubscription カスタムリソース (CR) は、Redfish をサポートし、ベンダーインターフェイスが redfish または idrac-redfish に設定されている物理ハードウェアにのみ作成できます。

注記

BMCEventSubscription CR を使用して事前定義された Redfish イベントにサブスクライブします。Redfish 標準は、特定のアラートおよびしきい値を作成するオプションを提供しません。例えば、エンクロージャーの温度が摂氏 40 度を超えたときにアラートイベントを受け取るには、ベンダーの推奨に従ってイベントを手動で設定する必要があります。

BMCEventSubscription CR を使用してノードのベアメタルイベントをサブスクライブするには、以下の手順を行います。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • BMC のユーザー名およびパスワードを取得します。
  • クラスターに Redfish が有効な Baseboard Management Controller (BMC) を持つベアメタルノードをデプロイし、BMC で Redfish イベントを有効にします。

    注記

    特定のハードウェアで Redfish イベントを有効にすることは、この情報の対象範囲外です。特定のハードウェアの Redfish イベントを有効にする方法は、BMC の製造元のドキュメントを参照してください。

手順

  1. 以下の curl コマンドを実行して、ノードのハードウェアで Redfish EventService が有効になっていることを確認します。

    curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"

    ここで、

    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

    出力例

    {
       "@odata.context": "/redfish/v1/$metadata#EventService.EventService",
       "@odata.id": "/redfish/v1/EventService",
       "@odata.type": "#EventService.v1_0_2.EventService",
       "Actions": {
          "#EventService.SubmitTestEvent": {
             "EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
             "target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
          }
       },
       "DeliveryRetryAttempts": 3,
       "DeliveryRetryIntervalSeconds": 30,
       "Description": "Event Service represents the properties for the service",
       "EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
       "EventTypesForSubscription@odata.count": 5,
       "Id": "EventService",
       "Name": "Event Service",
       "ServiceEnabled": true,
       "Status": {
          "Health": "OK",
          "HealthRollup": "OK",
          "State": "Enabled"
       },
       "Subscriptions": {
          "@odata.id": "/redfish/v1/EventService/Subscriptions"
       }
    }

  2. 以下のコマンドを実行して、クラスターの Bare Metal Event Relay サービスのルートを取得します。

    $ oc get route -n openshift-bare-metal-events

    出力例

    NAME             HOST/PORT                                                                                           PATH   SERVICES                 PORT   TERMINATION   WILDCARD
    hw-event-proxy   hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com          hw-event-proxy-service   9087   edge          None

  3. BMCEventSubscription リソースを作成し、Redfish イベントにサブスクライブします。

    1. 以下の YAML を bmc_sub.yaml ファイルに保存します。

      apiVersion: metal3.io/v1alpha1
      kind: BMCEventSubscription
      metadata:
        name: sub-01
        namespace: openshift-machine-api
      spec:
         hostName: <hostname> 1
         destination: <proxy_service_url> 2
         context: ''
      1
      Redfish イベントが生成されるワーカーノードの名前または UUID を指定します。
      2
      ベアメタルイベントプロキシーサービスを指定します (例: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook)。
    2. BMCEventSubscription CR を作成します。

      $ oc create -f bmc_sub.yaml
  4. オプション: BMC イベントサブスクリプションを削除するには、以下のコマンドを実行します。

    $ oc delete -f bmc_sub.yaml
  5. オプション:BMCEventSubscription CR を作成せずに Redfish イベントサブスクリプションを手動で作成するには、BMC のユーザー名およびパスワードを指定して以下の curl コマンドを実行します。

    $ curl -i -k -X POST -H "Content-Type: application/json"  -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v

    ここで、

    proxy_service_url
    ベアメタルイベントプロキシーサービスです (例: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook)。
    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

    出力例

    HTTP/1.1 201 Created
    Server: AMI MegaRAC Redfish Service
    Location: /redfish/v1/EventService/Subscriptions/1
    Allow: GET, POST
    Access-Control-Allow-Origin: *
    Access-Control-Expose-Headers: X-Auth-Token
    Access-Control-Allow-Headers: X-Auth-Token
    Access-Control-Allow-Credentials: true
    Cache-Control: no-cache, must-revalidate
    Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
    Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
    Link: </redfish/v1/EventService/Subscriptions>; path=
    ETag: "1651135676"
    Content-Type: application/json; charset=UTF-8
    OData-Version: 4.0
    Content-Length: 614
    Date: Thu, 28 Apr 2022 08:47:57 GMT

11.4.2. curl を使用した Redfish ベアメタルイベントサブスクリプションのクエリー

一部のハードウェアベンダーは Redfish ハードウェアイベントサブスクリプションの量を制限します。curl を使用して Redfish イベントサブスクリプションの数をクエリーできます。

前提条件

  • BMC のユーザー名およびパスワードを取得します。
  • クラスターに Redfish が有効な Baseboard Management Controller (BMC) を持つベアメタルノードをデプロイし、BMC で Redfish ハードウェアイベントを有効にします。

手順

  1. 以下の curl コマンドを実行して、BMC の現在のサブスクリプションを確認します。

    $ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions

    ここで、

    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

    出力例

    % Total % Received % Xferd Average Speed Time Time Time Current
    Dload Upload Total Spent Left Speed
    100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
    {
      "@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
      "@odata.etag": ""
      1651137375 "",
      "@odata.id": "/redfish/v1/EventService/Subscriptions",
      "@odata.type": "#EventDestinationCollection.EventDestinationCollection",
      "Description": "Collection for Event Subscriptions",
      "Members": [
      {
        "@odata.id": "/redfish/v1/EventService/Subscriptions/1"
      }],
      "Members@odata.count": 1,
      "Name": "Event Subscriptions Collection"
    }

    この例では、サブスクリプションが 1 つ設定されています(/redfish/v1/EventService/Subscriptions/1)。

  2. オプション: curl/redfish/v1/EventService/Subscriptions/1 サブスクリプションを削除するには、BMC のユーザー名およびパスワードを指定して以下のコマンドを実行します。

    $ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1

    ここで、

    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

11.4.3. ベアメタルイベントおよびシークレット CR の作成

ベアメタルイベントの使用を開始するには、Redfish ハードウェアが存在するホストの HardwareEvent カスタムリソース(CR)を作成します。ハードウェアイベントと障害は hw-event-proxy ログに報告されます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • Bare Metal Event Relay をインストールします。
  • BMC Redfish ハードウェア用に BMCEventSubscription CR を作成します。
注記

複数の HardwareEvent リソースは許可されません。

手順

  1. HardwareEvent カスタムリソース(CR)を作成します。

    1. 以下の YAML を hw-event.yaml ファイルに保存します。

      apiVersion: "event.redhat-cne.org/v1alpha1"
      kind: "HardwareEvent"
      metadata:
        name: "hardware-event"
      spec:
        nodeSelector:
          node-role.kubernetes.io/hw-event: "" 1
        transportHost: "amqp://amq-router-service-name.amq-namespace.svc.cluster.local" 2
        logLevel: "debug" 3
        msgParserTimeout: "10" 4
      1
      必須。nodeSelector フィールドを使用して、指定されたラベルを持つノードをターゲットにします (例: node-role.kubernetes.io/hw-event: ""
      2
      必須。AMQP プロトコルを使用してトランスポート層でイベントを提供する AMQP ホスト。
      3
      任意。デフォルト値は debug です。hw-event-proxy ログでログレベルを設定します。fatalerrorwarninginfodebugtrace のログレベルを利用できます。
      4
      任意。Message Parser のタイムアウト値をミリ秒単位で設定します。メッセージ解析要求がタイムアウト期間内に応答しない場合には、元のハードウェアイベントメッセージはクラウドネイティブイベントフレームワークに渡されます。デフォルト値は 10 です。
    2. HardwareEvent CR を作成します。

      $ oc create -f hardware-event.yaml
  2. BMC ユーザー名およびパスワード Secret CR を作成します。これにより、ハードウェアイベントプロキシーがベアメタルホストの Redfish メッセージレジストリーにアクセスできるようになります。

    1. 以下の YAML を hw-event-bmc-secret.yaml ファイルに保存します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: redfish-basic-auth
      type: Opaque
      stringData: 1
        username: <bmc_username>
        password: <bmc_password>
        # BMC host DNS or IP address
        hostaddr: <bmc_host_ip_address>
      1
      stringData の下に、さまざまな項目のプレーンテキスト値を入力します。
    2. Secret CR を作成します。

      $ oc create -f hw-event-bmc-secret.yaml

11.5. ベアメタルイベント REST API リファレンスへのアプリケーションのサブスクライブ

ベアメタルイベント REST API を使用して、親ノードで生成されるベアメタルイベントにアプリケーションをサブスクライブします。

リソースアドレス /cluster/node/<node_name>/redfish/event を使用して、アプリケーションを Redfish イベントにサブスクライブします。<node_name> は、アプリケーションを実行するクラスターノードに置き換えます。

cloud-event-consumer アプリケーションコンテナーおよび cloud-event-proxy サイドカーコンテナーを別のアプリケーション Pod にデプロイします。cloud-event-consumer アプリケーションは、アプリケーション Pod の cloud-event-proxy コンテナーにサブスクライブします。

以下の API エンドポイントを使用して、アプリケーション Pod の http://localhost:8089/api/cloudNotifications/v1/cloud-event-proxy コンテナーが送信する Redfish イベントに cloud-event-consumer アプリケーションをサブスクライブします。

  • /api/cloudNotifications/v1/subscriptions

    • POST: 新しいサブスクリプションを作成します。
    • GET: サブスクリプションの一覧を取得します。
  • /api/cloudNotifications/v1/subscriptions/<subscription_id>

    • GET:指定されたサブスクリプション ID の詳細を返します。
  • api/cloudNotifications/v1/subscriptions/status/<subscription_id>

    • PUT: 指定されたサブスクリプション ID に新しいステータス ping 要求を作成します。
  • /api/cloudNotifications/v1/health

    • GET: cloudNotifications API の正常性ステータスを返します。
注記

9089 は、アプリケーション Pod にデプロイされた cloud-event-consumer コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。

api/cloudNotifications/v1/subscriptions

HTTP メソッド

GET api/cloudNotifications/v1/subscriptions

詳細

サブスクリプションの一覧を返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。

API 応答の例

[
 {
  "id": "ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "endpointUri": "http://localhost:9089/api/cloudNotifications/v1/dummy",
  "uriLocation": "http://localhost:8089/api/cloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
 }
]

HTTP メソッド

POST api/cloudNotifications/v1/subscriptions

詳細

新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created ステータスコードが返されます。

表11.1 クエリーパラメーター

パラメータータイプ

subscription

data

ペイロードの例

{
  "uriLocation": "http://localhost:8089/api/cloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
}

api/cloudNotifications/v1/subscriptions/<subscription_id>

HTTP メソッド

GET api/cloudNotifications/v1/subscriptions/<subscription_id>

詳細

ID が <subscription_id>のサブスクリプションの詳細を返します。

表11.2 クエリーパラメーター

パラメータータイプ

<subscription_id>

string

API 応答の例

{
  "id":"ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "endpointUri":"http://localhost:9089/api/cloudNotifications/v1/dummy",
  "uriLocation":"http://localhost:8089/api/cloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "resource":"/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
}

api/cloudNotifications/v1/subscriptions/status/<subscription_id>

HTTP メソッド

PUT api/cloudNotifications/v1/subscriptions/status/<subscription_id>

詳細

ID <subscription_id> のサブスクリプションの新規ステータス ping 要求を作成します。サブスクリプションが存在する場合は、ステータスリクエストに成功し、202 Accepted ステータスコードが返されます。

表11.3 クエリーパラメーター

パラメータータイプ

<subscription_id>

string

API 応答の例

{"status":"ping sent"}

api/cloudNotifications/v1/health/

HTTP メソッド

GET api/cloudNotifications/v1/health/

詳細

cloudNotifications REST API の正常性ステータスを返します。

API 応答の例

OK

第12章 サードパーティーのモニターリング UI および API へのアクセス

OpenShift Container Platform 4.10 では、Alertmanager、Thanos Ruler、および Thanos Querier のモニターリングコンポーネントのサードパーティーの Web ブラウザーユーザーインターフェイス (UI) にアクセスできません。ただし、Grafana および Prometheus の Web UI にアクセスすることはできますが、このアクセスは非推奨であり、将来の OpenShift Container Platform リリースで削除される予定です。さらに、コマンドラインインターフェイス (CLI) からサードパーティーのモニタリングコンポーネントの Web サービス API にアクセスできます。

12.1. サードパーティーのモニタリング UI へのアクセス

OpenShift Container Platform は、モニターリングスタック内の次のコンポーネント (Alertmanager、Thanos Ruler、および Thanos Querier) のサードパーティー Web ユーザーインターフェイス (UI) への直接アクセスを提供またはサポートしていません。これらのサードパーティー UI の代わりに、OpenShift Container Platform Web コンソールのObserveセクションに移動して、プラットフォームコンポーネントの metrics、alerting、metrics targets、および dashboard UI にアクセスします。

注記

Web コンソールまたは CLI からサードパーティーの Grafana および Prometheus Web UI にアクセスできますが、このアクセスは非推奨であり、将来の OpenShift Container Platform リリースで削除される予定です。

12.2. サードパーティーのモニタリング Web サービス API へのアクセス

コマンドラインからサードパーティーの Web サービス API に直接アクセスして、Prometheus、Alertmanager、Thanos Ruler、Thanos Querier などのスタックコンポーネントを監視できます。

次の例は、Alertmanager のサービス API レシーバーにクエリを実行する方法を示しています。この例では、関連付けられたユーザーアカウントがopenshift-monitoring名前空間のmonitoring-alertmanager-editロールに対してバインドされていること、およびアカウントにルートを表示する権限があることが必要です。このアクセスは、認証に Bearer Token を使用することのみをサポートします。

$ host=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath={.spec.host})
$ token=$(oc whoami -t)
$ curl -H "Authorization: Bearer $token" -k "https://$host/api/v2/receivers"
注記

Thanos Ruler および Thanos Querier サービス API にアクセスするには、要求元のアカウントが名前空間リソースに対するアクセス許可を get している必要があります。これは、アカウントに cluster-monitoring-view クラスターロールを付与することで実行できます。

12.3. 関連情報

第13章 モニタリング関連の問題のトラブルシューティング

13.1. ユーザー定義のメトリクスが利用できない理由の調査

ServiceMonitor リソースを使用すると、ユーザー定義プロジェクトでサービスによって公開されるメトリクスの使用方法を判別できます。ServiceMonitor リソースを作成している場合で、メトリクス UI に対応するメトリクスが表示されない場合は、この手順で説明されるステップを実行します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • ユーザー定義のワークロードのモニタリングを有効にし、設定している。
  • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • ServiceMonitor リソースを作成している。

手順

  1. サービスおよび ServiceMonitor リソース設定で、対応するラベルの一致を確認 します。

    1. サービスに定義されたラベルを取得します。以下の例では、ns1 プロジェクトの prometheus-example-app サービスをクエリーします。

      $ oc -n ns1 get service prometheus-example-app -o yaml

      出力例

        labels:
          app: prometheus-example-app

    2. ServiceMonitor リソース設定の matchLabels app ラベルが直前のステップのラベルの出力と一致することを確認します。

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      出力例

      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      注記

      プロジェクトの表示パーミッションを持つ開発者として、サービスおよび ServiceMonitor リソースラベルを確認できます。

  2. openshift-user-workload-monitoring プロジェクトの Prometheus Operator のログを検査します。

    1. openshift-user-workload-monitoring プロジェクトの Pod を一覧表示します。

      $ oc -n openshift-user-workload-monitoring get pods

      出力例

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

    2. prometheus-operator Pod の prometheus-operator コンテナーからログを取得します。以下の例では、Pod は prometheus-operator-776fcbbd56-2nbfm になります。

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      サービスモニターに問題がある場合、ログには以下のようなエラーが含まれる可能性があります。

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload
  3. Prometheus UI でプロジェクトのターゲットステータスを直接確認します。

    1. openshift-user-workload-monitoring プロジェクトで Prometheus インスタンスへのポート転送を確立します。

      $ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090
    2. Web ブラウザーで http://localhost:9090/targets を開き、 Prometheus UI でプロジェクトのターゲットのステータスを直接確認します。ターゲットに関連するエラーメッセージがあるかどうかを確認します。
  4. openshift-user-workload-monitoring プロジェクトで Prometheus Operator のデバッグレベルのロギングを設定 します。

    1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    2. prometheusOperatorlogLevel: debugdata/config.yaml に追加し、ログレベルを debug に設定します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug
    3. 変更を適用するためにファイルを保存します。

      注記

      openshift-user-workload-monitoring プロジェクトの prometheus-operator は、ログレベルの変更時に自動的に再起動します。

    4. debug ログレベルが openshift-user-workload-monitoring プロジェクトの prometheus-operator デプロイメントに適用されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      出力例

              - --log-level=debug

      debug レベルのロギングにより、Prometheus Operator によって行われるすべての呼び出しが表示されます。

    5. prometheus-operator Pod が実行されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get pods
      注記

      認識されない Prometheus Operator の loglevel 値が設定マップに含まれる場合、prometheus-operator Pod が正常に再起動されない可能性があります。

    6. デバッグログを確認し、Prometheus Operator が ServiceMonitor リソースを使用しているかどうかを確認します。ログで他の関連するエラーの有無を確認します。

関連情報

13.2. Prometheus が大量のディスク領域を消費している理由の特定

開発者は、キーと値のペアの形式でメトリクスの属性を定義するためにラベルを作成できます。使用できる可能性のあるキーと値のペアの数は、属性について使用できる可能性のある値の数に対応します。数が無制限の値を持つ属性は、バインドされていない属性と呼ばれます。たとえば、customer_id 属性は、使用できる値が無限にあるため、バインドされていない属性になります。

割り当てられるキーと値のペアにはすべて、一意の時系列があります。ラベルに多数のバインドされていない値を使用すると、作成される時系列の数が指数関数的に増加する可能性があります。これは Prometheus のパフォーマンスに影響する可能性があり、多くのディスク領域を消費する可能性があります。

Prometheus が多くのディスクを消費する場合、以下の手段を使用できます。

  • 収集される 収集サンプルの数を確認 します。
  • Prometheus UI での時系列データベース (TSDB) のステータスを確認 して、最も多くの時系列ラベルを作成するラベルについて確認できます。これには、クラスター管理者の権限が必要です。
  • ユーザー定義メトリクスに割り当てられるバインドされていない属性の数を減らすことで、作成される一意の時系列の数を減らします

    注記

    使用可能な値の制限されたセットにバインドされる属性を使用すると、可能なキーと値のペアの組み合わせの数が減ります。

  • ユーザー定義プロジェクト間で 収集可能なサンプル数の数に制限を適用します。これには、クラスター管理者の権限が必要です。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. Administrator パースペクティブで、ObserveMetrics に移動します。
  2. Expression フィールドで、以下の Prometheus Query Language (PromQL)クエリーを実行します。これにより、収集サンプルの数が最も多い 10 メトリクスが返されます。

    topk(10,count by (job)({__name__=~".+"}))
  3. 予想されるよりも多くの収集サンプルを持つメトリクスに割り当てられたバインドされていないラベル値の数を調査します。

    • メトリクスがユーザー定義のプロジェクトに関連する場合、ワークロードに割り当てられたメトリクスのキーと値のペアを確認します。これらのライブラリーは、アプリケーションレベルで Prometheus クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
    • メトリクスが OpenShift Container Platform のコアプロジェクトに関連する場合、Red Hat サポートケースを Red Hat カスタマーポータル で作成してください。
  4. Prometheus UI で TSDB ステータスを確認します。

    1. Administrator パースペクティブで、NetworkingRoutes に移動します。
    2. Project: 一覧で openshift-monitoring プロジェクトを選択します。
    3. prometheus-k8s 行の URL を選択し、Prometheus UI のログインページを開きます。
    4. Log in with OpenShift を選択し、OpenShift Container Platform 認証情報を使用してログインします。
    5. Prometheus UI で、StatusTSDB Status に移動します。

関連情報

第14章 Cluster Monitoring Operator の ConfigMap リファレンス

14.1. クラスターモニタリング設定リファレンス

クラスターモニタリングの一部は設定可能です。API には、さまざまな ConfigMap で定義されたパラメーターを介してアクセスできます。

設定するスタックの部分に応じて、次を編集します。

  • openshift-monitoring namespace の cluster-monitoring-config と呼ばれる ConfigMap 内の OpenShift Container Platform モニタリング コンポーネントの設定。ClusterMonitoringConfiguration によって定義されます。
  • openshift-user-workload-monitoring namespace の user-workload-monitoring-config と呼ばれる ConfigMap でユーザー定義プロジェクトをモニターするコンポーネントの設定。UserWorkloadConfiguration によって定義されます。

設定ファイル自体は、常に ConfigMap データ内の config.yaml キーの下で定義されます。

注記

すべての設定パラメーターが公開されるわけではありません。クラスター監視の設定はオプションです。設定が存在しないか、空であるか形式が正しくない場合は、デフォルトが使用されます。

14.2. AdditionalAlertmanagerConfig

14.2.1. 説明

AdditionalAlertmanagerConfig は、コンポーネントが追加の Alertmanager インスタンスと通信する方法に関する設定を定義します。

14.2.2. 必須

  • apiVersion

出現場所: PrometheusK8sConfigPrometheusRestrictedConfigThanosRulerConfig

プロパティータイプ説明

apiVersion

string

APIVersion は Alertmanager の API バージョンを定義します。

bearerToken

v1.SecretKeySelector

BearerToken は、Alertmanager への認証時に使用するベアラー トークンを定義します。

pathPrefix

string

PathPrefix は、プッシュエンドポイントパスの前に追加するパス接頭辞を定義します。

scheme

string

Alertmanagers と通信するときに使用する URL スキームをスキームします。

staticConfigs

array(string)

StaticConfigs は、静的に設定された Alertmanager のリストです。

timeout

string

タイムアウトは、アラートの送信時に使用されるタイムアウトを定義します。

tlsConfig

TLSConfig

TLSConfig は、alertmanager 接続に使用する TLS 設定を定義します。

14.3. AlertmanagerMainConfig

14.3.1. 説明

AlertmanagerMainConfig は、メインの Alertmanager インスタンスに関連する設定を定義します。

表示場所: ClusterMonitoringConfiguration

プロパティータイプ説明

enabled

bool

openshift-monitoring の下でメインの Alertmanager インスタンスを有効または無効にするブール値フラグを有効にしました。

enableUserAlertmanagerConfig

bool

EnableUserAlertManagerConfig ユーザー定義の namespace を AlertmanagerConfig ルックアップで選択することを有効または無効にするブールフラグ。UWM Alertmanager インスタンスが有効でない場合にのみ動作します。デフォルト:false

logLevel

string

LogLevel は、Alertmanager のログ レベルを定義します。可能な値は次のとおりです: error、warn、info、debug。デフォルト: info

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

resources

v1.ResourceRequirements

リソースは、単一 Pod のリソースリクエストと制限を定義します。

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

volumeClaimTemplate

monv1.EmbeddedPersistentVolumeClaim

VolumeClaimTemplate は、Alertmanager の永続ストレージを定義します。storageClass とボリュームのサイズを設定することが可能です。

14.4. ClusterMonitoringConfiguration

14.4.1. 説明

ClusterMonitoringConfiguration は、ユーザーが openshift-monitoring namespace の cluster-monitoring-config ConfigMap を介してプラットフォーム監視スタックをカスタマイズできるようにする設定を定義します

プロパティータイプ説明

alertmanagerMain

AlertmanagerMainConfig

AlertmanagerMainConfig は、メインの Alertmanager インスタンスに関連する設定を定義します

enableUserWorkload

bool

ユーザー定義プロジェクトの監視を有効にする UserWorkloadEnabled ブール値フラグです

k8sPrometheusAdapter

K8sPrometheusAdapter

K8sPrometheusAdapter は、prometheus-adapter に関連する設定を定義します

kubeStateMetrics

KubeStateMetricsConfig

KubeStateMetricsConfig は、kube-state-metrics エージェントに関連する設定を定義します

prometheusK8s

PrometheusK8sConfig

PrometheusK8sConfig は、prometheus に関連する設定を定義します

prometheusOperator

PrometheusOperatorConfig

PrometheusOperatorConfig は、prometheus- operator に関連する設定を定義します

openshiftStateMetrics

OpenShiftStateMetricsConfig

OpenShiftMetricsConfig は、openshift-state-metrics エージェントに関連する設定を定義します

thanosQuerier

ThanosQuerierConfig

ThanosQuerierConfig は、Thanos Querier コンポーネントに関連する設定を定義します

14.5. K8sPrometheusAdapter

14.5.1. 説明

K8sPrometheusAdapter は、Prometheus Adapter に関連する設定を定義します

表示場所: ClusterMonitoringConfiguration

プロパティータイプ説明

audit

Audit

Audit は、prometheus アダプター インスタンスによって使用される監査設定を定義します。可能なプロファイル値は次のとおりです: metadata、request、requestresponse、none.デフォルト: metadata

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

14.6. KubeStateMetricsConfig

14.6.1. 説明

KubeStateMetricsConfig は、kube-state-metrics エージェントに関連する設定を定義します。

表示場所: ClusterMonitoringConfiguration

プロパティータイプ説明

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

14.7. OpenShiftStateMetricsConfig

14.7.1. 説明

OpenShiftStateMetricsConfig は、openshift-state-metrics エージェントに関連する設定を保持します。

表示場所: ClusterMonitoringConfiguration

プロパティータイプ説明

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

14.8. PrometheusK8sConfig

14.8.1. 説明

PrometheusK8sConfig は、Prometheus コンポーネントに関連する設定を保持します。

表示場所: ClusterMonitoringConfiguration

プロパティータイプ説明

additionalAlertmanagerConfigs

array(AdditionalAlertmanagerConfig)

AlertmanagerConfigs は、Prometheus コンポーネントが追加の Alertmanager インスタンスと通信する方法に関する設定を保持します。デフォルト: nil

externalLabels

map[string]string

ExternalLabels は、外部システム (federation、remote storage、Alertmanager) と通信するときに、任意の時系列またはアラートに追加されるラベルを定義します。デフォルト: nil

logLevel

string

LogLevel は、Prometheus のログ レベルを定義します。可能な値は次のとおりです: error、warn、info、debug。デフォルト: info

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

queryLogFile

string

QueryLogFile は、PromQL クエリーがログに記録されるファイルを指定します。ファイル名のみをサポートし、その場合、ファイルは /var/log/prometheus の emptyDir ボリュームに保存されます。フルパスが指定されている場合、emptyDir ボリュームはその場所にマウントされます。相対パスはサポートされておらず、Linux std ストリームへの書き込みもサポートされていません。デフォルト: ""

remoteWrite

array(remotewritespec)

RemoteWrite リモート書き込み設定、URL、承認から再ラベル付けまでのすべてを保持します

resources

v1.ResourceRequirements

リソースは、単一 Pod のリソースリクエストと制限を定義します。

retention

string

Retention は、Prometheus がデータを保持する期間を定義します。正規表現 [0-9]+(ms|s|m|h|d|w|y) (ミリ秒秒分時間日週年) と一致する必要があります。デフォルト: 15 日

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

volumeClaimTemplate

monv1.EmbeddedPersistentVolumeClaim

VolumeClaimTemplate は、Prometheus の永続ストレージを定義します。storageClass とボリュームのサイズを設定することが可能です。

14.9. PrometheusOperatorConfig

14.9.1. 説明

PrometheusOperatorConfig は、Prometheus Operator に関連する設定を保持します。

表示場所: ClusterMonitoringConfigurationUserWorkloadConfiguration

プロパティータイプ説明

logLevel

string

LogLevel は、Prometheus Operator のログ レベルを定義します。可能な値は次のとおりです: error、warn、info、debug。デフォルト: info

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

14.10. PrometheusRestrictedConfig

14.10.1. 説明

PrometheusRestrictedConfig は、ユーザー定義のプロジェクトを監視する Prometheus コンポーネントに関連する設定を定義します。

表示場所: UserWorkloadConfiguration

プロパティータイプ説明

additionalAlertmanagerConfigs

array(additionalalertmanagerconfig)

AlertmanagerConfigs は、Prometheus コンポーネントが追加の Alertmanager インスタンスと通信する方法に関する設定を保持します。デフォルト: nil

enforcedSampleLimit

uint64

EnforcedSampleLimit は、受け入れられるスクレイプされたサンプルの数に対するグローバル制限を定義します。これは、ServiceMonitor または/および PodMonitor ごとに設定された SampleLimit をオーバーライドします。これは、管理者が SampleLimit を適用して、サンプル/シリーズの総数を目的の制限未満に保つために使用することを目的としています。SampleLimit が低い場合は、代わりにその値が使用されることに注意してください。デフォルト: 0

enforcedTargetLimit

uint64

EnforcedTargetLimit は、スクレイプされたターゲットの数に対するグローバル制限を定義します。これは、ServiceMonitor または/および PodMonitor ごとに設定された TargetLimit をオーバーライドします。これは、管理者が TargetLimit を適用して、ターゲットの総数を目的の制限未満に保つために使用することを目的としています。TargetLimit が低い場合は、いずれかの値がゼロである場合を除いて、代わりにその値が使用されることに注意してください。ゼロ以外の値が使用されます。両方の値がゼロの場合、制限は適用されません。デフォルト: 0

externalLabels

map[string]string

ExternalLabels は、外部システム (federation、remote storage、Alertmanager) と通信するときに、任意の時系列またはアラートに追加されるラベルを定義します。デフォルト: nil

logLevel

string

LogLevel は、Prometheus のログ レベルを定義します。可能な値は次のとおりです: error、warn、info、debug。デフォルト: info

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

queryLogFile

string

QueryLogFile は、PromQL クエリーがログに記録されるファイルを指定します。ファイル名のみをサポートし、その場合、ファイルは/var/log/prometheus の emptyDir ボリュームに保存されます。フルパスが指定されている場合、emptyDir ボリュームはその場所にマウントされます。相対パスはサポートされておらず、Linux std ストリームへの書き込みもサポートされていません。デフォルト: ""

remoteWrite

array(remotewritespec)

RemoteWrite リモート書き込み設定、URL、承認から再ラベル付けまでのすべてを保持します

resources

v1.ResourceRequirements

リソースは、単一 Pod のリソースリクエストと制限を定義します。

retention

string

Retention は、Prometheus がデータを保持する期間を定義します。正規表現 [0-9]+(ms|s|m|h|d|w|y) (ミリ秒秒分時間日週年) と一致する必要があります。デフォルト: 15 日

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

volumeClaimTemplate

monv1.EmbeddedPersistentVolumeClaim

VolumeClaimTemplate は、Prometheus の永続ストレージを定義します。storageClass とボリュームのサイズを設定することが可能です。

14.11. RemoteWriteSpec

14.11.1. 説明

RemoteWriteSpecmonv1.RemoteWriteSpec のほぼ同一のコピーですが、BearerToken フィールドが削除されています。将来、他のフィールドがここに追加される可能性があります。

14.11.2. 必須

  • url

出現場所: PrometheusK8sConfigPrometheusRestrictedConfig

プロパティータイプ説明

認可

monv1.SafeAuthorization

承認は、リモート書き込みの承認セクションを定義します

basicAuth

monv1.BasicAuth

BasicAuth は、URL の基本認証の設定を定義します。

bearerTokenFile

string

BearerTokenFile は、リモート書き込み用のベアラー トークンが存在するファイルを定義します。

ヘッダー

map[string]string

各リモート書き込み要求とともに送信される Headers カスタム HTTP ヘッダー。Prometheus 自体によって設定されたヘッダーは上書きできないことに注意してください。

metadataConfig

monv1.MetadataConfig

MetadataConfig は、リモートストレージへのシリーズメタデータの送信を設定します。

name

string

Name は、リモート書き込みキューの名前を定義します。指定する場合は一意である必要があります。この名前は、キューを区別するためにメトリックとロギングで使用されます。

oauth2

monv1.OAuth2

OAuth2 は、リモート書き込み用の OAuth2 認証を設定します。

proxyUrl

string

ProxyURL は、オプションのプロキシー URL を定義します

queueConfig

monv1.QueueConfig

QueueConfig を使用すると、リモート書き込みキューパラメーターを調整できます。

remoteTimeout

string

RemoteTimeout は、リモート書き込みエンドポイントへのリクエストのタイムアウトを定義します。

sigv4

monv1.Sigv4

Sigv4 により、AWS の署名検証 4 を設定できます

tlsConfig

monv1.SafeTLSConfig

TLSConfig は、リモート書き込みに使用する TLS 設定を定義します。

url

string

URL は、サンプルを送信するエンドポイントの URL を定義します。

writeRelabelConfigs

array(monv1.RelabelConfig)

WriteRelabelConfigs は、リモート書き込み再ラベル設定のリストを定義します。

14.12. TLSConfig

14.12.1. 説明

TLSConfig は、TLS 接続のオプションを設定します。

14.12.2. 必須

  • insecureSkipVerify

表示場所: AdditionalAlertmanagerConfig

プロパティータイプ説明

ca

v1.SecretKeySelector

CA は、Prometheus コンテナーでターゲットに使用する CA 証明書を定義します。

cert

v1.SecretKeySelector

Cert は、ターゲットに使用する Prometheus コンテナー内のクライアント証明書を定義します。

key

v1.SecretKeySelector

Key は、ターゲットに使用する Prometheus コンテナー内のクライアント キーを定義します。

serverName

string

ターゲットのホスト名を確認するために使用される ServerName。

insecureSkipVerify

bool

InsecureSkipVerify は、ターゲット証明書の検証を無効にします。

14.13. ThanosQuerierConfig

14.13.1. 説明

ThanosQuerierConfig は、Thanos Querier コンポーネントに関連する設定を保持します。

表示場所: ClusterMonitoringConfiguration

プロパティータイプ説明

enableRequestLogging

bool

リクエスト Logging を有効または無効にする EnableRequestLogging ブール値フラグ デフォルト: false

logLevel

string

LogLevel は、Thanos Querier のログ レベルを定義します。可能な値は次のとおりです: error、warn、info、debug。デフォルト: info

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

resources

v1.ResourceRequirements

リソースは、単一 Pod のリソースリクエストと制限を定義します。

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

14.14. ThanosRulerConfig

14.14.1. 説明

ThanosRulerConfig は、ユーザー定義プロジェクトの Thanos Ruler インスタンスの設定を定義します。

表示場所: UserWorkloadConfiguration

プロパティータイプ説明

additionalAlertmanagerConfigs

array(additionalalertmanagerconfig)

AlertmanagerConfigs は、Thanos Ruler コンポーネントが追加の Alertmanager インスタンスと通信する方法に関する設定を保持します。デフォルト: nil

logLevel

string

LogLevel は、Thanos Ruler のログ レベルを定義します。可能な値は次のとおりです: error、warn、info、debug。デフォルト: info

nodeSelector

map[string]string

NodeSelector は、Pod がスケジュールされるノードを定義します。

resources

v1.ResourceRequirements

リソースは、単一 Pod のリソースリクエストと制限を定義します。

retention

string

Retention は、Thanos Ruler がデータを保持する期間を定義します。正規表現 [0-9]+(ms|s|m|h|d|w|y) (ミリ秒秒分時間日週年) と一致する必要があります。デフォルト: 15 日

tolerations

array(v1.Toleration)

Tolerations は Pod の容認を定義します。

volumeClaimTemplate

monv1.EmbeddedPersistentVolumeClaim

VolumeClaimTemplate は、Thanos Ruler の永続ストレージを定義します。storageClass とボリュームのサイズを設定することが可能です。

14.15. UserWorkloadConfiguration

14.15.1. 説明

UserWorkloadConfiguration は、openshift-user-workload-monitoring namespace の user-workload-monitoring-config ConfigMap を介して、ユーザー定義のプロジェクトを担当するモニタリングスタックをユーザーがカスタマイズできるようにする設定を定義します。

プロパティータイプ説明

prometheus

PrometheusRestrictedConfig

Prometheus は、Prometheus コンポーネントの設定を定義します。

prometheusOperator

PrometheusOperatorConfig

PrometheusOperator は、prometheus- operator コンポーネントの設定を定義します。

thanosRuler

ThanosRulerConfig

ThanosRuler は、Thanos Ruler コンポーネントの設定を定義します