Prometheus エージェントの構成
以下の例は、エージェントのconfigセクションに配置する必要があります。あなたのケースにある既知のインストール方法を参照してください。
Helm を使用してエージェントを構成するには、次の 2 つの方法のいずれかでvalues.yamlを設定する必要があります。
ヒント
New Relicを追加する必要があります values.yamlファイルにあります。
スクレイピングするエンドポイントを定義する
デフォルトでは、New Relic Prometheus エージェントはnewrelic.io/scrape: "true"とprometheus.io/scrape: "true"の 2 つのアノテーションを使用してターゲットを検出します。
newrelic.io/scrape: "true"のアノテーションが付けられたクラスター内のすべてのターゲットが、デフォルトで検出され、スクレイピングされます。prometheus.io/scrape: "true"で注釈が付けられたターゲットは、構成に応じてスクレイピングされるか、スクレイピングされません。
Prometheus 統合からのみメトリクスをスクレイプする
Prometheus エージェントは、Kubernetes で最も一般的な統合からメトリクスを収集するように構成できます。 一連のダッシュボードを含む統合のリストを確認してください。 すぐに監視を開始できます。
そのリストは、New Relic の Prometheus エージェント ヘルム チャートの values.yaml で定義されています。このリストは変更できますが、一部 カスタム ラベルまたは値を使用すると、そのままでは機能しない場合があります。
アップグレードすると、新しい統合フィルターが使用できる場合があります。したがって、クラスター内のサービスによっては、統合フィルターを含むアップグレード後に、スクレイピングされるデータの量が増加する可能性があります。これを回避するには、 app_valuesの固定リストをvalues.yamlファイルに保存します。例えば：
app_values: ["redis", "traefik", "calico", "nginx", "coredns", "kube-dns", "etcd", "cockroachdb"]さらに、統合フィルターの新しいバージョンにより、1 つのジョブによって既にスクレイピングされたターゲットが 2 回目にスクレイピングされる可能性があります。重複データが発生した場合に通知を受け取る (および重複スクレイピングを完全に防止する) ために、次のクエリに基づいてアラートを作成できます。
FROM Metric select uniqueCount(job) facet instance, cluster_name limit 10 since 2 minutes agoいずれかの値が 1 以外の場合、同じクラスター内の同じインスタンスをスクレイピングする 2 つ以上のジョブがあります。
すべてのターゲットからメトリックをスクレイピングする
prometheus.io/scrape: "true"アノテーションが付けられたすべてのターゲットをスクレイピングする必要がある場合は、選択したインストール方法に応じて、次のいずれかのアクションを実行する必要があります。
ガイド付きインストールを使用した場合は、 Scrape all Prometheus endpoints [すべての Prometheus エンドポイントをスクレイピング]オプションを選択します。
Helm を使用した場合は、prometheus-agent 構成に次の値を追加します。
kubernetes:integrations_filter:enabled: false
Kubernetes ターゲットの検出
Kubernetes ジョブは、 target_discovery構成に従ってターゲットを検出し、ターゲットを取得します。target_discovery構成内でpodとendpointsのトグルをtrueに設定すると、Prometheus は公開ポートを持つクラスター内のポッドまたはエンドポイントを検出するルールを作成します。
target_discovery.filter構成パラメーターを使用して、Prometheus がスクレイピングするターゲットをフィルタリングします。labelおよびannotationsラベルを使用して現在の条件でフィルタリングし、 AND演算子を使用してすべての条件をフィルタリングします。
次の例では、 newrelic.io/scrape: "true"アノテーションを使用してPodsとEndpointsのみをスクレイピングし、値としてpostgresまたはmysqlを使用してk8s.io/appラベルをスクレイピングします。エンドポイントの場合、アノテーションはそれに関連するサービスに存在する必要があります。つまり、 scrape: 'true'を構成すると、Prometheus はtrueを^true$として評価します。これを避けるには、 .*true.*使用してa-true-exampleにも一致するようにします。
kubernetes: jobs: - job_name_prefix: example integrations_filter: enabled: false target_discovery: pod: true endpoints: true filter: annotations: # <string>: <regex> newrelic.io/scrape: 'true' label: # <string>: <regex> k8s.io/app: '(postgres|mysql)'ヒント
ラベルまたは注釈の値を追加しない場合、フィルターは存在するかどうかのみを確認します。
静的ターゲットのセットアップ
Prometheus エージェントは、デフォルトで自己メトリクスをスクレイピングする静的ターゲット ジョブを定義しますが、追加のジョブを含めることで、追加の静的ターゲットを設定できます。
次の例には、個別に管理されるサーバーをスクレイピングするための追加のジョブと、 デフォルトで定義されているように、prometheus エージェント メトリックを報告し続けるためのセルフ メトリック ジョブが含まれています。
static_targets: jobs: - job_name: managed-exporter targets: - "managed_exporter.your-company.tld:5432" - job_name: self-metrics skip_sharding: true # sharding is skipped to obtain self-metrics from all Prometheus servers. targets: - "localhost:9090" extra_metric_relabel_config: - source_labels: [__name__] action: keep regex: "\ prometheus_agent_active_series|\ prometheus_target_interval_length_seconds|\ prometheus_target_scrape_pool_targets|\ prometheus_remote_storage_samples_pending|\ prometheus_remote_storage_samples_in_total|\ prometheus_remote_storage_samples_retried_total|\ prometheus_agent_corruptions_total|\ prometheus_remote_storage_shards|\ prometheus_sd_kubernetes_events_total|\ prometheus_agent_checkpoint_creations_failed_total|\ prometheus_agent_checkpoint_deletions_failed_total|\ prometheus_remote_storage_samples_dropped_total|\ prometheus_remote_storage_samples_failed_total|\ prometheus_sd_kubernetes_http_request_total|\ prometheus_agent_truncate_duration_seconds_sum|\ prometheus_build_info|\ process_resident_memory_bytes|\ process_virtual_memory_bytes|\ process_cpu_seconds_total"注意
static_targetsセクションを変更し、セルフ メトリクス ジョブを含めない場合、エージェント メトリクスはレポートされません。
目標こすり間隔
デフォルトでは、構成内のすべてのスクレイピング ジョブについて、 common.scrape_intervalで定義されているように、Prometheus エージェントは 30 秒ごとにメトリックのすべてのターゲットをスクレイピングします。これは、そのセクションでscrape_intervalキーを使用して変更できます。
この例は、スクレイプ間隔が異なる 2 つの Kubernetes ジョブを示しています。
common: scrape_interval: 30skubernetes: jobs: # this job will use the default scrape_interval defined in common. - job_name_prefix: default-targets-with-30s-interval target_discovery: pod: true filter: annotations: newrelic.io/scrape: 'true'
- job_name_prefix: slow-targets-with-60s-interval scrape_interval: 60s target_discovery: pod: true filter: annotations: newrelic.io/scrape_slow: 'true'指標とラベルの変換
任意の構成セクションでメトリックとラベルの変換を適用できますが、リモート書き込みレベルで設定すると、フィルタリングまたは変換の幅が広がります。
これらをnewrelic_remote_writeレベルで設定すると、フィルタは New Relic に送信されるすべてのメトリクスに適用されます。他のセクションで設定すると、そのセクションでスクレイピングされたメトリックに適用されます。メトリック フィルター プロセスは、メトリックがターゲットからスクレイピングされた後に発生します。
extra_metric_relabel_configパラメータを使用してフィルタを適用すると、 metric_relabel_configパラメータのエントリが追加されます。このパラメーターは、 static_targets.jobs 、 kubernetes.jobs 、およびnewrelic_remote_writeのextra_write_relabel_configsパラメーターにあります。
YAML 構成ファイルのさまざまな部分で使用する方法の例を次に示します。
static_targets:- name: self-metrics urls: - 'http://static-service:8181' extra_metric_relabel_config: # Drop metrics with prefix 'go_' for this target. - source_labels: [__name__] regex: 'go_.+' action: drop
newrelic_remote_write: extra_write_relabel_configs: # Drop all metrics with the specified name before sent to New Relic. - source_labels: [__name__] regex: 'metric_name' action: dropYAML ファイル スニペットのサンプル
これらの例のいずれかを、メトリックとラベルの変換セクションから YAML 構成ファイルに追加します。
指標をフィルタリングするには
メトリック ラベルを追加または削除するには
重要
メトリック ラベルの名前は、 Prometheus DataModelに準拠する必要があります。
ターゲット認可構成
一部のターゲットでは、接続しているユーザーがアクセスできるデータを取得するための No-SQL データベースや、メトリック エンドポイントで重要なデータを公開するエクスポーターなど、スクレイピングするためにアクセス承認が必要です。Prometheus でサポートされているすべての認証方法は、 static_targetsセクションとkubernetesセクションで構成できます。
インストール ガイドで説明されているように、YAML に基づいて Prometheus の構成を作成します。構成のこの部分は、YAML からそのまま Prometheus に渡されるため、Prometheus のドキュメントを参照してください。
アクセス許可が必要なターゲットを処理するためのいくつかの例を次に示します。
kubernetes: jobs: - job_name_prefix: skip-verify-on-https-targets target_discovery: pod: true filter: annotations: newrelic.io/scrape: 'true' - job_name_prefix: bearer-token target_discovery: pod: true filter: label: k8s.io/app: my-app-with-token authorization: type: Bearer credentials_file: '/etc/my-app/token'
startic_targets: jobs: - job_name: mtls-target scheme: https targets: - 'my-mtls-target:8181' tls_config: ca_file: '/etc/my-app/client-ca.crt' cert_file: '/etc/my-app/client.crt' key_file: '/etc/my-app/client.key'
- job_name: basic-auth-target targets: - 'my-basic-auth-static:8181' basic_auth: password_file: '/etc/my-app/pass.htpasswd'