简介这份Python源码资源面向数据分析与运维开发初学者聚焦应用系统负载分析与磁盘容量预测这一典型数据挖掘场景帮助读者理解如何从历史监控数据中提取模式并构建预测模型。压缩包共6个文件以4个xls数据表为核心分别承载原始磁盘数据、预处理后数据及预测数据另含1个py主程序脚本和1个txt模块导入说明整体仅20KB轻量易读适合直接运行调试。资源围绕数据挖掘算法的基本流程展开从数据探索、概念描述到参数确定与模型应用完整呈现了负载与容量预测的实现思路。目前已有561人学习下载可作为课程实验、毕业设计或运维监控项目的参考范例帮助读者快速掌握数据预处理、特征分析与预测建模的衔接方式并在此基础上迁移到其他容量规划场景。1. 应用系统负载分析与磁盘容量预测从一份 Python 源码包说起线上系统最怕的不是流量高峰而是磁盘悄悄写满的那一刻。日志暴涨、临时文件堆积、数据库 WAL 撑大这些场景在监控告警触发时往往只剩几十分钟处置窗口。应用系统负载分析与磁盘容量预测这套 Python 源码解决的正是把「事后救火」变成「提前扩容」的问题它采集 CPU、内存、IO 等待和磁盘使用率等指标用时间序列模型预测未来一段时间的容量走势在真正写满之前给出扩容建议。适合运维工程师、SRE、后端开发和做课程设计的学生——只要你会装 Python、能读懂 pandas 和 matplotlib 的基本用法就能把这份源码跑起来并改成自己业务的版本。下面按「先跑通、再讲原理、最后避坑」的顺序拆开讲。2. 环境搭建与源码目录结构把 Python 源码包跑起来的第一公里拿到一个.rar后缀的 Python 源码包第一件事不是急着看代码而是先把运行环境对齐。很多新手卡在python安装和vscode python环境配置上代码本身没问题环境版本不对就报一堆 ImportError。这一章先把环境、依赖、目录结构三件事理清楚后面读代码才顺畅。2.1 Python 版本与依赖库的选型理由磁盘容量预测这类任务核心依赖是 pandas 做时间序列处理、numpy 做数值计算、scikit-learn 或 statsmodels 做建模、matplotlib 做可视化。这几个库对 Python 版本有隐性要求pandas 2.x 要求 Python 3.9 以上statsmodels 的 ARIMA 在 3.8 上偶发兼容问题。我一般直接上 Python 3.10 或 3.11避开 3.12 刚发布时的第三方库轮子缺失期。安装依赖不要一个个 pip源码包里通常带requirements.txt直接批量装# 建议先建虚拟环境避免污染系统 Python python -m venv venv # Windows 激活 venv\Scripts\activate # Linux / macOS 激活 source venv/bin/activate # 批量安装依赖-i 指定国内镜像加速 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple逻辑说明虚拟环境把这份源码的依赖和系统其他项目隔离避免版本冲突。-i参数换成国内镜像源装 pandas、numpy 这种大包时能省不少时间。如果requirements.txt里没锁版本号建议手动补上pandas2.1.4、numpy1.26.2这类明确版本否则不同机器装出来的结果可能不一致预测曲线对不上。参数说明python -m venv venv里的第二个venv是环境目录名可以改成env或项目名。激活后命令行前面会出现(venv)前缀看到这个前缀才说明环境生效了。如果pip install报 SSL 证书错误多半是公司网络代理问题换镜像源或找网管开白名单。2.2 源码目录的典型结构与各文件职责一份规范的负载分析与容量预测源码目录结构通常长这样不同作者命名略有差异但职责划分大同小异目录/文件职责读代码优先级data/存放采集的指标 CSV 或数据库导出文件高先看数据长什么样config.py数据库连接、阈值、预测步长等配置高改参数先改这里collector.py采集 CPU/内存/磁盘指标中看采集频率和字段preprocess.py缺失值填充、异常值处理、重采样高决定预测质量model.pyARIMA / Prophet / LSTM 建模与训练高核心逻辑predict.py调用模型输出未来容量中visualize.py画历史曲线和预测曲线低但排查时有用main.py串起采集→预处理→建模→预测→出图高入口读代码的顺序建议是先看data/里的样本数据知道字段名和时间粒度再看config.py知道可调参数然后从main.py顺着调用链往下读。不要一上来就啃model.py没有数据上下文模型参数看不懂。2.3 用样本数据跑通第一次预测在改任何代码之前先用源码自带的样本数据跑一遍确认环境没问题# 进入源码根目录 cd disk_capacity_predict # 直接运行主程序用默认配置和样本数据 python main.py --data data/sample_disk.csv --predict-days 7逻辑说明--data指定输入数据文件--predict-days指定预测未来多少天。第一次跑通比什么都重要看到终端打印出预测结果、目录下生成output/图片说明环境、依赖、数据格式三关都过了。参数说明如果源码不支持命令行参数很多课程设计源码是硬编码路径就打开main.py把data_path变量改成实际路径。--predict-days设 7 是保守值预测步长越长误差越大先跑 7 天看趋势稳定后再试 30 天。跑通后打开生成的 PNG横轴是日期纵轴是磁盘使用率百分比实线是历史虚线是预测两条线衔接处是否平滑是判断模型好坏的第一眼标准。提示如果运行报ModuleNotFoundError先确认虚拟环境激活了没有如果报FileNotFoundError检查数据路径是相对路径还是绝对路径相对路径是相对于你执行命令的目录不是源码目录。3. 负载指标采集与磁盘容量特征工程预测准不准八成看这里模型再花哨喂进去的数据是垃圾出来的预测就是玄学。磁盘容量预测的准确度八成取决于特征工程做得好不好。这一章讲清楚采集哪些指标、怎么处理缺失和异常、怎么构造对预测有用的特征。3.1 采集哪些指标CPU、内存、IO 等待与磁盘使用率的关系单纯看磁盘使用率一条曲线做预测遇到业务突增就会翻车。磁盘增长往往和负载相关IO 等待高说明写入压力大CPU 高说明业务繁忙这些指标是磁盘增长的先行信号。常见做法是采集四类指标磁盘使用率disk_used_percent核心预测目标按挂载点分别采集磁盘写入速率disk_write_bytes直接反映增长动力IO 等待占比iowait_percent写入瓶颈的先行指标CPU 和内存使用率业务负载的代理变量采集频率建议 5 分钟一次太低1 小时会丢失突增细节太高10 秒数据量爆炸且噪声大。采集脚本核心逻辑import psutil import pandas as pd from datetime import datetime def collect_disk_metrics(mount_point/): 采集单个挂载点的磁盘与负载指标 usage psutil.disk_usage(mount_point) io psutil.disk_io_counters() cpu psutil.cpu_percent(interval1) mem psutil.virtual_memory().percent return { timestamp: datetime.now(), mount: mount_point, disk_used_percent: usage.percent, # 磁盘使用率预测目标 disk_write_bytes: io.write_bytes, # 累计写入字节需做差分 cpu_percent: cpu, mem_percent: mem, } # 追加写入 CSV避免内存里攒一大堆 row collect_disk_metrics(/data) pd.DataFrame([row]).to_csv(metrics.csv, modea, headerFalse, indexFalse)逻辑说明psutil.disk_usage直接给出使用率百分比disk_io_counters给的是累计字节数必须做差分才能得到「这段时间写了多少」否则喂给模型的是单调递增的累计值预测毫无意义。modea追加写入配合定时任务cron 或 Windows 计划任务每 5 分钟跑一次。参数说明mount_point要按实际挂载点填Linux 上常见/、/data、/varWindows 上是C:\\、D:\\。cpu_percent(interval1)里的 1 表示采样 1 秒设 0 会返回自上次调用以来的平均值第一次调用不准建议设 1。3.2 缺失值与异常值处理别让一个脏点毁掉整条预测曲线真实采集数据一定有缺失采集器重启、网络抖动和异常某次批量任务导致写入暴涨。直接丢给 ARIMA缺失值会让模型报错异常值会把预测曲线拉偏。处理策略分三步import pandas as pd import numpy as np df pd.read_csv(metrics.csv, parse_dates[timestamp]) df df.sort_values(timestamp).set_index(timestamp) # 第一步按 5 分钟重采样缺失时间点补 NaN df df.resample(5min).mean() # 第二步线性插值填补短缺口超过 1 小时的缺口标记为不可信 df[disk_used_percent] df[disk_used_percent].interpolate( methodlinear, limit12 # 12 * 5min 1 小时 ) # 第三步用 IQR 法识别异常值替换为前后均值 q1 df[disk_used_percent].quantile(0.25) q3 df[disk_used_percent].quantile(0.75) iqr q3 - q1 lower, upper q1 - 1.5 * iqr, q3 1.5 * iqr outliers (df[disk_used_percent] lower) | (df[disk_used_percent] upper) df.loc[outliers, disk_used_percent] np.nan df[disk_used_percent] df[disk_used_percent].interpolate(methodlinear)逻辑说明重采样把不规则时间点对齐到固定间隔是时间序列建模的前提。limit12限制插值最多补 12 个点超过就留 NaN因为长时间缺失靠插值补出来的数据是编的会误导模型。IQR 法比 3σ 法更稳健磁盘使用率这种非正态分布的数据用 IQR 更合适。参数说明resample(5min)的间隔要和采集频率一致采集是 5 分钟就写 5min写错了会导致数据错位。limit的值按业务容忍度调日志类磁盘增长快缺口容忍度低可以设 6半小时归档类磁盘增长慢设 24 也行。3.3 构造滞后特征与滑动窗口让模型看到增长趋势ARIMA 这类模型靠历史值预测未来但原始序列只有当前值构造滞后特征能让模型「看到」增长速度和加速度# 滞后特征前 1、2、3 个时间点的值 for lag in [1, 2, 3]: df[flag_{lag}] df[disk_used_percent].shift(lag) # 滑动窗口统计过去 1 小时、6 小时、24 小时的均值和斜率 df[rolling_mean_12] df[disk_used_percent].rolling(12).mean() # 1 小时 df[rolling_mean_72] df[disk_used_percent].rolling(72).mean() # 6 小时 df[rolling_std_72] df[disk_used_percent].rolling(72).std() # 增长斜率用差分近似 df[growth_rate] df[disk_used_percent].diff() df[growth_accel] df[growth_rate].diff() df df.dropna() # 去掉构造特征产生的头部空值逻辑说明shift(lag)把过去的值挪到当前行模型就能学到「昨天这个点是多少」。滑动均值平滑噪声滑动标准差反映波动大小波动大的磁盘要留更多余量。growth_rate是一阶差分代表每天增长多少个百分点这是判断「还能撑几天」的直接依据。参数说明窗口大小 12 对应 1 小时5 分钟 × 1272 对应 6 小时288 对应 24 小时。窗口不是越多越好特征太多会过拟合一般选 3 个时间尺度短、中、长就够。dropna()会删掉前几行如果数据总量少可以改用fillna(0)但要清楚这是在引入偏差。注意特征工程做完一定要画图看一眼。把disk_used_percent和growth_rate画在双轴图上如果增长斜率在某个时间点突然跳变回去查那个时间点是不是有批量任务或数据异常别让脏数据进模型。4. 磁盘容量预测建模ARIMA、Prophet 与线性回归怎么选建模这一步最容易陷入「哪个模型高级用哪个」的误区。磁盘容量预测的本质是带趋势的时间序列外推不是图像识别不需要上深度学习。这一章把三种常见方案的适用场景、代码实现和参数调优讲清楚让你按数据特征选而不是按热度选。4.1 ARIMA 的阶数怎么定ACF、PACF 与自动定阶ARIMA(p, d, q) 三个参数里d 是差分次数把非平稳序列变平稳p 是自回归项q 是移动平均项。定阶靠 ACF自相关和 PACF偏自相关图import pandas as pd import matplotlib.pyplot as plt from statsmodels.graphics.tsaplots import plot_acf, plot_pacf from statsmodels.tsa.arima.model import ARIMA series df[disk_used_percent] # 画 ACF 和 PACF 图辅助定阶 fig, axes plt.subplots(2, 1, figsize(10, 8)) plot_acf(series.diff().dropna(), axaxes[0], lags40) plot_pacf(series.diff().dropna(), axaxes[1], lags40) plt.savefig(acf_pacf.png) # 按图定阶后拟合这里以 (2,1,2) 为例 model ARIMA(series, order(2, 1, 2)) result model.fit() print(result.summary()) # 预测未来 7 天按 5 分钟粒度是 2016 个点 forecast result.forecast(steps2016)逻辑说明先做一阶差分d1把趋势去掉再看差分后序列的 ACF 和 PACF。ACF 拖尾、PACF 截尾在 p 阶说明是 AR(p)ACF 截尾在 q 阶、PACF 拖尾说明是 MA(q)。实际中很少手工精确定阶更常用pmdarima的auto_arima自动搜索。参数说明order(2,1,2)里 d1 表示做一次差分磁盘使用率通常一次差分就平稳。steps2016是 7 天 × 24 小时 × 12 个 5 分钟点。预测步长越长置信区间越宽超过 30 天的预测基本只能看趋势方向不能看具体数值。4.2 Prophet 的节假日与突变点处理适合有周期性业务的场景如果磁盘增长有明显的周期性比如每天白天涨、晚上平周末不涨Prophet 比 ARIMA 更省心它自动处理趋势、周期和突变点from prophet import Prophet # Prophet 要求列名必须是 ds时间和 y值 prophet_df df.reset_index()[[timestamp, disk_used_percent]] prophet_df.columns [ds, y] model Prophet( changepoint_prior_scale0.05, # 突变点灵敏度越大越敏感 seasonality_modemultiplicative, # 增长幅度随基数放大时用乘法 daily_seasonalityTrue, weekly_seasonalityTrue, ) model.fit(prophet_df) # 构造未来 7 天的时间框 future model.make_future_dataframe(periods2016, freq5min) forecast model.predict(future) # 只保留预测部分 pred forecast[[ds, yhat, yhat_lower, yhat_upper]].tail(2016)逻辑说明changepoint_prior_scale控制趋势变化的灵活度默认 0.05调大0.1~0.5会让模型更快跟随突变但也更容易过拟合噪声。seasonality_mode选multiplicative是因为磁盘使用率是百分比增长幅度往往和当前基数成比例。参数说明periods2016和 ARIMA 一样是 7 天。yhat_lower和yhat_upper是置信区间扩容决策建议看yhat_upper按最坏情况留余量。如果业务有明显的大促或月末结算可以在model.add_country_holidays或自定义add_seasonality里加进去。4.3 简单线性回归作为基线别小看它很多时候够用磁盘容量预测在多数场景下就是一条缓慢上升的斜线线性回归加滑动平均就能给出足够好的结果而且可解释性最强import numpy as np from sklearn.linear_model import LinearRegression # 用时间序号做特征磁盘使用率做目标 df[t] np.arange(len(df)) X df[[t]].values y df[disk_used_percent].values model LinearRegression().fit(X, y) # 预测未来 7 天 future_t np.arange(len(df), len(df) 2016).reshape(-1, 1) pred model.predict(future_t) # 算「还能撑几天」从当前值到 100% 需要多少个点 slope_per_point model.coef_[0] current y[-1] points_to_full (100 - current) / slope_per_point days_to_full points_to_full * 5 / 60 / 24 print(f按当前增速预计 {days_to_full:.1f} 天后磁盘写满)逻辑说明线性回归把时间当自变量斜率就是每个时间点的增长量直接换算成「还能撑几天」这是运维最想要的结论。它不处理周期性和突变但胜在稳定、可解释、不会给出离谱预测。参数说明slope_per_point是每个 5 分钟点的增长百分点乘以 5/60/24 换算成天。如果斜率是负的磁盘在释放points_to_full会是负数说明短期无风险代码里要加判断避免除零或负数误导。提示三种模型建议都跑一遍用最后 20% 的历史数据做验证算 MAE 和 MAPE选误差最小的。不要迷信「高级模型」我见过线性回归 MAPE 3%、LSTM MAPE 8% 的情况数据规律简单时简单模型反而赢。5. 避坑与排查磁盘容量预测源码跑不通的五个血泪经验这一章是我和身边同事踩过的坑按「现象 → 原因 → 解决」写遇到问题先对照这里查能省不少时间。5.1 预测曲线是一条直线完全不跟随历史波动现象跑出来的预测图历史曲线有起伏预测部分却是一条笔直的斜线。原因模型没学到周期性或者特征里只有时间序号没有滞后项。ARIMA 的 d 设太大把波动差没了或者 Prophet 的seasonality_mode设成了additive但数据实际是乘法增长。解决先画 ACF 图确认序列是否平稳d 从 1 开始试Prophet 换成multiplicative线性回归加上hour、dayofweek这类周期特征。判断标准是预测曲线应该有和历史相似的日内波动而不是一条直线。5.2 预测值超过 100% 或低于 0%现象预测未来 30 天结果出现 120% 或 -5% 这种物理上不可能的值。原因模型是无约束的外推ARIMA 和线性回归都会线性延伸不认 0~100 的边界。解决预测后做截断pred np.clip(pred, 0, 100)。更根本的办法是预测「剩余空间」而不是「使用率」剩余空间到 0 就是写满天然有下界。或者用对数变换把值域压到实数域再建模预测后反变换回来。5.3 时间戳时区不一致导致预测错位现象预测曲线和历史曲线在时间轴上对不上差了几个小时。原因采集时用了本地时间建模时 pandas 按 UTC 解析或者反过来。跨时区部署的采集器和分析机时区不同。解决统一用 UTC 存储和计算展示时再转本地时区。pandas 里用pd.to_datetime(..., utcTrue)强制 UTCtz_convert转展示时区。检查df.index.tz是不是 NoneNone 说明没设时区容易出问题。5.4 数据量太少导致模型报错或预测离谱现象只有几天数据ARIMA 报「矩阵奇异」Prophet 预测出天文数字。原因ARIMA 定阶需要足够样本估计参数数据少于 2 个周期比如日周期至少 2 天周周期至少 2 周时参数估计不稳。解决数据不足时退回线性回归或简单移动平均别硬上 ARIMA。采集阶段至少攒够 2 周数据再建模。如果急着要结果用「当前值 平均日增长 × 天数」的朴素法虽然粗糙但不会给出离谱值。5.5 依赖库版本冲突导致 import 失败现象import pandas报numpy版本不兼容或statsmodels报scipy缺失。原因源码包里的requirements.txt没锁版本pip 装了最新版和代码里用的旧 API 不匹配。解决按报错信息逐个降级pip install numpy2.0这类约束。更省事的办法是找作者提供的环境导出文件conda env export或pip freeze直接复现原环境。实在搞不定就新建虚拟环境按pandas → numpy → scipy → statsmodels的顺序装让 pip 自己解决依赖。6. 把预测接入告警从「能跑」到「有用」的最后一步模型跑通、曲线画出来只是完成了演示。真正让这套源码产生价值是把它接入日常运维流程定时预测、按剩余天数分级告警、自动生成扩容工单。我一般用 cron 每天凌晨跑一次预测把「预计写满天数」写进监控系统小于 7 天告警、小于 3 天电话通知。# 每天凌晨 2 点跑预测结果追加到日志 0 2 * * * cd /opt/disk_predict /opt/disk_predict/venv/bin/python main.py \ --data /data/metrics.csv --predict-days 30 /var/log/disk_predict.log 21逻辑说明用虚拟环境的绝对路径调 Python避免 cron 环境变量缺失导致找不到包。追加日志21把错误也写进去出问题能回溯。预测结果建议同时写一份 JSON 到固定路径方便监控系统读取。参数说明--predict-days 30是预测窗口告警阈值另设。我习惯把「剩余天数」和「置信下界剩余天数」都算出来按后者告警更保守。如果业务有明确的扩容审批周期比如 5 个工作日阈值就设成审批周期加缓冲。验证预测准不准别只看图。每周把上周的预测值和实际值拉出来对比算 MAPE记录在表格里。连续几周 MAPE 超过 15%说明业务模式变了该重新调参或换模型了。我自己的习惯是每月复盘一次预测误差把误差大的时间段和当时的业务事件对上慢慢就能摸清哪些突变是模型学不会、必须人工干预的。这套源码的价值不在于模型多先进而在于把「磁盘什么时候满」这个模糊问题变成了可量化、可告警的数字。先跑通再按自己业务的数据特征调最后接入流程三步走下来它就能真正帮你少熬几个半夜扩容的夜。希望帮到你。本文还有配套的精品资源点击获取