Prometheus 3.0 の発表
2024年11月14日筆者: Prometheus チーム
ベルリンで開催されたPromConでのPrometheus 3.0 Beta版のリリースに続き、PrometheusチームはPrometheusバージョン3.0の即時リリースを発表できることを嬉しく思います！
この最新バージョンは、7年ぶりのメジャーリリースとして、重要な節目となります。この間、Prometheusは大きく進化し、初期導入者向けのプロジェクトから、クラウドネイティブ監視スタックの標準的な一部となりました。Prometheus 3.0は、いくつかのエキサイティングな新機能を追加しつつ、以前のバージョンとの安定性と互換性をほぼ維持することで、その道のりを継続することを目指しています。
3.0リリースでは、ベータ版にいくつかの新機能が追加されたほか、本文で説明するいくつかの破壊的変更も導入されています。
新機能
ベータ版でリリースされたエキサイティングな変更点の概要と、それ以降に追加された内容を以下に示します。
新しいUI
Prometheus 3.0のハイライトの1つは、デフォルトで有効になっている全く新しいUIです。
UIは完全に書き直され、 clutter が減り、よりモダンなルック＆フィール、PromLens スタイルのツリービューのような新機能が追加され、よりモダンな技術スタックを使用することで将来のメンテナンスが容易になります。
新しいUI全般については、Julius の PromLabs ブログの詳細記事 を参照してください。ユーザーは old-ui 機能フラグを使用することで、古いUIを一時的に有効にすることができます。
新しいUIはまだ実運用でテストされていないため、バグが存在する可能性も十分にあります。もし見つけた場合は、GitHubで報告してください。
ベータ版以降、UIはUTF-8のメトリック名とラベル名に対応するように更新されました。
Remote Write 2.0
Remote-Write 2.0 は、メタデータ、エクサン プル、作成タイムスタンプ、ネイティブヒストグラムなど、多くの新しい要素のネイティブサポートを追加することで、以前のプロトコルバージョンを改良しています。また、文字列インターニングを使用して、圧縮および解凍時のペイロードサイズとCPU使用量を削減しています。部分的な書き込みに対してより良い処理を提供し、クライアントに詳細情報を提供します。詳細については、こちらをご覧ください。
UTF-8 サポート
Prometheus は、バージョン2.xで可能だったように、デフォルトですべての有効なUTF-8文字をメトリック名、ラベル名、およびラベル値に使用できるようになりました。
ユーザーは、メトリックプロデューサーがUTF-8名を渡すように設定されていることを確認する必要があります。どちらかの側がUTF-8をサポートしていない場合、メトリック名は従来のアンダースコア置換方法を使用してエスケープされます。PromQLクエリは、UTF-8メトリックを取得するために新しい引用符構文で記述するか、ユーザーは __name__ ラベル名を手動で指定できます。
現在、UTF-8をサポートするように更新されているのはGoクライアントライブラリのみですが、他の言語のサポートも間もなく追加される予定です。
OTLP サポート
OpenTelemetry へのコミットメントに沿って、Prometheus 3.0 は OpenTelemetry との相互運用性を向上させるためのいくつかの新機能を提供します。
OTLP取り込み
Prometheus は、OTLP Metrics プロトコルのネイティブレシーバーとして設定でき、/api/v1/otlp/v1/metrics エンドポイントで OTLP メトリクスを受信します。
Prometheus への OTLP メトリックトラフィックの取り込みに関するベストプラクティスについては、ガイドを参照してください。
UTF-8 正規化
Prometheus 3.0 では、UTF-8 サポートのおかげで、ユーザーは、ドットをアンダースコアに変更する のような煩わしい変更なしに、OpenTelemetry メトリクスを保存およびクエリできます。
特に、これにより、OpenTelemetry セマンティック規約または SDK で定義されたものと、実際にクエリ可能なものの間の不一致に関して、ユーザーとツールの**混乱が少なくなります**。
これを OTLP 取り込みで実現するために、Prometheus 3.0 はさまざまな変換戦略の実験的なサポートを提供します。詳細については、Prometheus 設定のotlp セクションを参照してください。
注「NoUTF8EscapingWithSuffixes」戦略は特殊文字を許可しますが、最良の体験のために必要なサフィックスを追加します。Prometheus におけるサフィックスなしを可能にする将来の作業に関する提案を参照してください。
ネイティブヒストグラム
ネイティブヒストグラムは、従来のヒストグラムよりも効率的でコストの低い代替手段を提供する Prometheus のメトリックタイプです。データセットに基づいてバケット境界を選択（および更新）する必要がある代わりに、ネイティブヒストグラムには指数関数的な成長に基づいた事前設定されたバケット境界があります。
ネイティブヒストグラムはまだ実験的であり、デフォルトでは有効になっていません。--enable-feature=native-histograms を渡すことで有効にできます。ネイティブヒストグラムのテキスト形式やアクセサ関数/演算子などの一部の側面は、まだ活発に設計中です。
破壊的変更
Prometheus コミュニティは、メジャーリリース内での既存機能の破壊を避けるように努めています。新しいメジャーリリースでは、長年にわたるいくつかの小さな問題をクリーンアップする機会を得ました。つまり、Prometheus 3.0 にはいくつかの破壊的変更が含まれています。これには、機能フラグ、設定ファイル、PromQL、およびスクレイピングプロトコルの変更が含まれます。
設定が影響を受けるかどうか、およびどのような措置を講じる必要があるかについては、移行ガイドをお読みください。
パフォーマンス
Prometheus 2.0以降、コミュニティが達成したことを目の当たりにするのは印象的です。私たちは皆、数字が好きなので、TSDBモードのCPUとメモリ使用量の両方における効率改善を祝いましょう。以下は、8CPUと49GBの割り当て可能メモリを持つノードでの3つのPrometheusバージョン間のパフォーマンス数値です。
- 2.0.0（7年前）
- 2.18.0（4年前）
- 3.0.0（現在）
さらに印象的なのは、これらの数値が、同じPromQLクエリ、設定、環境を使用するprombench マクロベンチマークで取得されたことです。これは、3.0であっても、コア機能の互換性と安定性を強調しています。
今後
Prometheus およびエコシステムには、まだたくさんのエキサイティングな機能と改善の余地があります。以下は、皆様を興奮させ、...そして貢献して参加する意欲を掻き立てることを願う、網羅的ではないリストです！
- 新しい、より包括的なガバナンス
- より多くのOpenTelemetry互換性と機能
- OpenMetrics 2.0、現在はPrometheusガバナンス下！
- ネイティブヒストグラムの安定性（カスタムバケット付き！）
- さらなる最適化！
- より多くのSDKとツールでのUTF-8サポートカバー
試してみてください！
Prometheus 3.0 は、公式バイナリとコンテナイメージ からダウンロードして試すことができます。
Prometheus 2.x からアップグレードする場合、必要な調整については移行ガイドを確認してください。v3.0 にアップグレードする前に v2.55 にアップグレードすることを強く推奨します。v3.0 から v2.55 へのロールバックは可能ですが、それ以前のバージョンへのロールバックはできません。
いつものように、コミュニティからのフィードバックと貢献を歓迎します！