• /
  • EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

Prometheusのリモートライトデータの送信バイト数と請求バイト数の比較

Prometheus のリモートライトからの請求バイトのサイズは、New Relic に送信されるバイトよりも大きくなることがあります。この違いに驚かないためにも、データ圧縮が課金バイトにどのように影響するかを確認することをお勧めします。

データ圧縮と課金の理解

Prometheus のリモート書き込みデータは、New Relic に送信されます 圧縮されています より速く、ロスレスで送信されます。インジェストされたデータは圧縮解除され、 エンティティ合成 などの New Relic の機能で適切に使用できるように装飾されます。圧縮時と非圧縮時のバイトレートには差があることが予想されますが、Prometheus Remote Write データの潜在的な差は、New Relic の 課金モデル のために重要です。

課金は、データの取り込みに必要な計算量と、New Relicに保存されたデータのサイズに基づいて行われます。解凍プロセスとデータ変換により、最終的に保存される非圧縮のバイト数は、圧縮されたバイト数の約15倍になります。

たとえば、実際の交通をシミュレートする際に収集した時系列データのサンプリングに基づくと、次のような結果になる場合があります。

~124 GB/day compressed data sent = ~1.86TB uncompressed data stored

以下は、Prometheus の読み書きデータが我々のシステムを通過する際のバイトレートの変化をシミュレーションしたものです。このケースでは、ローカルのPrometheusサーバーがローカルのnode-exporterをリモートで書き込んだデータを取り込むことでメトリクスが生成されました。

Byte rate estimate total comparison

Prometheusの送信バイト数が、データポイントを解凍する直前に我々が記録したリモートライトの圧縮バイト数とほぼ一致していることに注目してほしい。リモートライトの圧縮バイト数のばらつきが大きくなっているのは、分散システムでのデータ処理の性質によるものだと考えられます。

Sent vs. compressed bytes comparison

データポイントが解凍されると、5~10倍の拡大率が、データ解凍の直前と直後に測定した「リモートライトの圧縮データバイトレート」と「リモートライトの非圧縮バイトレート」の差に反映されます。

Uncompressed vs. compressed bytes comparison

最後に、データが変換され、エンリッチメントが実行されると、リモート書き込みの非圧縮バイトと bytecountestimate() の違いが以下のようになります。リストされた bytecountestimate() は、保存される前のデータの最終状態のバイト数の尺度です。

Bytecountestimate() vs. uncompressed bytes comparison

Prometheus の読み取り/書き込みデータが通過する可能性のあるデータ変換/追加をよりよく理解するために、Prometheus サーバーによって報告される測定値であるprometheus_remote_storage_bytes_totalメトリックの比較を次に示します。

1つ目はPrometheusが提供する表現、2つ目はNRQLクエリの対応です。

Prometheusサーバーの表現。

"prometheus_remote_storage_bytes_total" {
"instance=""localhost:9090"
"job=""prometheus"
"remote_name=""5dfb33"
"url=""https://staging-metric-api.newrelic.com/prometheus/v1/write?prometheus_server=foobarbaz"
}
23051

NRQLクエリの表現

{
"endTimestamp": 1631305327668,
"instance": "localhost:9090",
"instrumentation.name": "remote-write",
"instrumentation.provider": "prometheus",
"instrumentation.source": "foobarbaz",
"instrumentation.version": "0.0.2",
"job": "prometheus",
"metricName": "prometheus_remote_storage_bytes_total",
"newrelic.source": "prometheusAPI",
"prometheus_remote_storage_bytes_total": {
"type": "count",
"count": 23051
},
"prometheus_server": "foobarbaz",
"remote_name": "5dfb33",
"timestamp": 1631305312668,
"url": "https://staging-metric-api.newrelic.com/prometheus/v1/write?prometheus_server=foobarbaz"
}

ヒント

上記の例は、基本的なコンセプトを説明するために単純化した比較であり、ラベリングや特徴的なメトリクスを平均よりも軽く使用しています。実際のバージョンでは、より複雑であるため、少し違って見えるでしょう。

NRQLを使ってデータ数を照会する

以下の NRQL クエリ をチェックして、バイトカウント情報を収集します。

New Relicに保存されている推定バイト数を表示します。

FROM Metric SELECT rate(bytecountestimate(), 1 minute) AS 'bytecountestimate()'
WHERE prometheus_server = INSERT_PROMETHEUS_SERVER_NAME SINCE 1 hour ago TIMESERIES AUTO

New Relicに送信されるPrometheusのバイトを監視する。

FROM Metric SELECT rate(sum(prometheus_remote_storage_bytes_total), 1 minute) AS 'Prometheus sent bytes rate'
WHERE prometheus_server = INSERT_PROMETHEUS_SERVER_NAME SINCE 1 hour ago TIMESERIES AUTO

外部参照

圧縮とエンコーディングについて説明しているPrometheusやGitHubのドキュメントへの外部リンクを紹介します。

  • Prometheus referencing Snappy Compression being used in encoding: 読み取りプロトコルと書き込みプロトコルは、どちらも HTTP 上で snappy-compressed protocol buffer encoding を使用しています。このプロトコルはまだ安定した API とはみなされておらず、将来的には、Prometheus とリモートストレージ間のすべてのホップが HTTP/2 をサポートしていると安全に想定できるようになった時点で、HTTP/2 上の gRPC を使用するように変更される可能性があります。

  • Prometheus Protobuf リファレンス.

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.