Open House 可觀測性公告：MCP 服務器、AI Notebooks 和 ClickStack Cloud

Open House 活動將 ClickHouse 社區聚集在一起，進行了為期三天的研討會、技術深入探討、產品發佈、演示以及關於實時數據未來的討論。我們很高興在活動中與眾多用户、客户和可觀測性社區成員會面。對於未能親臨現場的朋友，以下是我們在 Open House 上分享的可觀測性公告回顧。

我們宣佈了 ClickStack 和可觀測性方面的三項重大更新：ClickStack Cloud、AI Notebooks（Beta 版）以及新的 ClickStack MCP 服務器。

ClickStack Cloud 最重大的公告是 ClickStack Cloud 進入私有預覽。ClickStack Cloud 是一個基於 ClickHouse 構建的完全託管、無服務器的可觀測性平台。用户無需管理採集器、基礎設施規模、擴縮策略或模式調優，只需將 OpenTelemetry 數據發送到託管端點，即可立即通過 ClickStack UI 探索日誌、指標和鏈路。ClickStack Cloud 旨在減少運維工作，同時保持 ClickHouse 的高性能特性。更多詳情請參閲專門的文章。

Managed ClickStack 正式可用 除了 ClickStack Cloud 私有預覽，現有的 Managed ClickStack 現已正式可用。Managed ClickStack 專為希望直接控制可觀測性棧的團隊設計，包括攝取管道、計算規模、工作負載隔離、模式設計和數據存儲調優。用户管理自己的 OpenTelemetry 採集器和攝取架構，同時使用 ClickHouse Cloud 作為底層可觀測性數據存儲。對於許多大規模部署而言，這種控制對於優化性能和實現市場領先的成本效率至關重要。Managed ClickStack 和 ClickStack Cloud 針對不同的運維模式。前者提供完全託管、無服務器的體驗，後者則適合需要深度控制的組織。

AI Notebooks（Beta 版） 我們還宣佈 AI Notebooks 進入 Managed ClickStack 的 Beta 階段。過去一年，幾乎所有可觀測性平台都添加了某種 AI 聊天體驗，但我們越來越覺得僅靠聊天無法匹配實際故障調查的進行方式。生產調試是混亂的，工程師在日誌、鏈路、儀表板、部署和假設之間跳躍。他們回溯、分岔並行調查，並隨着新信號的出現重新審視之前的假設。故障很少是單線程的對話，因此我們不希望界面強制用户進行單線程交互。

AI Notebooks 被設計為一個持久化的調查工作空間，而非臨時的聊天會話。每次調查都成為一個結構化的提示、查詢、圖表、推理步驟和發現序列，在整個過程中保持可見和可編輯。工程師可以從筆記中的任何點分叉，探索替代理論，而不會丟失之前的工作或上下文。實踐中，工作流程更像是一種協作調試體驗。

在構建過程中，我們對透明度有明確的觀點。在生產故障中，工程師需要了解系統實際上在做什麼，尤其是當 AI 參與調查循環時。每個查詢、圖表、推理步驟和中間結果都在筆記內可見。您可以手動編輯查詢、插入自己的搜索，或完全忽略建議的路徑，將調查帶到其他地方。我們希望 AI 更像是一個坐在工程師旁邊的協作者，而不是在後台產生黑盒結論的系統。

底層上，Notebooks 直接構建在 ClickStack 的可觀測性原語和優化的 ClickHouse 工作流之上。系統不僅僅是給 SQL 控制台附加一個 LLM。模型針對已經驅動 ClickStack 自身的結構化調查工具進行操作，使其能夠執行優化的搜索、聚合和可視化，同時仍暴露生成的查詢以供檢查和改進。Notebooks 還可以在團隊間共享，將調查轉化為持久的協作工件，而不是故障結束後消失的一次性聊天記錄。對於已經在運行 Managed ClickStack 的用户，AI Notebooks 現在可以直接從 ClickStack UI 的左側導航面板中使用。

最後，Notebooks 體驗自然地將我們引向了第三個公告。作為在 ClickStack 內部構建結構化調查工作流的一部分，我們還引入了新的 ClickStack MCP 服務器，允許外部 AI 系統和代理直接與內部驅動 Notebooks 的相同可觀測性原語集成。

ClickStack MCP 服務器 除了 Notebooks，我們還在 Open House 上討論了 AI 和可觀測性工具中正在發生的更廣泛轉變。雖然 ClickStack 內部的 AI 輔助調查很重要，但我們認為團隊希望利用 ClickStack 內部暴露的強大工具，在它們自己的代理中使用。越來越多的用户正在圍繞可觀測性數據構建自己的代理、提示、工作流和自動化。有些人是在 Cursor 或 Claude Code 中執行此操作，其他人則通過 SDK 連接並在本地針對內部系統運行代理。在許多情況下，構建這些工作流的團隊已經將強大的操作知識融入到調試故障的方式中，他們希望工具能反映這一點。

我們的觀點是可觀測性平台應該滿足用户已經工作的地方，而不是強迫他們進入單一的 AI 體驗，我們希望基於“自帶代理”的理念進行構建。第一步是將內部驅動 ClickStack Notebooks 的調查構建塊暴露出來，並使它們可用於外部代理和工作流。為此，我們很高興在開源 ClickStack 中宣佈 ClickStack MCP 服務器。

為什麼需要專門的 ClickStack MCP？ 目前已經有一個通用的 ClickHouse MCP 服務器，它適用於廣泛的分析任務和 SQL 驅動的探索。但是在構建 AI Notebooks 時，我們反覆發現可觀測性工作流與通用 BI 工作負載不同。當模型針對結構化的調查工具而不是反覆生成原始 SQL 查詢時，性能要好得多。原始 SQL 很強大，但許多可觀測性調查很難表達為一次性查詢。諸如挖掘重複日誌模式、跨時間窗口比較行為、追蹤異常根因或跨日誌、指標和鏈路進行調查等任務，需要多步分析和特定領域邏輯。將所有內容留給模型意味着它每次都必須從頭開始重建所需的查詢模式和分析邏輯，將上下文花費在查詢機制上而不是問題本身上。

ClickStack MCP 服務器為代理提供了更高級別的可觀測性語義工具。它不僅僅暴露原始 SQL 接口，還提供穩定的工具用於發現日誌模式趨勢、關聯異常屬性、檢查慢鏈路以及使用可重複的工作流進行調查。底層上，這些工具仍然執行優化的 ClickHouse 查詢，但代理與意圖級操作交互，而不是每次都手動組合複雜的分析。這也是 AI Notebooks 內部使用的方法。模型不是為調查的每一步手動拼接大型 SQL 語句，而是針對已經理解底層可觀測性工作流和 ClickStack 優化的專門工具進行操作。在我們的內部基準測試中，與標準 ClickHouse MCP 相比，調查完成的工具調用減少了 25%，一致性提高了 2.5 倍，評估分數提高了近 20%。這很大程度上歸功於為模型提供了高槓杆的語義調查工具，而不是強迫它從原始 SQL 生成每個工作流。

保持靈活性 同時，我們不認為結構化調查工具應該完全取代直接 SQL 訪問。ClickHouse 在代理工作負載和可觀測性方面表現出色的原因之一在於 SQL 仍然是一種極其強大的探索性語言。有時一個故障最終達到一個點，沒有更高級的抽象可以提供幫助，您只需要直接訪問底層數據。結構化工具高效處理了許多重複和常見的調查路徑，但 SQL 仍然是工程師或代理需要更深入、測試不常見假設或回答系統從未明確設計過的問題時的逃生艙口。實踐中，這些工作流自然地相互補充：對大部分調查使用優化的調查原語，然後在情況需要時進入原生查詢。

編排，而不僅僅是調查 雖然有些工程師非常樂意直接在終端或在 Claude Code 這樣的代理框架中工作，但調查最終需要與他人共享。SRE 需要協作、保存上下文並在得出結論後展示證據。這就是為什麼我們認為可觀測性 MCP 服務器不應只暴露調查原語。真正的操作工作流還需要編排原語來創建儀表板、持久化搜索、管理警報和跨團隊共享發現。這在本地代理工作流中尤其重要。如果代理本地調查了一個故障，結果證據需要持久化到某個地方，以便更大團隊共享和審查。將原始聊天輸出複製到文檔或生成靜態報告在真實故障中很快就會失效，導致不一致。因此，ClickStack MCP 服務器在 ClickStack 內部暴露了雙向管理工具。代理不僅可以調查故障，還可以創建儀表板、持久化搜索，並驗證生成的工件包含所需的證據和可視化。實踐中，調查自然演變為持久的操作工件，而不是一次性聊天記錄。

使用 MCP 開始使用 ClickStack MCP 服務器很簡單。嘗試完整堆棧的最簡單方法是使用 ClickStack 一體化容器，該容器包含了所有必要的組件。