📌 同一个月初，两种做法的日程对比
传统模式：上午在 Prometheus 逐条手敲 PromQL 拉曲线存档 → 中午登主机核水位 → 下午整理 Excel 拉趋势、写建议 → 第二天评审会上被追问"这个数字怎么来的"，再补证据。耗时约 1–2 人天。
智能体模式：一句"出本月容量评估报告"→ 采集、外推、规则判定、报告生成一气呼成 → 运维人员把时间花在复核建议、结合业务计划修正结论上。执行耗时分钟级，人的工作量集中在最有价值的判断环节。
扩容该不该批？下个月哪台主机会先撑不住？停掉的服务还在吃资源吗？ 让智能体用同一套"采集 → 聚合 → 外推 → 决策"流水线，把容量评估从拍脑袋变成有算法、有阈值、有建议的工程实践。
日常巡检回答的是"现在有没有事"，容量管理回答的是"未来会不会出事、钱花得值不值"。它同时压着三个问题：
传统做法里，这三件事分散在 Prometheus 手工拼查询、登主机敲命令、Excel 拍预测三个动作里，口径不统一，结论靠经验。金蝶Apusic应用运维与治理智能体的思路是：一条命令触发全链路——通过平台的 CLI 工具拉取服务/实例清单，驱动 Prometheus 完成 7 天聚合与 30 天外推，套用决策规则，最终产出一份带扩缩容建议的 HTML 报告。
* 以上为某次真实容量评估的规模快照，服务与主机均已化名。
主机水位是"房租"，服务侧水位才是"饭量"。两者要分开看。
智能体在服务侧采集两类核心指标：
通过进程级监控指标 process_resident_memory_bytes（按平台服务来源过滤）统计每个服务进程的实际常驻内存，做 7 天平均与 30 天外推，并按服务名聚合各实例之和。真实样例：
| 服务（化名） | 进程内存 7d 平均 | 进程内存 30d 预测 | 判读 |
|---|---|---|---|
| 缓存服务 A（单实例） | 16.9 MB | 187.5 MB | 斜率偏高，列入观察 |
| 缓存服务 B（已停止） | 17.8 MB | 17.6 MB | 历史曲线平稳 |
| 负载均衡服务 | 9.0 MB | 11.9 MB | 低位平稳 |
对缓存类中间件，进程内存还不够，真正的容量风险是数据内存逼近 maxmemory 上限。智能体采集 redis_memory_used_bytes 与配置项 redis_config_maxmemory，计算"占上限百分比"的 7 天均值与 30 天预测，且预测值会按 maxmemory 封顶（数据内存不可能超过配置上限，封顶后外推才有意义）。样例：数据内存 841 KB / 上限 2 GB，占比 0.04%，容量富余一目了然。
服务侧评估还叠加了两个稳定性信号：节点就绪数（ready/node）与重启次数。重启次数本身不是容量指标，但"高重启 + 高水位"组合意味着资源压力可能正在制造故障。这条规则在维度三的决策中会用到。
服务要扩容，先得问承载它的主机答不答应。
智能体对每台承载主机采集 CPU、内存、磁盘三类水位，每类都给出7 天平均（现状）与30 天线性外推（趋势）两个数字。需要说明："7 天历史 + 30 天预测"是本次评估任务提出的口径要求，skill 只提供通用的指标查询能力，并未预设时间窗口。核心 PromQL 如下：
# 主机 CPU 使用率（7 天平均 / 30 天外推） avg_over_time((100 - avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)[7d:5m]) predict_linear(... 同上表达式 ..., 30d) # 主机内存使用率 avg_over_time((1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)[7d:1h]) * 100 # 根分区磁盘使用率 avg_over_time((100 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100)[7d:1h])
某次评估输出的主机水位总览（IP 已化名，每主机 32 GB 内存）：
| 主机 | CPU 7d | CPU 30d | 内存 7d | 内存 30d | 磁盘 7d | 磁盘 30d |
|---|---|---|---|---|---|---|
| host-A | 4.08% | — | 67.04% | — | 41.24% | 44.75% |
| host-B | 1.30% | 1.12% | 23.20% | 24.32% | 1.81% | 1.84% |
| host-C | 1.81% | 26.95% | 8.66% | 43.82% | 6.81% | 16.46% |
| host-D | 3.53% | 63.52% | 6.83% | 34.26% | 8.61% | 17.55% |
这张表里有三个值得运维注意的读法：
预测不是算命，是"外推 + 阈值 + 决策树"三件套。
对每个水位序列执行 predict_linear(metric[7d], 30d)：基于近 7 天数据做最小二乘线性回归，外推 30 天后的值。其中 7 天/30 天两个窗口是本次任务的口径参数，可按需调整。百分位指标（CPU/内存/磁盘使用率）统一做 0%–100% 边界截断，防止数学上出现"128% 的内存"这种无意义数字。
决策不靠大模型自由发挥，而是跑在一组显式阈值上——阈值即代码，任何人可审、可调。需要如实说明阈值的来源层级：配套 skill 只提供了指标查询能力，并未定义任何阈值标准；下表阈值是报告生成脚本首次生成时选定的启发式默认值，不属于厂商或行业标准，投产前应按自身历史基线校准；"语义"一列为对阈值设计意图的解读性注释。
| 触发条件（任一满足即告警该维度） | 阈值 | 语义 |
|---|---|---|
| 内存：7d 均值 或 30d 预测 | > 60% / > 80% | 现状偏高 或 趋势触线 |
| 磁盘：7d 均值 或 30d 预测 | > 80% / > 90% | 磁盘容忍度更高，阈值更宽 |
| CPU：7d 均值 或 30d 预测 | > 50% / > 60% | CPU 突发多，均值阈值放低 |
| 缓存数据内存占 maxmemory 的 30d 预测 | > 80% | 提前量留给数据增长 |
| 重启次数（近 7 天） | > 5000 | 稳定性风险，叠加资源条件升级处置级别 |
注意：数值本身为会话生成的启发式默认值，无权威标准出处，使用前请结合平台实际水位基线调整。
规则命中后按优先级合成最终建议：已停止 → 缩容/清理；高重启 × 资源超标 → 扩容该资源 + 排查稳定性根因；单项超标 → 扩容对应资源；全部未触线 → 保持现状。本次评估五个服务的实际输出：
| 服务（化名） | 关键证据 | 结论 |
|---|---|---|
| 单机应用服务器 | 重启 159,044 次 + CPU 30d 预测 63.5% | 扩容 CPU 并排查稳定性 |
| 单机配置中心 | 重启 9,992 次 + 主机内存 7d 均值 67.0% + 告警命中 516 次 | 扩容内存 并排查稳定性 |
| 缓存服务 B | 就绪 0/2，长期停止，节点配置仍占位 | 缩容/清理 释放闲置资源 |
| 缓存服务 A | 7d 水位平稳，30d 外推未触线 | 保持现状 |
| 负载均衡服务 | 全指标低位平稳（CPU 外推 1.12%） | 保持现状 |
注意第三行：容量评估不只找"要扩容的"，也找"该缩容的"。停止的服务继续保留节点配置，等于白占主机资源——这是很多平台账单里看不见的浪费。
对想复用这套做法的同行，这是可以照抄的骨架。
[7d:5m]、[7d:1h] 这类步长能显著降低长窗口聚合的计算量，步长太细会让 Prometheus 超时；avg by(instance)，再从标签里截取 IP 做归组键，避免多网卡/多端口的重复序列干扰；智能体只做只读采集与建议输出：查询走平台 CLI 的既有认证与权限体系，报告不触碰任何变更操作；扩缩容动作本身（调整规格、增删节点、清理服务）仍由运维人员评审后通过平台执行。报告内每条建议都附原始证据数字与控制台跳转链接，结论可追溯、可复核、可否决。
以"每月一次全平台容量评估"为例，逐环节对比。
| 环节 | 传统模式（人工） | 智能体模式 |
|---|---|---|
| 数据采集 | 在 Prometheus 查询页逐条手拼 PromQL 拉曲线、登主机敲命令，服务与主机指标分开收集 | CLI 一次拉齐服务/实例/告警清单，PromQL 批量查询自动归组 |
| 趋势判断 | 肉眼看图估趋势，或 Excel 手拉曲线 | predict_linear 对每个序列统一做线性外推，口径一致 |
| 扩容决策 | 凭经验拍阈值，评审会上各执一词 | 显式阈值常量 + 规则合成建议，评审有统一标尺（阈值需按基线校准） |
| 报告产出 | 手工拼文档，半天起步，下次从零再来 | 一份 HTML 含水位表、趋势、建议、控制台链接，分钟级生成，可重复执行 |
| 覆盖度 | 重点服务重点看，边缘服务常漏；已停止的服务容易被遗忘 | 全量实例无差别覆盖，停止服务也会被标记为缩容/清理对象 |
| 决策追溯 | 结论靠会议记录与记忆，事后难复盘 | 每条建议附证据数字与来源标注，可随时复核与否决 |
传统模式：上午在 Prometheus 逐条手敲 PromQL 拉曲线存档 → 中午登主机核水位 → 下午整理 Excel 拉趋势、写建议 → 第二天评审会上被追问"这个数字怎么来的"，再补证据。耗时约 1–2 人天。
智能体模式：一句"出本月容量评估报告"→ 采集、外推、规则判定、报告生成一气呼成 → 运维人员把时间花在复核建议、结合业务计划修正结论上。执行耗时分钟级，人的工作量集中在最有价值的判断环节。
| 动作 | 说明 |
|---|---|
| 月初跑一次全量报告 | 生成 HTML 归档，作为本月扩缩容评审的输入材料 |
| 红线服务 48 小时内闭环 | 扩容类建议（红色徽标）进入工单，处理结果回填报告备注 |
| 停止服务按季度清理 | 缩容/清理类建议（蓝色徽标）纳入季度资源回收清单 |
| 阈值按平台水位校准 | 阈值是显式常量，不同规模的平台可按自身基线调整 |
| 预测与业务计划对表 | 遇大促/上线/迁移等已知增量，人工修正外推结论后再决策 |
| 补齐监控端点 | 对"无可用指标"的服务开启自身 exporter，消灭评估盲区 |