Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

4.4. ユーザーワークロードモニタリングのメトリクスの設定

メトリクスのコレクションを設定して、クラスターコンポーネントおよび独自のワークロードの実行方法を監視します。

長期ストレージのために、取り込んだメトリックをリモートシステムに送信し、クラスター ID ラベルをメトリクスに追加して、異なるクラスターから送られるデータを特定できます。

関連情報

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

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
  • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
  • OpenShift CLI (oc) がインストールされている。

  • リモート書き込み互換性のあるエンドポイント (Thanos) を設定し、エンドポイント URL を把握している。リモート書き込み機能と互換性のないエンドポイントの情報ては、Prometheus リモートエンドポイントおよびストレージに関するドキュメント を参照してください。

    重要

    Red Hat は、リモート書き込み送信側の設定に関する情報のみを提供し、受信側エンドポイントの設定に関するガイダンスは提供しません。お客様は、リモート書き込みと互換性のある独自のエンドポイントを設定する責任があります。エンドポイントレシーバー設定に関する問題は、Red Hat 製品サポートには含まれません。

  • リモート書き込みエンドポイントの Secret オブジェクトに認証クレデンシャルを設定している。シークレットは openshift-user-workload-monitoring namespace に作成する必要があります。

    警告

    セキュリティーリスクを軽減するには、HTTPS および認証を使用してメトリクスをエンドポイントに送信します。

手順

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

4.4.1.1. サポート対象のリモート書き込み認証設定

異なる方法を使用して、リモート書き込みエンドポイントとの認証を行うことができます。現時点でサポートされている認証方法は AWS 署名バージョン 4、Basic 認証、認可、OAuth 2.0、および TLS クライアントです。以下の表は、リモート書き込みで使用するサポート対象の認証方法の詳細を示しています。

認証方法config map フィールド説明

AWS 署名バージョン 4

sigv4

この方法では、AWS Signature Version 4 認証を使用して要求を署名します。この方法は、認可、OAuth 2.0、または Basic 認証と同時に使用することはできません。

Basic 認証

basicAuth

Basic 認証は、設定されたユーザー名とパスワードを使用してすべてのリモート書き込み要求に承認ヘッダーを設定します。

認可

認可

Authorization は、設定されたトークンを使用して、すべてのリモート書き込みリクエストに Authorization ヘッダーを設定します。

OAuth 2.0

oauth2

OAuth 2.0 設定は、クライアントクレデンシャル付与タイプを使用します。Prometheus は、リモート書き込みエンドポイントにアクセスするために、指定されたクライアント ID およびクライアントシークレットを使用して tokenUrl からアクセストークンを取得します。この方法を認可、AWS 署名バージョン 4、または基本認証と同時に使用することはできません。

TLS クライアント

tlsConfig

TLS クライアント設定は、TLS を使用してリモート書き込みエンドポイントサーバーで認証するために使用される CA 証明書、クライアント証明書、およびクライアントキーファイル情報を指定します。設定例は、CA 証明書ファイル、クライアント証明書ファイル、およびクライアントキーファイルがすでに作成されていることを前提としています。

4.4.1.2. リモート書き込み認証の設定例

次のサンプルは、リモート書き込みエンドポイントに接続するために使用できるさまざまな認証設定を示しています。各サンプルでは、認証情報やその他の関連設定を含む対応する Secret オブジェクトを設定する方法も示しています。各サンプルは、openshift-user-workload-monitoring namespace 内のユーザー定義プロジェクトのモニタリングで使用する認証を設定します。

4.4.1.2.1. AWS 署名バージョン 4 認証のサンプル YAML

以下は、openshift-user-workload-monitoring namespace の sigv4-credentials という名前の sigv 4 シークレットの設定を示しています。 

apiVersion: v1
kind: Secret
metadata:
  name: sigv4-credentials
  namespace: openshift-user-workload-monitoring
stringData:
  accessKey: <AWS_access_key> 1
  secretKey: <AWS_secret_key> 2
type: Opaque
1
AWS API アクセスキー。
2
AWS API シークレットキー。

以下は、openshift-user-workload-monitoring namespace の sigv4-credentials という名前の Secret オブジェクトを使用する AWS Signature Version 4 リモート書き込み認証のサンプルを示しています。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://authorization.example.com/api/write"
        sigv4:
          region: <AWS_region> 1
          accessKey:
            name: sigv4-credentials 2
            key: accessKey 3
          secretKey:
            name: sigv4-credentials 4
            key: secretKey 5
          profile: <AWS_profile_name> 6
          roleArn: <AWS_role_arn> 7
1
AWS リージョン。
2 4
AWS API アクセスクレデンシャルが含まれる Secret オブジェクトの名前。
3
指定された Secret オブジェクトに AWS API アクセスキーが含まれるキー。
5
指定された Secret オブジェクトに AWS API シークレットキーが含まれるキー。
6
認証に使用される AWS プロファイルの名前。
7
ロールに割り当てられた Amazon Resource Name (ARN) の一意の識別子。
4.4.1.2.2. Basic 認証用のサンプル YAML

以下は、openshift-user-workload-monitoring namespace の rw-basic-auth という名前の Secret オブジェクトの Basic 認証設定の例を示しています。 

apiVersion: v1
kind: Secret
metadata:
  name: rw-basic-auth
  namespace: openshift-user-workload-monitoring
stringData:
  user: <basic_username> 1
  password: <basic_password> 2
type: Opaque
1
ユーザー名
2
パスワード。

以下の例は、openshift-user-workload-monitoring namespace の rw-basic-auth という名前の Secret オブジェクトを使用する basicAuth リモート書き込み設定を示しています。これは、エンドポイントの認証認証情報がすでに設定されていることを前提としています。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://basicauth.example.com/api/write"
        basicAuth:
          username:
            name: rw-basic-auth 1
            key: user 2
          password:
            name: rw-basic-auth 3
            key: password 4
1 3
認証クレデンシャルが含まれる Secret オブジェクトの名前。
2
指定の Secret オブジェクトのユーザー名が含まれるキー。
4
指定された Secret オブジェクトにパスワードが含まれるキー。
4.4.1.2.3. Secret オブジェクトを使用したベアラートークンによる認証のサンプル YAML

以下は、openshift-user-workload-monitoring namespace の rw-bearer-auth という名前の Secret オブジェクトのベアラートークン設定を示しています。 

apiVersion: v1
kind: Secret
metadata:
  name: rw-bearer-auth
  namespace: openshift-user-workload-monitoring
stringData:
  token: <authentication_token> 1
type: Opaque
1
認証トークン。

以下は、openshift-user-workload-monitoring namespace の rw-bearer-auth という名前の Secret オブジェクトを使用するベアラートークン設定マップの設定例を示しています。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    enableUserWorkload: true
    prometheus:
      remoteWrite:
      - url: "https://authorization.example.com/api/write"
        authorization:
          type: Bearer 1
          credentials:
            name: rw-bearer-auth 2
            key: token 3
1
要求の認証タイプ。デフォルト値は Bearer です。
2
認証クレデンシャルが含まれる Secret オブジェクトの名前。
3
指定された Secret オブジェクトに認証トークンが含まれるキー。
4.4.1.2.4. OAuth 2.0 認証のサンプル YAML

以下は、openshift-user-workload-monitoring namespace の oauth2-credentials という名前の Secret オブジェクトの OAuth 2.0 設定のサンプルを示しています。 

apiVersion: v1
kind: Secret
metadata:
  name: oauth2-credentials
  namespace: openshift-user-workload-monitoring
stringData:
  id: <oauth2_id> 1
  secret: <oauth2_secret> 2
type: Opaque
1
Oauth 2.0 ID。
2
OAuth 2.0 シークレット。

以下は、openshift-user-workload-monitoring namespace の oauth2-credentials という Secret オブジェクトを使用した oauth2 リモート書き込み認証のサンプル設定です。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://test.example.com/api/write"
        oauth2:
          clientId:
            secret:
              name: oauth2-credentials 1
              key: id 2
          clientSecret:
            name: oauth2-credentials 3
            key: secret 4
          tokenUrl: https://example.com/oauth2/token 5
          scopes: 6
          - <scope_1>
          - <scope_2>
          endpointParams: 7
            param1: <parameter_1>
            param2: <parameter_2>
1 3
対応する Secret オブジェクトの名前。ClientId は ConfigMap オブジェクトを参照することもできますが、clientSecret は Secret オブジェクトを参照する必要があることに注意してください。
2 4
指定された Secret オブジェクトの OAuth 2.0 認証情報が含まれるキー。
5
指定された clientId および clientSecret でトークンを取得するために使用される URL。
6
認可要求の OAuth 2.0 スコープ。これらのスコープは、トークンがアクセスできるデータを制限します。
7
認可サーバーに必要な OAuth 2.0 認可要求パラメーター。
4.4.1.2.5. TLS クライアント認証のサンプル YAML

以下は、openshift-user-workload-monitoring namespace 内の mtls-bundle という名前の tls Secret オブジェクトに対する TLS クライアント設定のサンプルです。 

apiVersion: v1
kind: Secret
metadata:
  name: mtls-bundle
  namespace: openshift-user-workload-monitoring
data:
  ca.crt: <ca_cert> 1
  client.crt: <client_cert> 2
  client.key: <client_key> 3
type: tls
1
サーバー証明書を検証する Prometheus コンテナーの CA 証明書。
2
サーバーとの認証用のクライアント証明書。
3
クライアントキー。

以下の例は、mtls-bundle という名前の TLS Secret オブジェクトを使用する tlsConfig リモート書き込み認証設定を示しています。 

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"
        tlsConfig:
          ca:
            secret:
              name: mtls-bundle 1
              key: ca.crt 2
          cert:
            secret:
              name: mtls-bundle 3
              key: client.crt 4
          keySecret:
            name: mtls-bundle 5
            key: client.key 6
1 3 5
TLS 認証クレデンシャルが含まれる対応する Secret オブジェクトの名前。ca と cert は、代わりに ConfigMap オブジェクトを参照することができますが、keySecret は Secret オブジェクトを参照する必要があることに注意してください。
2
エンドポイントの CA 証明書が含まれる指定された Secret オブジェクトのキー。
4
エンドポイントのクライアント証明書が含まれる指定された Secret オブジェクトのキー。
6
クライアントシークレットが含まれる指定の Secret オブジェクトのキー。

4.4.1.3. リモート書き込みキューの設定例

リモート書き込み用の queueConfig オブジェクトを使用して、リモート書き込みキューパラメーターを調整できます。以下の例は、キューパラメーターと、openshift-user-workload-monitoring namespace のユーザー定義プロジェクトのモニタリング用のデフォルト値を示しています。

デフォルト値を使用したリモート書き込みパラメーターの設定例

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>
        queueConfig:
          capacity: 10000 1
          minShards: 1 2
          maxShards: 50 3
          maxSamplesPerSend: 2000 4
          batchSendDeadline: 5s 5
          minBackoff: 30ms 6
          maxBackoff: 5s 7
          retryOnRateLimit: false 8
          sampleAgeLimit: 0s 9

1
キューから削除される前にシャードごとにバッファーリングするサンプルの数。
2
シャードの最小数。
3
シャードの最大数
4
送信ごとの最大サンプル数。
5
サンプルがバッファー内で待機する最大時間。
6
失敗したリクエストを再試行する前に待機する最初の時間。maxbackoff の時間になるまで、再試行するたびに時間が 2 倍になります。
7
失敗したリクエストを再試行するまでに待機する最大時間。
8
リモート書き込みストレージから 429 ステータスコードを受信した後に要求を再試行するには、このパラメーターを true に設定します。
9
sampleAgeLimit 制限よりも古いサンプルはキューから削除されます。値が未定義であるか、0s に設定されている場合、パラメーターは無視されます。

関連情報

4.4.2. メトリクスのクラスター ID ラベルの作成

openshift-user-workload-monitoring namespace の user-workload-monitoring-config config map にリモート書き込みストレージの write_relabel 設定を追加することで、メトリクスのクラスター ID ラベルを作成できます。

注記

Prometheus が namespace ラベルを公開するユーザーワークロードターゲットをスクレイプすると、システムはこのラベルを exported_namespace として保存します。この動作により、最終的な namespace ラベル値がターゲット Pod の namespace と等しくなります。このデフォルトは、PodMonitor または ServiceMonitor オブジェクトの honorLabels フィールドの値を true に設定してオーバーライドすることはできません。

前提条件

  • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
  • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
  • OpenShift CLI (oc) がインストールされている。
  • リモート書き込みストレージを設定している。

手順

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

    次のサンプルは、クラスター 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
    1
    システムは最初に __tmp_openshift_cluster_id__ という名前の一時的なクラスター ID ソースラベルを適用します。この一時的なラベルは、指定するクラスター ID ラベル名に置き換えられます。
    2
    リモート書き込みストレージに送信されるメトリクスのクラスター ID ラベルの名前を指定します。メトリクスにすでに存在するラベル名を使用する場合、その値はこのクラスター ID ラベルの名前で上書きされます。ラベル名には __tmp_openshift_cluster_id__ は使用しないでください。最後の再ラベル手順では、この名前を使用するラベルを削除します。
    3
    replace 置き換えラベルの再設定アクションは、一時ラベルを送信メトリクスのターゲットラベルに置き換えます。このアクションはデフォルトであり、アクションが指定されていない場合に適用されます。
  3. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

関連情報

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

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

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

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

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとして、または namespace の管理権限を持つユーザーとして、クラスターにアクセスできる。

手順

  1. サービス設定の YAML ファイルを作成します。この例では、prometheus-example-app.yaml という名前です。

  2. 以下のデプロイメントおよびサービス設定の詳細をファイルに追加します。 

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

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

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

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

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

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

    $ oc -n ns1 get pod

    出力例

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

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

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

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

前提条件

  • cluster-admin クラスターロールまたは monitoring-edit クラスターロールのあるユーザーとしてクラスターにアクセスできる。
  • ユーザー定義プロジェクトのモニタリングが有効化されている。

  • この例では、prometheus-example-app サンプルサービスを ns1 プロジェクトにデプロイしている。

    注記

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

手順

  1. example-app-service-monitor.yaml という名前の新しい YAML 設定ファイルを作成します。

  2. ServiceMonitor リソースを YAML ファイルに追加します。以下の例では、prometheus-example-monitor という名前のサービスモニターを作成し、ns1 namespace の prometheus-example-app サービスによって公開されるメトリクスを収集します。 

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1 1
spec:
  endpoints:
  - interval: 30s
    port: web 2
    scheme: http
  selector: 3
    matchLabels:
      app: prometheus-example-app
    1
    サービスが実行されるユーザー定義の namespace を指定します。
    2
    Prometheus によってスクレープされるエンドポイントポートを指定します。
    3
    メタデータラベルに基づいてサービスに一致するようにセレクターを設定します。
    注記

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

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

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

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

  4. ServiceMonitor リソースが実行されていることを確認します。 

    $ oc -n <namespace> get servicemonitor

    出力例

    NAME                         AGE
prometheus-example-monitor   81m

4.4.3.3. サービスエンドポイント認証設定の例

ServiceMonitor および PodMonitor カスタムリソース定義 (CRD) を使用して、ユーザー定義のプロジェクト監視用のサービスエンドポイントの認証を設定できます。

次のサンプルは、ServiceMonitor リソースのさまざまな認証設定を示しています。各サンプルでは、認証認証情報やその他の関連設定を含む対応する Secret オブジェクトを設定する方法を示します。

4.4.3.3.1. ベアラートークンを使用した YAML 認証の例

以下の例は、ns1 namespace の example-bearer-auth という名前の Secret オブジェクトのベアラートークン設定を示しています。

ベアラートークンシークレットの例

apiVersion: v1
kind: Secret
metadata:
  name: example-bearer-auth
  namespace: ns1
stringData:
  token: <authentication_token> 1

1
認証トークンを指定します。

以下の例は、ServiceMonitor CRD のベアラートークン認証設定を示しています。この例では、example-bearer-auth という名前の Secret オブジェクトを使用しています。

ベアラートークンの認証設定の例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - authorization:
      credentials:
        key: token 1
        name: example-bearer-auth 2
    port: web
  selector:
    matchLabels:
      app: prometheus-example-app

1
指定された Secret オブジェクトに認証トークンが含まれるキー。
2
認証クレデンシャルが含まれる Secret オブジェクトの名前。
重要

bearerTokenFile を使用してベアラートークンを設定しないでください。bearerTokenFile 設定を使用する場合、ServiceMonitor リソースは拒否されます。

4.4.3.3.2. Basic 認証用のサンプル YAML

次のサンプルは、ns1 の example-basic-auth という名前の Secret オブジェクトの Basic 認証設定を示しています。

Basic 認証シークレットの例

apiVersion: v1
kind: Secret
metadata:
  name: example-basic-auth
  namespace: ns1
stringData:
  user: <basic_username> 1
  password: <basic_password>  2

1
認証のユーザー名を指定します。
2
認証のパスワードを指定します。

以下の例は、ServiceMonitor CRD の Basic 認証設定を示しています。この例では、example-basic-auth という名前の Secret オブジェクトを使用しています。

Basic 認証の設定例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - basicAuth:
      username:
        key: user 1
        name: example-basic-auth 2
      password:
        key: password 3
        name: example-basic-auth 4
    port: web
  selector:
    matchLabels:
      app: prometheus-example-app

1
指定の Secret オブジェクトのユーザー名が含まれるキー。
2 4
Basic 認証が含まれる Secret オブジェクトの名前。
3
指定された Secret オブジェクトにパスワードが含まれるキー。
4.4.3.3.3. OAuth 2.0 を使用した YAML 認証のサンプル

以下の例は、ns1 namespace の example-oauth2 という名前の Secret オブジェクトの OAuth 2.0 設定を示しています。

OAuth 2.0 シークレットの例

apiVersion: v1
kind: Secret
metadata:
  name: example-oauth2
  namespace: ns1
stringData:
  id: <oauth2_id> 1
  secret: <oauth2_secret> 2

1
Oauth 2.0 ID を指定します。
2
Oauth 2.0 シークレットを指定します。

以下の例は、ServiceMonitor CRD の OAuth 2.0 認証設定を示しています。この例では、example-oauth2 という名前の Secret オブジェクトを使用します。

OAuth 2.0 認証の設定例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - oauth2:
      clientId:
        secret:
          key: id 1
          name: example-oauth2 2
      clientSecret:
        key: secret 3
        name: example-oauth2 4
      tokenUrl: https://example.com/oauth2/token 5
    port: web
  selector:
    matchLabels:
      app: prometheus-example-app

1
指定された Secret オブジェクトの OAuth 2.0 ID が含まれるキー。
2 4
OAuth 2.0 認証情報を含む Secret オブジェクトの名前。
3
指定された Secret オブジェクトに OAuth 2.0 シークレットが含まれるキー。
5
指定された clientId および clientSecret でトークンを取得するために使用される URL。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.