web-dev-qa-db-ja.com

Prometheus node_exporterメトリック-Grafanaの巨大なスパイク

私たちの設定は次のとおりです。

  • prometheus node_exporter v。0.18.1がサービスとしてインストールされているいくつかのDebian 9.12ノード
  • ノードからメトリックをスクレイピングするPrometheusサーバーv。2.14.0（Windows Server 2016）
  • メトリックを視覚化するGrafana

基本的に、負荷が変動する可能性があるため、詳細をキャプチャしたいので、現在は10秒ごとにメトリックを取得し、Grafanaに次のようなクエリで1分のレートを表示しています。

_rate(node_network_receive_bytes_total{instance=~'$node',device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[1m])*8
_

Grafanaでは、平均的なスループットが100Mbit/s未満のネットワークインスタンスの場合、巨大なスパイクが見られます。スパイクは毎秒数百ギガビットを超えますが、これは明らかに技術的には不可能です。 CPU負荷、CPU待機時間、ディスクIOPS、およびその他の_node_exporter_メトリックでも同じことが起こります。一般的には、平均値と最大値の劇的な違いを確認してください。

network interface spikes

どうやらこれは、Prometheusがデータの単一ポイントを「欠落」しているようであり、rateの動作に基づいて、最後のポイントをゼロと現在の_node_network_receive_bytes_total_を最後の起動以降に累積して比較し、出力を急上昇させるために発生します。 irateに切り替えようとすると、スパイクはさらに高くジャンプするだけで、私たちの推測を証明しているようです。

rateにスパイクが発生している特定の時間範囲のデータポイントをPrometheus収集サーバーに照会すると、ゼロ点は表示されず、「スパイク」時間範囲のデータは連続的に増加しているように見えます。

_node_network_receive_bytes_total{device="ens8",instance="cassandra-xxxxxxxxx0:9100",job="cassandra-xxxxxxxxx"}
3173659836137 @1585311247.489
3173678570634 @1585311257.49
3173696782823 @1585311267.491
3173715943503 @1585311277.492
3173715937480 @1585311277.493
3173731328095 @1585311287.495
3173743034248 @1585311297.502
3173756482486 @1585311307.497
3173775999916 @1585311317.497
3173796096167 @1585311327.498
3173814354877 @1585311337.499
3173833456218 @1585311347.499
3173852345655 @1585311357.501
_

グラフでも同じ：

prometheus graph

rate query rate(node_network_receive_bytes_total{instance="cassandra-xxxxxxxxx0:9100",device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[1m])*8は、同じ時間範囲で驚くほど異なる画像を表示しています：

prometheus rate graph

Prometheusのドキュメントには、欠落しているデータポイントを推定する必要があると記載されていますが、rate/irateの特定の問題は 広く認識されています が、現時点ではかなり混乱しています上記。

私たちの最大の問題は、スパイクによって視覚化が可能になり、さらに重要なことに制限/アラートの設定が不可能になることです。

今のところ、私たちはGrafanaが問題外であり、問​​題が私たちのPrometheus内にあることだけを確信しています。そして、問題は次のようになります。はいの場合、どのように対処しますか？

そうでない場合、おそらくさらに診断的なアプローチを提案できますか？

とにかく、ここまで読んでくださった皆さん、ありがとうございました。

grafanaprometheus
2
Arseny V.
3173715943503 @1585311277.492
3173715937480 @1585311277.493

値は逆方向に進んでおり、カウンターのリセットとして扱われます。これは通常、カーネルのバグを示しますが、値が1ミリ秒しか離れていないことを考えると、これは実際には2つの異なるPrometheusのマージされたデータであるという主要な詳細に言及しなかったことが原因だと思いますサーバー-あなたが発見したように動作しません。

2
brian-brazil