jobの分け方ベストプラクティス - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

jobラベルは何のためにあるか?

jobラベルはターゲットに必ず付いているラベルの1つである。どうこれを使うことができるか?

jobラベルは、ターゲットのリラベルの後でjobラベルがなければ設定項目job_nameが利用されるので、特別である。 このようにしてターゲットは必ずjobラベルを持つことになる。

では、どうやってこれを最大限に活用するべきか? オススメは、同じことをするアプリケーション(これはほぼ常に、同じバイナリを完全に同じ設定で動かしているプロセスのことを意味している)を整理するためにjobラベルを使うことである。 例えば、job="frontend"でwebのフロントエンドがあり、job="redis"でキャッシュとして利用されるRedisがあるとする。 このようなラベルを利用すると、jobに渡って集約することが容易になる。 例えば、jobあたりのCPU利用率はsum by (job)(rate(process_cpu_seconds_total[5m]))となるだろう。 これに対して、Kubernetes上で動くプロセス全てにjob="kubernetes"を付けても特に役に立たない。もっと意味のあるjobラベルを目指すべきである。

もし、異なる目的に対して異なるRedisサーバー群を稼働させているなら、それぞれのサーバー群に対して異なるjobラベルを付けるのが理にかなっているだろう。 それぞれのサーバー群は結局、異なるパフォーマンス特性を持つ可能性が高く、それらを一緒くたに集約して役に立つことは恐らくないだろう。 もし、サーバー群に下位区分(シャーディングなど)があるなら、shardや類似のラベルを追加してジョブを区分するのが多くの場合理に適っている。

避けるべきなのは、プロセスのバイナリと設定のようなもの以上の情報をjobラベルで表現することである。 例えば、本番環境を開発・ステージング環境から区別するには、job="redis_production"とするのではなく、別にenv="production"を付ける方が良いだろう。 これによって、ラベル値に対する正規表現に頼る必要なしに、環境を跨いだ計算が簡単になる。

翻訳元

おすすめ書籍

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム