Bartek Płotka は 2019 年から Prometheus のメンテナーであり、Red Hat のプリンシパルソフトウェアエンジニアです。CNCF Thanos プロジェクトの共同著者。CNCF アンバサダーであり、CNCF TAG Observability の技術リードです。自由時間には、O'Reilly と共に「Efficient Go」というタイトルの本を執筆しています。意見は私個人のものです！
私が Prometheus プロジェクトで個人的に気に入っている点、そして私がチームに加わった多くの理由の一つは、プロジェクトの目標にレーザーのように集中していることです。Prometheus は常に、実用的で信頼性が高く、安価でありながら、非常に貴重なメトリックベースの監視を提供するという点で、限界を押し広げてきました。Prometheus の非常に安定した堅牢な API、クエリ言語、および統合プロトコル（例: リモート書き込みおよび OpenMetrics）により、Cloud Native Computing Foundation (CNCF) のメトリックエコシステムは、これらの強力な基盤の上に成長することができました。その結果、素晴らしいことが起こりました。
- コンテナ(https://github.com/google/cadvisor)、eBPF(https://github.com/cloudflare/ebpf_exporter)、Minecraft サーバー統計(https://github.com/sladkoff/minecraft-prometheus-exporter)や、ガーデニング時の植物の健康状態(https://megamorf.gitlab.io/2019/07/14/monitoring-plant-health-with-prometheus/)など、ほぼすべてのメトリックを取得するためのコミュニティエクスポーターを見ることができます。
- 今日、ほとんどの人は、クラウドネイティブソフトウェアが、Prometheus がスクレイピングできる HTTP/HTTPS
/metricsエンドポイントを持つことを期待しています。Google 内で秘密裏に開発され、Prometheus プロジェクトによってグローバルに先駆的に開発された概念です。 - 可観測性のパラダイムは変化しました。SRE や開発者が、ソフトウェアの回復力、デバッグ可能性、およびデータ駆動型の意思決定を改善するために、初日からメトリックに大きく依存していることがわかります！
結局のところ、Prometheus が稼働していない Kubernetes クラスターはほとんど見られません。
Prometheus コミュニティの強力な焦点により、他のオープンソースプロジェクトも成長し、Prometheus のデプロイモデルを単一ノードを超えて拡張することができました（例: Cortex、Thanosなど）。クラウドベンダーが Prometheus の API とデータモデルを採用していること（例: Amazon Managed Prometheus、Google Cloud Managed Prometheus、Grafana Cloud など）は言うまでもありません。Prometheus プロジェクトがこれほど成功している唯一の理由を探しているのであれば、それは次の点です。監視コミュニティを重要なことに集中させること。
この（長文の）ブログ投稿では、Prometheus の新しい動作モードである「エージェント」を紹介したいと思います。これは Prometheus バイナリに直接組み込まれています。エージェントモードでは、Prometheus の通常の機能の一部が無効になり、スクレイピングとリモートロケーションへのリモート書き込みのためにバイナリが最適化されます。機能数を減らすモードを導入することで、新しい使用パターンが可能になります。このブログ投稿では、それが CNCF エコシステムにおける特定のデプロイメントにとってなぜゲームチェンジャーであるのかを説明します。これについて非常に興奮しています！
転送ユースケースの歴史
Prometheus のコア設計は、プロジェクトの全期間にわたって変更されていません。Google の Borgmon 監視システムに触発されて、監視したいアプリケーションと一緒に Prometheus サーバーをデプロイし、Prometheus にそれらに到達する方法を伝え、定期的にメトリックの現在の値をスクレイピングできるようにすることができます。多くの場合「プルモデル」と呼ばれるこのような収集方法は、Prometheus を軽量で信頼性の高いものにするコア原則です。さらに、複雑なプッシュインフラストラクチャと重要でないクライアントライブラリなしで、現在のすべての追跡メトリックの値（OpenMetrics 形式）を備えた単純な人間が読める HTTP エンドポイントを提供する必要があるため、アプリケーションのインストルメンテーションとエクスポーターが非常にシンプルになります。全体として、簡素化された典型的な Prometheus 監視デプロイメントは次のようになります。
これは非常にうまく機能しており、何千万ものアクティブなシリーズを処理するこのような何百万ものデプロイメントが長年にわたって成功していることがわかっています。それらのいくつかは、約 2 年間のような長期保持のためです。すべて、クラスター管理者と開発者の両方に役立つメトリックをクエリ、アラート、記録できます。
ただし、クラウドネイティブの世界は常に成長し進化しています。マネージド Kubernetes ソリューションの成長と、数秒以内にオンデマンドで作成されるクラスターにより、私たちはついにクラスターを「ペット」ではなく「家畜」として扱うことができるようになりました（言い換えれば、それらの個々のインスタンスについてはあまり気にしなくなりました）。場合によっては、ソリューションにはクラスターの概念すらなくなっています。例: kcp、Fargate、その他のプラットフォーム。
もう 1 つの興味深いユースケースは、エッジクラスターまたはネットワークの概念です。電気通信、自動車、IoT デバイスなどの業界がクラウドネイティブテクノロジーを採用するにつれて、リソース量が制限された非常に小さなクラスターがますます増えています。これにより、ほぼすべてのデータ（可観測性を含む）は、それらのリモートノードには何も保存できないため、リモートのより大きな対応するものに転送されることを余儀なくされています。
それはどういう意味ですか？それは、監視データを何らかの方法で集約し、ユーザーに提示し、場合によってはグローバルレベルで保存する必要があることを意味します。これは多くの場合、グローバルビュー機能と呼ばれます。
素朴に考えると、グローバルレベルに Prometheus を配置し、リモートネットワーク間でメトリックをスクレイピングするか、監視目的でアプリケーションから中央ロケーションにメトリックを直接プッシュすることでこれを実装することを考えることができます。どちらも一般的に非常に悪い考えである理由を説明させてください。
🔥 ネットワーク境界を越えたスクレイピングは、監視パイプラインに新しい未知の要素を追加する場合、課題になる可能性があります。ローカルプルモデルを使用すると、Prometheus はメトリックターゲットに問題がある理由と時期を正確に把握できます。ダウンしている、誤って構成されている、再起動された、メトリックを提供するには遅すぎる（例: CPU が飽和状態）、サービス検出で検出できない、アクセスするための資格情報がない、または DNS、ネットワーク、またはクラスター全体がダウンしている可能性があります。ネットワークの外にスクレイパーを配置すると、個々のターゲットとは関係のないスクレイピングに信頼性がなくなることで、この情報の一部を失うリスクがあります。それに加えて、ネットワークが一時的にダウンしている場合は、重要な可視性を完全に失うリスクがあります。それをするのはやめてください。それは価値がありません。（
🔥 アプリケーションから中央ロケーションにメトリックを直接プッシュすることも同様に悪いことです。特に、より大きなフリートを監視する場合、リモートアプリケーションからのメトリックが表示されない場合、文字通り何もわかりません。アプリケーションはダウンしていますか？レシーバーパイプラインはダウンしていますか？アプリケーションの認証に失敗した可能性がありますか？リモートクラスターの IP アドレスを取得できなかった可能性がありますか？遅すぎますか？ネットワークがダウンしていますか？さらに悪いことに、一部のアプリケーションターゲットからのデータが欠落していることさえ知らない可能性があります。そして、データを送信する必要があるすべての状態とステータスを追跡する必要があるため、あまり得られません。このような設計は、簡単に失敗につながる可能性があるため、慎重な分析が必要です。
注: サーバーレス関数と短命のコンテナは、アプリケーションからのプッシュをレスキューと考えることが多いケースです。ただし、この時点では、より長期の時系列に集約したいイベントまたはメトリックの一部について説明します。このトピックについてはこちらで説明されています。お気軽にご意見をお寄せいただき、これらのケースをより適切にサポートできるようにご協力ください！
Prometheus は、グローバルビューケースをサポートする 3 つの方法を導入しました。それぞれに長所と短所があります。それらを簡単に見ていきましょう。それらは下の図でオレンジ色で示されています。
- フェデレーションは、集約目的で最初に導入された機能です。これにより、グローバルレベルの Prometheus サーバーは、リーフ Prometheus からメトリックのサブセットをスクレイピングできます。このような「フェデレーション」スクレイピングは、フェデレーションエンドポイントによって公開されるメトリックに元のサンプルのタイムスタンプが含まれているため、ネットワーク間の未知の要素を減らします。ただし、通常は、すべてのメトリックをフェデレーションできず、ネットワークパーティション（数分）の長い間、データを失うという問題があります。
- Prometheus リモート読み取りでは、直接 PromQL クエリを使用せずに、リモート Prometheus サーバーのデータベースから生のメトリックを選択できます。グローバルレベルで Prometheus またはその他のソリューション（例: Thanos）をデプロイして、このデータに対して PromQL クエリを実行しながら、複数のリモートロケーションから必要なメトリックをフェッチできます。これは、データを「ローカル」に保存し、必要な場合にのみアクセスできるため、非常に強力です。残念ながら、短所もあります。クエリプッシュダウンのような機能がないと、極端な場合には、単一のクエリに答えるために GB 単位の圧縮メトリックデータをプルしています。また、ネットワークパーティションがある場合、一時的に見えなくなります。最後に、特定のセキュリティガイドラインでは、送信トラフィックのみが許可されており、受信トラフィックは許可されていません。
- 最後に、Prometheus リモート書き込みがあります。これは、今日最も人気のある選択肢であるようです。エージェントモードはリモート書き込みのユースケースに焦点を当てているため、詳細に説明しましょう。
リモート書き込み
Prometheus リモート書き込みプロトコルを使用すると、Prometheus によって収集されたすべてのメトリックまたはメトリックのサブセットをリモートロケーションに転送（ストリーミング）できます。リモート書き込み API をサポートする 1 つ以上のロケーションに、一部のメトリック（必要に応じて、すべてのメタデータとエグゼンプラー付きで！）を転送するように Prometheus を構成できます。実際、Prometheus はリモート書き込みの取り込みと送信の両方をサポートしているため、グローバルレベルで Prometheus をデプロイして、そのストリームを受信し、クラスター間でデータを集約できます。
公式のPrometheus リモート書き込み API 仕様はレビュー段階にありますが、エコシステムはリモート書き込みプロトコルをデフォルトのメトリックエクスポートプロトコルとして採用しました。たとえば、Cortex、Thanos、OpenTelemetry、および Amazon、Google、Grafana、Logz.io などのクラウドサービスはすべて、リモート書き込みを介したデータの取り込みをサポートしています。
Prometheus プロジェクトは、API の公式コンプライアンステストも提供しています。例: リモート書き込みクライアント機能を提供するソリューション用のリモート書き込み送信者コンプライアンスです。このプロトコルを正しく実装しているかどうかをすばやく知るための素晴らしい方法です。
このようなスクレイパーからのデータをストリーミングすることで、メトリックデータを集中ロケーションに保存できるため、グローバルビューのユースケースが可能になります。これにより、関心の分離も可能になり、アプリケーションが可観測性または監視パイプラインとは異なるチームによって管理されている場合に役立ちます。さらに、ベンダーが顧客からの作業をできるだけ多くオフロードしたい場合にリモート書き込みが選択される理由でもあります。
ちょっと待って、Bartek。以前、アプリケーションからメトリックを直接プッシュすることは最良のアイデアではないと言ったばかりです！
確かにそうですが、驚くべき部分は、リモート書き込みでも、Prometheus は依然としてプルモデルを使用してアプリケーションからメトリックを収集し、それらのさまざまな障害モードを理解できるようにしていることです。その後、サンプルとシリーズをバッチ処理し、リモート書き込みエンドポイントにデータをエクスポート、レプリケート（プッシュ）し、中央ポイントが持つ監視の未知数を制限します！
信頼性が高く効率的なリモート書き込みの実装は、解決すべき簡単な問題ではないことに注意することが重要です。Prometheusコミュニティは、安定したスケーラブルな実装を考案するために約3年を費やしました。私たちはWAL（先行書き込みログ）を数回再実装し、内部キューイング、シャーディング、スマートバックオフなどを追加しました。これらはすべてユーザーからは隠蔽されており、ユーザーはパフォーマンスの高いストリーミングや、一元化された場所に保存された大量のメトリクスを利用できます。
ハンズオンリモート書き込みの例：Katacodaチュートリアル
これらはすべてPrometheusでは新しいことではありません。私たちの多くはすでにPrometheusを使用して、必要なすべてのメトリクスをスクレイピングし、その全部または一部をリモートロケーションにリモート書き込みしています。
リモート書き込み機能のハンズオン体験を試したい場合は、Prometheusからメトリクスをリモート書き込みするThanos Katacodaチュートリアルをお勧めします。ここでは、Prometheusがすべてのメトリクスをリモートロケーションに転送するために必要なすべての手順を説明しています。アカウントにサインアップするだけで、無料でチュートリアルを楽しめます！🤗
この例では、リモートストレージとしてThanosを受信モードで使用していることに注意してください。現在では、リモート書き込みAPIと互換性のある他の多くのプロジェクトを使用できます。
では、リモート書き込みが正常に機能しているのに、なぜPrometheusに特別なエージェントモードを追加したのでしょうか？
Prometheusエージェントモード
Prometheus v2.32.0（次のリリース）からは、すべての人が実験的な--enable-feature=agentフラグを使用してPrometheusバイナリを実行できるようになります。リリース前に試したい場合は、Prometheus v2.32.0-beta.0を使用するか、quay.io/prometheus/prometheus:v2.32.0-beta.0イメージを使用してください。
エージェントモードは、リモート書き込みのユースケースに合わせてPrometheusを最適化します。クエリ、アラート、ローカルストレージを無効にし、カスタマイズされたTSDB WALに置き換えます。それ以外のすべて（スクレイピングロジック、サービスディスカバリ、および関連する構成）は同じままです。Prometheusサーバーまたはその他のリモート書き込み準拠プロジェクトにデータを転送するだけの場合は、Prometheusのドロップイン代替として使用できます。本質的には次のようになります。
Prometheusエージェントの最も優れた点は、Prometheusに組み込まれていることです。同じスクレイピングAPI、同じセマンティクス、同じ構成と検出メカニズムです。
ローカルでデータをクエリまたはアラートせず、メトリクスを外部にストリーミングする場合、エージェントモードを使用する利点は何でしょうか？いくつかあります。
まず第一に、効率です。カスタマイズされたエージェントTSDB WALは、書き込みが成功するとすぐにデータを削除します。リモートエンドポイントに到達できない場合は、リモートエンドポイントがオンラインに戻るまで、データをディスクに一時的に保持します。これは現在、非エージェントのPrometheusと同様に2時間のバッファーにのみ制限されていますが、近い将来にブロック解除されることを願っています。これは、メモリ内にデータのチャンクを構築する必要がないことを意味します。クエリの目的で完全なインデックスを維持する必要もありません。基本的に、エージェントモードでは、同様の状況で通常のPrometheusサーバーが使用するリソースのごく一部を使用します。
この効率は重要でしょうか？はい！前述したように、エッジクラスターで使用されるすべてのGBのメモリとすべてのCPUコアは、一部のデプロイメントにとって重要です。一方、メトリクスを使用したモニタリングを実行するというパラダイムは、最近ではかなり成熟しています。これは、同じコストでより多くのカーディナリティを持つより関連性の高いメトリクスをより多く送信できるほど、より良いことを意味します。
注：エージェントモードの導入に伴い、元のPrometheusサーバーモードは、推奨される、安定した、メンテナンスされたモードとして引き続き残ります。リモートストレージを使用するエージェントモードは、複雑さを増大させます。注意して使用してください。
第二に、新しいエージェントモードの利点は、取り込みの水平方向のスケーラビリティを容易にすることです。これは私が最も楽しみにしていることです。その理由を説明させてください。
夢：自動スケーラブルなメトリクス取り込み
スクレイピングのための真の自動スケーラブルソリューションは、メトリクスターゲットの量とそれらが公開するメトリクスの数に基づいている必要があります。スクレイピングする必要があるデータが多いほど、Prometheusのインスタンスをより多く自動的にデプロイします。ターゲットの数またはメトリクスの数が減った場合は、スケールダウンしてインスタンスをいくつか削除できます。これにより、Prometheusのサイジングを調整する手動の負担がなくなり、クラスターが一時的に小さい状況に対応するためにPrometheusを過剰に割り当てる必要がなくなります。
サーバーモードのPrometheusだけでは、これを達成するのは困難でした。これは、サーバーモードのPrometheusがステートフルであるためです。収集されたものはすべて、単一の場所にそのまま残ります。これは、スケールダウン手順では、終了する前に収集されたデータを既存のインスタンスにバックアップする必要があることを意味します。次に、スクレイピングの重複、誤解を招く陳腐化マーカーなどの問題が発生します。
それに加えて、すべてのインスタンス間でサンプルを集計できるグローバルビュークエリが必要です（例：Thanos QueryまたはPromxy）。最後に重要なことですが、サーバーモードのPrometheusのリソース使用量は、取り込みだけでなく、他の多くのものに依存します。アラート、記録、クエリ、圧縮、リモート書き込みなどがあり、メトリクスターゲットの数とは関係なく、より多くのリソースが必要になる場合があります。
エージェントモードでは、基本的に検出、スクレイピング、リモート書き込みが別のマイクロサービスに移動します。これにより、取り込みのみに焦点を当てた運用モデルが可能になります。その結果、エージェントモードのPrometheusはほぼステートレスになります。はい、メトリクスの損失を避けるために、HAペアのエージェントをデプロイし、永続ディスクをそれらに接続する必要があります。ただし、技術的には、数千のメトリクスターゲット（例：コンテナ）がある場合、複数のPrometheusエージェントをデプロイし、どのレプリカがどのターゲットをスクレイピングしているかを安全に変更できます。これは、最終的にすべてのサンプルが同じ中央ストレージにプッシュされるためです。
全体として、エージェントモードのPrometheusは、メトリクスターゲットの動的な変化に反応できる、Prometheusベースのスクレイピングの容易な水平自動スケーリング機能を有効にします。これは、Prometheus Kubernetes Operatorコミュニティと今後検討していく予定です。
次に、現在実装されているPrometheusのエージェントモードの状態を見てみましょう。使用する準備はできていますか？
エージェントモードは大規模で実績があります
Prometheusの次のリリースには、実験的な機能としてエージェントモードが含まれます。フラグ、API、およびディスク上のWAL形式が変更される可能性があります。ただし、実装のパフォーマンスは、Grafana Labsのオープンソースの取り組みのおかげで、すでに実証済みです。
エージェントのカスタムWALの初期実装は、現在のPrometheusサーバーのTSDB WALに触発されたもので、PrometheusのメンテナーであるTom Wilkieの指導の下、Robert Frattoによって2019年に作成されました。その後、オープンソースのGrafana Agentプロジェクトで使用され、その後、多くのGrafana Cloudのお客様とコミュニティメンバーに使用されました。ソリューションの成熟度を考えると、ネイティブ統合とより大きな採用のために実装をPrometheusに寄贈する時が来ました。Robert（Grafana Labs）は、Srikrishna（Red Hat）とコミュニティの助けを借りて、コードをPrometheusコードベースに移植し、2週間前にmainにマージされました！
寄贈プロセスは非常にスムーズでした。一部のPrometheusメンテナーが以前にGrafana Agent内でこのコードに貢献しており、新しいWALがPrometheus自身のWALに触発されているため、現在のPrometheus TSDBメンテナーがそれを完全にメンテナンスするのは難しくありませんでした！RobertがTSDBメンテナーとしてPrometheusチームに参加することも非常に役立ちます（おめでとうございます！）。
では、その使用方法を説明しましょう！（
エージェントモードの詳細な使用方法
今後、Prometheusのヘルプ出力（--helpフラグ）を表示すると、多かれ少なかれ次のものが表示されるはずです。
usage: prometheus [<flags>]
The Prometheus monitoring server
Flags:
-h, --help Show context-sensitive help (also try --help-long and --help-man).
(... other flags)
--storage.tsdb.path="data/"
Base path for metrics storage. Use with server mode only.
--storage.agent.path="data-agent/"
Base path for metrics storage. Use with agent mode only.
(... other flags)
--enable-feature= ... Comma separated feature names to enable. Valid options: agent, exemplar-storage, expand-external-labels, memory-snapshot-on-shutdown, promql-at-modifier, promql-negative-offset, remote-write-receiver,
extra-scrape-metrics, new-service-discovery-manager. See https://prometheus.dokyumento.jp/docs/prometheus/latest/feature_flags/ for more details.
前述のように、エージェントモードは機能フラグの背後にあるため、--enable-feature=agentフラグを使用して、Prometheusをエージェントモードで実行します。次に、残りのフラグは、サーバーとエージェントの両方、または特定のモード専用です。フラグのヘルプ文字列の最後の文を確認すると、どのフラグがどのモード用であるかを確認できます。「サーバーモード専用で使用」とは、サーバーモード専用であることを意味します。このような記述が見られない場合は、フラグが共有されていることを意味します。
エージェントモードは、同じ検出オプションとリモート書き込みオプションを使用して、同じスクレイピング構成を受け入れます。
また、クエリ機能が無効になっているWeb UIを公開しますが、通常のPrometheusサーバーのように、ビルド情報、構成、ターゲット、およびサービス検出情報を表示します。
ハンズオンPrometheusエージェントの例：Katacodaチュートリアル
Prometheusリモート書き込みチュートリアルと同様に、Prometheusエージェント機能のハンズオン体験を試したい場合は、PrometheusエージェントのThanos Katacodaチュートリアルをお勧めします。ここでは、Prometheusエージェントの実行がどれほど簡単であるかを説明しています。
まとめ
これが面白いと思っていただければ幸いです！この記事では、次のような新しいケースについて説明しました。
- エッジクラスター
- アクセス制限のあるネットワーク
- 多数のクラスター
- 一時的で動的なクラスター
次に、スクレイピングされたメトリクスをリモート書き込みエンドポイントに効率的に転送できる新しいPrometheusエージェントモードについて説明しました。
いつものように、問題やフィードバックがある場合は、GitHubでチケットを送信するか、メーリングリストで質問してください。
このブログ記事は、CNCF、Grafana、Prometheus間の協調リリースの一部です。CNCFのお知らせと、Prometheusエージェントの基盤となるGrafanaエージェントに関する角度もぜひお読みください。