ConfigMap を使用して Kubernetes クラスターからカスタム Prometheus スクレープ ジョブを作成する

Kubernetes クラスターから Prometheus メトリックのコレクションをカスタマイズ するには、ConfigMap を使用して、Kubernetes クラスター内の既定のターゲットから Prometheus メトリックのスクレイピングをカスタマイズする方法について説明します。 この記事では、ConfigMap を使用してカスタム スクレープ ジョブを作成し、さらにカスタマイズし、追加のターゲットを作成する方法について説明します。

ConfigMaps

次の表では、カスタム スクレイピング ジョブの作成に使用される ConfigMap について説明します。 Managed Prometheus が有効になっている場合、これらの ConfigMap はクラスターに既定では存在しません。

Prometheus 構成ファイルを作成する

ama-metrics-prometheus-configを直接変更する代わりに、構成ファイルを作成してから ConfigMap に変換する方が簡単です。 このファイルのさまざまなセクションの詳細については、以下の スクレイプ構成設定を参照してください。

次の形式を使用して、 prometheus-config という名前の Prometheus スクレープ構成ファイルを作成します。 これにより、セクション scrape_configs セクションの下にスクレーピング構成が一覧表示され、必要に応じてグローバル scrape_interval、 scrape_timeout、および external_labelsを設定するためにグローバル セクションを使用できます。 スクレープ構成のオプションの詳細については、Prometheus.ioのスクレープ構成リファレンスを参照してください。

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

Prometheus のスクレープ構成ファイルのサンプルを次に示します。

global:
  scrape_interval: 30s
scrape_configs:
- job_name: my_static_config
  scrape_interval: 60s
  static_configs:
    - targets: ['my-static-service.svc.cluster.local:1234']
- job_name: prometheus_example_app
  scheme: http
  kubernetes_sd_configs:
    - role: service
  relabel_configs:
    - source_labels: [__meta_kubernetes_service_name]
      action: keep
      regex: "prometheus-example-service"

スクレーピング構成ファイルを検証する

エージェントは、カスタム promconfigvalidator ツールを使用して、ConfigMap を介して指定された Prometheus 構成を検証します。 構成が有効でない場合、カスタム構成はエージェントによって拒否されます。 Prometheus 構成ファイルを作成したら、このツールを使用して、エージェントの ConfigMap を作成する前に構成を検証できます。

promconfigvalidator ツールは、Azure Monitor メトリック アドオン ポッド内に付属しています。 クラスター内の名前空間ama-metrics-node-*kube-systemポッドのいずれかを使用して、検証用のツールをダウンロードできます。 kubectl cpを使用して、次のコマンドを使用してツールとその構成をダウンロードします。

for podname in $(kubectl get pods -l rsName=ama-metrics -n=kube-system -o json | jq -r '.items[].metadata.name'); do kubectl cp -n=kube-system "${podname}":/opt/promconfigvalidator ./promconfigvalidator;  kubectl cp -n=kube-system "${podname}":/opt/microsoft/otelcollector/collector-config-template.yml ./collector-config-template.yml; chmod 500 promconfigvalidator; done

実行可能ファイルと yaml をコピーした後、Prometheus 構成ファイルのパスを見つけます。 次に、コマンドの <config path> を置き換え、次のコマンドで検証コントロールを実行します。

./promconfigvalidator/promconfigvalidator --config "<config path>" --otelTemplate "./promconfigvalidator/collector-config-template.yml"

検証コントロールを実行すると、オプションの merged-otel-config.yaml パラメーターでパスが指定されていない場合、マージされた構成ファイルoutputが生成されます。 この自動生成されたマージ されたファイルは、ツールの検証とデバッグの目的でのみ使用されるため、使用しないでください。

ConfigMap として構成ファイルをデプロイする

カスタム Prometheus 構成ファイルは、prometheus-config名前空間の ama-metrics-prometheus-config、ama-metrics-prometheus-config-node、または ama-metrics-prometheus-config-node-windows ConfigMap 内の kube-system という名前のフィールドとして使用されます。 スクレープ構成ファイルから ConfigMap を作成するには、Prometheus 構成ファイルの名前をファイル拡張子のない prometheus-config に変更し、カスタム スクレープ ジョブ構成用に作成する ConfigMap に応じて、次のサンプル コマンドのうち 1 つ以上を実行します。

レプリカセットで使用する ConfigMap を作成します。

kubectl create ConfigMap ama-metrics-prometheus-config --from-file=prometheus-config -n kube-system

これにより、ama-metrics-prometheus-config名前空間に kube-system という名前の ConfigMap が作成されます。 構成の検証、処理、またはマージに問題があるかどうかを確認するには、 ama-metrics レプリカ ポッドを確認します。

Linux DaemonSet で使用する ConfigMap を作成します。

kubectl create ConfigMap ama-metrics-prometheus-config-node --from-file=prometheus-config -n kube-system

これにより、ama-metrics-prometheus-config-node名前空間に kube-system という名前の ConfigMap が作成されます。 構成の検証、処理、またはマージに問題があるかどうかを確認するには、 ama-metrics-node linux deamonset ポッドを確認します

Windows DaemonSet で使用する ConfigMap を作成する

kubectl create ConfigMap ama-metrics-prometheus-config-node-windows --from-file=prometheus-config -n kube-system

これにより、ama-metrics-prometheus-config-node-windows名前空間に kube-system という名前の ConfigMap が作成されます。 構成の検証、処理、またはマージに問題があるかどうかを確認するには、windows deamonset ポッド ama-metrics-win-node を確認できます

トラブルシューティング

kube-system 名前空間で ConfigMap を正常に作成した後もカスタムターゲットがスクレイピングされない場合は、kubectl logs を使用して ama-metrics-prometheus-config ConfigMap に対してレプリカポッドのログ、ama-metrics-prometheus-config-node ConfigMap に対して DaemonSet ポッドのログを確認し、prometheus-config-merger プレフィックス付きの「既定とカスタム Prometheus 設定のマージ開始」セクションにエラーがないことを確認してください。

スクレイピング構成

現在、スクレイピング構成のターゲット検出方法としてサポートされているのは、ターゲットの指定または検出のための static_configs または kubernetes_sd_configs のいずれかです。

静的構成には、静的ターゲットの一覧と、次のように追加する追加のラベルが含まれています。

scrape_configs:
  - job_name: example
    - targets: [ '10.10.10.1:9090', '10.10.10.2:9090', '10.10.10.3:9090' ... ]
    - labels: [ label1: value1, label1: value2, ... ]

kubernetes_sd_configs を使用して検出されるターゲットの __meta_* ラベルは、指定されたロールに応じてそれぞれ異なります。 ラベルを relabel_configs セクションで使用して、ターゲットのフィルター処理やターゲットのラベルの置き換えを行うことができます。

ラベル書き換えの構成

relabel_configs セクションは、ターゲット検出時に適用され、ジョブの各ターゲットに適用されます。 次の例では、relabel_configs の使用方法を示します。

ラベルを追加するジョブのすべてのメトリックにexample_label値を持つ example_value という名前の新しいラベルを追加します。 ラベル __address__ は常に存在し、ジョブのすべてのターゲットにラベルを追加するため、ソース ラベルとしてのみ使用します。

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

Kubernetes Service Discovery ラベルを使用する

ジョブで kubernetes_sd_configs を使用してターゲットを検出している場合、各ロールには、メトリックの __meta_* ラベルが関連付けられています。 __* ラベルは、ターゲットの検出後に削除されます。 メトリック レベルでこれらを使用してフィルター処理するには、まず、ラベル名を割り当てて relabel_configs の使用を維持します。 その後、metric_relabel_configs を使用してフィルター処理します。

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
  action: replace
  target_label: kubernetes_namespace

# Keep only metrics with the kubernetes namespace 'default'
metric_relabel_configs:
- source_labels: [kubernetes_namespace]
  action: keep
  regex: 'default'

ジョブとインスタンスの再ラベル付け

job および instance のラベル値は、他のラベルと同様に、ソース ラベルに基づいて変更することができます。

# Replace the job name with the pod label 'k8s app'
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_k8s_app]
  target_label: job

# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabel_configs:
- source_labels: [__meta_kubernetes_node_name]
  target_label: instance

メトリックのラベル書き換えの構成

メトリックのラベル書き換えの構成は、スクレイピング後、インジェストの前に適用されます。 スクレイピング後にメトリックをフィルター処理するには、metric_relabel_configs セクションを使用します。 次の例を参照してください。

名前でメトリックを削除する

# Drop the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
  action: drop
  regex: 'example_metric_name'

特定のメトリックのみを名前で保持する

# Keep only the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
  action: keep
  regex: 'example_metric_name'

# Keep only metrics that start with 'example_'
metric_relabel_configs:
- source_labels: [__name__]
  action: keep
  regex: '(example_.*)'

ラベルでメトリックをフィルター処理する

# Keep metrics only where example_label = 'example'
metric_relabel_configs:
- source_labels: [example_label]
  action: keep
  regex: 'example'

# Keep metrics only if `example_label` equals `value_1` or `value_2`
metric_relabel_configs:
- source_labels: [example_label]
  action: keep
  regex: '(value_1|value_2)'

# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metric_relabel_configs:
- source_labels: [example_label_1, example_label_2]
  separator: ';'
  action: keep
  regex: 'value_1;value_2'

# Keep metrics only if `example_label` exists as a label
metric_relabel_configs:
- source_labels: [example_label_1]
  action: keep
  regex: '.+'

メトリックの名前を変更する メトリックの名前変更はサポートされていません。

relabel_configs:
- source_labels: [__address__]
  target_label: example_label
  replacement: 'example_value'

基本認証とベアラー トークン

スクレープ構成でユーザー名、パスワード、または資格情報をプレーンテキストとして使用している場合、追加の変更は必要ありません。 構成に指定されている値が、スクレイピングに使用されます。 prometheus 構成のusername_fileまたはpassword_file設定に_fileまたはbasic_auth (または任意のbearer_token構成設定) を使用している場合は、次の手順に従います。

1. kube-system 名前空間に ama-metrics-mtls-secret という名前のシークレットを作成します。

   キー password1 の名前は、次の手順で Prometheus スクレープ構成の password_file ファイルパスのファイル名と一致する限り、任意の名前にできます。 キーの値は base64-encoded である必要があります。

   apiVersion: v1
   kind: Secret
   metadata:
     name: ama-metrics-mtls-secret
     namespace: kube-system
   type: Opaque
   data:
     password1: <base64-encoded-string>
   

   ama-metrics-mtls-secret シークレットは、パス ama-metrics の /etc/prometheus/certs/ ポッドにマウントされ、Prometheus スクレイパーで使用できるようになります。 キー (上記の例でpassword1 ) はファイル名になります。 値は base64 でデコードされ、コンテナー内のファイルの内容として追加されます。

2. ConfigMap のカスタム スクレープ構成にファイルパスを指定します。

   基本認証username フィールドには、実際のユーザー名文字列が含まれている必要があります。 password_file フィールドには、パスワードを含むファイルへのパスが含まれている必要があります。

   # Sets the `Authorization` header on every scrape request with the
   # configured username and password.
   basic_auth:
     username: <username string>
     password_file: /etc/prometheus/certs/password1
   

   ベアラー トークンbearer_token_file フィールドには、トークンを含むファイルへのパスが含まれている必要があります。

   # Sets the `Authorization` header on every scrape request with the bearer token
   # read from the configured file. It is mutually exclusive with `bearer_token`.
   bearer_token_file: /etc/prometheus/certs/password1
   

これらの設定の詳細については、 Prometheus scrape_configドキュメント を参照してください。

TLS ベースのスクレイピング

Https エンドポイントから Prometheus メトリックをスクレイピングする場合、Prometheus 構成、PodMonitor、または ServiceMonitorで、scheme を https に設定し、追加の TLS 設定を行う必要があります。

1. kube-system 名前空間に ama-metrics-mtls-secret という名前のシークレットを作成します。 シークレット オブジェクトのデータ セクションで指定した各キーと値のペアは、この /etc/prometheus/certs の場所に、データ セクションで指定したキーと同じファイル名で別個のファイルとしてマウントされます。 シークレット値は base64-encoded である必要があります。

   シークレットの YAML の例を次に示します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: ama-metrics-mtls-secret
     namespace: kube-system
   type: Opaque
   data:
     <certfile>: base64_cert_content    
     <keyfile>: base64_key_content 
   

   ama-metrics-mtls-secret シークレットは、パス ama-metrics の /etc/prometheus/certs/ ポッドにマウントされ、Prometheus スクレイパーで使用できるようになります。 キーはファイル名になります。 値は base64 でデコードされ、コンテナー内のファイルの内容として追加されます。

2. Prometheus 構成、PodMonitor、または ServiceMonitor でファイルパスを指定します。

   • ConfigMap で TLS 構成設定を指定するには、次の例を使用します。

   tls_config:
      # CA certificate to validate API server certificate with.
      ca_file: /etc/prometheus/certs/<certfile>
   
      # Certificate and key files for client cert authentication to the server.
      cert_file: /etc/prometheus/certs/<certfile>
      key_file: /etc/prometheus/certs/<keyfile>
   
      # Disable validation of the server certificate.
      insecure_skip_verify: false
   

基本認証と TLS

ConfigMap で基本的な認証トークンまたはベアラー トークン (ファイル ベースの資格情報) と TLS 認証設定の両方を使用する場合は、次の例に示すように、シークレット ama-metrics-mtls-secret に、対応する base64 でエンコードされた値を持つデータ セクションのすべてのキーが含まれていることを確認します。

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  certfile: base64_cert_content    # used for TLS
  keyfile: base64_key_content      # used for TLS
  password1: base64-encoded-string # used for basic auth
  password2: base64-encoded-string # used for basic auth

詳細設定: DaemonSet のカスタム Prometheus スクレープ ジョブを構成する

ama-metrics レプリカ ポッドでは、カスタム Prometheus 構成を使用して、指定されたターゲットをスクレイピングします。 ノードとポッドの数が多く、メトリックの量が多いクラスターでは、該当するカスタム スクレーピング ターゲットの一部を、単一の ama-metrics レプリカ ポッドから ama-metrics DaemonSet ポッドにオフロードできます。

ama-metrics-prometheus-config-node ConfigMap は、レプリカ セットの ConfigMap に似ています。各ノードに静的なスクレープ構成を作成できます。 スクレーピング構成は 1 つのノードのみを対象とし、サービス検出/ポッド注釈を使用しないでください。 それ以外の場合、各ノードはすべてのターゲットをスクレイピングし、Kubernetes API サーバーに対して多数の呼び出しを行います。

カスタム スクレーピング ターゲットは、ターゲットで static_configs を使用し、 $NODE_IP 環境変数を使用し、スクレーピングするポートを指定することで、同じ形式に従うことができます。 DaemonSet の各ポッドは構成を受け取り、メトリックをスクレイピングし、そのノードに対して送信します。

次の node-exporter 構成は、DaemonSet ポッドの既定のターゲットの 1 つです。 $NODE_IP環境変数が使用されます。この環境変数は、ノード上の特定のポートをターゲットにするすべてのama-metricsアドオン コンテナーに既に設定されています。

- job_name: nodesample
  scrape_interval: 30s
  scheme: http
  metrics_path: /metrics
  relabel_configs:
  - source_labels: [__metrics_path__]
    regex: (.*)
    target_label: metrics_path
  - source_labels: [__address__]
    replacement: '$NODE_NAME'
    target_label: instance
  static_configs:
  - targets: ['$NODE_IP:9100']

構成設定をスクレーピングする

以降のセクションでは、ConfigMap で使用される Prometheus 構成ファイルでサポートされる設定について説明します。 これらの設定の詳細については、 Prometheus 構成リファレンス を参照してください。

グローバル設定

グローバル設定の構成形式は、OSS Prometheus 構成でサポートされている形式と同じです

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

グローバル セクションで提供される設定は、すべてのスクレープ ジョブ (Configmap リソースとカスタム リソースの両方のジョブ) に適用されますが、個々のジョブで指定されている場合はオーバーライドされます。

次のステップ

• Prometheus メトリックの収集について詳しくは、こちらをご覧ください。