次の方法で共有

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 コンテナーに関する情報をスクレイピングします。

既定では有効になっていない既定のターゲットのスクレイピングを有効にする場合は、configmap ama-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 を configmap ama-metrics-settings-configmap 内の prometheus-collector-settings の下にある任意の文字列に設定します。 この configmap は、クラスターに存在しない場合は作成でき、クラスターに既に存在する場合は既存のものを編集できます。

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

注意

英数字のみを使用できます。 それ以外の文字はすべて、_ に置き換えられます。 この変更は、このラベルを使用するさまざまなコンポーネントが基本的な英数字規則に確実に準拠するようにするためです。 記録とアラートのルールを有効にしている場合は、ルールが機能するように、ルール オンボード テンプレートのクラスター名パラメーターに必ずクラスターのエイリアス名を使用してください。

デバッグ モード

警告

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

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

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

任意のターゲットのスクレイピング間隔の設定を更新するには、configmap ama-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 の構成に関するヒントと例

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

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

注意

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

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

スクレイピング構成

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

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

ポッド モニターとサービス モニターを使用して検出されたターゲットには、使用されるモニターに応じて異なる __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

Note

再ラベル付けの構成がある場合は、再ラベル付けによってターゲットが除外されず、構成されたラベルがターゲットと正しく一致していることを確認します。

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

メトリックのラベルの変更は、スクレイピング後、インジェストの前に適用されます。 スクレイピング後にメトリックをフィルター処理するには、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: '.+'

基本認証

prometheus 構成で basic_auth 設定を使用している場合は、次の手順に従ってください。

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

password1 の値は base64encoded です。

キー password1 は何でもかまいませんが、scrapeconfig password_file ファイルパスと一致する必要があります。

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

ama-metrics-mtls-secret シークレットは、パス /etc/prometheus/certs/ にある ama-metrics コンテナーにマウントされ、prometheus メトリックをスクレイピングするプロセスから使用できるようになります。 上記の例のキー (例 - password1) はファイル名になり、値は base64 でデコードされてコンテナー内のファイルの内容に追加され、prometheus スクレイパーはこのファイルの内容を使用し、エンドポイントのスクレーピングに使われるパスワードとして使われる値を取得します。

  1. カスタム スクレイピング構成の configmap で、次の設定を使用します。 ユーザー名フィールドには、実際のユーザー名文字列が含まれている必要があります。 password_file フィールドには、パスワードを含むファイルへのパスが含まれている必要があります。
basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

上記の password_file のパスを指定すると、prometheus スクレイパーはパス /etc/prometheus/certs にある password1 というファイルの内容を基本認証ベースのスクレイピングのパスワードの値として使用します。

基本認証と TLS 認証の両方を使用している場合は、以下のセクションを参照してください。 詳細については、以下の「注意」セクションを参照してください。

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

TLS で提供される Prometheus インスタンスがあり、そこからメトリックをスクレイピングしたい場合は、スキームを https に設定し、configmap またはそれぞれの CRD で TLS の設定を行う必要があります。 以下の手順に従ってください。

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

    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 シークレットは、パス /etc/prometheus/certs/ にある ama-metrics コンテナーにマウントされ、prometheus メトリックをスクレイピングするプロセスから使用できるようになります。 上記の例のキー (例 - certfile) はファイル名になり、値は base64 でデコードされてコンテナー内のファイルの内容に追加され、prometheus スクレイパーはこのファイルの内容を使用し、エンドポイントのスクレーピングに使われるパスワードとして使われる値を取得します。

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

  • configmap で TLS 構成設定を指定するには、次の例に従ってください。
tls_config:
    ca_file: /etc/prometheus/certs/<certfile> # since it is self-signed
    cert_file: /etc/prometheus/certs/<certfile>
    key_file: /etc/prometheus/certs/<keyfile>
    insecure_skip_verify: false

基本認証と TLS

configmap と CRD で基本と TLS の認証設定の両方を使用する場合は、次に示すように、シークレット ama-metrics-mtls-secret に data セクション以下のすべてのファイル (キー) とそれに対応する base 64 エンコード値が含まれていることを確認します。

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

Note

Note

/etc/prometheus/certs/ パスは必須ですが、password1 は任意の文字列にすることができ、上記で作成したシークレット内のデータのキーと一致する必要があります。 これは、シークレット ama-metrics-mtls-secret がコンテナー内のパス /etc/prometheus/certs/ にマウントされるためです。

base64 でエンコードされた値は、シークレットがファイルとしてマウントされるときに、エージェント ポッドによって自動的にデコードされます。

シークレット名が ama-metrics-mtls-secret であり、kube-system 名前空間内にあることを確認します。

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

TLS 構成設定の詳細については、この構成の記事を参照してください。

次のステップ

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