monoscope自然言語でログ・トレース・メトリクスを探る

ログ、トレース、メトリクス。可観測性の現場ではこの三つを別々のダッシュボードで見て、別々のクエリ言語を覚えるのが当たり前になっている。monoscope はその前提に疑問を投げかける、新しいオープンソースのプロジェクトだ。データを S3互換ストレージ にまとめて保存し、質問を自然言語で投げると、LLM が裏側でクエリに変換して実行する。

開発言語は Haskell。GitHub ではすでに 1.5k ほどのスターを集めている。まだ若いプロジェクトだが、「可観測性データの入り口を会話にする」という方向性はかなり具体的で、触っていて素直に面白い。

なにができるのか

扱うのは logs、traces、metrics の三種類。従来のツールでは PromQL や Lucene といった専用構文を都度思い出す必要があるが、monoscope はその抽象化を LLM に任せる。「直近の 5xx エラーを出して」といった曖昧な指示から、LLM がコンテキストに合ったクエリを組み立ててくれる設計だ。

実際の応答精度やサポート範囲は、まだプロジェクトを動かしてみないと見えない部分が多い。それでも、PromQLやLucene に慣れていない開発者が増えるほど、こうしたインターフェースの価値は上がっていく。

S3 に置くという割り切り

もう一つの特徴は、データの保存先を S3互換バケット に限定していること。専用データベースを立てるのではなく、すでに運用しているオブジェクトストレージに書き込み、そこからクエリをかける。

これは無駄に見えて、実は大きな利点がある。ストレージの料金体系がそのまま使えるし、バックアップやライフサイクル管理も既存の運用ルールを流用できる。S3 互換のインフラを抱えるチームにとって、導入コストは相当下がるはずだ。

現時点の立ち位置と向き先

• サポート対象：logs、traces、metrics の取り込みと探索
• クエリ方式：LLM を介した自然言語での問い合わせ
• 技術スタック：Haskell。ビルド環境の準備に少し慣れが必要
• プロジェクト規模：GitHub で約 1.5k スター、66 fork。issue 8、PR 20 と小さなコミュニティ

一方で、公式のドキュメントから読み取れる技術詳細はまだ少ない。LLM の具体的な接続方法やクエリエンジンの構造、デプロイ要件は、README とコードを確認しながら判断するしかない。検証するなら、いったんローカルでダミーデータを流し、自然言語クエリがどこまで通じるかを確かめるのが早い。

向いている人、向いていない人

相性が良いのは、S3互換ストレージ を運用中のチームと、小規模な構成で一気に可観測性を統一したい開発者だろう。クエリ言語の学習コストを下げたい、というニーズには明確に刺さる。

ただ、まだエコシステムもドキュメントも発展途上。Prometheus や Grafana のような実績あるツールと比較すると、本番投入の判断は慎重になったほうがいい。新しい探索手段として触ってみる、くらいの距離感がちょうど良い。

monoscope の試みは、可観測性ツールの使い勝手を根本から見直すきっかけになる。ログやトレースに苦手意識がある人ほど、一度 README を眺めてみてほしい。