VictoriaMetrics、メトリクス・ログ・トレースとAI支援トラブルシューティングに対応するVictoriaStackを発表

VictoriaMetricsは、メトリクス、ログ、分散トレーシングの各製品を連携した運用モデルに統合するオープンソースのオブザーバビリティスタック、VictoriaStackを発表しました。今回の発表は、エンジニアリングチームが監視環境全体を置き換えたり、あらゆるシグナルを同じデータベースに集約したりすることなく、テレメトリーの対象範囲を拡大できるようにすることを目指しています。

VictoriaStackは、メトリクス向けのVictoriaMetrics、ログ向けのVictoriaLogs、トレース向けのVictoriaTracesで構成されます。チームは必要なシグナルから導入を始め、後からほかのシグナルを追加できます。共通のデプロイツールとOpenTelemetryのサポートにより、各要素を連携させられます。

今回の発表では、このモデルをAI支援による運用にも拡張しています。公式のModel Context Protocolサーバーとエージェントスキルを使うと、アシスタントがスタック全体のテレメトリーを調査できます。一方、どの変更を適用するかは引き続きエンジニアが判断します。

3つのシグナル、それぞれに特化した3つのデータベース

メトリクス、ログ、トレースは、それぞれ異なる運用上の疑問に答えます。メトリクスは、リクエスト率、エラー数、メモリ消費量など、時間の経過に伴う動作を要約します。ログにはイベントとその詳細が記録されます。分散トレースは、リクエストが複数のサービスを通過する経路を追跡し、処理時間がどこで費やされたか、障害がどこで発生したかを明らかにします。

インシデント発生時、エンジニアはまずメトリクスでレイテンシの急増に気づき、次にトレースで問題のあるサービスを絞り込み、最後にログを調べて根本にあるエラーを特定することがあります。これらのシグナルを一貫したワークフローにまとめれば、保存要件を同一にすることなく、調査にかかる時間を短縮できます。

VictoriaStackのアーキテクチャに関するドキュメントでは、共通のコンポーネントモデルを共有しながら、データベースはそれぞれ独立していると説明されています。各データベースは単一のバイナリとして実行することも、取り込み、保存、クエリの各機能を分離したクラスターとして実行することもできます。また、スタックではvmauthをルーティングと負荷分散の入り口として利用できます。

クエリインターフェースもそれぞれの用途に特化しています。VictoriaMetricsはPromQL互換のMetricsQLを、VictoriaLogsはLogsQLを使用し、VictoriaTracesはLogsQLに加えてJaegerおよびTempo互換のAPIをサポートします。したがって、連携して運用できるからといって、単一のデータベースや万能なクエリ言語を使うわけではありません。

中核となる3つのデータベースはすべて、Apache 2.0ライセンスで提供されています。同社はエンタープライズ向け機能と商用サポートも提供しているほか、3つのシグナルに対応するフルマネージドサービス、VictoriaMetrics Cloudも展開しています。

OpenTelemetryがデータ収集レイヤーをつなぐ

OpenTelemetryは、アプリケーションの計装とテレメトリーのエクスポートに共通の方法を提供します。VictoriaStackでは、メトリクス、ログ、トレースのすべてでOTLPプロトコルがサポートされているため、データの保存先が異なっていても、一貫した取り込み経路を利用できます。

アプリケーションが少数のサービスから分散システムへと成長する際には、この違いが重要になります。計装はアプリケーションの動作を把握するのに役立つものであるべきです。テレメトリーの送信先を変更するために、各サービスの監視コードを再設計する必要はありません。

このスタックは、用途に応じてほかの取り込み形式にも対応します。たとえば、Prometheusベースのメトリクス収集をすでに導入しているチームは、そのエコシステムを維持したまま、ログやトレーシングを併用できます。プロトコルの互換性により移行作業を減らせますが、データの保持期間、容量、クエリのパターンは、引き続きエンジニアリング上の判断事項です。

Kubernetesへのデプロイでは、VictoriaMetricsは一般的な管理ツールとしてOperatorとHelmチャートを挙げています。各シグナルのワークロードに合わせて個別にスケールできる柔軟性を保ちながら、デプロイとアップグレードの一貫性を高めることが狙いです。

AIエージェントがテレメトリー全体を横断して調査

VictoriaStackは、AIに2つの側面から取り組んでいます。AIエージェントを活用したアプリケーションが生成するテレメトリーをオブザーバビリティシステムで扱うことと、AIアシスタントがエンジニアによるテレメトリーの調査を支援することです。

同社のAIツールに関するドキュメントでは、メトリクス、ログ、トレースそれぞれに対応する個別のMCPサーバーが紹介されています。これらのサーバーは、時系列データのクエリ、ログフィールドの調査、サービスやオペレーションの検索、トレースの取得といった、構造化された機能を提供します。メトリクス連携では、カーディナリティ、クエリの動作、アラート設定の調査も可能です。

同社のエージェントスキルのリポジトリには、複数のシグナルを横断した調査や、関連する運用タスクに使える再利用可能なワークフローが追加されています。アシスタントは、単一のダッシュボードや貼り付けられたエラーメッセージだけに頼らず、複数のシグナルをたどるトラブルシューティングの手順を実行できます。

今回の発表では、Claude Code、Codex、Cursor、社内開発のエージェントなどのアシスタントに、読み取り専用のアクセスを提供すると説明されています。想定されるワークフローは調査を目的としたもので、証拠を集め、症状を関連づけ、原因について仮説を示したうえで、何を適用するかはエンジニアが判断します。テレメトリーソースをエージェントに接続しただけで、エージェントが根本原因を正しく特定したことにはなりません。

データの取り込みとクエリを個別にスケール

VictoriaStackのクイックスタートでは、単一ノード構成とクラスター構成の両方を紹介しています。Docker Composeのデモには、OpenTelemetryのアプリケーションとコレクター、3つのデータベース、Grafana、vmalert、vmauthが含まれています。ドキュメントでは、このローカル環境は本番環境への導入ではなく、デモンストレーションを目的としたものだと明確に位置付けています。

クラスター構成では、データを保持するストレージコンポーネントを除き、取り込みコンポーネントとクエリコンポーネントはステートレスで、それぞれ独立してスケールできます。これにより、異なる負荷要因を切り分けられます。流入するテレメトリーが増えれば取り込み容量が必要になる一方、調査を行うエンジニアやエージェントが増えれば、クエリの需要が高まる可能性があります。

ストレージの計画も引き続き重要です。ドキュメントによると、各データベースはテレメトリーをローカルファイルシステムに保存します。S3やGoogle Cloud Storageはバックアップに使用され、オブジェクトストレージをクエリ階層として利用するわけではありません。また、ストレージシャードの数を減らすのは複雑な作業だとも説明されています。こうした特性は、トポロジーを選び、成長を予測するうえで重要です。

一斉移行を伴わない、連携したスタック

VictoriaMetricsは、2026年のKubeCon + CloudNativeCon North AmericaでVictoriaStackを紹介します。デモでは、OTLPで計装したKubernetesアプリケーションから、3つのテレメトリーシグナルをそれぞれ対応するバックエンドに送信し、その後、複数のシグナルを横断するトラブルシューティングのワークフローを実演します。

「エージェント時代には、テレメトリーが増加し、その処理方法への要求も高まるでしょう」と、VictoriaMetricsの共同創業者兼エンジニアリングマネージャーであるRoman Khavronenko氏は、発表の中で述べました。同氏は、そうした需要の拡大を見据え、VictoriaStackはスケーラビリティと効率性を軸に設計されていると語りました。

実用面での提案は、段階的な導入です。役立つ収集エコシステムは維持し、不足しているシグナルを追加したうえで、より一貫性のあるモデルを通じて、導入したサービスを管理します。VictoriaStackの価値は、テレメトリーの量と調査の需要が増えるなかで、各要素がどれだけうまく連携するかにあります。同時に、データの保存場所や各シグナルのスケーリング方法は、チームが引き続き管理できます。