S4-8G 的监控指标配置建议

发布时间:2026-07-15 21:12

监控项不是越多越好，指标铺满屏幕的结果往往是告警疲劳，真正的问题反而被淹没。8G 内存机型要盯的核心指标其实很少，围绕内存、磁盘 IO、连接数三条线配齐，就能覆盖大多数故障前兆，剩下的指标留给专项排查时再看。 内存线：available 与换页 告警阈值建议两条：available 低于 800M（总量的 10%）触发预警，低于 400M 触发严重告警；vmstat 里 si、so 持续非零超过五分钟同样告警。采集一行命令即可： free -m | awk '/Mem:/{print $7}' 输出是可用内存的兆数，接进任意定时脚本或监控代理都能用，每分钟采一次足够。阈值不是拍脑袋定的，先观察两周正常水位，再在水位上浮五成的位置画线。 磁盘 IO 线：await 与利用率 iostat -x 1 的输出里看两列：r_await、w_await（单次读写等待的毫秒数）与 %util。await 长期高于 20 毫秒，或 %util 长期在 90% 以上，说明磁盘成了瓶颈。数据库类业务对这条线最敏感，MySQL 慢查询增多时先看 IO 再看 SQL，很多"SQL 变慢"的真相其实是磁盘排队。固态盘和机械盘的预期不同，机械盘的 await 放宽到 30 毫秒也属正常范围。 连接数线：两头都要看 一头是系统的 TCP 总量：ss -s 汇总各状态连接数，TIME_WAIT 数万且持续增长要查应用连接池配置。另一头是数据库自身连接：show status like 'Threads_connected'，与 max_connections 对比，使用率过七成就该收拢连接池或调参。两条都以曲线形式记录，水位变化一目了然，故障回看时也多了一份证据。连接数突增常常伴随异常，比如接口被扫或脚本没释放连接，曲线至少保留三十天。 告警怎么发才有效 分级是关键：预警级别发消息即可，严重级别必须能叫醒值班的人；通知文案里带上指标当前值和阈值，省掉一遍登录查看的工夫。误报多的指标先降级观察一段时间，别硬扛着每天响，告警失去信誉比没有告警更糟。每次告警的处理结果记进值班表，重复出现的告警说明阈值或根因没解决。 收尾：三条线配齐大约一小时，之后保持报警必处理、处理必留痕的习惯，这台机器的状态就始终在你掌握里。