手順

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 オブジェクトに適用します。新規設定の影響を受ける Pod は自動的に再起動します。

   警告

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

手順

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. コンポーネントの 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 にテイントを追加します。これにより、モニタリングコンポーネントが 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. 変更を適用するためにファイルを保存します。新しいコンポーネントの配置設定が自動的に適用されます。

   警告

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

手順

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/prometheus に remoteWrite: セクションを追加します。

   3. このセクションにエンドポイント URL および認証情報を追加します。

      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 Signature Version 4、HTTP an Authorization リクエストヘッダーを用いた認証、Basic 認証、OAuth 2.0、TLS client です。サポートされる認証方法の設定例は、以下のサポート対象のリモート書き込み認証設定を参照してください。

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

      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>
              <your_write_relabel_configs> 1

      1

      書き込みの再ラベル設定。

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

      以下の例では、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

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

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

   警告

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

手順

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

   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/alertmanager/secrets の下に Secrets: セクションを次の設定で追加します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          alertmanager:
            secrets: 1
            - <secret_name_1> 2
            - <secret_name_2>

      1

      このセクションには、Alertmanager にマウントされるシークレットが含まれています。シークレットは、Alertmanager オブジェクトと同じ namespace 内に配置する必要があります。

      2

      受信者の認証認証情報を含む Secret オブジェクトの名前。複数のシークレットを追加する場合は、それぞれを新しい行に配置します。

      次の config map 設定の例では、test-secret および test-secret-api-token という名前の 2 つの Secret オブジェクトを使用するように Alertmanager を設定します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          alertmanager:
            enabled: true
            secrets:
            - test-secret
            - test-api-receiver-token

2. ファイルを保存して、変更を ConfigMap オブジェクトに適用します。新しい設定は自動的に適用されます。

手順

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 の下にすべてのメトリクスについて追加する必要のあるラベルのマップを定義します。

      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

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

   警告

   変更がモニタリング config map に保存されると、関連するプロジェクトの 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. Pod トポロジーの分散制約を設定するには、data/config.yaml フィールドの下に次の設定を追加します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       <component>: 1
         topologySpreadConstraints:
         - maxSkew: <n> 2
           topologyKey: <key> 3
           whenUnsatisfiable: <value> 4
           labelSelector: 5
             <match_option>

   1

   Pod トポロジーの分散制約を設定するコンポーネントの名前を指定します。

   2

   maxSkew の数値を指定します。これは、どの程度まで Pod が不均等に分散されることを許可するか定義します。

   3

   topologyKey にノードラベルのキーを指定します。このキーと同じ値のラベルを持つノードは、同じトポロジーにあると見なされます。スケジューラーは、各ドメインにバランスの取れた数の Pod を配置しようとします。

   4

   whenUnsatisfiable の値を指定します。利用可能なオプションは DoNotSchedule と ScheduleAnyway です。maxSkew 値で、ターゲットトポロジー内の一致する Pod の数とグローバル最小値との間で許容される最大差を定義する場合は、DoNotSchedule を指定します。スケジューラーが引き続き Pod をスケジュールするが、スキューを減らす可能性のあるノードにより高い優先度を与える場合は、ScheduleAnyway を指定します。

   5

   一致する Pod を見つけるには、labelSelector を指定します。このラベルセレクターに一致する Pod は、対応するトポロジードメイン内の Pod の数を決定するためにカウントされます。

   Thanos Ruler の設定例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: monitoring
           whenUnsatisfiable: ScheduleAnyway
           labelSelector:
             matchLabels:
               app.kubernetes.io/name: thanos-ruler

3. ファイルを保存して、変更を自動的に適用します。

   警告

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

手順

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. コンポーネントの 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

      ログレベルを設定するモニタリングスタックコンポーネント。ユーザーワークロードのモニタリングの場合、使用可能なコンポーネントの値は、alertmanager、prometheus、prometheusOperator、および thanosRuler です。

      2

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

2. 変更を適用するためにファイルを保存します。ログレベルの変更を適用する際に、コンポーネントの Pod は自動的に再起動します。

   警告

   変更がモニタリング config map に保存されると、関連するプロジェクトの 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 が正常に再起動しない可能性があります。

手順

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 の下の prometheus の queryLogFile: <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. 変更を適用するためにファイルを保存します。

   警告

   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 の設定を元に戻します。

手順

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. Administrator パースペクティブで、Observe → Targets を選択します。Metrics targets ページが開き、メトリクス用にスクレイピングされているすべてのサービスエンドポイントターゲットのリストが表示されます。

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

   • スクレイピングされるサービスエンドポイント 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. Red Hat OpenShift Service on AWS Web コンソールを開き、Observe → Alerting → Alerts ページに移動します。
2. オプション: 検索リストで Name フィールドを使用し、アラートを名前で検索します。
3. オプション: Filter リストでフィルターを選択し、アラートを状態、重大度およびソースでフィルターします。
4. オプション: 1 つ以上の Name、Severity、State、および Source 列ヘッダーをクリックし、アラートを並べ替えます。

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

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

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

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

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

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

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

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

1. Observe → <project_name> → Alerts ページに移動します。

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

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

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

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

手順

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

   $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. alertmanager.yaml で設定を編集します。

   route:
     receiver: Default
     group_by:
     - name: Default
     routes:
     - matchers:
       - "service = prometheus-example-monitor" 1
       receiver: <receiver> 2
   receivers:
   - name: Default
   - name: <receiver>
   #  <receiver_configuration>

   1

   ルートに一致するアラートを指定します。この例では、service="prometheus-example-monitor" ラベルの付いたすべてのアラートを示しています。

   2

   アラートグループに使用するレシーバーを指定します。

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

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

手順

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

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

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

   • 時間範囲 リストで カスタムの時間範囲 を選択して、カスタムの時間範囲を設定します。

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

手順

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

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

   注記

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

4. 必要に応じて、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={.spec.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={.spec.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={.spec.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"]}]}}

手順

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

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

   3. Select query 一覧からクエリーを選択するか、Show PromQL を選択してカスタム 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 クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
   • メトリクスがコアの Red Hat OpenShift Service on AWS プロジェクトに関連している場合は、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={.spec.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 -dt */ | 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 ...