この記事では、いくつかの新機能とそれがPrometheusコミュニティに与えるであろう影響を分析します。ここでは、編集部のおすすめを紹介します。
#10641 新しいリラベルアクション
この新しいバージョンでは、メトリクスの値を大文字または小文字に変更する2つの新しいアクションを使用することができます。これは、例えば、標準に従わないメトリクス名において重要です。また、IONOS Cloudで発見された新しいサービスで、一部のラベルを大文字で提供していた問題が修正されています。コード例です：
relabel_configs:
- action: uppercase
source_labels: [instance]
target_label: instanceDavid Lorite – Integrations Engineer at Sysdig
#10682 prometheus_readyの新しいメトリクス
他のPrometheusを監視するPrometheusで構成される古典的なアーキテクチャーがあります。その目的は、メインの監視サーバの誤動作を検出し、監視者の監視者になることです。この新しいバージョンでは、新しいメトリクスとしてprometheus_readyが導入されました。これは、すでにあるupメトリックに加わるものです。違いは、 up はPrometheusサーバーが稼働しているときに監視し、 prometheus_ready は再起動後にWALが処理されて新しいメトリクスが取り込まれ始めたときに監視する点です。このメトリクスは、データの損失やアラートがトリガーされないことを意味する遅い起動の監視に便利です。次のように、それを監視するアラートを作成することができます。
prometheus_ready = 0
Nikola Milikic – Software Engineer at Sysdig
#9638 サーバモードとエージェントモードの識別
コミュニティがPrometheusをエージェントモードで使用する機能を発表してから、もう6ヶ月以上が経ちました。これは、ローカルのPrometheusがデータを保存せず、リモートライトで時系列をリモートエンドポイントに送信することを意味します。この新しいモードは、牽引力を増し、成熟しつつあります。その良い例が、今回のリリースから、Prometheusがサーバーモード(Prometheus Server) で動作しているか、エージェントモード (Prometheus Agent)で動作しているかをログに明記するようになったことです。このモードに関する情報を新しいメトリクスとして追加するのは面白いのではないか、という議論もあります。次のリリースでは、このあたりの動きがもっと出てくるでしょう。
Carlos Adiego – Integrations Engineer at Sysdig
#10714, #10514, #10673 サービス検出の改善
Prometheus 2.35で見たように、Prometheusのサービスディスカバリーと異なるクラウドプロバイダーとの統合は、ベンダーにとって優先事項となっています。ベンダーはPrometheusとのネイティブかつ公式な互換性を顧客に提供することができます。しかし、オープンソースのPrometheusのメンテナーは、開発者がこれらの新しい統合を提供するために必要なテストを実装し、実行するのを助けるために、良い努力をしています。新たに追加されたサービス発見は、Vultr (#10714) と IONOS Cloud (#10514) のためのものです。
また、前回のリリースで見たAzureの障害をカウントするメトリクスの実装 (
prometheus_sd_azure_failures_total)に続き、今回はLinodeサービス検出用の新しいメトリクス prometheus_sd_linode_failures_totalが利用可能になりました。ここでは、Linodeサービスディスカバリーの失敗を検出する方法についてのアラート例を示します。
rate(prometheus_sd_linode_failures_total[5m]) > 0
Jesús Ángel Samitier – Integrations Engineer at Sysdig
これらは私たちのチームによって選ばれた新機能ですが、他にもまだまだあります。Prometheus 2.36の公式リリースノートで変更点の全リストを見ることができます。