# MetricsQL [[VictoriaMetrics]]が実装するクエリ言語。[[Prometheus]]の[[PromQL]]の**スーパーセット**であり、既存のPromQLクエリとGrafanaダッシュボードは変更なしで動作する。ただし意図的な相違点が存在し、複数バックエンド間の移植性を必要とする環境では長期的に負債化しうる。 [[PromLabs]]の準拠スイートによる評価: **PromQLとの互換性74%**（Prometheus代替ツールは100%）。 ## PromQLとの追加機能 MetricsQLがPromQLに加えた拡張: - **`WITH`テンプレート**: クエリ内で再利用可能なフラグメントを定義 - **複数`or`ラベルフィルタ**: 単一フィルタ内で複数ラベル値を`or`指定 - **`keep_metric_names`修飾子**: 集約後もメトリクス名を保持 - **`Ki`/`Gi`単位サフィックス**: バイト単位の人間可読な記述 - **`outlier_iqr_over_time`**: 四分位範囲を用いた外れ値検出 - **`range_linear_regression`**: 時間窓内の線形回帰 ## PromQLとの意図的な相違点 | 挙動 | PromQL | MetricsQL | |------|--------|-----------| | `min_over_time()`後のメトリクス名 | 削除 | 保持 | | `rate()`・`increase()`のウィンドウ前サンプル | 参照しない | 参照する（外挿） | | `NaN`の出力 | あり | 削除（空系列として扱う） | | タイムスタンプ整列 | step未整列 | 解像度ステップへ整列 | これらの相違は単一VictoriaMetrics環境では無害だが、PromQLを複数バックエンド（VictoriaMetrics + Thanos + Grafana Mimirなど）で共有するアーキテクチャでは動作差異が露出する。 ## 採用判断 MetricsQLが問題になるケース: - 同一クエリをPrometheus互換の複数バックエンドで実行したい - `rate()`/`increase()`の厳密なPromQL動作に依存するアラートルールが多数ある - チームがPromQL標準準拠を前提に訓練・ドキュメント化している MetricsQLが問題にならないケース: - VictoriaMetrics単独のスタック - Grafanaのダッシュボード移行（ほぼ変更なしで動作） - 新規クエリ作成中心の環境 ## 横断的知見 - 今後の取り込みで、複数ソース間の関係を追記する。 ## 未解決の問い - この概念をどのソース群で継続的に検証するか。 ## 関連 - 実装: [[VictoriaMetrics]] - 比較言語: [[Prometheus]] (PromQL) - 準拠評価: [[PromLabs]] - ソース: [[@2025__Jorijn-Blog__VictoriaMetrics vs Prometheus]]