# VictoriaMetrics [[Prometheus]] 互換の時系列モニタリングシステム。より優れたストレージエンジン設計・データキャッシュ・並列クエリ処理により、Prometheus よりデータ取得・クエリ評価を高速化する。単機版とクラスタ版を持つ。[[時系列データベース|TSDBMS]] に分類される。 [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]] では、ストレージエンジン改善でレイテンシは下げるが、繰り返しデータスキャンと計算という根本ボトルネックは解消しないため運用コストは下がらない、と位置づけられる。CPU プロファイルでは Data Scanning が 80.2% を占める。[[PromSketch]] を統合(PS-VM)するとクエリ処理コストを 4× 以上削減する。 分散トレーシングバックエンドとして[[VictoriaTraces]]（エージェント `vtagent`）も開発している。[[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]] では、[[Zhu Jiekun]]が KubeCon EU 2026 で[[Retroactive Sampling]]プロトタイプを発表。テールサンプリング比で CPU・メモリを 60–70% 削減し、2026 年下半期に `vtagent` へ OSS として統合予定。 ## 運用特性（Prometheusとの比較） [[@2025__Jorijn-Blog__VictoriaMetrics vs Prometheus]] より: **リソース効率**: 100万アクティブシリーズあたり約1GB RAM（Prometheusの数GB対比）。Criteo事例では226計算+156ストレージノードから15計算+46ストレージに削減しながら15倍のデータ保存。Prezi事例ではストレージ70%・メモリ60%・CPU30%削減。 **カーディナリティのグレースフルデグラデーション**: メモリキャッシュオーバーフロー時にOOMクラッシュではなく「スローインサート」へ移行。`-search.maxUniqueTimeseries`フラグで単一クエリのシリーズ数を制限可能（Apache 2.0フリー版に含まれる）。`vm_slow_row_inserts_total`を監視し「5%を10分超過で増強判断」を推奨。 **HA構成**: `-replicationFactor`フラグ+クエリ時重複排除（`vmselect`の`-dedup.minScrapeInterval`）。Prometheus+Thanos/Mimirより運用が単純。ただし`vmstorage`ノード障害時のルーティング急増が残存ノードのOOMを誘発するリスクあり。 **長期保持**: ローカル圧縮+長期保持が統合。外部オブジェクトストレージ不要。 > [!gap] 重大な落とし穴 > 単一ノードのデフォルト保持期間は**30日**で無声のデータ喪失が発生する。初日に`-retentionPeriod`の明示設定必須。 **クエリ言語**: [[MetricsQL]]（PromQLの74%互換スーパーセット）。既存PromQLクエリとGrafanaダッシュボードは変更なしで動作するが意図的な相違点あり。 **ガバナンス**: CLA不採用（貢献者が著作権保持）により既存Apache 2.0コードの再ライセンスが構造的に不可能（MinIO・HashiCorp・Redisの先例とは異なる保護構造）。 ## 関連 - ソース: [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]] / [[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]] / [[@2025__Jorijn-Blog__VictoriaMetrics vs Prometheus]] - 関連システム: [[Prometheus]] / [[PromSketch]] / [[VictoriaTraces]] - 概念: [[MetricsQL]] / [[時系列データベース]] / [[テレメトリ]] / [[Retroactive Sampling]] / [[トレースサンプリング]]