手順

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 は自動的に再起動します。

   警告

   変更がモニタリング設定マップに保存されると、関連するプロジェクトの 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. 変更を適用するためにファイルを保存します。新しいコンポーネントの配置設定が自動的に適用されます。

   警告

   変更がモニタリング設定マップに保存されると、関連するプロジェクトの 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>
              <write_relabel_configs> 1

      1

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

      <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 設定マップを編集します。

      $ 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 は予約され、上書きされるため、これらをキー名として使用しないでください。

      注記

      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. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

   警告

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

手順

1. openshift-user-workload-monitoring namespaceで user-workload-monitoring-config 設定マップを編集します。

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

2. data/config.yaml/thanosRuler の下に次の設定の値を追加して、Pod トポロジー分散制約を設定します。

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

   1

   maxSkew の数値を指定します。これは、どの程度まで Pod が不均等に分散されることを許可するか定義します。このフィールドは必須で、値はゼロより大きい必要があります。指定された値は、whenUnsatisfiable に指定した値に応じて異なる効果を持ちます。

   2

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

   3

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

   4

   matchLabels の値を指定します。この値は、制約の適用対象となる一致する Pod のセットを識別するために使用されます。

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

   警告

   変更が user-workload-monitoring-config 設定マップに保存されると、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 は自動的に再起動します。

   警告

   変更がモニタリング設定マップに保存されると、関連するプロジェクトの 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. オプション: 1 つ以上の Name、Firing Alerts、および State 列ヘッダーをクリックしてサイレンスを並べ替えます。

5. Silence Details ページに移動するサイレンスの名前を選択します。このページには、以下の詳細が含まれます。

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

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

4. アラートルールの名前を選択し、Alerting Rule Details ページに移動します。このページには、アラートルールに関する以下の情報が含まれます。

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

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. /federate ルートからメトリクスをクエリーします。以下の例では、メトリクスのクエリー up します。

   $ curl -G -s -k -H "Authorization: Bearer $token" \
       'https://<federation_host>/federate' \ 1
       --data-urlencode 'match[]=up'

   1

   <federation_host> については、フェデレーションルートのホスト URL を置き換えます。

   出力例

   # 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. メトリクス名に対してクエリーを実行し、プロジェクトが正しいことを確認します。

   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,count by (job)({__name__=~".+"}))

3. 予想されるよりも多くの収集サンプルを持つメトリクスに割り当てられたバインドされていないラベル値の数を調査します。

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

4. Prometheus HTTP API を使用して TSDB ステータスを確認するには、dedicated-admin として次のコマンドを実行します。

   $ oc login -u <username> -p <password>

   $ host=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})

   $ token=$(oc whoami -t)

   $ curl -H "Authorization: Bearer $token" -k "https://$host/api/v1/status/tsdb"

   出力例

   "status": "success",