web-dev-qa-db-ja.com

検出されたターゲットがない場合のPrometheusアラートルール

発見されたターゲットが見つからなくなったときにアラートを発生させる一般的なルールを記述しようとしています。特に、スクレイピング用に注釈が付けられ、kubernetes_sd_configsを使用して自動検出されたkubernetesポッド。

次の形式の式：absent(up{job="kubernetes-pods"}==1)は、アップ時系列の一部として使用できた追加のラベルを返しません。ポッドが削除された場合（誤って言うと）、そのポッドはターゲットとしてPrometheusから消えます。 absent（）に基づくアラートが発生しますが、どのポッドがなくなったかについての情報はありません。

自動検出されたkubernetesサービスでも同じことが起こると思います。誤って削除してしまうと、監視対象から外れるだけです。動作がtarget_groups（ https://prometheus.io/blog/2015/06/01/advanced-service-discovery/ ）でip範囲と同じかどうかはわかりません-つまり物理ノードがオフになっている場合、メトリックは停止してup == 0は使用できません。

自動検出されたターゲットが一般的な方法でなくなったときに検出する正しい方法は何ですか？または、自動検出された場合でも、各サービス/ノード/ポッドのルールを明示的にハードコードする必要がありますか？

prometheus
6
Budric

または、自動検出された場合でも、各サービス/ノード/ポッドのルールを明示的にハードコードする必要がありますか？

はい、プロメテウスはどこからでもラベルを認識していないため、欠落していることを警告するためのすべての個別のルールが必要です。サービスディスカバリはそれを返しません。

通常のアラートはabsent(up{job="kubernetes-pods"})です

7
brian-brazil

私たちは同じようなことを解決してきました。セットアップ：一部のサービスがどこかで開始されると、一部のメトリックがゼロ以外の値で表示されます。次に、これらのメトリックのいずれかが失われた場合、アラートが必要です。

私たちの場合、それを達成するための適切な表現は

_count (our_metric offset 1h > 0) by (some_name) unless count(our_metric) by (some_name)
_

これは、1時間前には存在していたが現在は存在していないメトリックを含むベクトルを返します。メトリックの値は、LHSのcount(...)です（これも役立つ場合があります）。

どのLHS/RHSも使用できます。 nless演算子の詳細をご覧ください。

6
David