モニタリング

手順

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

3. ユーザーワークロード監視を有効にする チェックボックスをクリックして選択を解除し、保存 をクリックします。

   ユーザーのワークロードモニタリングは無効になっています。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. 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. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける 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:
         retention: <time_specification> 

   1

   
         retentionSize: <size_specification> 

   2

   1

   保持時間: ms (ミリ秒)、s (秒)、m (分)、h (時)、d (日)、w (週)、y (年) が直接続く数値。1h30m15s などの特定の時間に時間値を組み合わせることもできます。

   2

   保持サイズ: B (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)、TB (テラバイト)、PB (ペタバイト)、および EB (エクサバイト) が直接続く数値。

   次の例では、Prometheus インスタンスの保持時間を 24 時間、保持サイズを 10 ギガバイトに設定します。

   Prometheus の保持期間を設定する例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         retention: 24h
         retentionSize: 10GB

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: |
       <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 が実行中であることを確認します。

   $ 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-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/prometheus/remoteWrite の下にある writeRelabelConfigs: セクションで、クラスター ID の再ラベル付け設定値を追加します。

   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: 

   1

   
             - <relabel_config> 

   2

   1

   リモートエンドポイントに送信するメトリクスの書き込み再ラベル付け設定のリストを追加します。

   2 2

   リモート書き込みエンドポイントに送信されるメトリクスのラベル設定を置き換えます。

   次のサンプルは、クラスター ID ラベル cluster_id を使用してメトリクスを転送する方法を示しています。

   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:
             - __tmp_openshift_cluster_id__ 

   1

   
             targetLabel: cluster_id 

   2

   
             action: replace 

   3

   3

   システムは最初に __tmp_openshift_cluster_id__ という名前の一時的なクラスター ID ソースラベルを適用します。この一時的なラベルは、指定するクラスター ID ラベル名に置き換えられます。

   リモート書き込みストレージに送信されるメトリクスのクラスター ID ラベルの名前を指定します。メトリクスにすでに存在するラベル名を使用する場合、その値はこのクラスター ID ラベルの名前で上書きされます。ラベル名には __tmp_openshift_cluster_id__ は使用しないでください。最後の再ラベル手順では、この名前を使用するラベルを削除します。

   replace 置き換えラベルの再設定アクションは、一時ラベルを送信メトリクスのターゲットラベルに置き換えます。このアクションはデフォルトであり、アクションが指定されていない場合に適用されます。

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

手順

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 を使用しないでください。これを使用すると、開発者ダッシュボードでデータが表示されない問題が発生する可能性があります。

   注記

   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 Dedicated Web コンソールで、Observe → Metrics をクリックします。

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

   Expand

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

   Show more

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

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

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

   Expand

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

   Show more

手順

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

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

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

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

   Expand

   オプション	説明
   ステータスとソースによってターゲットをフィルタリングします。	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 つ以上をクリックします。

   Show more

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

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

手順

1. OpenShift Dedicated Web コンソールで、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 コンソールで、Observe → Metrics をクリックします。

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

   Expand

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

   Show more

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

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

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

   Expand

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

   Show more

手順

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

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 サービスのインスタントクエリーエンドポイントを要求します。