1. 为何要把Linux服务器巡检从人肉改为自动1.1 我遇到过的三次本该发现却没发现的事故先讲三个真实发生过的事情都是同一个根因巡检不及时、不全面、靠感觉。第一次是磁盘分区满。那台服务器跑着业务数据库数据目录在 /data当时只有 40% 的告警阈值日常看的时候是 38%第二天业务方反馈写入超时。上去一看 /data 已经 100%日志文件把空间吃光了。问题在于凌晨的定时任务把日志量拉高而我恰好在前一天晚上做完巡检以为第二天早上再检查也来得及结果凌晨就爆了。第二次是内存缓慢增长。服务器连续运行了 200 多天业务进程的 RSS 一直在涨但每天看的时候涨得都不明显。一周之后 OOM 被触发MySQL 直接被系统杀掉。事后复盘发现如果当时的巡检脚本有进程内存与历史基线对比完全能提前三天发现异常趋势。第三次是 NTP 时间偏差。某个内部系统做时间戳校验总是间歇性报错。排查了一整天才发现服务器和标准时间差了 8 分钟。时间偏移是慢慢累积的人工巡检根本不会每天都去对一下时间。这三件事让我想明白一个道理Linux 服务器巡检不能靠今天有空看一下必须把它变成一套定时、可量化、能留痕的自动化机制。1.2 自动化巡检的目标与边界自动化巡检不是把所有监控系统都推倒重来而是在 Zabbix、Prometheus 这类重型监控之外补上轻量、直观、能出报告的一层能力。我给它定位成三个目标每天固定时间自动检查关键指标生成一份人类能直接看懂的巡检报告异常指标要能主动通知到人而不是等人来查报告要可留存、可回溯出了故障能快速给出昨天、上周、上个月的对比。边界也要清楚。自动化巡检不是实时监控它解决的是每天看一眼的问题秒级故障要靠独立监控系统。巡检的合理周期是每天一次或每几小时一次重点是覆盖全面而不是反应快。明确了这三点后面写脚本、做报告、接告警就有方向了不会越做越复杂。2. 巡检脚本的核心指标采集与阈值设定2.1 硬件与系统层CPU、内存、磁盘、负载第一层要采集的是系统最基础的指标命令本身都很常见关键是采集了之后怎么判断。CPU 部分我习惯同时取平均负载load average和 CPU 使用率。很多人只盯着使用率忽略负载其实负载才是更早的预警信号。比如 8 核机器CPU 使用率才 30%但 load average 已经到 7说明大量进程在等待调度CPU 可能已经饱和。判断时用 load 除以核数超过 0.7 就关注超过 1.0 就告警。内存部分重点关注 available 而不是 free。free 命令里的 free 值很容易骗人因为 page cache 会吃掉大量看起来已用的内存但实际上是可回收的。准确做法是从 /proc/meminfo 里读 MemAvailable 字段用它和总内存算使用率。我设置的阈值是 80% 警告、90% 严重光看数值不够还要配合 swap 的使用情况swap 一旦持续增长说明内存真的紧张了。磁盘检查不只是有没有满要拆成空间、inode、IO 三个维度。空间用 df 看使用率inode 用 df -i 看文件数爆了也会导致无法写入。IO 用 iostat 看重点考察 await 和 utilutil 接近 100% 不代表有问题但 await 持续很高通常意味着磁盘响应慢。另外临时目录 /tmp、日志目录 /var/log 这类容易不知不觉写满的路径要有单独的检查项。2.2 网络与服务层连通性、端口、进程第二层检查的是业务能不能正常被访问。端口检查最简单也最有效用 ss -tlnp 或 bash 的 /dev/tcp 方式探测。注意别用 netstat新系统里未必装了 netstatss 是 iproute2 自带的几乎必装。检查内容不只是端口开着没还要看监听地址是不是正确有时候端口是在 127.0.0.1 上监听外部根本访问不到但 ss 一看是 LISTEN 状态容易漏掉。要把实际监听地址也写到报告里。进程检查我推荐用 pgrep -f它能匹配完整命令行。比如 java 进程命令是 /usr/bin/java -jar app.jarpgrep -f app.jar 能精确找到pgrep java 反而可能匹配到其他 Java 进程。检查项要明确记录进程 PID、启动时间、运行时长。运行时长很重要某些服务频繁自动重启说明它一直在崩溃恢复光看进程存在会误判为健康。网络连通性除了本机端口还要检查依赖的外部资源。数据库服务器、Redis、对象存储、NTP 服务器这些是业务的隐形成本。如果应用连着数据库但数据库服务器网络不通应用端口检查是好的业务照样不可用。这部分用 curl 或 nc 探测即可每类资源检查一个关键地址加端口不必全面扫描。2.3 日志与安全层错误日志、登录记录、文件变更第三层是我认为自动化巡检最有价值的部分因为人工巡检几乎不会认真看日志和审计信息。错误日志检查的核心是最近一天新增了多少 ERROR。以应用日志为例可以统计当天日志文件里 ERROR、WARN 的行数和前一天对比。新增量突然翻倍比绝对数量大更能反映问题。日志采集要注意路径通配符比如 /var/log/app/*.log但要排除 .gz 之类的压缩归档。用 tail 或 grep 统计时要避免重复统计——如果定时任务每两小时跑一次直接统计全天的话同一个错误会被重复计。我的做法是用时间戳锚点记录上次巡检到本次巡检之间的增量或者简单点用 awk 按日期过滤当日日志行。登录记录检查是安全事故的第一道防线。检查 /var/log/secure 或 /var/log/auth.log统计当天 Successful login 的来源 IP重点标记非常用 IP 的 root 登录。第一次做这个功能时我发现有台服务器每天固定时间从某个外部 IP 登录 root查了一下是合作方的定时同步脚本虚惊一场。但这类异常就是要先发现再确认不能靠运气。文件变更检查可以用系统自带的 yum install aide 或者更轻量的脚本方案。不需要全盘扫描重点盯几个敏感目录/etc/passwd、/etc/shadow、/etc/ssh/sshd_config、/root/.bashrc、应用配置文件。做法很简单生成一次基线 MD5之后每次巡检对比 MD5 是否变化。很多人上来就想上复杂工具其实对于日常巡检一个几十行的 MD5 对比脚本完全够用。3. 报告输出从一行行数字到一眼看懂的结果3.1 选择HTML报告而不是纯文本的理由早期我做巡检输出都是纯文本邮件一屏幕的指标数字说实话连我自己都不想看。后来切到 HTML 报告效果立刻不一样了。原因不在于美观而在于信息密度的组织方式。纯文本只能按顺序罗列HTML 可以用表格、颜色、分组把健康和不健康的信息分开。巡检报告最高频的使用场景是早上花三十秒快速检查所有服务器这个场景下扫一眼有没有红色标记比逐行读数字高效得多。HTML 报告还有一个实际优势可以内嵌图表。用 JavaScript 图表库比如 ECharts 或者轻量的 Chart.js把历史数据画成折线图趋势异常一眼就能看出来。邮件客户端里大部分支持显示 HTML企业微信和钉钉的消息也能直接打开链接查看。技术选型上不需要上框架。我直接用 Shell 脚本拼 HTML 片段再通过 Python 脚本把数据填进模板。模板用简单字符串替换即可不要引入过重的模板引擎因为巡检脚本要部署到多台机器依赖越少越好。3.2 报告模板的数据组织逻辑一份合格的巡检报告结构上应该遵循结论在前、细节在后的原则。我用的模板分五块总体健康状态用红绿灯标记每台服务器是否健康有多少项异常一眼看全局。异常项明细把所有命中告警阈值的指标列出来附带当前值、阈值、持续时间。核心指标表格CPU、内存、磁盘、负载等常规指标正常值也展示方便横向对比。日志和安全事件当日新增错误行数、可疑登录 IP、文件变更记录。历史趋势对比关键指标最近 7 天的折线图或趋势表。这里有个实用的细节异常项明细一定要放在表格前面。很多运维同事反馈最反感的就是一封报告从头到尾都是数字异常埋在里面找不到。人眼对颜色的敏感度很高把异常项单独摘出来加上红底标注比什么都有效。生成 HTML 片段时要注意转义问题尤其是日志内容里可能包含尖括号、HTML 标签。用简单的 replace 函数把和替换成lt;gt;即可防止报告页面样式被撑破也能避免意外注入。3.3 异常项展示与历史趋势对比异常项不只是列出来就完了要附带上为什么异常的初步判断。这个靠脚本里的规则引擎实现比如磁盘使用率超阈值附上当前占用最大的三个目录CPU 负载高附上 top 5 的 CPU 消耗进程内存不足附加 swap 变化趋势日志错误激增附加错误关键字排名。这些附加信息采集成本很低但对判断问题方向帮助巨大。收到报告的人不用再登录服务器查到底什么导致磁盘满报告里已经给出线索了。历史趋势对比是报告里最容易被忽略却最有价值的部分。我的做法是每天把核心指标追加到本地 CSV 文件然后 Python 读取生成 7 天和 30 天两个维度的趋势。趋势比单点数值更能反映问题比如某台服务器的内存使用率连续三天上涨 2%一周后可能就逼近危险线。单看某一天可能只是轻度偏高趋势却告诉你要提前处理了。Python 生成图表建议直接用 matplotlib 保存 base64 字符串嵌入 HTML避免额外维护静态图片目录。如果服务器上没装 matplotlib也可以用简单表格展示历史数值效果差一些但能接受。4. 告警通知与定时任务让巡检报告主动找上门4.1 邮件/DingTalk/WeCom 通知方式对比报告生成只是第一步能主动通知到位才算闭环。常见的通知方式有几种我实际都用过各有各的适用面。邮件最通用可靠性最高适合做正式存档。SMTP 发送用 Python smtplib 很成熟但要注意收件人邮箱的垃圾邮件策略尤其是公司邮箱外部 SMTP 发来的 HTML 邮件很容易进垃圾箱。解决方法是固定发件人地址、配置 SPF 和 DKIM或者干脆走公司内部邮件网关。企业微信机器人最方便主要用 Webhook 形式。只需要一个 URLPOST 一段 JSON 就能发到群里支持 Markdown 格式。优点是无需额外账号缺点是有频率限制每个机器人每分钟最多 20 条对巡检报告这种低频场景完全够用。钉钉机器人类似区别在于签名机制和关键词安全设置。钉钉自定义机器人需要加签密钥要放在脚本配置里统一管理建议单独建配置目录权限设成 600。我现在的组合方案是正常报告发邮件存档异常告警同时发企业微信群。这样既不会因为每天都发消息导致大家麻木又能保证真正需要关注的问题能第一时间触达。始终不要全量内容都推给所有人告警风暴比没告警更可怕。4.2 定时任务的坑路径、环境变量、锁机制写 crontab 定时任务时最容易踩坑的就是环境变量。cron 执行时环境变量和手动执行差很多PATH 可能不包括 /usr/local/bin很多命令会找不到。解决方法是脚本开头统一 export PATH/usr/local/bin:/usr/bin:/bin把 Python 等特殊路径也显式加进去。第二个坑是工作目录。cron 执行脚本时工作目录是执行者的 HOME不是脚本所在目录。脚本内部千万不要用相对路径要么 cd 到脚本目录要么所有配置和输出路径都用绝对路径。我习惯在脚本开头加一句cd $(dirname $0) || exit 1这样无论从哪里调都能保证相对路径从脚本目录开始算。第三个坑是任务重叠。巡检本身可能消耗一些时间如果上次任务还没跑完cron 又触发下一次就会产生并发问题数据可能写乱。加锁是最简单可靠的方法exec 9/tmp/check_report.lock if ! flock -n 9; then echo previous check still running, skip exit 0 fiflock 是 Linux 自带的文件锁工具-n 参数表示非阻塞获取拿不到锁就退出避免脚本重入。4.3 从报告到处置的闭环报告出来了、通知也发出去事情还没完。真正有价值的是建立发现问题 - 分配处理 - 验证解决的闭环。我的做法是给异常项加编号和严重级别。每次巡检脚本生成一个异常 ID比如 DISK-FULL-20250612-01通知消息里带上这个 ID 和对应的处置建议。运维或研发人员处理完后在报告页面的标注区登记处理结果形成一个简单的工单流。不要在这个环节引入太重的工单系统除非公司本来就有 Jira 或禅道。我在实际项目中就只用了一个简单的 Markdown 文件作为处理记录文件名按日期命名内容记录异常 ID、报告时间、处理人、处理结果。配合报告页面底部的“历史异常处理记录”两个月用下来我觉得比单独上系统更实用没有额外维护成本。关键是原则自动化巡检不是帮你决定怎么修而是帮你在最佳处理时机把问题暴露出来。处置流程可以简单但不能缺失否则巡检报告看多了就麻木了。5. 巡检发现问题的真实排查案例从告警到根因5.1 案例一磁盘IO异常引发的假慢某天巡检报告里出现一条告警数据库服务器磁盘 util 达到 85%await 平均值 120ms。但磁盘空间使用率只有 52%CPU 也不高。一开始按老思路以为磁盘要满了上去看 df 发现空间充足然后用 iostat -x 1 观察了十秒钟发现 util 基本稳定在 60%-90% 之间。问题在于 await 这么高数据库 SQL 肯定慢但 util 又不算极端爆满说明 IO 队列里有些请求长时间排队。继续深挖发现是两块盘里的其中一块在做 RAID 重组另一块盘上的业务 IO 全部被拖慢。RAID 组的同步逻辑在凌晨自动启动并且限速参数设置成了低速影响了在线业务。处理方式很简单调整同步速度限制让它不要抢占业务 IO重启同步任务await 回落到 5ms 以下。这个案例能通过巡检发现就是因为报告里除了空间使用率还采集了 await 和 util。如果只看空间这台服务器会被误判为健康。同一台服务器不同维度指标要分开看组合起来才有判断力。5.2 案例二内存泄漏与OOM另一个案例是 Java 应用服务器巡检报告连续三天显示内存使用率从 68% 上升到 72%、75%、79%。因为脚本里有趋势对比功能这块异常被提前标记出来比 OOM 早了两天。查起来倒是熟悉的味道Java 进程的堆内存设置过大-Xmx 给了 8G但物理内存只有 16G而堆外内存、线程栈、JIT 缓存这些又额外占了 2G。JVM 的堆内内存快满的时候GC 频繁但无法释放最终触底 OOM。处理方案是两步先把 -Xmx 调整到 6G给堆外内存留出空间再用 jmap 导出堆快照分析发现一个静态 List 一直在累积业务数据代码里没有清理逻辑。修复代码并发布后内存使用率稳定在 60% 左右。从巡检角度讲这个案例的价值在于趋势比阈值更能预警。如果只看是否超过 80%这条线等到触发告警时通常已经很紧急了。把连续三天上涨超过一定幅度做成一条规则很多问题都能在早期介入处理成本低得多。5.3 案例三NTP时间偏差导致的服务异常还有一个隐蔽的坑时间漂移。某内部系统之间的签名校验总是偶发失败业务方怀疑是网络问题排查了几天都没有结果。巡检报告里其实有一条关于 NTP 偏移的检查项显示某台服务器与标准时间偏差 8 分多钟。业务系统的签名有效期只有 5 分钟A 服务器认为时间还在有效期内B 服务器已经认为过期了于是校验失败。单看接口日志很难发现问题因为报错原因是签名已过期看起来就是时间戳不一致但谁会想到服务器的时钟偏差能大到 8 分钟呢处理方式不复杂重启 chronyd 或 ntpd 服务、强制同步一次时间再配置好 cron 定期同步。但这个案例提醒我一个巡检要点NTP 偏移检查必须纳入默认巡检项而且阈值要敏感一些偏移超过 30 秒就要告警。时间问题是所有分布式系统最容易忽略的隐藏依赖。6. 进阶如何让巡检适应业务场景而不是千篇一律6.1 按业务划分巡检策略巡检脚本很容易写成所有服务器一套参数但实际运行中我发现必须区分业务场景。数据库服务器、Web 应用服务器、消息队列服务器它们的瓶颈完全不同关注点应该区分。数据库服务器要重点看磁盘 IO、连接数、慢查询日志、主从延迟Web 应用服务器要重点看 CPU 负载、Java/Node 进程内存、请求错误日志、Nginx 的 5xx 数量消息队列服务器要重点看堆积数量、消费者 lag、网络吞吐。实现方式很简单给每台服务器打一个 role 标签比如 db、web、mq、cache配置目录里放不同角色的指标清单和阈值文件。巡检脚本根据主机名或配置文件读取对应的检查列表。一台服务器如果有混合角色就叠加多个清单。这套设计初期会麻烦一点但服务器数量超过几十台以后收益非常明显。你不会再收到一堆当前角色不适用的无效告警报告里的数据对运维和研发都有参考价值。6.2 引入历史基线动态判断固定阈值有个天然缺陷不同服务器的正常负载差异很大。有的服务器常年 CPU 负载 60% 也没问题有的 30% 就已经异常。解决方案是引入历史基线。我的做法是脚本里维护一个简单的基线库。前 14 天采集的指标数据按天存储系统自动计算每天相同时间段的平均值和标准差。判断时如果当前值超过平均值 2 倍标准差即使绝对值远低于阈值也会生成一条 趋势异常 提示。这个规则非常实用能捕捉到两类问题一类是缓慢增长的内存泄漏另一类是流量突然变化导致的负载异常。基线不是越复杂越好简单滑动窗口加上标准差判断在几台到上百台服务器的规模下都够用。当然也要防止基线被污染。如果连续多天都出现异常异常值会被纳入基线之后就变成正常了。所以基线库要定期重置比如每月重新学习一次或者设置异常数据不参与基线计算的标记。6.3 巡检脚本的性能开销控制自动化巡检本身不能对业务产生明显影响。我做了一个简单的性能开销测试脚本采集一次全量的指标耗时约 3 到 5 秒CPU 占用不超过单核的 8%。这个量级对绝大多数服务器是安全的。但要注意几个放大开销的点。第一个是日志扫描如果应用日志非常大比如超过 5GBgrep 一次全表扫描会消耗较多 CPU 和 IO。解决办法是只扫描当天新写入的日志段用 tail 配合行号增量而不是每次全文本 grep。第二个是 IO 采集频率iostat 这类命令如果连续采样多次单次巡检可能延迟到十几秒建议只采一次或最多两次取平均。第三个是图表生成matplotlib 渲染 30 天趋势图在低配服务器上可能是秒级延迟有条件的话把图表生成放到独立机器或者直接用轻量图表库在前端渲染。7. 我在实际维护中沉淀的几条巡检心得7.1 巡检脚本本身也要被巡检听起来像套娃但这是非常现实的问题。很多自动化系统最后死于无人维护巡检脚本也一样。如果脚本自身有 bug产出的报告就是错的而大家习惯了看报告之后反而比没有报告更容易漏掉问题。我的做法是每个星期手动跑一次脚本对比报告和真实数据是否一致。另外在脚本开头加一个版本号报告页面上显示版本号和最近运行时间。如果连续 24 小时没有生成新的报告文件就触发一条巡检任务本身异常的告警。这个兜底非常有价值。7.2 避免文件越来越胖的趋势巡检脚本天天跑日志文件、报告文件、历史数据会不断积累。如果不做清理最终消耗的磁盘可能比业务还大。我建议报告保留最近 60 天超过的压缩归档CSV 历史数据保留 180 天脚本自身的日志保留 30 天。清理任务用 logrotate 或者一个简单的 find mtime 命令都可以关键是别等到空间满了才发现。7.3 从小规模开始逐步扩大覆盖最后想对刚开始做自动化巡检的读者说不要试图一次把上百台服务器全纳入巡检。先选三到五台核心服务器跑两周验证脚本稳定性、阈值合理性、报告可读性再逐步添加服务器和检查项。我自己第一次做这套系统时试图完全覆盖所有检查维度结果脚本修修补补了一个月都没稳定运行。后来砍掉八成不常用功能只保留核心检查反而两周内就让团队依赖上了报告。功能是滚雪球一样加出来的不是一步到位的。如果能把今天这篇的框架用起来从一批最核心的机器开始下一周你就能看到第一份自动化巡检报告一个月之后它就会成为你们团队日常运维中离不开的部分。
花式格式化玩法)
