Prometheusリモート書き込みを使用してデータを削除する

保持したくないデータは、YAML構成ファイルのremote_writeセクションを変更することで削除できます。

リモート書き込みインテグレーションからメトリクスデータポイント全体を削除する

ターゲットが、New Relicに送信不要のノイズの多いメトリクスを送信している場合は、New Relicでそのデータを削除するように指定できます。

例

localhost:9100で実行中のインスタンスからnode_memory_active_bytesメトリクスのデータを受信したくないとします。下に示すwrite_relabel_configエントリを使用して、インスタンス名と組み合わせた__name__ラベルを使用して、メトリクス名をターゲットにできます。

remote_write:
- url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=macbook-server-cluster
  bearer_token: <redacted>
  write_relabel_configs:
    - source_labels: ['__name__', 'instance']
      regex: 'node_memory_active_bytes;localhost:9100'
      action: 'drop'

これにより、Prometheusは、これらのラベルを使用してメトリクスに対して何らかのアクションを実行する必要があると伝えます。これらのラベルが影響を受けるメトリクスを制限するには、regexの値を含める必要があります。デフォルトでは、この値は.*に設定され、すべてのメトリクスが含まれます。この場合、リモート書き込みによって、Prometheusから出力されるすべてのメトリクスデータポイントが削除されます。

データポイントから特定のラベルまたは属性を削除する

ターゲットが特定のラベルを送信している、または受信を希望しない属性を送信している場合は、これらを受信するメトリクスから削除できます。

例

ターゲットの1つが、受信したくない属性を多数送信しているとしましょう。これらには、一意のマシン識別子、JVM IDなど、高いカーディナリティ属性などが含まれる場合があります。この場合、YAMLファイルのremote_writeセクションとscrape_configsセクションの両方を変更する必要があります。

結果は、次のようになります。

remote_write:
- url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=macbook-server-cluster
  bearer_token: <redacted>
  write_relabel_configs:
    - regex: 'extraLabelToRemove.*'
      action: 'labeldrop'
...
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any time series scraped from this config.
  - job_name: 'node'
    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9100']
        labels:
          group: 'production'
          keepLabelName1: 'please-keep-me'
          extraLabelToRemove: 'please-remove-me'
          extraLabelToRemove1: 'please-remove-me'
          extraLabelToRemove2: 'please-remove-me'
          extraLabelToRemove4: 'please-remove-me'
          extraLabelToRemove3: 'please-remove-me'
          extraLabelToRemove5: 'please-remove-me'

PrometheusまたはNerdGraphの場合

このページで説明する方法、およびNerdGraphを使用してデータを削除する方法のどちらにも利点があります。このセクションは、特定のニーズや好みに適したメソッドを見つける上で役立ちます。

Prometheus設定ファイルメソッドに関する考慮事項

このメソッドを使用すると、削除されたデータが関連するPrometheusインスタンスを残すことはありません。転送されたバイトがアプリのホスティング側のコスト考慮事項である場合は、貴重な機能になります。

ただし、このメソッドは、次の考慮事項のため、NerdGraphオプションよりも魅力的に欠ける可能性があります。

• 各Prometheusインスタンス（または共有ストレージメカニズム）にロードする必要があるconfig yamlファイルによる管理
• Prometheusサーバーへのアクセスが必要です。つまり、以下のいずれかです。
• • サーバーを再起動する必要がある
• • パス/-/reloadを使用してポートでサーバーにアクセスする必要がある（Prometheus設定ドキュメントで説明しているように、サーバーのライフサイクル管理が有効になっていると仮定します）

NerdGraphメソッドの考慮事項

NerdGraphは、すべてのデータ削除を1か所で管理する場合に最適なオプションです。また、APIを介して簡単に更新でき、再起動またはPrometheusとのインタラクションは不要です。ただし、このメソッドはすべての受信データポイントにルールを適用します。つまり、WHEREフィルタリングを使用して慎重にルールを設定する必要があります。

詳細については、NerdGraphを使用してデータを削除するを参照してください。

もっと詳しく知る

• New RelicのPrometheus Metric Dataに送信
• Prometheus高可用性（HA）