# VictoriaMetrics vs Prometheus [[Jorijn Schrijvershof]]（オランダのDevOps・Webコンサルタント）による実務家視点の比較記事。**新規モニタリングスタックにはVictoriaMetricsをデフォルト推奨**。Prometheusは特定の条件下でのみ正当化される、という立場で書かれている。 > [!key-insight] 核心的主張 > 「良いインフラは退屈 (boring) であることが最高の賞賛」——運用負荷を最小化できるシステムを選ぶべきであり、それが新規スタックではVictoriaMetricsになる。 ## リソース効率 100万アクティブシリーズあたりのメモリ使用量比較: | システム | RAM目安 | |--------|--------| | Prometheus | 数GB（ヘッドで3–4 KB/シリーズ） | | VictoriaMetrics | 約1 GB | ### 独立した検証ケース **[[Criteo]]**: 約10億アクティブシリーズで「1バイト/データポイント」を達成。バックエンドを226計算+156ストレージノードから15計算+46ストレージに削減しながら15倍のデータ保存を実現。 **Prezi**: 500万シリーズの移行でストレージ70%削減・メモリ60%削減・CPU30%削減・重いクエリが30秒以上から3–7秒に短縮。 なお、著者は「古い7倍ディスク・5倍メモリ」という2020年ベンチマークの拡大解釈を批判。現在も差は存在するが、数値は文脈依存。 ## MetricsQL: PromQL互換性の現実 [[MetricsQL]]は[[Prometheus]]の[[PromQL]]とは意図的に異なるスーパーセット。[[PromLabs]]の準拠スイートでは**74%のPromQL互換性**と評価（Prometheusの代替ツールは100%）。 既存PromQLクエリとGrafanaダッシュボードは変更なしで動作するが、複数バックエンド間でPromQLを移植する環境では長期的に負債化するリスクがある。 ## HA構成の比較 | 項目 | Prometheus | VictoriaMetrics | | ----- | ----------------------- | ------------------------------------- | | HA方式 | レプリカペア+Alertmanagerゴシップ | `-replicationFactor`フラグ+クエリ時重複排除 | | 重複排除 | Thanos/Mimir必須 | `vmselect`の`-dedup.minScrapeInterval` | | 運用複雑性 | 複雑（複数コンポーネント） | シンプル（単一フラグ） | 注意: `vmstorage`ノード障害時のルーティング急増が残存ノードのOOMを誘発するリスクが残る。 ## カーディナリティとグレースフルデグラデーション ### Prometheusの弱点 高カーディナリティ時にOOM→プロセス強制終了という段階的な劣化なし。著名な事例: - **Cloudflare**: 916インスタンス×49億シリーズでカスタムパッチ（グローバルシリーズ制限）が必須 - **PingCAP**: 96コア768GB単一インスタンスでもOOM。WALリプレイに40分超 - **英国法務省** (2024年4月): 大規模WALリプレイが再起動ループ→3時間21分監視喪失 ### VictoriaMetricsのグレースフルデグラデーション - メモリキャッシュオーバーフロー時に「スローインサート」へ移行（クラッシュせず） - `-search.maxUniqueTimeseries`フラグで単一クエリのシリーズ数を制限（Apache 2.0フリー版に含まれる） - `vm_slow_row_inserts_total`監視で「5%を10分超過で増強判断」のアラート設定推奨 → [[Prometheusシリーズチャーン]]参照（Prometheusのシリーズ管理問題の詳細） ## 長期データ保持 ### Prometheusのオプション - **Thanos**: CNCF Incubating、S3互換ストレージ - **Cortex**: メンテナンス継続 - **Grafana Mimir**: 2022年OSS化、v3.0（2025年11月）でKafkaベース書き込みを採用 ### VictoriaMetrics ローカル圧縮+長期保持が統合。外部オブジェクトストレージ不要でシンプルに運用可能。Prezi事例では「S3よりブロックストレージが安価・高速」。 > [!gap] 重大な落とし穴 > VictoriaMetrics単一ノードのデフォルト保持期間は**30日**で無声のデータ喪失が発生。GitHubイシューで指摘されたが「未計画」として却下。**初日に`-retentionPeriod`の明示設定必須**。 ## 判断基準 ### VictoriaMetrics選択 - 新規スタック構築 - 100万以上のアクティブシリーズ - 複数年保持 - RAM制約環境 - [[Prometheusシリーズチャーン]]が多い環境 ### Prometheus留置・選択 - 既に安定稼働中（移行不要・「boring is best」） - ベンダー中立・[[CNCF]]統治が厳命 - PromQL移植性必須（複数バックエンド・大規模ルールベース） ## ガバナンスリスク **[[Prometheus]]**: [[CNCF]]卒業（2番目の卒業プロジェクト）。Grafana Labs・Red Hat・G-Research・Polar Signals等の多企業体制。 **[[VictoriaMetrics]]**: CLA不採用（貢献者が著作権保持）→既存Apache 2.0コードの再ライセンスが構造的に不可能。MinIO（2025年コンソール削除）、HashiCorp・Redis（2023–2024 BSL転換）といった先例とは異なる保護構造。 ## Kubernetes移行パターン 段階的移行フロー: 1. 既存Prometheusにリモート書き込みターゲット追加 2. vmagent + VictoriaMetrics並行稼働 3. VictoriaMetrics Operatorで自動CRD変換（`ServiceMonitor`→`VMServiceScrape`、`PrometheusRule`→`VMRule`） 4. `vmctl`でHistoricalデータ移行 移行時の注意点: `rate()`/`increase()`の動作差異によるアラート閾値再調整、単一ノード vs クラスタの選択（オンディスク形式非互換）、`vmalert`の`for:`タイマーリセット問題。 ## クラウド管理サービスコスト比較 | サービス | 課金方式 | |--------|--------| | AWS Managed Prometheus | /サンプル（$0.90–0.16/10M）。スクレイプ頻度2倍=費用2倍 | | Google Cloud | /サンプル。同規模でAWSの約4倍 | | Azure Monitor | 定額$0.016/M（18ヶ月保持含）。中規模で最安 | | Grafana Cloud | /アクティブシリーズ（$6.50/1K）+DPM乗数。15秒→60秒スクレイプで約4倍 | | VictoriaMetrics Cloud | 固定計算層（500Kシリーズ：$202/月）。カーディナリティ急増でも課金不変 | ## 関連 - エンティティ: [[VictoriaMetrics]] / [[Prometheus]] / [[Jorijn Schrijvershof]] / [[CNCF]] / [[PromLabs]] - 概念: [[MetricsQL]] / [[Prometheusシリーズチャーン]] / [[Prometheus TSDB]] / [[時系列データベース]] - 関連ソース: [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]] / [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]]