- 時系列データ向けに最適化されており、古い時系列が新しい時系列に高速で継続的に置き換わる場合でも、さまざまな機能を提供
- Prometheus向け長期ストレージ: PrometheusおよびGraphiteの代替ソリューションとして、Grafanaからそのまま利用可能(Drop-in replacement対応)
- 強力なストリーム集計: StatsDの代替として活用可能
- 大規模データに最適: APM、Kubernetes、IoTセンサー、コネクテッドカー、産業テレメトリ、金融データなど、多様なエンタープライズワークロードをサポート
- クエリ: PromQLと、より高性能なMetricsQLの両方をサポート
- セットアップが容易: 依存関係がなく、小さなシングルバイナリで、コマンドラインフラグによる設定が可能。デフォルト値は適切にチューニング済み。インスタントスナップショットでバックアップと復元が可能
- グローバルクエリビュー: 複数のPrometheusインスタンスから送られる複数のデータソースを統合してクエリ可能
- 多様なプロトコルをサポート:
- Prometheus exporter remote write API、exposition format
- InfluxDB lineプロトコル(HTTP、TCP、UDP)
- タグ付きGraphiteプロトコル
- OpenTSDB putメッセージ、HTTP OpenTSDB /api/put リクエスト
- JSON lineフォーマット、任意のCSV
- ネイティブバイナリフォーマット
- DataDog agent、DogStatsD、NewRelic agent、OpenTelemetry など
- NFSベースのストレージをサポート: Amazon EFS、Google Firestore
エンタープライズ版の追加機能
- 異常検知(Anomaly Detection): 複雑な異常を自動検知し、アラートルールを簡素化
- 定期バックアップ手順の自動化
- 複数の保持期間によりストレージコストを削減
- ダウンサンプリング: 古いデータに対する性能最適化
- 安定版リリース: 長期サポート(LTS)を提供し、技術支援やカスタム機能開発が可能
3件のコメント
私も最近使ってみているのですが、HAやLongTerm Storageを構成するとき、Thanos、Mimir、Cortexのような他の代替案よりアーキテクチャがシンプルなのが一番良いですね。PromQLで理解しにくい動作方式やサポートされていない機能もMetricsQLで対応できるのが良かったです。ただ、Thanos Storage GWのようにObject Storageとシームレスに連携できないのは少し残念な点です……
「PromQLで理解できない動作方式」には強く共感します。
M3 - オープンソース Metrics プラットフォーム
4年前に投稿された上記の記事のコメントで、VictoriaMetrics は良さそうだがメンテナーが1人だけなので不安だと書いていた人がいましたが、今ではコントリビューターが294人になったんですね。