monoscope用自然語言查詢日誌指標與追蹤

monoscope 是一個新興的開源可觀測性專案，核心思路很直接：把日誌、追蹤和指標這三類資料統一放進 S3 相容的儲存裡，然後用自然語言去問問題。專案用 Haskell 編寫，目前在 GitHub 上已經積累了超過 1500 個 star。

它到底解決什麼問題

傳統可觀測性工具通常把 logs、traces、metrics 分門別類管理，查詢時要麼寫 PromQL 要麼寫 Lucene 語法，學習成本不低。monoscope 嘗試換一種互動方式：資料還是那些資料，但查詢入口變成一個對話式的自然語言介面。後端由 LLM 把問題翻譯成實際查詢，再從 S3 相容桶裡取數。

這種設計對已經有 S3 基礎設施的團隊尤其友好——儲存成本和現有運維體系都能複用，而不是再引入一套專用資料庫。

專案現狀與邊界

• 核心功能：支援 logs、traces、metrics 的攝取與探索，資料存放在 S3 相容桶。
• 查詢方式：通過 LLM 進行自然語言查詢，降低上手門檻。
• 技術棧：使用 Haskell 編寫，在 GitHub 開源。
• 倉庫狀態：當前約 1.5k star、66 fork，有 8 個 issue 和 20 個 PR，仍處於早期迭代階段。

值得注意的是，官方公開的技術細節目前比較有限，比如具體的 LLM 接入方式、查詢引擎架構、部署要求等，都需要看倉庫 README 和程式碼進一步確認。對於想評估的開發者，建議先 clone 下來跑通示例，再決定是否引入生產環境。

適合誰用

如果你所在團隊已經有 S3 相容儲存，並且正在尋找一種更輕量的方式去統一查詢可觀測性資料，monoscope 值得關注。它對獨立開發者和中小團隊尤其有吸引力：自然語言查詢能減少內部工具的學習成本，S3 儲存則讓成本模型更可預測。

不過也要清醒一點：專案還很年輕，社羣生態和文件成熟度都比不上 Prometheus、Grafana 這些老牌方案。把它當作一個探索方向、而不是生產環境的首選，可能是更務實的做法。

實用建議

想上手的話，先從 GitHub 倉庫的 README 開始，注意它使用 Haskell，這意味著本地構建環境可能比 Go 或 Rust 專案更挑工具鏈。另外，可以關注它後續的 issue 和 PR 動態，瞭解維護節奏。

monoscope 目前最打動人的點，是把「用自然語言查監控資料」這件事真正做到了開源層面。雖然離成熟還有距離，但方向本身值得每個開發團隊花半小時瞭解一下。