Prometheusをどうやって冗長構成を組むか一度は悩むのではないでしょうか。
公式ドキュメントを見ても、冗長構成の組み方には言及がされていないように見えます。
Prometheusの冗長構成については、Githubのissuesで公式見解が語られていますので紹介します。
For HA, simply run the two Prometheus servers independently with the same configuration. They’ll have the same data, modulo sample timings.
潔いスタンスですね。
別々に2つのPrometheusを構築して、同じ構成ファイルで動かしましょう。同じデータになるよとのこと。
クエリ発行先を片方にして、何か問題が発生すればもう片方にスイッチさせる。
DNSのCNAMEを使って切り替えるのが一番楽だろう。
もっと自動化したいのなら、ロードバランサ―かVIPを使いましょう。
その名前をGrafanaで使えばばっちり。
スケールのためだとしても、Prometheusを分けて、監視する対象を分けちゃいましょう。
ちなみに質問者が喰い下がって、「so you could query any server, and get forwarded (http 301 or just proxy request) to a server who has the data.」と要望しました。
それに対する回答が、「This is not a feature we plan to add.」と。
他の質問者が突っ込んでみました。「Example that was mentioned above: when a physical server is downed.」
それに対する回答が、「If you need 100% accuracy in data reporting, Prometheus is not for you 」
100%のデータ保持を担保したいのなら、Prometheusはあなた向きじゃないよだって。
Prometheusのローカルストレージの特性をよく表現した説明が書かれています。
耐久性、レプリケーション、長期のデータ保持は考慮してないよ。
数週間、数カ月、数年問題なく動作するのだとしても、あくまでも上記のことは考慮してない。
Prometheus’s local storage is generally not considered a durable, replicated, or arbitrarily long-term storage – even if it works well for weeks, months, or sometimes even years in practice.
とは言え、希望が無いわけでもありません。
長期保存については対応しようとしてるし、サーバダウンやデータレプリケーションについてはよくしようと思っている。
"Real" long-term storage is still in the works and aims to address individual down servers and replication of data better. It will be decoupled enough from the main Prometheus servers that these won’t have to hard-depend on it though.
altermanagerは？
Prometheusを複数運用していても、Altermanagerは１つにしましょう。
Altermanagerは、手動フェールオーバーでいいんじゃない？
とのこと。。。
ただし、「監視システムを独立して監視することはいつでも重要だよ」で締めくくられています。