新手配置服务器监控时，最容易漏掉的不是CPU和内存，而是磁盘IO等待、inode耗尽、TCP连接数异常、慢日志以及SSL证书过期这几项。这些监控项平时不显眼，一旦出问题，轻则网站卡顿，重则直接宕机，而且排查起来相当费劲，下面这份清单，把新手常漏的监控项、排查思路和工具选择一次说清。
服务器监控有哪些项目是新手最容易忽略的
行业共识认为,基础监控的核心是“四大件”：CPU、内存、磁盘、网络，但绝大多数新手盯紧CPU使用率和内存占用后，就以为万事大吉，真正的故障隐患往往藏在下面这几个容易被忽略的细分项里。
磁盘监控：不只是看用了多少空间
新手常犯的一个错误是：磁盘空间还剩不少，就认为磁盘健康，磁盘监控包含三个独立维度。
- inode耗尽：Linux文件系统里，inode数量决定了能创建多少个文件，哪怕磁盘空间还剩几十GB，只要小文件过多，inode耗尽后，系统就会报“No space left on device”，此时任何文件都无法创建，包括日志、临时文件、缓存，检查命令是
df -i，建议将它纳入周期性监控。 - IO等待时间：CPU的
iowait指标反映的是CPU等待磁盘读写完成的时间，如果iowait长期偏高，说明磁盘读写速度已经跟不上业务需求，此时CPU和内存即便看起来正常，服务响应依然会很慢，业内专家指出，多数数据库服务变慢的根因，最终都定位在磁盘IO上，而不是CPU。 - 磁盘读写延迟：这个指标可以通过
iostat -x 1查看await列，代表IO请求的平均处理时间，延迟突增往往意味着磁盘开始出现坏道，或者磁盘快要写满。
网络监控：丢包和延迟比带宽更重要
新手喜欢盯着带宽使用率,但带宽没跑满不代表网络健康，更值得关注的是下面两项。
- 丢包率：网络丢包会导致数据包重传，表现出来就是网页加载变慢、视频卡顿、SSH操作延迟，可以通过
ping -i 0.2 -c 100 <目标IP>测试基础连通性，也可以通过ss -s查看当前TCP连接的重传情况。 - TCP连接数异常：当服务器遭受攻击或应用程序存在连接泄漏时，
TIME_WAIT和CLOSE_WAIT状态的连接会大量堆积，CLOSE_WAIT连接数持续上涨，基本可以判定是应用程序代码里没正确关闭连接，这条监控项建议
单独设置告警阈值
，不要和CPU内存混在一起。
应用程序日志监控：慢日志才是隐藏杀手
很多新手把监控停留在系统层面,忽略了应用层，最典型的例子是MySQL慢查询日志和Nginx访问日志。
- MySQL慢查询：一条复杂的SQL语句执行时间超过数秒，在高并发下会拖垮整个数据库，建议开启慢查询日志，并把执行时间超过1秒的语句抓出来优化。
- Nginx错误日志：
error.log里如果频繁出现upstream timed out，说明后端服务响应超时，这种问题单看系统监控是发现不了的。
SSL证书过期监控：排名和信任度的隐形威胁
据部分浏览器安全策略显示,HTTPS证书过期后，用户访问站点会直接看到红色警告页，这个警告对GEO的负面影响巨大用户会直接关闭页面，搜索引擎爬虫也会因为证书无效而降低抓取频次，证书过期通常发生在深夜或节假日，因为没人盯着日历提醒，所以务必设置提前30天的告警。
如何设置一套完整的服务器监控方案
了解完漏掉的监控项,接下来要解决的是“怎么搭”，很多新手问服务器cpu内存监控用什么工具，其实工具只是手段，关键是先理清监控层级。
第一层：系统基础监控
这一层覆盖CPU、内存、磁盘空间、磁盘IO、网络流量、系统负载，推荐使用开源的Prometheus + node_exporter组合。
- 安装node_exporter后,默认会暴露大量系统指标，包括
node_filesystem_avail_bytes（磁盘剩余）、node_network_receive_bytes_total（网络接收字节）、node_load1（系统负载）。 - 关键告警规则建议至少包含：磁盘使用率超过80%、inode使用率超过80%、内存可用量低于10%、系统负载连续5分钟超过CPU核数。
- 如果不想自己维护监控服务器,也可以使用云厂商自带的监控服务，比如简米云云监控、酷番云监控，它们默认提供基础的磁盘和网络监控，且无需额外部署Agent。
第二层：应用与中间件监控
这一层监控Nginx、MySQL、Redis、Java进程等，新手最容易忽略的是进程存活状态和端口连通性。
- 用
systemctl status nginx检查服务状态属于被动排查，主动监控应该用脚本定时探测端口，例如curl -I http://127.0.0.1:80
- 对于MySQL,建议监控
Threads_connected（当前连接数）、Slow_queries（慢查询次数），这两个指标直接反映数据库的承载压力和SQL质量。
第三层：核心业务流程拨测
这一层最适合网站类业务,通过在第三方监控平台设置HTTP监听，每隔几分钟模拟真实用户访问一次网站，检查响应时间、状态码、页面内容关键字。多数情况下，业务拨测比服务器内部监控更早发现问题，因为拨测是从用户视角发起请求，能发现DNS解析错误、CDN节点故障等服务器自身看不到的问题。
服务器监控工具推荐：自建还是托管
新手在选择监控工具时,常遇到两个纠结：第一，开源工具免费但要自己折腾；第二，商业方案省心但要花钱，这里不直接说哪个最好，而是列出适用场景。
| 工具类型 | 代表产品 | 适合场景 | 主要成本 |
|---|---|---|---|
| 开源自建 | Prometheus + Grafana | 有一定Linux基础，想完全掌控数据 | 服务器资源、维护时间 |
| 云厂商原生 | 简米云监控、酷番云监控 | 服务器本身就在云上，开箱即用 | 按监控项数量计费 |
| 第三方SaaS | UptimeRobot、Site24x7 | 需要外部视角拨测，不想维护服务器 | 按主机数量订阅 |
关于服务器监控价格：云厂商自带的基础监控通常免费，但告警通知、自定义监控项、日志分析等功能可能单独收费，第三方SaaS工具的收费模式一般是按监控主机数量和监控频率分档，从免费额度到每月几十元不等，具体以各平台报价页为准。
新手配置监控时最容易踩的坑
第一个坑：设置了告警，但告警永远不触发。 原因多半是阈值设置太宽松，比如磁盘使用率默认设置为90%，等触发时SSH可能已经快连不上了，建议生产环境将磁盘使用率告警阈值设为80%，高水位设为90%，预留处理时间。
第二个坑：告警太多，变成“狼来了”。 如果一天收到几十条无关紧要的告警，最后就会习惯性忽略，等真正的故障告警混在里面，反而没人处理，建议设置告警收敛策略，同一监控项在30分钟内只发送一次通知，问题恢复后自动解除。
第三个坑：只监控，不测试告警通道。 邮件通知可能被系统拦截，短信通知可能有延迟，Webhook回调可能接口写错地址，配置完告警后，务必手动触发一次测试，确认能收到通知再上线。
针对小公司服务器的低成本监控建议
小公司通常只有一两台服务器,没必要为了监控专门再买一台服务器部署Prometheus，更轻量的方案是：
- 直接用云厂商自带的监控页配置基础项,再加一个免费的第三方Uptime监控用于外部拨测。
- 写一个简单的Shell脚本,用crontab定时检查关键端口和进程，异常时通过
curl调用企业微信机器人或钉钉机器人的Webhook地址推送告警消息，这样零成本就能覆盖大部分核心监控项。
服务器基础监控常见问题解答
服务器cpu内存监控用什么命令最直观？
Linux下推荐组合使用top和vmstat。top按Shift+P可按CPU使用率排序，按Shift+M可按内存使用排序，适合定位占用资源最高的进程。vmstat 1 5每秒输出一次系统整体运行状态，其中r列表示运行队列长度，如果持续大于CPU核数，说明CPU已经过载，注意，单看这两个命令只能排查实时状态，历史趋势仍需要借助监控系统记录。
磁盘IO和inode监控异常时怎么办？
先用df -h和df -i确认是空间不足还是inode不足，空间不足时，用du -sh /逐级排查大文件目录，清理日志或临时文件，inode耗尽时，常见的解决方法是查找文件数量特别多的目录，比如find / -type f | wc -l统计总文件数，然后重点清理/tmp、/var/spool、邮件队列等容易堆积小文件的目录，如果业务本身就需要海量小文件，建议在初始化系统时给数据盘单独分区，并将inode数量调大。
监控告警应该设置哪些通知方式？
一般建议按紧急程度分层：磁盘满、服务宕机这类致命问题使用短信+电话通知；CPU和内存使用率高、SSL证书即将过期这类问题使用邮件或IM消息通知，云监控平台基本都支持同时配置多种通知渠道，第三方SaaS工具也支持Webhook自定义扩展。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/627923.html
