多くのメトリックにわたって、多くの時点で使用する、かなり複雑なPromQLクエリには多くのパターンがあります。 たとえば、私はこの記事に基づいていくつかの非常に複雑なクエリを作成しました。
https://about.gitlab.com/blog/2019/07/23/anomaly-detection-using-prometheus/
これらのクエリは再現が非常に難しい場合があり、組織内の新しいユーザーがこれらを理解することはほぼ不可能です。 Prometheusの記録ルールを使用することは、パターンをいつどこで使用するかが必ずしもわからないため、まったく意味がありません。また、すべてのメトリックにルールを適用するにはコストがかかりすぎます。
これらのユースケースを処理するには、Prometheusユーザーがマクロを使用してPrometheusを構成できると便利です。 これらはパラメータ化して、PromQLの新しい部分に拡張できます。 これにより、複雑なクエリをより頻繁に使用することが非常に簡単になります。
これはかなり複雑になる可能性があり、マクロがスタックされるとパフォーマンスの問題が発生する可能性があることを認識しています。 それでも、本当にいいと思います!
例として、クエリの結果がどこかでなくなった場合にアラートを出したいとします。 クエリがこれだとしましょう:
sum by (a,b) (rate(my_metric_count{foo="bar"}[5m]))
これが欠落していることを検出するには、次のクエリを使用できます。
max_over_time((timestamp(
sum by (a,b) (rate(my_metric_count{foo="bar"}[5m]))
))[24h:])
unless
max_over_time((timestamp(
sum by (a,b) (rate(my_metric_count{foo="bar"}[5m]))
))[10m:])
このパターンをマクロとして定義できるようにしたいと思います。これは次のようになります。
macro query_result_becomes_absent(query, search_window, absent_window):
max_over_time((timestamp(
query
))[search_window:])
unless
max_over_time((timestamp(
query
))[absent_window:])
次に、次のようにマクロを呼び出すことができます。
query_result_becomes_absent(
sum by (a,b) (rate(my_metric_count{foo="bar"}[5m])),
24h,
10m)
これらの例がどのようにあなたに何かを節約しているかはわかりません-実際、私にとってはクエリを理解しにくくするだけです。 一般に、これは、構成管理やGrafanaテンプレートなどを介して、Prometheus上で処理するものです。
また、これらのクエリは必要以上に複雑であることに注意してください。
こんにちは、この提案に感謝します。 私はマクロがもたらす利点に完全に同意しますが、同時に、@ brian-brazilが述べたように任意の言語でPromQLの外で同じマクロを作成することができます。 サノスの例では、我々が使用するプロジェクトとしてjsonnet
mixin
アラートなどのリソースを生成するために、ルールやダッシュボードには、例えば(箱から出して!)便利なHTTPクエリとHTTP jsonnet libにこの素晴らしいが、私たちを生成しますこのようなダッシュボード: https :
また、これらのクエリは必要以上に複雑であることに注意してください。
私もそう思います。
これを別の言語で処理することは良い提案です。 私はそれをもっと探求します。
私が共有した例が少しばかげていることに同意します。 異常検出の記事には、はるかに現実的な例がありますが、これは非常に大きな投稿になります。
最も参考になるコメント
これらの例がどのようにあなたに何かを節約しているかはわかりません-実際、私にとってはクエリを理解しにくくするだけです。 一般に、これは、構成管理やGrafanaテンプレートなどを介して、Prometheus上で処理するものです。
また、これらのクエリは必要以上に複雑であることに注意してください。