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 一体化容器，该容器包含了所有必要的组件。