Prometheus 用 Azure Monitor マネージド サービスで Prometheus メトリックのスクレイピングをカスタマイズする

この記事では、Azure Monitor でメトリック アドオンを使用してメトリックのスクレイピングを Kubernetes クラスター用にカスタマイズする手順について説明します。

configmap

メトリック アドオンにスクレイピング構成やその他の設定を提供するには、4 つの異なる configmap を構成できます。 すべての構成マップは、任意のクラスターの kube-system 名前空間に適用する必要があります。

注意

Managed Prometheus が有効の場合、既定ではクラスター内に 4 つの configmaps のいずれも存在しません。 カスタマイズする必要がある内容に応じて、kube-system 名前空間で同じ名前を使用し、これら 4 つの configmap の一部またはすべてをデプロイする必要があります。 これらの configmaps を kube-system 名前空間にデプロイした後に、AMA-Metrics ポッドは、これらの configmaps を取得し、2 ～ 3 分間で再起動して configmaps で指定された構成設定を適用します。

1. ama-metrics-settings-configmap この構成マップには、構成できる単純な設定を以下に示します。 上記の Git ハブ リポジトリから configmap を取得し、必要な設定を変更し、configmap をクラスターの kube-system 名前空間に適用またはデプロイできます
   • クラスター エイリアス (クラスターから取り込まれるすべての時系列/メトリックの cluster ラベルの値を変更する場合)
   • 既定のスクレイピング ターゲットを有効または無効にする - ターゲットに基づいて既定のスクレイピングをオンまたはオフにします。 これらの既定のターゲットのスクレイピング構成は既に定義済みまたは組み込まれています
   • 名前空間ごとにポッド注釈ベースのスクレイピングを有効にする
   • metric keep-lists - この設定は、各既定のターゲットから許可するようにリストされているメトリックを制御し、既定の動作を変更するために使用されます
   • 既定または事前定義ターゲットの間隔をスクレイピングします。 30 secs は既定のスクレイピング頻度であり、この configmap を使用して既定のターゲットごとに変更できます
   • debug-mode - これをオンにすると、不足しているメトリック/インジェストの問題をデバッグするのに役立ちます。詳細については、「トラブルシューティング」を参照してください
2. ama-metrics-prometheus-config この構成マップを使用して、アドオン レプリカの Prometheus スクレイピング構成を提供できます。 アドオンはシングルトン レプリカを実行し、この configmap でスクレイピング ジョブを提供することで、クラスター レベルのサービスを検出してスクレイピングできます。 上記の Git ハブ リポジトリからサンプル configmap を取得し、必要なスクレイピング ジョブを追加し、構成マップをクラスターの kube-system 名前空間に適用またはデプロイできます。 これはサポートされていますが、カスタム ターゲットをスクレイピングするために推奨される方法は、カスタム リソースを使用することです
3. ama-metrics-prometheus-config-node (詳細) この構成マップを使用すると、クラスター内のすべての Linux ノードで実行されるアドオン デーモンセットの Prometheus スクレイピング構成を提供できます。また、この構成マップでスクレイピング ジョブを提供することで、各ノード上のすべてのノード レベル ターゲットをスクレイピングできます。 この configmap を使用すると、スクレイピング構成で $NODE_IP 変数を使用 できます。これは、各ノードで実行されているデーモンセット ポッド内の対応するノードの IP アドレスによって置き換えられます。 これにより、メトリック アドオン デーモンセットから、そのノードで実行されるすべてのものをスクレイピングするアクセス権を取得できます。 このノード レベルの構成マップのスクレイピング構成で検出を使用する場合は注意してください。クラスタ内のすべてのノードがターゲットを設定して検出し、冗長なメトリックを収集するためです。 上記の Git ハブ リポジトリからサンプル configmap を取得し、必要なスクレイピング ジョブを追加し、構成マップをクラスターの kube-system 名前空間に適用またはデプロイできます
4. ama-metrics-prometheus-config-node-windows (詳細) この構成マップを使用すると、クラスター内のすべての Linux ノードで実行されるアドオン デーモンセットの Prometheus スクレイピング構成を提供できます。また、この構成マップでスクレイピング ジョブを提供することで、各ノード上のノード レベル ターゲットをスクレイピングできます。 この configmap を使用すると、スクレイピング構成で $NODE_IP 変数を使用 できます。これは、各ノードで実行されているデーモンセット ポッド内の対応するノードの IP アドレスによって置き換えられます。 これにより、メトリック アドオン デーモンセットから、そのノードで実行されるすべてのものをスクレイピングするアクセス権を取得できます。 このノード レベルの構成マップのスクレイピング構成で検出を使用する場合は注意してください。クラスタ内のすべてのノードがターゲットを設定して検出し、冗長なメトリックを収集するためです。 上記の Git ハブ リポジトリからサンプル configmap を取得し、必要なスクレイピング ジョブを追加し、構成マップをクラスターの kube-system 名前空間に適用またはデプロイできます

カスタム リソース定義

Azure Monitor メトリック アドオンでは、OSS Prometheus オペレーターと同様に、Prometheus - ポッド モニターとサービス モニターを使用した Prometheus メトリックのスクレイピングがサポートされています。 アドオンを有効にすると、ポッド モニターとサービス モニターのカスタム リソース定義がデプロイされ、独自のカスタム リソースを作成できるようになります。 手順に従って、クラスターにカスタム リソースを作成して適用します。

メトリック アドオン設定の configmap

ama-metrics-settings-configmap をダウンロード、編集してクラスターに適用し、メトリック アドオンのすぐに使える機能をカスタマイズできます。

既定のターゲットの有効化と無効化

次の表では、Azure Monitor のメトリック アドオンで既定によってスクレイピングできるすべての既定のターゲットと、それが最初に有効になっているかどうかを示しています。 既定のターゲットは 30 秒ごとにスクレイピングされます。 レプリカは、kube-state-metrics などのクラスター全体のターゲットをスクレイピングするためにデプロイされます。 デーモンセットは、kubelet などのノード全体のターゲットをスクレイピングするためにもデプロイされます。

キー	Type	Enabled	Pod	説明
kubelet	[bool]	true	Linux デーモンセット	追加のスクレイピング構成を必要とせずに、K8s クラスター内のすべてのノードで kubelet をスクレイピングします。
cadvisor	[bool]	true	Linux デーモンセット	追加のスクレイピング構成を必要とせずに、K8s クラスター内のすべてのノードで cadvisor をスクレイピングします。 Linux のみ。
kubestate	[bool]	true	Linux レプリカ	追加のスクレイピング構成を必要とせずに、K8s クラスター内で kube-state-metrics (アドオンの一部としてインストール済み) をスクレイピングします。
nodeexporter	[bool]	true	Linux デーモンセット	追加のスクレイピング構成を必要とせずに、ノード メトリックをスクレイピングします。 Linux のみ。
coredns	[bool]	false	Linux レプリカ	追加のスクレイピング構成を必要とせずに、K8s クラスター内で coredns サービスをスクレイピングします。
kubeproxy	[bool]	false	Linux デーモンセット	追加のスクレイピング構成を必要とせずに、K8s クラスター内で検出されたすべての Linux ノードで kube-proxy をスクレイピングします。 Linux のみ。
apiserver	[bool]	false	Linux レプリカ	追加のスクレイピング構成を必要とせずに、K8s クラスター内で Kubernetes API サーバーをスクレイピングします。
windowsexporter	bool	false	Windows デーモンセット	追加のスクレイピング構成を必要とせずに、K8s クラスター内のすべてのノードで Windows エクスポーターをスクレイピングします。 Windows のみ。
windowskubeproxy	bool	false	Windows デーモンセット	追加のスクレイピング構成を必要とせずに、K8s クラスター内のすべてのノードで windows-kube-proxy をスクレイピングします。 Windows のみ。
prometheuscollectorhealth	[bool]	false	Linux レプリカ	スクレイピングされた時系列の量とサイズなど、prometheus-collector コンテナーに関する情報をスクレイピングします。

既定では有効になっていない既定のターゲットのスクレイピングを有効にする場合は、configmapama-metrics-settings-configmap を編集して、default-scrape-settings-enabled の下にリストされているターゲットを true に更新します。 その configmap をクラスターに適用します。

ポッドの注釈に基づくスクレイピングを有効にする

注釈をポッドに追加すると、Prometheus のカスタム構成を作成する必要なしに、アプリケーション ポッドをスクレイピングできます。 ポッドをスクレイピングするには、注釈 prometheus.io/scrape: "true" が必要です。 注釈 prometheus.io/path と prometheus.io/port は、メトリックがポッドでホストされているパスとポートを示します。 <pod IP>:8080/metrics でメトリックをホストしているポッドの注釈は次のようになります。

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

特定の注釈によるこれらのポッドのスクレイピングは、既定では無効にされています。 有効にするには、ama-metrics-settings-configmap で、スクレイピングする注釈を含むポッドの名前空間の正規表現を、podannotationnamespaceregex フィールドの値として追加します。

たとえば、次のように設定すると、名前空間 kube-system と my-namespace 内にある注釈付きのポッドのみがスクレイピングされます。

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

注釈によるポッドのスクレイピングをすべての名前空間で有効にするには、次の設定を使います。

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

警告

多くの名前空間からポッドの注釈のスクレイピングを行うと、注釈を持つポッドの数に応じて、非常に大量のメトリックが生成される可能性があります。

既定のターゲットによって収集されるメトリックのカスタマイズ

既定では、すべての既定のターゲットについて、minimal-ingestion-profile に記述されているとおり、既定の記録ルール、アラート、Grafana ダッシュボードで使用される最小限のメトリックのみが取り込まれます。 既定のターゲットからすべてのメトリックを収集するには、設定 configmap の default-targets-metrics-keep-list の下にある keep-lists を更新し、minimalingestionprofile を false に設定します。

既定のターゲットについて、許可されるようにリストされている既定のメトリックスに加えて、さらに多くのメトリックを許可リストに載せるには、変更する対応するジョブの default-targets-metrics-keep-list の下の設定を編集します。

たとえば、kubelet は、既定のターゲット kubelet のメトリック フィルター処理設定です。 正規表現ベースのフィルター処理を使用して、既定のターゲットについて収集されるメトリックをフィルター処理して "取り込む" には、次のスクリプトを使用します。

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

注意

正規表現で引用符または円記号を使用する場合は、たとえば "test\'smetric\"s\""、testbackslash\\* のように、円記号を使用してエスケープする必要があります。

既定のジョブをさらにカスタマイズして収集の頻度やラベルなどのプロパティを変更するには、ターゲットの configmap 値を false に設定して、対応する既定のターゲットを無効にします。 その後、カスタムの configmap を使用してジョブを適用します。 カスタム構成の詳細については、「Azure Monitor で Prometheus メトリックのスクレイピングをカスタマイズする」を参照してください。

クラスターの別名

スクレイピングされたすべての時系列に追加されるクラスター ラベルでは、AKS クラスターの完全な Azure Resource Manager リソース ID の、最後の部分が使用されます。 たとえば、リソース ID が/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername の場合、クラスター ラベルは myclustername になります。

スクレイピングされた時系列のクラスター ラベルをオーバーライドするには、設定 cluster_alias を configmapama-metrics-settings-configmap 内の prometheus-collector-settings の下にある任意の文字列に設定します。 この configmap は、クラスターに存在しない場合は作成でき、クラスターに既に存在する場合は既存のものを編集できます。

新しいラベルは、Grafana ダッシュボードのクラスター パラメーター ドロップダウンにも、既定のラベルに代わって表示されます。

注意

英数字のみを使用できます。 それ以外の文字はすべて、_ に置き換えられます。 この変更は、このラベルを使用するさまざまなコンポーネントが基本的な英数字規則に確実に準拠するようにするためです。

デバッグ モード

警告

このモードはパフォーマンスに影響を与える可能性があり、デバッグのために短時間だけ有効にする必要があります。

デバッグの目的でスクレイピングされるすべてのメトリックを表示するには、configmapama-metrics-settings-configmap 内の debug-mode 設定の下にある設定 enabled を true に更新して、メトリック アドオン エージェントをデバッグ モードで実行するように構成できます。 この configmap を作成するか、既存の configmap を編集することができます。 詳細については、Prometheus メトリックの収集のトラブルシューティングに関する記事の「デバッグ モード」セクションを参照してください。

スクレイピング間隔の設定

任意のターゲットのスクレイピング間隔の設定を更新するには、configmapama-metrics-settings-configmap にあるそのターゲットの設定 default-targets-scrape-interval-settings にある期間を更新します。 スクレイピング間隔は、こちらの Web サイトで指定されている正しい形式で設定する必要があります。 そうしない場合は、既定値の 30 秒が対応するターゲットに適用されます。 たとえば、kubelet ジョブのスクレイピング間隔を 60s に更新する場合は、YAML の次のセクションを更新できます。

default-targets-scrape-interval-settings: |-
    kubelet = "60s"
    coredns = "30s"
    cadvisor = "30s"
    kubeproxy = "30s"
    apiserver = "30s"
    kubestate = "30s"
    nodeexporter = "30s"
    windowsexporter = "30s"
    windowskubeproxy = "30s"
    kappiebasic = "30s"
    prometheuscollectorhealth = "30s"
    podannotations = "30s"

次のコマンドを使用して YAML を適用します: kubectl apply -f .\ama-metrics-settings-configmap.yaml

カスタムの Prometheus スクレイピング ジョブを構成する

OSS Prometheus オペレーターと同様に、Prometheus - ポッド モニターとサービス モニター (推奨) を使用して Prometheus メトリックをスクレイピングできます。 手順に従って、クラスターにカスタム リソースを作成して適用します。

加えて、手順に従って、クラスター用の configmap を作成、検証、適用できます。 構成の形式は、Prometheus 構成ファイルと類似しています。

Prometheus の構成に関するヒントと例

このセクションの例から、いくつかのヒントを学びます。

カスタム スクレイピング構成に CRD を使用した構成

ポッド モニターとサービス モニターのテンプレートを使用し、API 仕様に従ってカスタム リソース (PodMonitor と Service Monitor) を作成します。 Managed Prometheus によって取得される既存の OSS CR に必要な変更は、API グループ - azmonitoring.coreos.com/v1 のみであることに注意してください。 詳細については、こちらを参照してください

カスタム スクレイピング構成用の構成ファイル

構成の形式は、Prometheus 構成ファイルと同じです。 現在、次のセクションがサポートされています。

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

その他のサポートされていないセクションは、configmap として適用する前に構成から削除する必要があります。 そうしなければ、カスタム構成は検証に失敗し、適用されません。

Prometheus 構成から configmap を作成するには、「設定ファイルの適用」セクションを参照してください。

注意

検証エラーが原因でカスタム スクレイピング構成を適用できない場合、既定のスクレイピング構成が引き続き使用されます。

すべてのスクレイピング ジョブに適用されるグローバル設定を使用し、カスタム リソースのみを使用する場合は、グローバル設定のみを使用して ConfigMap を作成する必要があります (カスタム リソース内のこれらのそれぞれに対する設定は、グローバル セクションの設定をオーバーライドします)

スクレイピング構成

CRD を使用して構成をスクレイピングする

現在、カスタム リソースのターゲット検出方法でサポートされているのは、ポッド モニターとサービス モニターです

ポッド モニターとサービス モニター

ポッド モニターとサービス モニターを使用して検出されたターゲットには、使用されるモニターに応じて異なる __meta_* ラベルがあります。 ラベルを relabelings セクションで使用して、ターゲットのフィルター処理やターゲットのラベルの置き換えを行うことができます。

ポッド モニターとサービス モニターの「ポッド モニターとサービス モニターの例」を参照してください。

ラベルの変更

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

ラベルを追加する

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

relabelings:
- sourceLabels: [__address__]
  targetLabel: example_label
  replacement: 'example_value'

ポッド モニターまたはサービス モニターのラベルを使用する

ポッド モニターとサービス モニターを使用して検出されたターゲットには、使用されるモニターに応じて異なる __meta_* ラベルがあります。 __* ラベルは、ターゲットの検出後に削除されます。 メトリック レベルでこれらを使用してフィルター処理するには、まず、ラベル名を割り当てて relabelings の使用を維持します。 その後、metricRelabelings を使用してフィルター処理します。

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  action: replace
  targetLabel: kubernetes_namespace

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

ジョブとインスタンスのラベルの書き換え

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

# Replace the job name with the pod label 'k8s app'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
  targetLabel: 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
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
  targetLabel: instance

メトリックのラベルの変更

メトリックのラベルの変更は、スクレイピング後、インジェストの前に適用されます。 スクレイピング後にメトリックをフィルター処理するには、metricRelabelings セクションを使用します。 次の例では、この実行方法を示します。

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

# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: drop
  regex: 'example_metric_name'

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

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

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

メトリックの名前を変更する

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

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

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

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

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

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

構成ファイルを使用して構成をスクレイピングする

現在、スクレイピング構成のターゲット検出方法としてサポートされているのは、ターゲットの指定または検出のための 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 サービス検出の構成

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

Kubernetes クラスター用スクレイピング構成の Prometheus の例を参照してください。

ラベル書き換えの構成

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

ラベルを追加する

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

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

Kubernetes サービス検出のラベルを使用する

ジョブで 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: '.+'

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

TLS で提供される Prometheus インスタンスがあり、そこからメトリックをスクレイピングしたい場合は、スキームを https に設定し、configmap またはそれぞれの CRD で TLS の設定を行う必要があります。 カスタム スクレイピング ジョブ内の tls_config 構成プロパティを使い、CRD または configmap を使って TLS の設定を構成できます。 API サーバー証明書を検証するための CA 証明書を指定する必要があります。 CA 証明書は、Prometheus が TLS 経由でターゲットに接続するときに、サーバーの証明書の信頼性を検証するために使われます。 これは、サーバーの証明書が信頼されている機関によって署名されていることを確認するのに役立ちます。

シークレットが kube-system 名前空間で作成された後で、configmap と CRD が kube-system 名前空間で作成される必要があります。 シークレットの作成順序が重要です。 シークレットがないのに、有効な CRD や構成マップがある場合、コレクター ログに次のエラーが記録されます ->no file found for cert....

configmap または CRD を使って TLS 構成設定を提供する方法の詳細を次に示します。

• ConfigMap で TLS 構成設定を指定するには、mtls 対応アプリ内に、自己署名証明書とキーを作成してください。 構成マップ内の tlsConfig の例は次のようになります。

tls_config:
    ca_file: /etc/prometheus/certs/client-cert.pem
    cert_file: /etc/prometheus/certs/client-cert.pem
    key_file: /etc/prometheus/certs/client-key.pem
    insecure_skip_verify: false

• CRD で TLS 構成設定を指定するには、mtls 対応アプリ内に、自己署名証明書とキーを作成してください。 Podmonitor 内の tlsConfig の例は次のようになります。

tlsConfig:
    ca:
        secret:
        key: "client-cert.pem" # since it is self-signed
        name: "ama-metrics-mtls-secret"
    cert:
        secret:
        key: "client-cert.pem"
        name: "ama-metrics-mtls-secret"
    keySecret:
        key: "client-key.pem"
        name: "ama-metrics-mtls-secret"
    insecureSkipVerify: false

Note

CRD ベースのスクレイピングの場合は、mtls アプリ内の証明書ファイル名とキー名が次の形式であることを確認します。 例: secret_kube-system_ama-metrics-mtls-secret_cert-name.pem と secret_kube-system_ama-metrics-mtls-secret_key-name.pem。 CRD は、kube-system 名前空間に作成する必要があります。 シークレット名は、厳密に kube-system 名前空間の ama-metrics-mtls-secret である必要があります。 シークレットを作成するためのコマンドの例: kubectl create secret generic ama-metrics-mtls-secret --from-file=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem --from-file=secret_kube-system_ama-metrics-mtls-secret_client-key.pem=secret_kube-system_ama-metrics-mtls-secret_client-key.pem -n kube-system

TLS 認証の詳細については、次のドキュメントが役に立つ場合があります。

• TLS 証明書の生成 ->https://o11y.eu/blog/prometheus-server-tls/
• 構成 ->https://prometheus.io/docs/alerting/latest/configuration/#tls_config

次のステップ

Prometheus のメトリックに対してアラートを設定する
Prometheus のメトリックのクエリを実行する
Prometheus メトリックの収集に関する詳細情報