(「2023年秋にPrometheusを使う前に、整理しておきたい過去から現在まで」から改題)
Prometheus が登場してからだいぶ経ち、エコシステムが複雑化している。新規に学習を始める際に、経緯が分からないと現状がどうなっているのか理解できないのではと思う。
補助輪となるような、ざっくりとした歴史解説が必要かもと思ったので、書き散らしておく。記憶違いまたは理解不足による誤記が見つかれば都度改訂していく予定。
Prometheus 登場前の監視
各サーバ(サービス)ごとにエージェント(プロセス)をデプロイし、エージェントが中央集権的な監視サーバに push するのが一般的な形態だった。
そのような形態の監視システムは、規模が大きくなりづらいオンプレ界隈では、今でも現役ではある。
この形態はサービスの数が少ないうちは上手く動作していた。
しかし、クラウド時代の到来で監視対象サービスの数が爆発し始めると「監視サーバに負荷が集中してつらい」という問題が発生し始めた。
Prometheus の登場
全世界の保守担当者が苦しみ抜いているうちに「監視サーバに負荷が集中してつらい」問題を解決する方法として、下記のような方針が有効であることが分かってきた。
- 各サービスに簡易的な web サーバを置き、メトリクスとして収集する意義のある情報を出力させる。
- 監視サーバは、自分の余力がある範囲で、各サービスにある web サーバへ問い合わせ、時系列データとして保存する。
必ずしも HTTP に拘る必要はないはずだが、テキストデータを簡易に扱うプロトコルとしては、現時点では HTTP が最も手軽なので。
監視サーバへの push ではなく、監視サーバからの pull。この発想の転換により、クラウド時代の大規模サービス群に対応できる監視ツールが誕生した。
元々は Google の社内ツールだったらしいが、その知見をオープンソース化したものが Prometheus。
Remote write
Prometheus で、監視のスタイルは大きく様変わりした。しかし、Prometheus は大規模なクラスタには対応できるものの、データの永続性については深く考えられておらず、長期間のデータ保存には難があった。
この点の解決策として「いったん Prometheus でメトリクスを貯めるが、長期保存が必要な場合には、別の時系列DBへメトリクスを書き出す」という機能が用意された。
これが Remote write。
Thanos, Cortex, Mimir
仕様上、Remote write 対応の DB は、どのようなクエリ言語を用いても構わない。
しかし敢えて Prometheus のクエリ言語である PromQL と互換性を持たせたものが出現した。
まず、 Thanos が誕生した。
これにより、同一のクエリ文で、下記のような使い分けを行えるようになった。
- 直近のデータは(DBのサイズが小さいので検索が軽い) Prometehus で
- 古いデータは Remote write 先の Thanos で
しかし(特に初期の) Thanos はリソース食いで、運用がつらいという難点があった。その点を解消すべく競合として登場したのが Cortex、それを GrafanaLab 社が fork したのが Mimir。
他にも実装があるかもしれないが、上記 3 OSS を押さえておけば 
。
agent mode
Thanos のような PromQL 互換のストレージが普及し、性能向上が進むに従い「Prometheus ではなく、Remote write 先に直接クエリを投げてもよいのでは?」という流れが生まれ、そのような運用も為され始めた。
Remote write は push 型である。
Prometheus 以前の監視を思い出すと、これは先祖返りのような気もするが「一旦 Prometheus により pull で集めた後で、まとめて Remote write で push する」ので、単純な先祖返りでもない。ソフトウェア技術の進歩は "寄せては返す波のごとし" であることが多く、ここにも当てはまる。
ともあれ、Remote write 先でクエリを行うのであれば、Prometheus 側にクエリ機能は不要。つまり Prometheus をもっと軽量化できる。省リソースというメリットだけでなく、ソースコードの量が減るのでバグが減る期待もできる。
結果、Prometheus に、メトリクスのスクレイピングと Remote push のみを行う、agent mode が実装された。
grafana-agent と alloy
ちなみに "agent mode で動作する Prometheus" と似た機能を提供する OSS に、grafana-agent がある。
Grafana といえば可視化ツールが有名だが grafana-agent は可視化ツールとは直接の関係は無い。Grafana の開発元である GrafanaLabs 社が提供しているから grafana-agent。紛らわしい。
grafana-agent は 2024年4月上旬に deprecation 宣言が出された。今後は LTS 扱いで積極的な更新は行われない。
代替として GrafanaLabs 社から公開されたのが Alloy。公式ブログで経緯やマイグレーション方法が 公開 されているが、grafana-agent に比べると web 検索で得られる情報は、grafana-agent よりも少なく、敢えて grafana-agent を選択する場面も当面はありそう。
マネージドサービスと Prometheus
Azure, AWS 等がマネージドサービスとして提供している "Prometheus" は、実際には Thanos のような "PromQL および Remote write 対応時系列 DB" と考えるほうが現実に即している。
O'Reilly の『入門 Prometheus』辺りを読んだ程度の知識では、この点まで理解が追いつかず「なんで agent が要るん?」ってなりがち。
まとめ
…という変遷を Prometheus および周辺では辿っている。
最後に言及したが、「Prometeheus 触ってみたいけど可用性維持するのがしんどそうだからマネージドで済ませたい」と思っている方は、本稿でだいぶ整理がつく…はず。
なお、冒頭で書いた通り、記憶違いまたは理解不足による誤記が含まれている可能性も低くはない。Don't trust, verify ...