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をリモートで書き込んだデータを取り込むことでメトリクスが生成されました。
Prometheusの送信バイト数が、データポイントを解凍する直前に我々が記録したリモートライトの圧縮バイト数とほぼ一致していることに注目してほしい。リモートライトの圧縮バイト数のばらつきが大きくなっているのは、分散システムでのデータ処理の性質によるものだと考えられます。
データポイントが解凍されると、5~10倍の拡大率が、データ解凍の直前と直後に測定した「リモートライトの圧縮データバイトレート」と「リモートライトの非圧縮バイトレート」の差に反映されます。
最後に、データが変換され、エンリッチメントが実行されると、リモート書き込みの非圧縮バイトと bytecountestimate()
の違いが以下のようになります。リストされた bytecountestimate()
は、保存される前のデータの最終状態のバイト数の尺度です。
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","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 リファレンス.