最近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.exeOS 名称: Microsoft Windows 11 家庭中文版OS 版本: 10.0.26100 暂缺 Build 26100系统类型: x64-based PC处理器: 安装了 1 个处理器。 [01]: Intel64 Family 6 Model 170 Stepping 4 GenuineIntel ~1200 MhzBIOS 版本: LENOVO N8CN27WW, 2024/4/29clone代码
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.lock6 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 - (可用空间/总空间)) * 1001. 筛选挂载点为根分区("/")的文件系统1. 筛选使用率大于60%的节点这个查询会返回所有根分区使用率超过60%的节点及其当前使用率值。结果将包含实例标签(instance)标识具体的节点。如果您需要更详细的信息，比如：- 查看具体使用率数值- 获取这些节点的其他相关信息(如主机名、IP等)- 设置时间范围查询历史数据请告诉我，我可以进一步调整查询或提供附加信息。**execute_query已完成**根据查询结果，以下是根分区磁盘使用率超过60%的Linux主机节点列表，已按使用率从高到低排序：### 高磁盘使用率节点清单1. **节点IP**: xx.xx.xx.xx:9100 - 使用率: 71.84% - 设备: /dev/sdb2 - 文件系统类型: ext4 - 挂载点: / - 所属Job: coding1. **节点IP**: xx.xx.xx.xx:9100 - 使用率: 70.36% - 设备: /dev/mapper/ubuntu--vg-ubuntu--lv - 文件系统类型: ext4 - 挂载点: / - 所属Job: apps-srv - 附加标签: - app: srv - env: sit1. **节点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 | Gemini05/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。
