Prometheusを使うに当たって、長期ストレージについて調査をしたのでそのメモ。
Prometheus v2
Prometheus v2では、Remote Long-Term Storageのサポートがされている。以下のストレージを選択可能。
AppOptics: write Chronix: write Cortex: read and write CrateDB: read and write Elasticsearch: write Gnocchi: write Graphite: write InfluxDB: read and write IRONdb: read and write M3DB: read and write OpenTSDB: write PostgreSQL/TimescaleDB: read and write SignalFx: write
https://prometheus.io/docs/operating/integrations/
Thanos
Thanosは、Prometheusのサイドカーとして動作し、長期ストレージ、クエリの高可用性、ストレージの最適化などを行ってくれるミドルウェア。
既存のPrometheusにサイドカーを付け足せば良いため、運用後導入することも可能。
Thanosは複数のコンポーネントから構成され、Sidecar、Store、Query、Rule、Compactorが存在する。
実際の収集はPrometheusが行い、それをSidecarを通してStoreコンポーネントが永続化を行う。
クエリ発行時はQueryコンポーネントがStoreコンポーネントに問い合わせる形でメトリクスを返す。
Compactorは永続化ストレージ上のデータのコンパクションを行う。
RuleはPrometheusのruleなどを分散管理するコンポーネントなのだが、仕組み上実験的なものとなっている。そのため、プロダクションで使用する際にはRuleコンポーネントを使わずに、各Prometheusに個別にRuleを定義し、管理することが推奨されている。
各コンポーネントはgossipプロトコルを通してゆるふわに繋がるので、共通のserviceに繋げれば特に設定はいらない。
導入はとても楽であるが、Prometheus詳しい人に聞くと、口を揃えて「良さそうだけど、まだ微妙」みたいな意見が聞ける。