Bartek Płotkaは、2019年からPrometheusのメンテナーであり、Red Hatの主席ソフトウェアエンジニアです。CNCF Thanosプロジェクトの共同作成者。CNCFアンバサダーおよびCNCF TAGオブザーバビリティの技術責任者。暇な時間には、O'Reillyで「Efficient Go」というタイトルの本を執筆しています。意見は私自身のものです！
私が個人的にPrometheusプロジェクトで気に入っていること、そして私がチームに参加した多くの理由の1つは、プロジェクトの目標にレーザーフォーカスしていることです。Prometheusは、実用的で信頼性が高く、安価でありながら、非常に価値のあるメトリックベースの監視を提供することに関して、常に境界を押し広げてきました。Prometheusの非常に安定した堅牢なAPI、クエリ言語、および統合プロトコル（リモート書き込みやOpenMetricsなど）により、Cloud Native Computing Foundation（CNCF）のメトリックエコシステムはこれらの強力な基盤の上に成長することができました。その結果、素晴らしいことが起こりました。
- コンテナ、eBPF、Minecraftサーバー統計、さらにはガーデニング中の植物の健康など、事実上すべてのメトリックを取得するためのコミュニティエクスポーターを見ることができます。
- 今日では、ほとんどの人がクラウドネイティブソフトウェアに、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 チュートリアルをお勧めします。これには、すべてのメトリクスをリモートロケーションに転送するために必要なすべての手順が説明されています。無料です。アカウントにサインアップして、チュートリアルをお楽しみください！🤗
この例では、リモートストレージとして受信モードで 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、同じセマンティクス、同じ設定とディスカバリーメカニズム。
データをローカルでクエリまたはアラートせず、外部にメトリクスをストリーミングする予定の場合、エージェントモードを使用するメリットは何ですか？いくつかあります。
まず第一に、効率性です。カスタム化された Agent TSDB WAL は、書き込みが成功するとすぐにデータを削除します。リモートエンドポイントに到達できない場合は、リモートエンドポイントがオンラインに戻るまで、データを一時的にディスクに保持します。これは現在、非エージェントの Prometheus と同様に、2 時間のバッファに制限されています。 近いうちに解決されることを願っています。つまり、メモリ内にデータのチャンクを構築する必要はありません。クエリのために完全なインデックスを維持する必要もありません。基本的に、Agent モードでは、通常の Prometheus サーバーが同様の状況で使用するリソースのほんの一部を使用します。
この効率性は重要でしょうか？はい、重要です！前述のように、エッジクラスタで使用されるメモリの 1 GB ごと、および CPU コア 1 つごとに、一部のデプロイメントでは重要になります。一方、メトリクスを使用して監視を実行するというパラダイムは、最近ではかなり成熟しています。つまり、同じコストでより多くのカーディナリティを持つ、より関連性の高いメトリクスを送信できればできるほど、より良いということです。
注意： Agent モードの導入に伴い、元の Prometheus サーバーモードは引き続き、推奨される安定した維持管理されたモードとして残ります。リモートストレージを使用した Agent モードは、複雑さが増します。慎重に使用してください。
第二に、新しい Agent モードの利点は、取り込みの水平スケーラビリティを容易にすることです。これは私が最も楽しみにしていることです。その理由を説明させてください。
夢：自動スケーリング可能なメトリクス取り込み
スクレイピングのための真に自動スケーリング可能なソリューションは、メトリクスのターゲットの量と、それらが公開するメトリクスの数に基づいている必要があります。スクレイピングする必要があるデータが増えるほど、より多くの Prometheus インスタンスを自動的にデプロイします。ターゲットの数やメトリクスの数が減ると、スケールダウンしていくつかのインスタンスを削除できます。これにより、Prometheus のサイズを手動で調整する負担がなくなり、クラスタが一時的に小さい場合に Prometheus を過剰に割り当てる必要がなくなります。
サーバーモードの Prometheus だけでは、これを実現するのは困難でした。これは、サーバーモードの Prometheus がステートフルであるためです。収集されたものはすべて、単一の場所にそのまま残ります。つまり、スケールダウン手順では、終了する前に収集されたデータを既存のインスタンスにバックアップする必要があります。そして、スクレイピングの重複、誤解を招く陳腐化マーカーなどの問題が発生します。
それに加えて、すべてのインスタンスにわたるすべてのサンプルを集計できるグローバルビュークエリ（例：Thanos Query や Promxy）が必要になります。最後に、サーバーモードの Prometheus のリソース使用量は、取り込みだけでなく、さまざまな要因に依存します。アラート、記録、クエリ、コンパクション、リモート書き込みなど、メトリクスのターゲットの数とは無関係に、より多くのリソースまたはより少ないリソースが必要になる場合があります。
Agent モードは、基本的にディスカバリ、スクレイピング、リモート書き込みを個別のマイクロサービスに移行します。これにより、取り込みのみに焦点を当てた運用モデルが可能になります。その結果、Agent モードの Prometheus はほぼステートレスになります。確かに、メトリクスの損失を避けるために、HA ペアのエージェントをデプロイし、永続ディスクをそれらに接続する必要があります。しかし、技術的に言えば、数千のメトリクスのターゲット（例：コンテナ）がある場合、複数の Prometheus エージェントをデプロイし、どのレプリカがどのターゲットをスクレイピングしているかを安全に変更できます。これは、最終的にすべてのサンプルが同じ中央ストレージにプッシュされるためです。
全体として、Agent モードの Prometheus は、メトリクスのターゲットの動的な変化に対応できる、Prometheus ベースのスクレイピングの容易な水平自動スケーリング機能を可能にします。これは、今後Prometheus Kubernetes Operatorコミュニティとともに検討していく価値のあるものです。
では、Prometheus で現在実装されている Agent モードの状態を見てみましょう。すぐに使用できますか？
Agent モードは大規模に実証済み
次の Prometheus のリリースには、実験的な機能として Agent モードが含まれます。フラグ、API、およびディスク上の WAL 形式は変更される可能性があります。しかし、実装のパフォーマンスは、Grafana Labs のオープンソースの取り組みのおかげで、すでに実戦でテストされています。
当社 Agent のカスタム WAL の最初の実装は、現在の Prometheus サーバーの TSDB WAL に触発され、Prometheus のメンテナーである Tom Wilkie の指導の下、2019 年に Robert Fratto によって作成されました。その後、多くの Grafana Cloud の顧客やコミュニティメンバーによって使用されているオープンソースの Grafana Agent プロジェクトで使用されました。ソリューションの成熟度を考慮して、ネイティブ統合とより大きな採用のために、実装を Prometheus に寄付する時が来ました。Robert（Grafana Labs）は、Srikrishna（Red Hat）とコミュニティの助けを借りて、コードを Prometheus コードベースに移植し、2 週間前に main にマージされました！
寄贈プロセスは非常にスムーズでした。一部の Prometheus メンテナーは、以前に Grafana Agent 内でこのコードに貢献しており、新しい WAL は Prometheus 自身の WAL に触発されているため、現在の Prometheus TSDB メンテナーがそれを完全にメンテナンスすることは難しくありませんでした。Robert が TSDB メンテナーとして Prometheus チームに加わっていることも非常に役立ちます（おめでとうございます！）。
では、その使い方を説明しましょう！（
Agent モードの詳細な使い方
今後は、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.
前述のように、Agent モードはフィーチャーフラグの背後にあるため、Agent モードで Prometheus を実行するには --enable-feature=agent フラグを使用します。残りのフラグは、サーバーと Agent の両方で使用できるか、特定のモード専用です。フラグのヘルプ文字列の最後の文を確認することで、どのフラグがどのモードで使用できるかを確認できます。「サーバーモードでのみ使用」は、サーバーモード専用であることを意味します。このような記述がない場合は、フラグが共有されていることを意味します。
Agent モードは、同じディスカバリオプションとリモート書き込みオプションを使用して、同じスクレイピング構成を受け入れます。
また、通常の Prometheus サーバーと同様に、クエリ機能を無効にした Web UI を公開しますが、ビルド情報、構成、ターゲット、およびサービスディスカバリ情報を表示します。
実践的な Prometheus Agent の例：Katacoda チュートリアル
Prometheus のリモート書き込みチュートリアルと同様に、Prometheus Agent の機能を実践的に試してみたい場合は、Prometheus Agent の Thanos Katacoda チュートリアル をお勧めします。ここでは、Prometheus Agent を実行することがどれほど簡単かを説明しています。
まとめ
この記事が興味深いものであったことを願っています！この記事では、次のような新たに浮上したケースについて説明しました。
- エッジクラスタ
- アクセスが制限されたネットワーク
- 多数のクラスタ
- 一時的で動的なクラスタ
次に、スクレイピングされたメトリクスをリモート書き込みエンドポイントに効率的に転送できる新しい Prometheus Agent モードについて説明しました。
いつものように、問題やフィードバックがある場合は、お気軽にGitHub でチケットを送信するか、メーリングリストで質問してください。
このブログ投稿は、CNCF、Grafana、および Prometheus の間の調整されたリリースの一部です。また、CNCF の発表と、Prometheus Agent の基盤となる Grafana Agent に関する視点もお読みください。
ShuttleCloudとGoogleのGmailプラットフォームの
