特に明記されていない限り、Prometheus OpenMetrics インテグレーションとNew Relicの設定オプションは、 docker環境とKubernetes環境の両方に適用されます。 少なくとも、次の設定値はrequiredです。
推奨事項: New Relicライセンスキーを LICENSE_KEY という名前の環境変数として構成します。 これにより、New Relic は相互 TLS 認証シークレットから環境変数を読み込むことができるため、より安全な環境が提供されます。
nri-prometheus-latest.yamlの設定 
nri-prometheus-latest.yamlマニフェストファイルには、設定例を示すnri-prometheus-cfgマップが含まれています。マニフェストファイルを使用して、次のパラメータを設定します。
以下は構成ファイルの例で、保存して必要に応じて変更することができます。詳細については、 相互TLS認証 および PromQLからNRQLへの変換 に関するドキュメントを参照してください。
cluster_name: "YOUR_CLUSTER_NAME"
insecure_skip_verify: false
scrape_enabled_label: "prometheus.io/scrape"
require_scrape_enabled_label_for_nodes: true
ここでは、Prometheus OpenMetricsの設定ファイルの主要な名称と定義を紹介します。
| キー名 | 説明 | 
|---|
| cluster_name
 Required. | クラスターの名前。この値は、すべてのメトリックのclusterName属性として含まれます。 | 
| verbose
 | 文字列化されたブーリアンです。 true(デフォルト):デバッグ情報をログに記録します。false:エラーメッセージのみをログに記録します。
 | 
| targets
 | インテグレーションによってスクレイピングされる静的エンドポイントの設定。オブジェクトのリストを含んでいます。この構造についての詳細は、 target configuration に関するドキュメントを参照してください。 | 
| scrape_enabled_label
  Kubernetes | 文字列です。統合は、Kubernetesポッドとサービスがアノテーションされているか、この値のラベルを持っているかどうかをチェックして、スクレイピングする必要があるかどうかを判断します。 これは、メトリクスを無視したり、New Relic に送信される特定のメトリクスを含めたりして、データ量を制限したい場合に特に有効です。デフォルトでは、Prometheusがスクレイピング可能なターゲットを発見するために使用するのと同じラベルを使用しているので、インストールしたほとんどのエクスポーターは自動的にこのラベルを設定します。 統合でスクレイプするターゲットをきめ細かく制御するには、このオプションを他の値( newrelic/scrapeなど)に設定してから、アノテーションまたはラベルnewrelic/scrape: "true"をKubernetesオブジェクトに追加します。両方が設定されている場合、注釈はラベルよりも優先されます。 デフォルト: "prometheus.io/scrape" | 
| scrape_duration
 | スクレーパーはどのくらいの頻度で稼働させればいいのでしょうか。 メモリ使用量を少なくするには、この値を大きくします。メモリ使用量を増やすには、この値を減らします。 メモリ使用量への影響は、すべてのデータを一度に照会(およびバッファリング)しないように、ターゲットのフェッチをスクレイプ間隔に分散させているためです。 デフォルトは30sです。有効な値には、1s、15s、30s、1m、5mなどがあります。
 | 
| scrape_timeout
 | エンドポイントからデータを取得する際のHTTPクライアントのタイムアウトです。 デフォルト: 5s。有効な値には、1s、15s、30s、1m、5mなどがあります。 | 
| worker_threads
 | ターゲットのスクレイピングに使用されるワーカースレッドの数。ターゲットの数が多い環境やレイテンシーの高いターゲットでは増やすことができますが、メモリ消費量が増える可能性があります。 デフォルト: 4。 10を超える使用はお勧めしません。 | 
| require_scrape_enabled_label_for_nodes
  Kubernetes | Kubernetesノードがスクレイピングにラベルを必要とするかどうか。 デフォルト: true。 | 
| percentiles
 | ヒストグラムのサポートは、 New Relic's guidelines for higher level metrics abstractions に基づいています。 このデータの視覚化をより適切にサポートするために、パーセンタイルはヒストグラムメトリックに基づいて計算され、NewRelicに送信されます。有効な値には、 50、95、および99が含まれます。 | 
| emitter_proxy
 | メトリクスを送信する際に統合が使用するプロキシ。 [scheme]://[domain]:[port]
 このプロキシは、ターゲットからメトリクスを取得する際には使用されません。 デフォルトでは、これは空で、プロキシは使用されません。 | 
| emitter_ca_file
 | エミッタがサーバ証明書を検証する際に使用するルートCAに追加する証明書。空の場合、TLSはホストのルートCAセットを使用する。 | 
| emitter_insecure_skip_verify
 | データを送信するときにエミッターがTLS検証をスキップする必要があるかどうか。デフォルト: false。 | 
| disable_autodiscovery
 | k8sクラスターで自動検出を無効にするには、trueに設定します。権限が制限されているサービスアカウントでポッドを実行する場合に便利です。デフォルト: false。 | 
ターゲットキーにオブジェクトを設定 
設定ファイルのターゲットキーに1つ以上のオブジェクトを含める場合は、YAMLリストに以下の構造を使用します。
| キー名 | 説明 | 
|---|
| description
 | このターゲット内のURLの説明です。 | 
| urls
 | スクレイピングされるURLを含む文字列のリスト。 | 
| tls_config
 | リクエストを送信する際に使用する認証設定です。TLSとMutual TLSに対応しています。詳細は、 相互TLS認証に関するドキュメント を参照してください。 | 
NewRelicのPrometheusOpenMetrics統合は、スクレイプするターゲットを自動的に検出します。ターゲットを構築するときに使用するポートとエンドポイントパスを指定するには、Kubernetesポッドとサービスでprometheus.io/portとprometheus.io/pathのアノテーションまたはラベルを使用できます。注釈はラベルよりも優先されます。
- prometheus.io/portが存在しない場合、統合はサービスに対して定義された各- portまたは- ContainerPortをスクレイプしようとします。
- prometheus.io/pathが存在しない場合、統合はデフォルトで- /metricsになります。
- サービスがデフォルトの/my-metrics-pathパスで実行されていない場合は、ポッドprometheus.io/path=my-metrics-pathにラベルを追加します。メトリックエンドポイントへのパスがより複雑で、有効なラベル値(たとえば、foo/bar)にできない場合は、代わりにアノテーションを使用してください。
この例では、クラスターにデプロイがあり、ポッドはポート8080とパスでPrometheusメトリックを公開します my-metrics.
デプロイメントマニフェストのPodSpecメタデータで、ラベルprometheus.io/port: "8080"とprometheus.io/path: "my-metrics"を設定します。統合がポッドからメトリックを取得しようとすると、 http://<pod-ip>:8080/my-metricsにリクエストが送信されます。
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
        prometheus.io/path: "my-metrics"
サービスとエンドポイントのスクレイプ動作
デフォルトでは、 scrape_servicesはtrueに設定され、 scrape_endpointsはfalseに設定されているため、サービスは基になるエンドポイントではなく直接スクレイピングされます。
この動作を変更するには、 scrape_endpointsをtrueに設定し、直接サービスではなく、Prometheusサーバーがネイティブに行うように、基になるエンドポイントをスクレイプするようにPrometheus OpenMetrics integrationsを構成します。
クラスタ内のサービスの背後にあるエンドポイントの数に応じて、負荷と取り込まれるデータが大幅に増加する可能性があることに留意し、監視し、必要に応じてリソース要件を増加させてください。
さらに、下位互換性を確保するためにscrape_servicesとscrape_endpointsの両方をtrueに設定できる場合でも、データが重複する可能性があります。
設定の再読み込み 
Prometheus OpenMetrics インテグレーションdoes notは、設定ファイルに変更を加えると、設定を自動的に再読み込みします。

Docker
設定を再読み込みするには、統合を実行しているコンテナを再起動します。
$docker restart nri-prometheus
 

Kubernetes
設定を再読み込みするには、インテグレーションを再起動してください。 推奨事項: デプロイメントをレプリカ 0 個までスケールダウンし、その後レプリカ 1 個までスケールバックします。
$kubectl scale deployment nri-prometheus --replicas=0
 $kubectl scale deployment nri-prometheus --replicas=1
 
Dockerです。以前の設定ファイルの実行 

Docker:以前の設定ファイルを使用してインテグレーションを実行するには:
- コンテンツをコピーして、 - config.yamlファイルに保存します。
 
- 同じディレクトリ内で、コマンドを実行します。 - $- docker run -d --restart unless-stopped \ 
 - >-     --name nri-prometheus \ 
 - >-     -e CLUSTER_NAME="YOUR_CLUSTER_NAME" \ 
 - >-     -e LICENSE_KEY="YOUR_LICENSE_KEY" \ 
 - >-     -v "$(pwd)/config.yaml:/config.yaml" \ 
 - >-     newrelic/nri-prometheus:latest --configfile=/config.yaml