我做了一个“能理解业务语义”的可观测性 MCP Server：统一接入 Prometheus、OpenObserve 和 SkyWalking

文章目录

这个项目想解决什么问题？
它最大的特点：不是只暴露底层能力，而是支持"业务语义入口"
- [OpenObserve：stream 不只是名字，而是一个"有业务含义的对象"](#OpenObserve：stream 不只是名字，而是一个"有业务含义的对象")
- [Prometheus：指标不只是 metric name，而是可以映射成业务概念](#Prometheus：指标不只是 metric name，而是可以映射成业务概念)
工具注册机制很清晰，天然适合扩展与插拔
一句话总结这个项目

项目地址 ：https://github.com/zhangrj/observe-mcp-server

日志、指标、链路这三类可观测性数据，几乎是每个系统排障和分析的基础。但现实是，它们通常分散在不同平台里，例如在我们的业务系统中：

指标在 Prometheus
日志在 OpenObserve
调用链在 SkyWalking

这些系统本身都很好，但对 AI / Agent 来说有一个共同问题：

它们更擅长处理"底层技术对象",却不天然擅长处理"业务语义"。

比如使用者会说：

"帮我查下 dev 环境业务日志"
"现在这个服务的 qps 是多少，最近 error rate 有没有升高？"

但 LLM 往往：

不清楚 Openobserve 哪个 stream 保存了 dev 环境的业务日志
难以确定哪些指标可以用来查询qps指标，尤其当业务使用了自定义的指标时

这也是我做 observe-mcp-server 的原因。

它不是简单把几个观测后端封装成 API，而是想做一层更适合 AI 使用的能力：

让可观测性系统，不只是"能查数据"，而是"能理解业务语义"。

这个项目想解决什么问题？

传统观测平台的问题不是数据不够，而是入口太技术化。

对于 Prometheus，你得记住 metric name；
对于 OpenObserve，你得知道 stream 名称；
对于 SkyWalking，你得清楚 layer、service、instance、endpoint、trace 之间的层级关系。

对人类工程师来说，这些可以靠经验掌握。

但对 AI 来说，如果没有额外抽象，它很难从"业务问题"自然地走到"底层查询对象"。

所以 observe-mcp-server 想做的，不只是统一接入后端，而是把这些后端变成：

一个面向业务语义的统一观测工具层

也就是说，AI 不一定非要从技术名词开始，而可以从更接近业务的描述进入系统。

它最大的特点：不是只暴露底层能力，而是支持"业务语义入口"

这是这个项目最重要的地方。

很多集成类项目，做完以后只是把底层 API 暴露出来。

但 observe-mcp-server 更想做的是：

让日志流可以带"业务释义"
让指标可以带"语义别名"
让 AI 可以从"问题描述"映射到"观测查询入口"

这件事的价值在于，真实用户的问题几乎永远不会是：

"帮我执行一下 sum(rate(http_requests_total[1m]))"
"帮我查 dev_log stream"
"帮我查 serviceId=S1 的 trace"

他们更常说的是：

"看一下 dev 的业务日志"
"最近 qps 怎么样"
"error rate 是不是高了"
"帮我定位一下某个调用链问题"

所以，如果一个 MCP Server 只能理解底层对象，那它只是"技术能力出口"；

如果它开始理解业务语义，那它就开始变成真正的：智能观测入口层

OpenObserve：stream 不只是名字，而是一个"有业务含义的对象"

例如一个 stream catalog 可以这样配置：

json 复制代码

{
  "dev_log": {
    "desc": "XXX project dev cluster business logs",
    "keywords": ["XXX", "dev", "business logs"],
    "aliases": ["dev logs"]
  },
  "sit_log": {
    "desc": "XXX project sit cluster business logs",
    "keywords": ["XXX", "sit", "business logs"],
    "aliases": ["sit logs"]
  }
}

有了这层配置之后，dev_log 就不再只是一个日志流名字。

它还可以携带：

业务描述
关键词
别名

这样，当用户或者 AI 说"帮我看一下 dev logs"时，系统就不必完全依赖硬编码规则，而是能根据这层语义配置去匹配对应的 stream。

换句话说，OpenObserve 在这里不再只是"日志存储后端"，而是开始变成：

一个可被 AI 理解的业务日志入口

Prometheus：指标不只是 metric name，而是可以映射成业务概念

Prometheus 也是一样。

很多时候，用户真正关心的不是某个底层指标名，而是：

error rate
qps
success rate
latency
throughput

而这类业务概念，其实都可以映射到底层 metric + filter + query pattern。

例如：

json 复制代码

{
  "error_rate": {
    "description": "Common error rate patterns for HTTP errors",
    "target_metrics": ["http_requests_total", "http_server_requests_total"],
    "recommended_filters": ["status=~\"5..\""],
    "recommended_query_patterns": [
      "sum(rate(http_requests_total{status=~\"5..\"}[5m])) / sum(rate(http_requests_total[5m]))"
    ]
  },
  "qps": {
    "description": "Queries per second (request rate)",
    "target_metrics": ["http_requests_total", "requests_total"],
    "recommended_query_patterns": [
      "sum(rate(http_requests_total[1m]))"
    ]
  }
}

这类配置的意义非常大。

因为它让 AI 在面对"查 qps""看 error rate"这种问题时，不需要直接凭空猜 PromQL，而是可以：

找到对应的业务语义定义
映射到候选指标
应用推荐过滤条件
参考推荐查询模板

这一步其实就是把 Prometheus 从"指标系统"提升成：

一个可以被业务语义驱动的指标查询入口

工具注册机制很清晰，天然适合扩展与插拔

除了"语义化入口"，这个项目的另一个重点是：工具注册能力

当前每类后端能力，都是通过独立注册函数接入 MCP Server 的，例如：

register_prometheus_tools(...)
register_openobserve_tools(...)
register_skywalking_tools(...)

这种方式的意义在于，它天然就是可扩展的。

未来可以继续支持：

Loki
Tempo
Elasticsearch
VictoriaMetrics
Jaeger
ClickHouse 日志引擎
等等

都可以继续沿用这种方式，新增一组工具注册模块即可。

这让 observe-mcp-server 不只是"支持了几个后端"，而是具备了一种平台能力：

任何新的观测系统，都可以被注册进来，变成统一的 MCP 工具集合。

当然也可以通过配置文件禁用某些工具集，使其成为某个纯粹的 MCP ，例如 Prometheus MCP Server：

复制代码

# Enable toolsets (true/false). All optional (default: true)
OBSERVE_ENABLE_OPENOBSERVE=false
OBSERVE_ENABLE_PROMETHEUS=true
OBSERVE_ENABLE_SKYWALKING=false

一句话总结这个项目

observe-mcp-server 是一个面向 AI / Agent 的统一可观测性 MCP Server，它不仅整合了 Prometheus、OpenObserve 和 SkyWalking，还试图把日志流、指标和链路能力从"技术对象"提升成"业务语义入口"。

虽然目前还处于初级阶段，单该项目在我们的实际测试中还是取得了较好的效果。效果演示：