别等炸了才看监控：Linux 性能基线建立与异常识别的实战方法论
概述 你大概率经历过这种场景：凌晨三点被告警吵醒，爬起来看 Grafana，发现 CPU 使用率飙到 85%。你紧张了半天，查了一圈，最后发现——这台数据库服务器每天凌晨 2:50 到 3:10 都会跑定时备份任务，CPU 本来就该到这个数。 问题出在哪？你不知道这台机器"正常"是什么样子。没有基线，85% 是高还是低，你根本判断不了。 性能基线（Performance Baseline）解决的就是这个问题：在系统健康的时候，把关键指标记录下来，形成一份"体检报告"。以后出了异常，拿当前数据跟基线一对比，是真故障还是正常波动，一眼就能看出来。 这篇文章讲的是怎么从零建立一套可落地的 Linux 性能基线体系。不是泛泛而谈"监控很重要"，而是从方法论选择、指标采集、基线建模、异常识别到自动化落地，每一步都给你能直接用的配置和代码。 为什么静态阈值不靠谱 大多数团队的告警配置是这样的：CPU > 80% 告警，内存 > 90% 告警，磁盘 > 85% 告警。这就是静态阈值——一个拍脑袋定的数字，挂在所有机器上。 静态阈值有三个致命问题： 第一，不同业务、不同时段的正常值不一样。 一台跑批处理任务的服务器，CPU 峰值在工作时间冲到 95% 是正常的；一台 API 网关，CPU 持续 70% 就得警惕了。用同一个 80% 阈值套上去，前者天天误报，后者出了事还不报。 第二，绝对值掩盖趋势。 某台机器 CPU 从 30% 缓慢爬到 60%，持续两周。静态阈值看不到——没到 80% 嘛。但这种缓慢上升往往是内存泄漏或连接堆积的前兆，等真到 80% 的时候已经炸了。 第三，无法识别"不正常的好"。 某个核心服务的 QPS 突然从 5000 掉到 200，CPU 使用率跟着降到 10%。静态阈值觉得一切正常——CPU 低着呢。但实际上上游可能挂了，流量根本没进来。 基线解决这些问题的思路很简单：不设固定阈值，而是让系统自己学什么算正常。当实际表现偏离了历史学到的"正常模式"，才触发告警。 USE 方法论：基线采集的骨架 建立基线之前，先得知道采什么指标。乱采一通，采了 200 个指标，80% 没人看，纯属浪费。...