Process Monitor 学习笔记(5.7):长时间运行追踪与日志文件体积的控制
Process Monitor 学习笔记(5.7):长时间运行追踪与日志文件体积的控制
- Process Monitor 学习笔记(5.7):长时间运行追踪与日志文件体积的控制
- 1)适用场景
- 2)为什么日志会巨“大”?
- 3)总体策略(一句话版)
- 4)采集前:把过滤做对
- 4.1 先“短时试跑”10–20分钟
- 4.2 建议的**基础过滤模板**
- 5)采集中:写盘与轮转(核心)
- 5.1 Backing File(写盘)
- 5.2 分段轮转(推荐按“小时/班次/天”)
- 5.3 降低开销的开关
- 6)采集后:保留价值区间,瘦身归档
- 7)两套可落地的“模板方案”
- 7.1 **工作站/办公日**(8–10 小时)
- 7.2 **服务器/在线追踪**(7×24)
- 8)性能与稳定性建议
- 9)常见 QA
- 10)一分钟执行清单(Checklist)
- 结语
Process Monitor 学习笔记(5.7):长时间运行追踪与日志文件体积的控制
一次抓“几分钟”的问题很常见;更难的是全天/多天在线追踪而不把磁盘打爆、也不拖垮系统。本篇给你一套稳定、可复用的长时间采集方案与体积控制技巧。
1)适用场景
- 间歇性卡顿/高 IO 峰值,不确定发生时间;
- 生产主机“偶发错误码”但复现窗口不稳定;
- 需要覆盖整段工作日(开机→使用→关机)的活动证据。
2)为什么日志会巨“大”?
- Procmon默认捕获文件/注册表/进程/网络/Profiling等全量事件;
- 背景进程(浏览器、杀软、同步盘、搜索索引等)会产生海量噪声;
- **Stack(调用栈)与 Profiling(采样)**显著放大事件与条目大小;
- Backing File写盘没有内置上限/轮转(需自行控制)。
3)总体策略(一句话版)
“先过滤,再写盘;分段轮转;只保留问题时间窗的高密度证据。”
- 采集前:用“短时试跑”找准过滤器;
- 采集中:写入 Backing File(非系统盘),按小时/天轮转;
- 采集后:只保留异常前后的 PML;其余归档或删除。
4)采集前:把过滤做对
4.1 先“短时试跑”10–20分钟
- 临时不开 Backing File,在界面实时看事件量曲线;
- 找到最吵的进程/路径(浏览器缓存、杀软、同步工具等),先排除。
4.2 建议的基础过滤模板
-
包含(Include):
Operation
:CreateFile
、ReadFile
、WriteFile
、RegSetValue
、RegCreateKey
、Process Create/Exit
、TCP Connect
(按需启用)- 或仅跟踪目标进程(Process Name/Process Tree)
-
排除(Exclude):
- 浏览器缓存:
Path contains \AppData\Local\...Cache
- 杀软、索引服务、同步盘目录(按实际环境添加)
- 持续高频但与问题无关的路径(如日志/临时目录)
- 浏览器缓存:
✅ 小贴士:当你对过滤非常有把握后,才考虑开启 “Drop Filtered Events” 来从源头减少写盘体积(风险:被过滤的事件将不可恢复)。
5)采集中:写盘与轮转(核心)
5.1 Backing File(写盘)
File → Backing Files…
指定到非系统盘,如D:\ProcmonLogs\current.pml
;- 目录做杀软白名单,避免实时扫描拖慢写入;
- 尽量不要与数据库/大流量业务共享同一物理盘。
5.2 分段轮转(推荐按“小时/班次/天”)
Procmon 没有内建“最大大小/自动轮转”,用命令行 + 计划任务实现。
PowerShell 轮转示例(小时级):
# 新开一段采集
$ts = Get-Date -Format "yyyyMMdd-HHmm"
$log = "D:\ProcmonLogs\pm_$ts.pml"
$cfg = "D:\ProcmonLogs\filters.pmc" # 你提前保存好的过滤配置
& "$env:ProgramFiles\Procmon\procmon.exe" /Quiet /Minimized /BackingFile "$log" /LoadConfig "$cfg"# …运行1小时后(由计划任务触发)停止并开始下一段
# Stop:
& "$env:ProgramFiles\Procmon\procmon.exe" /Terminate# 立即启动下一段(新任务会再次执行“新开一段采集”的脚本)
任务计划建议
- 建 2 个计划任务:
① 整点运行“Stop(/Terminate)”;
② 紧接着运行“Start(/BackingFile+配置)”; - 产物为:
pm_YYYYMMDD-HHMM.pml
按小时切片,可控可删。
5.3 降低开销的开关
- 关闭 Profiling Events(
Options → Enable Profiling Events
取消勾选),除非你在做 CPU 采样分析; - 按需开启
Capture Call Stacks
(调用栈)——溯源很有用,但体积显著增大; - 限制 UI 历史深度(History Depth)只影响界面显示,不显著减小写盘体积(Backing File 仍全量写入)。
6)采集后:保留价值区间,瘦身归档
-
先用
Tools → Process Tree
标出异常时间段的关键进程; -
通过 Time of Day 轴 & Duration 高亮 快速锁定“长耗时/错误码”事件;
-
File → Save…
导出两份:- PML(保真):用于深度复盘/二次筛选;
- CSV(聚合):喂给 Excel/Power BI 做统计图;
-
对无异常的时段日志批量删除或 7z 压缩(PML 压缩率通常可观)。
7)两套可落地的“模板方案”
7.1 工作站/办公日(8–10 小时)
- 过滤:包含目标业务进程 +
CreateFile/Reg*/Process Create
,排除浏览器缓存/杀软; - 栈:关闭(先定位业务面问题,命中后再局部开栈复抓);
- 轮转:每小时一段;保留异常前后 ±30 分钟,其余压缩/清理。
7.2 服务器/在线追踪(7×24)
- 过滤:仅跟业务进程/服务名(或端口对应进程),强过滤路径噪声;
- 栈:视场景按需;建议只对嫌疑进程单独开栈;
- 轮转:每 2–4 小时一段;配额策略:保留近72小时,其余日归档;
- 可靠性:日志盘单独卷 + 监控剩余空间(到阈值自动清理最旧切片)。
8)性能与稳定性建议
- 优先 SSD;日志目录不做加密压缩(采集中),归档时再 7z;
- 杀软/EDR 对日志目录做排除;
- 过滤/轮转脚本和配置文件存到受控目录,避免被清理器误删;
- 抓“全天”前,先做30 分钟彩排确认体积增长速度和开销。
9)常见 QA
Q1:Drop Filtered Events 要不要开?
A:仅在过滤已充分验证时开启;一旦开启,被过滤事件不会写入,无法回溯。
Q2:History Depth 能限制 PML 大小吗?
A:主要影响 GUI 的内存与显示,不限制 Backing File 体积。日志体积靠过滤与轮转控制。
Q3:长时间抓会不会“卡系统”?
A:正确过滤、关闭 Profiling、把日志写到独立 SSD,通常影响可控;仍建议先做试跑评估。
10)一分钟执行清单(Checklist)
- 用短时试跑确认过滤模板
- Backing File 指向非系统盘
- 建好轮转计划任务(Terminate → Start)
- 仅在确认无误后开启 Drop Filtered Events
- 非关键阶段关闭栈与 Profiling
- 定期清理/压缩无异常日志切片
结语
长时间追踪不是“硬顶着全量去抓”,而是以过滤为核心、以轮转为边界的工程化方案。
按本篇搭好模板,你可以稳定地跑一天,在几分钟内锁定“异常时间窗”,把“偶发问题”变成有证据可讲的事实。
下一篇将进入 5.8:配置设置的导入和导出 —— 团队如何共享“过滤+高亮+视图”模板,做到一键复用、拉齐口径。