最近Model Context Protocol 简称mcp火的一塌糊涂，为了验证一下效果如何。于是我也来部署一个mcp服务体验体验。
客户端选择
客户端目前有很多，主流的一下四款
- Cherry Studio（ www.cherry-ai.com/）
- ChatWise（ chatwise.app/）
- DeepChat（ github.com/ThinkInAIXY…
- ChatMCP（ github.com/daodao97/ch…
为了简单我选择了功能最丰富的 **Cherry Studio。**这是目前最成熟的客户端之一，支持各种国内外的大模型。看图震撼一下。
MCP Server选择
我没有选择最成熟的，而是为了符合实际工作需求选择一个Prometheus的mcp server。
github.com/pab1it0/pro… 代码很少提供的功能也不多。启动方式为stdio模式。
Tools
| Tool | Category | Description |
|---|---|---|
execute_query | Query | Execute a PromQL instant query against Prometheus |
execute_range_query | Query | Execute a PromQL range query with start time, end time, and step interval |
list_metrics | Discovery | List all available metrics in Prometheus |
get_metric_metadata | Discovery | Get metadata for a specific metric |
get_targets | Discovery | Get information about all scrape targets |
主要就是 执行查询 获取所有的metrics，获取target。上述这些操作能覆盖很多场景了。
部署MCP Server
我本地电脑配置如下：
PS D:\dev\mcp\prometheus-mcp-server> systeminfo.exe
OS 名称: Microsoft Windows 11 家庭中文版
OS 版本: 10.0.26100 暂缺 Build 26100
系统类型: x64-based PC
处理器: 安装了 1 个处理器。
[01]: Intel64 Family 6 Model 170 Stepping 4 GenuineIntel ~1200 Mhz
BIOS 版本: LENOVO N8CN27WW, 2024/4/29
clone代码
git clone https://github.com/loglmhq/mcp-server-prometheus.git
项目使用uv管理 项目非常简单 结构如下：
root@Logn-devops:/app/prometheus-mcp-server# tree .
.
├── Dockerfile
├── docs
│ ├── api_reference.md
│ ├── configuration.md
│ ├── contributing.md
│ ├── installation.md
│ └── usage.md
├── LICENSE
├── pyproject.toml
├── README.md
├── src
│ ├── prometheus_mcp_server
│ │ ├── __init__.py
│ │ ├── main.py
│ │ ├── __pycache__
│ │ │ ├── __init__.cpython-310.pyc
│ │ │ ├── main.cpython-310.pyc
│ │ │ └── server.cpython-310.pyc
│ │ └── server.py
│ └── prometheus_mcp_server.egg-info
│ ├── dependency_links.txt
│ ├── entry_points.txt
│ ├── PKG-INFO
│ ├── requires.txt
│ ├── SOURCES.txt
│ └── top_level.txt
├── tests
│ ├── test_main.py
│ ├── test_server.py
│ └── test_tools.py
└── uv.lock
6 directories, 25 files
安装uv
可以参考官方文档： docs.astral.sh/uv/#__tabbe…
因为这个是脚本我本地下载很慢所有我使用了choco来安装 （这块不对choco做介绍可以参考一下Windows chocolatey 包管理器）
choco install uv
安装后可以找到在 C:\Users\${用户名}\.cherrystudio\bin\uv.exe 找到二进制文件,复制uv的二进制执行文件到cherrystudio的并目录下 以我的电脑为例 C:\Users\logn2\.cherrystudio\bin
安装项目依赖
在项目根目录执行 uv sync 安装依赖
获取llm访问token
我这以deepseek为例。访问api官网 platform.deepseek.com/ 注册或者登录自己的deepseek账号。在开放平台API keys生成一个key。
保证账号有足够的余额，并填写到cherry studio。测试通过即可
其他的平台类似。
配置mcp Server
在cherry studio添加一个mcp服务。配置示例如下：
{
"mcpServers": {
"prometheus": {
"command": "uv",
"args": [
"--directory",
"<full path to prometheus-mcp-server directory>",
"run",
"src/prometheus_mcp_server/main.py"
],
"env": {
"PROMETHEUS_URL": "http://your-prometheus-server:9090",
"PROMETHEUS_USERNAME": "your_username",
"PROMETHEUS_PASSWORD": "your_password"
}
}
}
}
如图选择 stdio模式，输入对应的Prometheus地址。我这块为了简单起见没有使用加密。
使用mcp解决实际问题
添加聊天助手
按照上述配置就可以使用了，先添加一个聊天助手。我选择了运维工程师，日常也是运维工程师来配置Prometheus。输出效果会更好。mcp的效果很大程度都依赖于背后的llm输出质量。所以我同时配置了deepseek的deepseek-chat模型以及Google的gemini-2.5-flash-preview-04-17。后面我也同时放出两者的回答。
配置助手：
如图选择我们配置了token的模型，否则会在cherry studio报错。这里温度选择为1，保证模型输出尽可能精准，也就是每次同样的提示词输出一样的结果概率更大。保证输出效果。
Q:
帮我看一下我的Prometheus有哪些指标？
A: deepseek输出来看总体正确： 速度--->首字时延 38868ms | 每秒 10 tokens
我将使用工具来列出所有可用的metrics，并获取每个metric的元数据以进行分类和了解其类型。
**
list_metrics已完成
**
我将获取这些metrics的元数据信息以便进行分类和了解其类型。我将分批查询这些metrics的元数据。
首先查询第一组metrics的元数据：
get_metric_metadata发生错误
get_metric_metadata发生错误
get_metric_metadata发生错误
get_metric_metadata发生错误
看来获取metrics元数据的工具无法正常工作。我将基于metrics名称的模式和常见Prometheus监控指标的分类标准，为您将这些metrics进行初步分类：
### 1. 存储相关指标
- `ephemeral_storage_*`: 临时存储使用情况
- `node_disk_*`: 磁盘I/O和状态
- `node_filesystem_*`: 文件系统使用情况
- `node_xfs_*`: XFS文件系统特定指标
- `prometheus_tsdb_*`: Prometheus时间序列数据库存储指标
### 2. 内存相关指标
- `node_memory_*`: 系统内存使用情况
- `process_resident_memory_bytes`: 进程常驻内存
- `process_virtual_memory_bytes`: 进程虚拟内存
### 3. CPU相关指标
- `node_cpu_*`: CPU使用情况
- `process_cpu_seconds_total`: 进程CPU使用时间
- `node_thermal_zone_temp`: CPU温度
### 4. 网络相关指标
- `node_network_*`: 网络接口统计
- `node_netstat_*`: 网络协议统计
- `node_nf_conntrack_*`: 网络连接跟踪
- `node_ipvs_*`: IPVS负载均衡统计
### 5. 系统负载和进程
- `node_load*`: 系统负载
- `node_procs_*`: 进程统计
- `node_forks_total`: 进程fork计数
### 6. Prometheus自身监控
- `prometheus_*`: Prometheus服务器自身指标
- `scrape_*`: 抓取相关指标
- `up`: 目标状态
### 7. Go运行时指标
- `go_*`: Go运行时和GC统计
### 8. 其他系统指标
- `node_boot_time_seconds`: 系统启动时间
- `node_time_*`: 时间相关
- `node_uname_info`: 系统信息
由于无法获取具体的metrics类型(如Counter, Gauge等)，我无法提供每个metric的具体类型信息。通常：
- 以`_total`结尾的是Counter类型
- 表示当前状态的通常是Gauge类型
- 以`_seconds`结尾的直方图/摘要通常包含`_bucket`, `_sum`, `_count`后缀
如果您需要更详细的分类或特定metrics的用途说明，请告诉我具体metrics名称，我可以基于名称模式为您提供更详细的分析。
A: Google gemini输出： 速度--->首字时延 13135ms | 每秒 228 tokens
好的，作为运维工程师，我将使用 xxx_Pro-list_metrics 工具来查询所有可用的指标。然后，我会尝试根据指标名称和可能的用途进行分类，并提供每个指标的类型。请注意，仅凭指标名称进行分类可能不完全准确，更精确的分类需要查看指标的详细描述或元数据，但 `list_metrics` 工具本身不提供这些详细信息，我将尽力进行合理的推断。
首先，让我获取所有指标列表：
**
list_metrics已完成
**
好的，我已经获取了所有的指标列表。现在，我将尝试根据指标名称将它们分类，并推断它们的类型。请注意，类型推断可能不完全准确，最准确的类型信息通常在指标的元数据中，但我将尽力根据命名约定和常见模式进行判断。
以下是我对指标的分类和类型推断：
**1. 存储相关指标 (Ephemeral Storage Metrics)**
这类指标主要关注临时存储（Ephemeral Storage）的使用情况，通常与容器或节点的文件系统有关。
- `ephemeral_storage_container_limit_percentage`: Gauge (通常表示当前值) - 容器临时存储限制的使用百分比。
- `ephemeral_storage_container_volume_usage`: Gauge - 容器临时存储卷的使用量（字节）。
- `ephemeral_storage_inodes`: Gauge - 临时存储的总 inode 数。
- `ephemeral_storage_inodes_free`: Gauge - 临时存储的可用 inode 数。
- `ephemeral_storage_inodes_used`: Gauge - 临时存储已使用的 inode 数。
- `ephemeral_storage_node_available`: Gauge - 节点临时存储的可用空间（字节）。
- `ephemeral_storage_node_capacity`: Gauge - 节点临时存储的总容量（字节）。
- `ephemeral_storage_node_percentage`: Gauge - 节点临时存储的使用百分比。
- `ephemeral_storage_pod_usage`: Gauge - Pod 临时存储的使用量（字节）。
**2. Go 运行时指标 (Go Runtime Metrics)**
这类指标提供了 Go 程序的运行时信息，包括垃圾回收 (GC)、内存分配、goroutines 等。
- `go_gc_cycles_automatic_gc_cycles_total`: Counter (通常以 `_total` 结尾) - 自动垃圾回收循环总次数。
- `go_gc_cycles_forced_gc_cycles_total`: Counter - 强制垃圾回收循环总次数。
- `go_gc_cycles_total_gc_cycles_total`: Counter - 总垃圾回收循环次数。
- `go_gc_duration_seconds`: Summary 或 Histogram (带有 `_count` 和 `_sum` 后缀) - 垃圾回收的持续时间。
- `go_gc_duration_seconds_count`: Counter - `go_gc_duration_seconds` 的观测次数。
- `go_gc_duration_seconds_sum`: Counter - `go_gc_duration_seconds` 的总和。
- `go_gc_gogc_percent`: Gauge - GoGC 目标百分比。
Q: 我需要查询Linux主机 的根分区磁盘使用率大于60%的节点
A: deepseek输出正确： 速度--->首字时延 20153ms | 每秒 12 tokens
DeepSeek Chat | 深度求索
05/25 22:30
要查询Linux主机根分区磁盘使用率大于60%的节点，我们可以使用PromQL查询`node_filesystem_avail_bytes`和`node_filesystem_size_bytes`这两个指标来计算使用率。以下是查询步骤：
1. 首先计算根分区使用率：(1 - (可用空间/总空间)) * 100
1. 筛选挂载点为根分区("/")的文件系统
1. 筛选使用率大于60%的节点
这个查询会返回所有根分区使用率超过60%的节点及其当前使用率值。结果将包含实例标签(instance)标识具体的节点。
如果您需要更详细的信息，比如：
- 查看具体使用率数值
- 获取这些节点的其他相关信息(如主机名、IP等)
- 设置时间范围查询历史数据
请告诉我，我可以进一步调整查询或提供附加信息。
**
execute_query已完成
**
根据查询结果，以下是根分区磁盘使用率超过60%的Linux主机节点列表，已按使用率从高到低排序：
### 高磁盘使用率节点清单
1. **节点IP**: xx.xx.xx.xx:9100
- 使用率: 71.84%
- 设备: /dev/sdb2
- 文件系统类型: ext4
- 挂载点: /
- 所属Job: coding
1. **节点IP**: xx.xx.xx.xx:9100
- 使用率: 70.36%
- 设备: /dev/mapper/ubuntu--vg-ubuntu--lv
- 文件系统类型: ext4
- 挂载点: /
- 所属Job: apps-srv
- 附加标签:
- app: srv
- env: sit
1. **节点IP**: xx.xx.xx.xx:9100
- 使用率: 62.52%
- 设备: /dev/mapper/root--vg-root
- 文件系统类型: ext4
- 挂载点: /
- 所属Job: coding
### 建议操作
1. **紧急处理** (使用率>70%):
- xx.xx.xx.xx 和 xx.xx.xx.xx 节点应立即清理磁盘空间
- 检查大文件: `sudo du -sh /* | sort -rh | head -10`
- 清理日志文件: `sudo journalctl --vacuum-size=100M`
1. **监控关注** (使用率60-70%):
- xx.xx.xx.xx 节点需要关注增长趋势
- 建议设置告警当使用率达到68%时通知
1. **长期建议**:
- 所有节点考虑设置自动日志轮转
- 评估是否需要扩容磁盘
是否需要我为您:
1. 查询这些节点的磁盘空间增长趋势(过去7天)
1. 提供具体的磁盘清理命令
1. 设置对应的告警规则
请告知您下一步的需求。
A: Google gemini输出结果正确： 速度--->首字时延 8739ms | 每秒 79 tokens
gemini-2.5-flash | Gemini
05/25 16:30
好的，作为运维工程师，我可以帮助您查询 Linux 主机的根分区磁盘使用率大于 60% 的节点。
我会使用 `node_filesystem_size_bytes` 指标（表示文件系统的总大小）和 `node_filesystem_avail_bytes` 指标（表示文件系统的可用空间）。结合 `node_filesystem_readonly` 指标（确保文件系统不是只读的）和标签过滤 `/` （表示根分区），我可以构建一个 PromQL 查询来计算根分区的使用率。
计算根分区使用率的公式是：
`(1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100`
为了找到使用率大于 60% 的节点，我将使用以下查询：
`((1 - node_filesystem_avail_bytes{fstype!~"^(autofs|binfmt_misc|cgroup2?|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|pstore|rpc_pipefs|securityfs|sysfs|tracefs)$", mountpoint="/"} / node_filesystem_size_bytes{fstype!~"^(autofs|binfmt_misc|cgroup2?|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|pstore|rpc_pipefs|securityfs|sysfs|tracefs)$", mountpoint="/"}) * 100) > 60`
这个查询会过滤掉一些虚拟文件系统类型，确保我们只关注实际的根分区，并计算使用率是否大于 60%。
现在，我将使用 `xxx_Pro-execute_query` 工具来执行这个查询。
**
execute_query已完成
**
好的，根据您提供的查询结果，以下节点的根分区磁盘使用率大于 60%：
1. **Instance:** `xx.xx.xx.xx:9100` **使用率:** 71.78% **详细信息:** `{"device": "/dev/sdb2", "fstype": "ext4", "instance": "10.7.3.2:9100", "job": "coding", "mountpoint": "/"}`
1. **Instance:** `xx.xx.xx.xx:9100` **使用率:** 62.52% **详细信息:** `{"device": "/dev/mapper/root--vg-root", "fstype": "ext4", "instance": "10.177.82.1:9100", "job": "coding", "mountpoint": "/"}`
1. **Instance:** `xx.xx.xx.xx:9100` **使用率:** 70.29% **详细信息:** `{"app": "srv", "env": "sit", "device": "/dev/mapper/ubuntu--vg-ubuntu--lv", "fstype": "ext4", "instance": "xx.xx.xx.xx:9100", "job": "apps-srv", "mountpoint": "/"}`
这些节点（`xx.xx.xx.xx:9100`，`xx.xx.xx.xx:9100`，`xx.xx.xx.xx:9100`）的根分区磁盘使用率都超过了 60% 的阈值。您可能需要进一步检查这些节点上的磁盘使用情况，找出占用大量空间的文件或目录，并考虑进行清理或扩容。
上述结果都是正确的，对比看gemini简单明了，deepseek略显啰嗦。我并没有需要解决方案，就不需要他给出。
总结
目前我也只是，初步体验。 总体看下来mcp的效果是比较依赖其所调用的模型的。完成对于常用的查询磁盘使用，按照指标查询数据。都是比较好用且准确的。 我对比了deepseek-chat和gemini-2.5-flash-preview-04-17 总体看下来gemini的效果更好。简洁明了，deepseek存在调用慢而且经常报错。输出的结果也不稳定产生了大量的无用信息。（叠甲：我这块只对比了deepseek和gemini这两个模型在部分问题的效果无拉踩倾向）。这次也是初步体验，后续点赞转发三连多，我会继续深度使用体验。看mcp在解决复杂的现实场景效果如何。以及自己动手开发一个✅自己的mcp Server。
