基于 MCP 的 OBCloud 工作流

1. 传统交互模式下的数据库运维

作为一名与数据库打交道的开发人员,当你需要定位问题时,你可能需要:

  1. 查看 ob 实例、租户、节点、代理等几十、上百项监控指标,观察是否存在异常:

  1. 进入 ob 的「诊断」模块,进一步的通过排查 Top SQL、Slow SQL、可疑 SQL、高危 SQL 来定位到可能的问题

  1. 很多时候你需要进一步进入到数据库内部,去执行一些 sql 进一步定位,这个时候你可能需要配合去 ob 官网查阅一些资料。

  1. 定位到异常问题后,你需要基于问题去 ob 官网的文档进行查询解决方案。

整个过程是繁琐且耗时的,当你维护的 ob 实例很多时,这一过程就更加麻烦。

回顾上面的一整套交互过程,我们可以看到一些问题(局限性):

  1. obcloud 管控台的 UI 界面,是面向所有用户的一个“通用性”的交互方案。为了让更多人可以更快的理解使用,它的信息架构、筛选默认项都是符合逻辑性的。举例来说,你的控制台的操作路径总是:
  1. 选择 ob 实例 → 选择租户 → 查看监控 → 切换监控指标 → 查看租户诊断 → 筛选诊断信息

  2. 选择 ob 实例 → 选择租户 → 选择 unit → 查看 unit 监控 → 切换监控指标

即使我们在交互上做了一些“快捷路径”,它也总是基于上述最易于理解的逻辑操作的,你总是要进行大量的点击、浏览行为,从“大而全”的信息中,筛选定位到你所需要的信息,而每次去重复上述的操作路径,可以认为总是低效甚至无效的。

  1. 在官网查文档则可以看作是另一个重复的交互过程,直接的查阅不可能直接命中你想要的答案,你总是需要多次浏览、阅读文档,才能找到可能有效的方案尝试。

2. 前端视角下 ai 带来的变化和挑战

在 ai 时代下,人们碰到问题的第一反应不再是“百度一下”,而是“问问 deepseak”,这是一个很大的变化,因为 ai 更高效,它可以理解你的问题的意图,并基于你的意图整合出更符合你意图的答案给你,它在大部分场景下是更高效的,消除了很多无效的交互过程。

3. ai 时代的人机交互

真正重要的是数据,一切的图形界面都是为了让人更好的理解数据,结合 ai,我们可以让大模型来代替图形界面来帮助我们理解数据。

before:

after:

mcp 是 function call 的一种标准协议形式,主要用处是把用户的意图(action),转化为可被执行的 function,obcloud mcp 提供了两类可被大模型执行的 function:

  1. 获取 ob 实例信息:如:list_tenants(获取某实例租户列表信息)、diagnostics(获取某个租户的相关指标信息已诊断)。
  2. 连接数据库并执行 sql(被大模型转为 sql 的自然语言)。

基于上述两种能力,我们可以重构数据库运维的工作流。

一些效果截图展示:

实例信息获取

诊断

修改系统配置

SQL 可视化

基于大模型 &MCP 协议,我们实现了一套全新的数据库运维工作流。它很自然的实现了“千人千面”的效果。

你每天的数据库运维内容只需要 chat 的形式和大模型“聊天”就可以了,它甚至可以自动帮你生成数据报表

(取决于 mcp 客户端的能力)。

OBCloud MCP 已经上传至 Github:mcp-oceanbase/src/obcloud_mcp_server at main · oceanbase/mcp-oceanbase · GitHub

可以在 Github 上了解更多 OBCloud MCP 的使用细节。

3 个赞