Monitoring

手順

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

   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 リソース要求を定義します。

2. ファイルを保存して、変更を ConfigMap オブジェクトに適用します。

   警告

   ConfigMap オブジェクトの設定変更によって、結果も異なります。

   • Pod は再デプロイされません。したがって、サービスの停止はありません。

   • 変更された Pod が再デプロイされます。

     • 単一ノードクラスターの場合、一時的なサービスが停止します。
     • マルチノードクラスターの場合、高可用性であるため、影響を受ける Pod は徐々にロールアウトされ、モニタリングスタックは引き続き利用可能です。
     • 永続ボリュームの設定およびサイズ変更を行うと、高可用性であるかどうかに関係なく、常にサービスが停止します。

   config map の変更を必要とする手順にはそれぞれ、想定される結果が含まれます。

手順

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

   $ 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 で、値が value1 の node1 に taint を追加します。これにより、モニタリングコンポーネントが node1 に Pod をデプロイするのを防ぎます。ただし、その taint に対して toleration が設定されている場合を除きます。以下の例では、サンプルの taint を容認するように 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"

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

手順

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

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 以下の例のように、data/config.yaml/prometheus の下に remoteWrite: セクションを追加します。

   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.example.com" 1
           <endpoint_authentication_credentials> 2

   1

   リモート書き込みエンドポイントの URL。

   2

   エンドポイントの認証方法およびクレデンシャル。現在サポートされている認証方法は、AWS 署名バージョン 4、Authorization リクエストヘッダーでの HTTP を使用した認証、基本認証、OAuth 2.0、および TLS クライアントです。サポートされている認証方法のサンプル設定は、サポートされているリモート書き込み認証設定 を参照してください。

3. 認証クレデンシャルの後に、書き込みの再ラベル設定値を追加します。

   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.example.com"
           <endpoint_authentication_credentials>
           writeRelabelConfigs:
           - <your_write_relabel_configs> 1

   1

   リモートエンドポイントに送信するメトリクスの設定を追加します。

   my_metric という単一メトリクスを転送する例

   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.example.com"
           writeRelabelConfigs:
           - sourceLabels: [__name__]
             regex: 'my_metric'
             action: keep

   my_namespace namespace に my_metric_1 および my_metric_2 というメトリクスを転送する例

   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.example.com"
           writeRelabelConfigs:
           - sourceLabels: [__name__,namespace]
             regex: '(my_metric_1|my_metric_2);my_namespace'
             action: keep

4. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

手順

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

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml/<component> 下に、設定の詳細を含む additionalAlertmanagerConfigs セクションを追加します。

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

   2

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

   1

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

   次のサンプル config map は、クライアント 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

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

手順

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

   $ 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 は予約され、上書きされるため、これらをキー名として使用しないでください。
   • キー名に cluster または managed_cluster を使用しないでください。これらを使用すると、開発者ダッシュボードでデータが表示されなくなる問題が発生する可能性があります。
   注記

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

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

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         externalLabels:
           region: eu
           environment: prod

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

手順

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

   $ 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

   ログレベルを設定するモニタリングスタックコンポーネント。使用できるコンポーネントの値は、prometheus、alertmanager、prometheusOperator、および thanosRuler です。

   2

   コンポーネントに設定するログレベル。使用可能な値は、error、warn、info、および debug です。デフォルト値は info です。

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

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

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

   出力例

           - --log-level=debug

5. コンポーネントの Pod が実行中であることを確認します。次の例では、Pod のステータスをリスト表示します。

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

   注記

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

手順

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

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. Prometheus の queryLogFile パラメーターを data/config.yaml の下に追加します。

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

   1

   クエリーが記録されるファイルへの完全なパスを追加します。

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

4. コンポーネントの Pod が実行中であることを確認します。次のコマンド例は、Pod のステータスを表示します。

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

   出力例

   ...
   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
   ...

5. クエリーログを読みます。

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

   重要

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

手順

1. OpenShift Cluster Manager Hybrid Cloud Console からクラスターを選択します。
2. Settings タブをクリックします。

3. Enable user workload monitoring チェックボックスをクリックしてオプションの選択を解除し、Save をクリックします。

   ユーザーのワークロードモニタリングは無効になっています。Prometheus、Prometheus Operator、および Thanos Ruler コンポーネントは、openshift-user-workload-monitoring プロジェクトで停止されます。

手順

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

   $ oc label namespace my-project 'openshift.io/user-monitoring=false'

2. モニタリングを再度有効にするには、namespace からラベルを削除します。

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

   注記

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

手順

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

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml の下にある alertmanager セクションに enabled: true および enableAlertmanagerConfig: true を追加します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       alertmanager:
         enabled: true 1
         enableAlertmanagerConfig: true 2

   1

   enabled の値を true に設定して、クラスター内のユーザー定義プロジェクトの Alertmanager の専用インスタンスを有効にします。値を false に設定するか、キーを完全に省略してユーザー定義プロジェクトの Alertmanager を無効にします。この値を false に設定した場合や、キーを省略すると、ユーザー定義のアラートはデフォルトのプラットフォーム Alertmanager インスタンスにルーティングされます。

   2

   enableAlertmanagerConfig 値を true に設定して、ユーザーが AlertmanagerConfig オブジェクトで独自のアラートルーティング設定を定義できるようにします。

3. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトの Alertmanager の専用インスタンスが自動的に起動します。

手順

1. OpenShift Dedicated Web コンソールの Administrator パースペクティブで、Observe をクリックし、Metrics タブに移動します。

2. 1 つ以上のクエリーを追加するために、次のいずれかの操作を実行します。

   オプション	説明
   既存のクエリーを選択する	Select query ドロップダウンリストから、既存のクエリーを選択します。
   カスタムクエリーを作成する	Prometheus Query Language (PromQL) クエリーを Expression フィールドに追加します。 PromQL 式を入力すると、オートコンプリートの提案がドロップダウンリストに表示されます。これらの提案には、関数、メトリクス、ラベル、および時間トークンが含まれます。キーボードの矢印を使用して、提案された項目の中から 1 つを選択し、Enter キーを押して、その項目を式に追加します。提案された項目の上にマウスポインターを移動すると、その項目の簡単な説明が表示されます。
   複数のクエリーを追加する	Add query をクリックします。
   既存のクエリーを複製する	クエリーの横にあるオプションメニュー をクリックし、Duplicate query を選択します。
   クエリーの実行を無効する	クエリーの横にあるオプションメニュー をクリックし、Disable query を選択します。

3. 作成したクエリーを実行するために、Run queries をクリックします。クエリーからのメトリクスはプロットで可視化されます。クエリーが無効な場合は、UI にエラーメッセージが表示されます。

   注記
   • 時系列グラフを描画する場合、大量のデータを操作するクエリーにより、タイムアウトが発生したり、ブラウザーに過負荷がかかったりする可能性があります。これを回避するには、Hide graph をクリックし、メトリクステーブルのみを使用してクエリーを調整してください。次に、使用できるクエリーを確認した後に、グラフを描画できるようにプロットを有効にします。
   • デフォルトでは、クエリーテーブルに、すべてのメトリクスとその現在の値をリスト表示する拡張ビューが表示されます。クエリーの拡張ビューを最小化するには、下矢印 (˅) をクリックします。
4. オプション: このクエリーのセットを今後再度使用するには、ページの URL を保存します。

5. 視覚化されたメトリクスを調べます。最初に、有効な全クエリーの全メトリクスがプロットに表示されます。次のいずれかの操作を実行して、表示するメトリクスを選択します。

   オプション	説明
   クエリーのすべてのメトリクスを非表示にする	クエリーのオプションメニュー をクリックし、Hide all series をクリックします。
   特定のメトリクスを非表示にする	クエリーテーブルに移動し、メトリクス名の近くにある色付きの四角形をクリックします。
   プロットを拡大し、時間範囲を変更する	次のいずれかの操作を実行します。 プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。 メニューを使用して時間範囲を選択します。
   時間範囲をリセットする	Reset zoom をクリックします。
   特定の時点におけるすべてのクエリーの出力を表示する	プロット上の目的のポイントにマウスを移動します。クエリーの出力がポップアップボックスに表示されます。
   プロットを非表示にする	Hide graph をクリックします。

手順

1. OpenShift Dedicated Web コンソールの Developer パースペクティブで、Observe をクリックし、Metrics タブに移動します。
2. Project: リストから、メトリクスを表示するプロジェクトを選択します。

3. 1 つ以上のクエリーを追加するために、次のいずれかの操作を実行します。

   オプション	説明
   既存のクエリーを選択する	Select query ドロップダウンリストから、既存のクエリーを選択します。
   カスタムクエリーを作成する	Prometheus Query Language (PromQL) クエリーを Expression フィールドに追加します。 PromQL 式を入力すると、オートコンプリートの提案がドロップダウンリストに表示されます。これらの提案には、関数、メトリクス、ラベル、および時間トークンが含まれます。キーボードの矢印を使用して、提案された項目の中から 1 つを選択し、Enter キーを押して、その項目を式に追加します。提案された項目の上にマウスポインターを移動すると、その項目の簡単な説明が表示されます。
   複数のクエリーを追加する	Add query をクリックします。
   既存のクエリーを複製する	クエリーの横にあるオプションメニュー をクリックし、Duplicate query を選択します。
   クエリーの実行を無効する	クエリーの横にあるオプションメニュー をクリックし、Disable query を選択します。

4. 作成したクエリーを実行するために、Run queries をクリックします。クエリーからのメトリクスはプロットで可視化されます。クエリーが無効な場合は、UI にエラーメッセージが表示されます。

   注記
   • 時系列グラフを描画する場合、大量のデータを操作するクエリーにより、タイムアウトが発生したり、ブラウザーに過負荷がかかったりする可能性があります。これを回避するには、Hide graph をクリックし、メトリクステーブルのみを使用してクエリーを調整してください。次に、使用できるクエリーを確認した後に、グラフを描画できるようにプロットを有効にします。
   • デフォルトでは、クエリーテーブルに、すべてのメトリクスとその現在の値をリスト表示する拡張ビューが表示されます。クエリーの拡張ビューを最小化するには、下矢印 (˅) をクリックします。
5. オプション: このクエリーのセットを今後再度使用するには、ページの URL を保存します。

6. 視覚化されたメトリクスを調べます。最初に、有効な全クエリーの全メトリクスがプロットに表示されます。次のいずれかの操作を実行して、表示するメトリクスを選択します。

   オプション	説明
   クエリーのすべてのメトリクスを非表示にする	クエリーのオプションメニュー をクリックし、Hide all series をクリックします。
   特定のメトリクスを非表示にする	クエリーテーブルに移動し、メトリクス名の近くにある色付きの四角形をクリックします。
   プロットを拡大し、時間範囲を変更する	次のいずれかの操作を実行します。 プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。 メニューを使用して時間範囲を選択します。
   時間範囲をリセットする	Reset zoom をクリックします。
   特定の時点におけるすべてのクエリーの出力を表示する	プロット上の目的のポイントにマウスを移動します。クエリーの出力がポップアップボックスに表示されます。
   プロットを非表示にする	Hide graph をクリックします。

手順

1. OpenShift Dedicated Web コンソールの Administrator パースペクティブで、Observe → Targets に移動します。Metrics targets ページが開き、メトリクス用にスクレイピングされているすべてのサービスエンドポイントターゲットのリストが表示されます。

   このページには、デフォルトの OpenShift Dedicated プロジェクトとユーザー定義プロジェクトのターゲットの詳細が表示されます。このページには、ターゲットごとに以下の情報がリスト表示されます。

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

2. オプション: 特定のターゲットを検索するには、次のいずれかのアクションを実行します。

   オプション	説明
   ステータスとソースによってターゲットをフィルタリングします。	Filter リストでフィルターを選択します。 以下のフィルタリングオプションが利用できます。 ステータス フィルター: Up.ターゲットは現在 up で、メトリクスに対してアクティブにスクレイピングされています。 Down.ターゲットは現在 down しており、メトリクス用にスクレイピングされていません。 Source フィルター: Platform。プラットフォームレベルのターゲットは、デフォルトの Red Hat OpenShift Service on AWS プロジェクトにのみ該当します。これらのプロジェクトは、Red Hat OpenShift Service on AWS のコア機能を提供します。 User。ユーザーターゲットは、ユーザー定義プロジェクトに関連します。これらのプロジェクトはユーザーが作成したもので、カスタマイズすることができます。
   名前またはラベルでターゲットを検索します。	検索ボックスの横にある Text または Label フィールドに検索語を入力します。
   ターゲットを並べ替えます。	Endpoint Status、Namespace、Last Scrape、および Scrape Duration 列ヘッダーの 1 つ以上をクリックします。

3. ターゲットの Endpoint 列の URL をクリックすると、その Target details ページに移動します。このページには、ターゲットに関する以下の情報が表示されます。

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

1. OpenShift Dedicated Web コンソールの Administrator パースペクティブから、Observe → Alerting → Alerts ページに移動します。
2. オプション: 検索リストで Name フィールドを使用し、アラートを名前で検索します。
3. オプション: Filter リストでフィルターを選択し、アラートを状態、重大度およびソースでフィルターします。
4. オプション: 1 つ以上の Name、Severity、State、および Source 列ヘッダーをクリックし、アラートを並べ替えます。

5. アラートの名前をクリックして、Alert details ページを表示します。このページには、アラートの時系列データを示すグラフが含まれます。アラートに関する次の情報も提供されます。

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

1. OpenShift Dedicated Web コンソールの Administrator パースペクティブから、Observe → Alerting → Silences ページに移動します。
2. オプション: Search by name フィールドを使用し、サイレンスを名前でフィルターします。
3. オプション: Filter リストでフィルターを選択し、サイレンスをフィルターします。デフォルトでは、Active および Pending フィルターが適用されます。
4. オプション: Name、Firing alerts、State、Creator 列のヘッダーを 1 つ以上クリックして、サイレンスを並べ替えます。

5. サイレンスの名前を選択すると、その Silence details ページが表示されます。このページには、以下の詳細が含まれます。

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

1. OpenShift Dedicated Web コンソールの Administrator パースペクティブから、Observe → Alerting → Alerting rules ページに移動します。
2. オプション: Filter 一覧でフィルターを選択し、アラートルールを状態、重大度およびソースでフィルターします。
3. オプション: Name、Severity、Alert State、Source 列のヘッダーを 1 つ以上クリックし、アラートルールを並べ替えます。

4. アラートルールの名前を選択して、その Alerting rule details ページを表示します。このページには、アラートルールに関する以下の情報が含まれます。

   • アラートルール名、重大度、説明
   • アラートを発動する条件を定義する式
   • 条件が true で持続してアラートが発生するまでの期間
   • アラートルールで管理される各アラートのグラフ。アラートが発動される値が表示されます。
   • アラートルールで管理されるすべてのアラートを示す表。

1. OpenShift Dedicated Web コンソールの Developer パースペクティブから、Observe → <project_name> → Alerts ページに移動します。

2. アラート、サイレンス、またはアラートルールの詳細を表示します。

   • Alert details を表示するには、アラート名の横にある大なり記号 (>) をクリックし、リストからアラートを選択します。

   • Silence details を表示するには、Alert details ページの Silenced by セクションでサイレンスを選択します。Silence details ページには、以下の情報が含まれます。

     • アラート仕様
     • 開始時間
     • 終了時間
     • サイレンス状態
     • 発生するアラートの数およびリスト
   • Alerting rule details を表示するには、Alerts ページのアラートの横にある メニューをクリックし、次に View Alerting Rule をクリックします。

手順

1. OpenShift Dedicated Web コンソールの Administrator パースペクティブで、Observe → Dashboards に移動します。
2. Dashboard 一覧でダッシュボードを選択します。etcd や Prometheus ダッシュボードなどの一部のダッシュボードは、選択時に追加のサブメニューを生成します。

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

   • 事前定義済みの期間を選択します。

   • Time Range リストで Custom time range をクリックして、カスタムの時間範囲を設定します。

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

手順

1. OpenShift Dedicated Web コンソールの Developer パースペクティブで、Observe をクリックし、Dashboards タブに移動します。
2. Project: ドロップダウンリストからプロジェクトを選択します。

3. Dashboard ドロップダウンリストからダッシュボードを選択し、フィルターされたメトリクスを表示します。

   注記

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

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

   • 事前定義済みの期間を選択します。

   • Time Range リストで Custom time range をクリックして、カスタムの時間範囲を設定します。

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

手順

1. 次のコマンドを実行して認証トークンを抽出します。

   $ TOKEN=$(oc whoami -t)

2. 次のコマンドを実行して、alertmanager-main API ルート URL を抽出します。

   $ HOST=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath='{.status.ingress[].host}')

3. 次のコマンドを実行して、サービス API レシーバーに Alertmanager をクエリーを実行します。

   $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v2/receivers"

手順

1. 次のコマンドを実行してベアラートークンを取得します。

   $ TOKEN=$(oc whoami -t)

2. 次のコマンドを実行して、Prometheus フェデレーションルート URL を取得します。

   $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath='{.status.ingress[].host}')

3. /federate ルートからメトリクスをクエリーを実行します。次のコマンド例は、up メトリクスをクエリーを実行します。

   $ curl -G -k -H "Authorization: Bearer $TOKEN" https://$HOST/federate --data-urlencode 'match[]=up'

   出力例

   # TYPE up untyped
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.143.148:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035322214
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.148.166:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035338597
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.173.16:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035343834
   ...

手順

1. 次のコマンドを実行して、Prometheus に接続するための認証トークンを展開します。

   $ TOKEN=$(oc whoami -t)

2. 次のコマンドを実行して、thanos-querier API ルート URL を展開します。

   $ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath='{.status.ingress[].host}')

3. 次のコマンドを使用して、サービスが実行されている namespace に namespace を設定します。

   $ NAMESPACE=ns1

4. 次のコマンドを実行して、コマンドラインで独自のサービスのメトリクスに対してクエリーを実行します。

   $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}"

   出力には、Prometheus がスクレイピングしている各アプリケーション 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"
           ]
         }
       ],
     }
   }

   注記
   • フォーマット済み出力例では、jq などのフィルタリングツールを使用して、フォーマット済みのインデントされた JSON を出力しています。jq の使用に関する詳細は、jq Manual (jq ドキュメント) を参照してください。
   • このコマンドは、ある時点でセレクターを評価する Thanos Querier サービスのインスタントクエリーエンドポイントを要求します。

手順

1. メトリクス名に対してクエリーを実行し、プロジェクトが正しいことを確認します。

   1. Web コンソールの Developer パースペクティブで、Observe をクリックし、Metrics タブに移動します。
   2. Project: 一覧でメトリクスで表示するプロジェクトを選択します。

   3. Select query リストから既存のクエリーを選択するか、Expression フィールドに PromQL クエリーを追加してカスタムクエリーを実行します。

      メトリクスはグラフに表示されます。

      クエリーはプロジェクトごとに実行される必要があります。表示されるメトリクスは、選択したプロジェクトに関連するメトリクスです。

2. メトリクスが必要な Pod がアクティブにメトリクスを提供していることを確認します。以下の oc exec コマンドを Pod で実行し、podIP、port、および /metrics をターゲットにします。

   $ oc exec <sample_pod> -n <sample_namespace> -- curl <target_pod_IP>:<port>/metrics

   注記

   curl がインストールされている Pod でコマンドを実行する必要があります。

   以下の出力例は、有効なバージョンのメトリクスを含む結果を示しています。

   出力例

     % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                    Dload  Upload   Total   Spent    Left  Speed
   # HELP version Version information about this binary-- --:--:-- --:--:--     0
   # TYPE version gauge
   version{version="v0.1.0"} 1
   100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:-- 51000

   無効な出力は、対応するアプリケーションに問題があることを示しています。

3. PodMonitor CRD を使用している場合は、PodMonitor CRD がラベル一致を使用して適切な Pod を参照するよう設定されていることを確認します。詳細は、Prometheus Operator のドキュメントを参照してください。

4. ServiceMonitor CRD を使用し、Pod の /metrics エンドポイントがメトリクスデータを表示している場合は、以下の手順を実行して設定を確認します。

   1. サービスが正しい /metrics エンドポイントを参照していることを確認します。この出力のサービス labels は、後続の手順でサービスが定義するサービスモニターの labels と /metrics エンドポイントと一致する必要があります。

      $ oc get service

      出力例

      apiVersion: v1
      kind: Service 1
      metadata:
        labels: 2
          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

      1

      これがサービス API であることを指定します。

      2

      このサービスに使用されるラベルを指定します。

   2. serviceIP、port、および /metrics エンドポイントを取得し、以前に Pod で実行した curl コマンドと同じメトリクスがあるかどうかを確認します。

      1. 以下のコマンドを実行してサービス IP を見つけます。

         $ oc get service -n <target_namespace>

      2. /metrics エンドポイントを取得します。

         $ oc exec <sample_pod> -n <sample_namespace> -- curl <service_IP>:<port>/metrics

         以下の例では、有効なメトリクスが返されます。

         出力例

         % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                        Dload  Upload   Total   Spent    Left  Speed
         100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:--   99k
         # HELP version Version information about this binary
         # TYPE version gauge
         version{version="v0.1.0"} 1

   3. ラベルのマッチングを使用して、ServiceMonitor オブジェクトが必要なサービスを参照するように設定されていることを確認します。これを実行するには、oc get service 出力の Service オブジェクトを oc get servicemonitor 出力の ServiceMonitor オブジェクトと比較します。メトリクスを表示するには、ラベルが一致している必要があります。

      たとえば、直前の手順の Service オブジェクトに app: prometheus-example-app ラベルがあり、ServiceMonitor オブジェクトに同じ app: prometheus-example-app 一致ラベルがある点に注意してください。

5. すべて有効になっていても、メトリクスが利用できない場合は、サポートチームにお問い合わせください。

手順

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

2. Expression フィールドに、Prometheus Query Language (PromQL) クエリーを入力します。次のクエリー例は、ディスク領域の消費量の増加につながる可能性のある高カーディナリティメトリクスを識別するのに役立ちます。

   • 次のクエリーを実行すると、スクレイプサンプルの数が最も多いジョブを 10 個特定できます。

     topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))

   • 次のクエリーを実行すると、過去 1 時間に最も多くの時系列データを作成したジョブを 10 個特定して、時系列のチャーンを正確に特定できます。

     topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))

3. 想定よりもサンプルのスクレイプ数が多いメトリクスに割り当てられたラベルで、値が割り当てられていないものの数を確認します。

   • メトリクスがユーザー定義のプロジェクトに関連する場合、ワークロードに割り当てられたメトリクスのキーと値のペアを確認します。これらのライブラリーは、アプリケーションレベルで Prometheus クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
   • メトリクスがコア OpenShift Dedicated プロジェクトに関連している場合 は、Red Hat Customer Portal で Red Hat サポートケースを作成します。

4. 以下の手順に従い、dedicated-admin としてログインし、Prometheus HTTP API を使用して TSDB ステータスを確認します。

   1. 次のコマンドを実行して、Prometheus API ルート URL を取得します。

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath='{.status.ingress[].host}')

   2. 次のコマンドを実行して認証トークンを抽出します。

      $ TOKEN=$(oc whoami -t)

   3. 次のコマンドを実行して、Prometheus の TSDB ステータスのクエリーを実行します。

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"

      出力例

      "status": "success","data":{"headStats":{"numSeries":507473,
      "numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
      "maxTime":1712257935346},"seriesCountByMetricName":
      [{"name":"etcd_request_duration_seconds_bucket","value":51840},
      {"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
      ...

手順

1. 次のコマンドを実行して、すべての TSDB ブロックのサイズを古いものから新しいものの順にリスト表示します。

   $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
   -c prometheus --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
   -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
   -- sh -c 'cd /prometheus/;du -hs $(ls -dtr */ | grep -Eo "[0-9|A-Z]{26}")'

   1 2

   <prometheus_k8s_pod_name> は、KubePersistentVolumeFillingUp アラートの説明に記載されている Pod に置き換えます。

   出力例

   308M    01HVKMPKQWZYWS8WVDAYQHNMW6
   52M     01HVK64DTDA81799TBR9QDECEZ
   102M    01HVK64DS7TRZRWF2756KHST5X
   140M    01HVJS59K11FBVAPVY57K88Z11
   90M     01HVH2A5Z58SKT810EM6B9AT50
   152M    01HV8ZDVQMX41MKCN84S32RRZ1
   354M    01HV6Q2N26BK63G4RYTST71FBF
   156M    01HV664H9J9Z1FTZD73RD1563E
   216M    01HTHXB60A7F239HN7S2TENPNS
   104M    01HTHMGRXGS0WXA3WATRXHR36B

2. 削除できるブロックとその数を特定し、ブロックを削除します。次のコマンド例は、prometheus-k8s-0 Pod から最も古い 3 つの Prometheus TSDB ブロックを削除します。

   $ oc debug prometheus-k8s-0 -n openshift-monitoring \
   -c prometheus --image=$(oc get po -n openshift-monitoring prometheus-k8s-0 \
   -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
   -- sh -c 'ls -latr /prometheus/ | egrep -o "[0-9|A-Z]{26}" | head -3 | \
   while read BLOCK; do rm -r /prometheus/$BLOCK; done'

3. 次のコマンドを実行して、マウントされた PV の使用状況を確認し、十分な空き容量があることを確認します。

   $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
   --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
   -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') -- df -h /prometheus/

   1 2

   <prometheus_k8s_pod_name> は、KubePersistentVolumeFillingUp アラートの説明に記載されている Pod に置き換えます。

   次の出力例は、prometheus-k8s-0 Pod によって要求されるマウントされた PV に、63% の空き容量が残っていることを示しています。

   出力例

   Starting pod/prometheus-k8s-0-debug-j82w4 ...
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme0n1p4  40G   15G  40G  37% /prometheus
   
   Removing debug pod ...