✨ Prometheusの隠れた宝石、honor_labelsを徹底解説

—

こんにちは！今日は、Prometheusを使用する際に遭遇する可能性のある興味深い設定、honor_labelsについて深く掘り下げていきたいと思います。

Prometheusでメトリクスを収集していると、「あれ？設定したラベルが変わってる！」「欲しかったラベルが消えた！」といった経験をすることがあるかもしれません。その秘密の鍵は、honor_labelsにある可能性が高いです！🔑

Prometheusはメトリクスをスクレイプする際、そのメトリクスに関する有用な情報を含めるために、いくつかのラベルを自動的に追加します。最も代表的なものがjobとinstanceラベルです。

しかし、ここで問題が発生する可能性があります。もし、私たちがスクレイプしようとしているターゲットのメトリクスに、すでにjobやinstanceという名前のラベルが存在していたらどうなるでしょうか？🧐

例えば、ターゲットがmy_metric{job="my-app-exporter"}のようなメトリクスを公開しており、Prometheusの設定でこのターゲットをjob_name: 'api-server'としてスクレイプする場合、jobというラベル名が衝突します。

このとき、Prometheusがどのラベルを選択するかを決定するオプションがhonor_labelsです。

この設定はhonor_labelsのデフォルト値です。文字通り、スクレイプ対象のラベルを「尊重しない(false)」という意味で、Prometheusが自動的に付与するラベルが優先されます。

例:
スクレイプ対象メトリクス: http_requests_total{job="frontend"}
Prometheus設定: job_name: 'web-crawlers'
最終スクレイプ結果: http_requests_total{job="web-crawlers", exported_job="frontend", ...}

結果として、Prometheusのjobラベルが優先的に適用され、元々ターゲットが持っていたjobラベルはexported_jobに名前が変更されて保持されます。

この設定をtrueに変更すると、Prometheusは正反対に動作します。「スクレイプ対象のラベルを尊重する(true)」という意味で、スクレイプ対象が提供するラベルをそのまま使用します。

ご覧のように、Prometheusのjob_name設定値である’web-crawlers’は無視され、スクレイプ対象が元々持っていたjob="frontend"がそのまま維持されました。

では、このオプションはどのような場合に役立つのでしょうか？主に以下の状況でその真価を発揮します。

Federation構成時: 他のPrometheusサーバーの/federateエンドポイントをスクレイプする際に使用します。元のPrometheusがすでに意味のあるjob、instanceラベルを持っているため、それらをそのまま取り込みたい場合に不可欠です。
Pushgateway使用時: Pushgatewayは独自にjob、instanceラベルを管理するため、これらのラベルを上書きせずにそのまま使用したい場合に有用です。
サービスディスカバリ活用時: Kubernetesのような環境で、サービスディスカバリを通じて取得したメタデータラベルがPrometheusのjob名よりも重要な意味を持つ場合、そのラベルをjobとして使用したい場合に活用できます。


設定	`honor_labels: false` (デフォルト)	`honor_labels: true`
優先順位	Prometheusの自動追加ラベル 👑	スクレイプ対象(Target)の既存ラベル 👑
衝突時の動作	対象のラベル名の前に`exported_`を追加	Prometheusのラベルを破棄
結果の`job`ラベル	Prometheus設定値 (`job_name`)	スクレイプ対象の元の`job`ラベル値
主な使用箇所	ほとんどの一般的なスクレイプ環境	Federation、Pushgateway、高度なサービスディスカバリ

honor_labelsは、Prometheusのラベリング戦略を繊細に制御できる強力なツールです。このオプションをよく理解し活用して、よりクリーンで意味のあるメトリクスを管理しましょう！🚀

Comments