写一个Linux服务器硬件监控脚本，核心就是三件事：采集硬件状态、对比阈值、触发告警，这个闭环想通了，剩下全是在填坑误报怎么防、通知怎么发、脚本自己别挂掉。
Linux服务器硬件监控脚本怎么写才能避免假死和误报？
很多新手写完监控脚本,跑了两天就开始怀疑人生：凌晨三点CPU飙到90%疯狂告警，结果一看是跑批任务；硬盘温度偶尔跳一下，邮件轰炸了整个运维群，说白了，脚本的骨架是采集和告警，灵魂是防误报机制。
先搭好最常用的硬件指标采集框架
一个生产级的监控脚本,至少要覆盖这几类硬件状态：
- CPU负载和核心温度：用
mpstat看用户态和系统态占用率，用sensors读取CPU核心温度 - 内存使用情况：
free -m拿到总内存、已用、可用和缓存数据，重点关注可用内存比例 - 磁盘空间和IO负载：
df -h看分区使用率，iostat看读写延迟和队列长度 - 硬盘健康状态（SMART信息）：
smartctl -a /dev/sda查硬盘已用寿命、重映射扇区数、通电时长 - 风扇转速和主板温度：通过IPMI/
ipmitool获取，或者依赖lm-sensors直接读
举个例子,我这边的脚本在采集磁盘SMART信息时，用smartctl -H先看整体健康状态，如果返回”PASSED”就不管，一旦出现”FAILED”立刻触发严重告警，比单纯盯着磁盘空间要提前预警很多天。
采集频率设置在什么范围才合理？
设置采集间隔时,先想清楚一个场景：你的业务夜里会有批量任务吗？会有瞬间的编译高峰吗？
- 常规情况60秒一轮就够了，CPU、内存、磁盘这些指标变化没那么快
- 核心数据库或交易系统,可以缩短到10到15秒一轮，代价是脚本进程占用的CPU会稍微高一点
- 硬盘SMART检测不要每轮都跑，smartctl读取底层数据有一定开销，建议每10分钟或1小时跑一次
比较推荐的做法是把采集逻辑拆成两个循环：一个高频循环跑CPU/内存/磁盘空间，一个低频循环跑SMART和温度，这样脚本自己不会成为新的性能负担。
硬件监控脚本如何实现实时告警？三种通知渠道实测体验
脚本采集到的数据,得用一种能真正吵醒人的方式送出去，经历了大半夜被误报吵醒，又经历了硬盘快挂了邮件没人看之后，我把告警渠道分成了三个梯队，各有用武之地。
邮件通知：传统但适合固定工位场景
邮件适合内网环境,适合有IT值班人员的公司，你可以用系统自带的mail命令，或者sendmail、msmtp发给运维邮箱，优点是没有额外成本，缺点是邮件太容易被淹没，紧急程度不够醒目。
钉钉/企业微信机器人：中小团队的主流方案
现在不少中小团队都在用钉钉或企业微信的群机器人Webhook,脚本里用curl向Webhook地址推送JSON消息，十几行就能搞定，正文里带上主机名、IP、告警指标、当前数值和阈值，群里的值班同事一眼就能看到。
这类机器人还支持@指定成员，可以把告警直接推给对应负责人，相比邮件，实时性强了不止一点，而且免费。
短信网关：机房无外网环境的兜底方案
如果你管理的服务器在隔离机房,没有外网出口，短信是最稳妥的告警渠道，通常是脚本通过串口或者4G模组调用服务商的短信API，一条短信几分钱到一毛多，硬件监控一年短信费用也就几十块，换来的是哪怕机房网络断了也能收到告警。
为了直观对比,我整理了一张表：
| 告警渠道 | 实时性 | 部署成本 | 适合场景 |
|---|---|---|---|
| 邮件 | 低，容易延迟 | 几乎为零 | 有固定IT工位、内网环境 |
| 钉钉/企业微信机器人 | 高，秒级到达 | 零成本 | 中小团队日常运维值班 |
| 短信网关 | 最高，不依赖网络 | 按条计费，每年几十元 | 隔离机房、无人值守IDC |
服务器硬件告警阈值设置多少合适？按场景调参才靠谱
关于服务器硬件告警阈值设置多少合适这个问题,行业里没有一套放之四海皆准的数字，因为
做数据库的机器和做Web静态资源的机器，压力模型完全不一样，抄别人的配置往往容易翻车，我自己调参时，是按照这个思路来的：
CPU和内存的阈值，先看业务角色
- 数据库服务器：CPU持续超过70%，持续5分钟以上就发警告，数据库的查询高峰有周期性，短时冲高可以不用管，但长时间下不来就得查慢查询或锁等待了
- Web应用服务器：多数情况下CPU在50%以下算健康，超过80%就该告警，注意区分用户态占用和系统态占用，如果是sy占比太高，可能是频繁切换进程或内核异常
- 内存方面,生产环境建议可用内存低于20%时警告，需要留意的是，Linux的buff/cache不能简单算作不可用，建议用
available字段判断
磁盘和温度阈值，宁可保守不要激进
磁盘的使用率比较对称。根分区或数据盘超过85%告警，超过90%升级为严重告警，这个数字在运维圈算是共识，因为一旦写满，不光业务挂掉，连syslog和监控脚本本身都可能跑不起来。
温度方面,大多数x86服务器的安全上限是75°C左右，建议CPU核心温度超过65°C就触发警告，超过72°C触发严重告警，但同时要看风扇转速，如果温度高而风扇转速没跟着上来，那多半是风扇故障或散热风道堵了。
防误报的核心技巧：连续N次采样确认
这也是我踩过最大的坑,解决方案很简单：连续采集3次，每次都超过阈值才触发告警，比如60秒一个周期，连续3次CPU超过80%才发通知，中间任何一次回落到阈值以下，计数器清零，所以监控脚本不能写得太简单，状态机逻辑是必不可少的。
硬件监控脚本的性能开销与生产环境避坑指南
监控脚本本身是个常驻进程,它的性能开销直接关系到业务稳定性，在云服务器上，这个问题更明显买的是2核4G的小机器，再跑个Python写的监控脚本，动不动吃5%的CPU，业务方大概要来找你聊天了。
Bash和Python怎么选？
- 纯Bash脚本用
/proc/stat、/proc/meminfo直接读内核数据，开销极小，适合只做简单阈值判断 - Python脚本处理复杂逻辑更顺手,比如把数据写入SQLite、计算趋势、对接多个Webhook，但启动Python解释器本身就占一点内存
- 折中方案是：主循环用Bash，采集和告警逻辑用Python子进程，日常开销非常低
脚本本身的自我守护
写监控脚本,别忘了监控它自己，启动脚本时把PID写入文件，配合crontab每分钟检查一下进程是否存活，我自己的习惯是，要么用systemd管理监控服务，配置Restart=always，要么在crontab里加一条任务判断进程存在，不存在就拉起。
出门在外怎么快速定位硬件问题
有一次我在高铁上收到告警,说机房一台机器的磁盘SMART状态异常，手机上没有笔记本，只能借助脚本里提前集成的故障信息收集功能。把dmidecode、dmesg、smartctl -a和ipmitool sel list的输出统一打包到一个日志目录，这样收到告警短信或机器人推送时，直接登上去抓日志，远程排查效率高很多。
其实这个思路算是一条不成文的行业经验：监控脚本做的不是告警这一个动作，而是把故障的上下文也一并打包，方便后续定位。
关于Linux服务器硬件监控脚本的常见疑问解答
监控脚本每30秒跑一次会影响线上业务性能吗？
影响很小,但看写法，用Bash直接读/proc接口，每轮执行时间在毫秒级，几乎可以忽略不计，真正要留意的是smartctl这类底层工具扫描硬盘时的IO开销，有概率影响到正在做大量磁盘读写的业务，建议把它放到单独的低频周期里执行，比如每10分钟跑一次。
服务器硬件监控脚本怎么防误报？
核心思路是加状态判断,连续多次采样超过阈值再告警，同时对单次瞬时抖动设置容忍窗口，配套手段包括：区分告警级别、过滤已知的维护时间段、定期更新基线数据，能把误报率压下来，监控系统才算真正可用。
云服务器和物理机的硬件监控脚本有什么不一样？
云服务器拿不到温度、风扇、SMART这类底层硬件数据，因为虚拟化层屏蔽了这些接口，通常只能监控CPU使用率、内存、磁盘IO等资源指标，物理机则可以靠IPMI读取完整的硬件健康状态，如果买的是云服务器，建议把重点放在云平台自带的监控告警上，这类监控脚本更侧重于云主机的资源使用率与进程层面的异常检测。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/618587.html
