硬件健康、系统性能、进程与服务、日志安全、业务可用性，日常运维最离不开的，永远是CPU、内存、磁盘、带宽这四件事。
监控不是堆指标，而是要给服务器做一套“体检体系”，你刚接手一台服务器，第一件事不是装环境，而是先知道它哪里会疼，下面按需求权重,把该盯的项目一项项拆开说。
服务器监控指标有哪些：从硬件到业务的完整清单
很多新手以为监控就是看看CPU高不高，这远远不够，服务器监控指标有哪些，得从底层往上分四层看,每一层漏掉都容易出事。
硬件层：物理机先看温度和磁盘健康
云服务器用户往往跳过这一层,但物理机使用者必须重视。
- 温度与电源：通过IPMI或iDRAC查看，CPU温度持续超过80℃，风扇转速异常,都属于需要立即处理的项目。
- 磁盘健康：查看SMART信息，重点关注
Reallocated_Sector_Ct和Pending_Sector，这两个数值一旦上升,说明物理盘已经在提前退休的路上。 - RAID状态：用
MegaCli或storcli查，RAID降级时性能会明显下滑，但系统通常还能跑，很多人就是在“还能跑”的时候丢了数据。
系统层：CPU、内存、磁盘、带宽缺一不可
这四项是监控的核心基本盘,任何监控工具第一个采集的都是它们。
- CPU：用
top或htop看us（用户态）、sy（系统态）、wa（IO等待）。wa偏高说明CPU在排队等磁盘，业务慢的根源未必是CPU算力不够，而是存储拖后腿，顺带看load average，它超过CPU核心数两倍时,说明系统已经超负荷运转。
📦 为了博客园排版整洁，代码块默认折叠，点击右侧 ▶ 展开查看完整代码
# 动态查看CPU和内存
top -d 2
# 采样5次，间隔1秒，输出平均值
mpstat -P ALL 1 5
# 查看过去10分钟的CPU负载趋势
uptime- 内存：用
free -h看available而不是看used，Linux的buff/cache本来就是拿去给磁盘做缓存的，只要available充足，used再高也不用慌，真正要警惕的是swap，持续出现si和so不为0,说明物理内存已经顶不住压力。 - 磁盘：先用
df -h看空间，再用iostat看await和util。util接近100%不代表磁盘快满了，而是磁盘一直处于忙碌状态，业务高峰期await一旦超过30ms,就该去查慢查询或者磁盘队列了。 - 带宽：用
sar -n DEV或iftop看实时流量，云服务器尤其要注意入方向和出方向带宽是否打满，带宽耗尽会导致丢包率直线上升，用户感受就是“卡成PPT”。
进程与服务层：进程活着不等于服务正常
这是最容易被忽略的监控盲区。
进程活着不代表服务在正常工作,这是运维老兵经常讲的一句话。
- 进程存活：
systemctl status nginx看主进程状态。 - 端口连通：
ss -lntp | grep 80确认端口在监听。 - 日志心跳：如果进程活着但日志半天没有新输出,大概率是线程卡死或死锁。
真正可靠的做法是配上业务探活，写一个健康检查脚本，curl项目自带的健康检查接口，能返回HTTP 200才算真活,而不是只看进程在不在列表里。
📦 为了博客园排版整洁，代码块默认折叠，点击右侧 ▶ 展开查看完整代码
#!/bin/bash
# 业务探活脚本，每30秒执行一次
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/healthcheck)
if [ "$HTTP_CODE" != "200" ]; then
echo "health check failed: $HTTP_CODE" >> /var/log/service_check.log
fi
日志与安全层：出问题前总有预兆
日志是服务器故障前的唯一自述，监控日志,很多时候比监控指标更能提前发现问题。
- 系统日志：
journalctl -xe看内核和systemd报错。 - 登录日志：
last和lastb分别看成功和失败的登录记录。lastb里出现大量内网IP的SSH爆破记录,说明已经被盯上了。 - 关键文件完整性：对
/bin、/etc下的关键二进制和配置文件做Hash快照，定期比对,防止被植入后门改掉配置。 - 安全监控：包括SSH暴力破解频率、异常外联连接、防火墙规则变动，外联出网连接平时极少，突然大量出现,大概率是中了挖矿木马。
业务层：用户体验才是最终答案
基础设施都正常，不代表业务没问题，监控的最终目的，是让用户不受影响,业务层监控要盯三件事：
- 核心接口响应时间：下单、登录、支付这类接口的平均响应时间和P99延迟。
- 错误率：5xx响应占比,以及应用日志里的异常堆栈数量。
- 关键链路可用性：比如用户从打开页面到完成支付的全过程，任何一步失败率升高,都需要告警。
服务器监控方案怎么选：三类主流落地路径
搞清楚监控哪些项目后，下一步就是选载体，服务器监控方案怎么选，取决于你有几个人、几台机器、懂不懂代码。
自建开源方案：灵活但费人
Prometheus + Grafana + Alertmanager的组合是目前云原生环境下的标准答案，行业共识认为,这套架构在可扩展性和生态兼容性上暂时没有对手。
- 优点：指标想要什么就自定义什么,数据完全在自己手里。
- 缺点：需要自己维护时间序列数据库，存储和分片是长期成本,告警规则也需要花时间去调。
- 适合：有专职运维或后端能力的团队,机器数量超过五十台。
Zabbix则更适合传统物理机和网络设备监控，自带Agent，SNMP支持完善,但云原生支持弱一些。
云厂商监控：开箱即用但别太天真
简米云云监控和酷番云云监控是目前国内使用最广泛的两款，它们的优势是自动接入，买了云主机就有基础指标，但很多人只用了默认监控,默认指标往往不够细。
- 云监控的默认采集周期通常是1分钟到5分钟,突发流量根本来不及反映。
- 自定义监控项需要额外配置，比如Java应用的方法级调用链,云厂商默认不采集。
- 带宽、CPU积分这类云特定指标，私有机房没有,需要适应云厂商的命名方式。
适合：所有云上客户,至少把默认监控打开。
商业SaaS工具：适合中小团队应急
监控宝、UptimeRobot这类外部监控工具，胜在不用部署、成本低，价格从免费版到几百元每月不等，它们大多从外部节点发请求探测你的站点，能真实反映用户侧的可达性，但无法采集服务器内部指标,比较适合个人站长或初创团队作为补充。
| 维度 | 自建开源 | 云厂商监控 | 商业SaaS |
|---|---|---|---|
| 部署成本 | 高，需要自己搭 | 低，开通即用 | 最低，注册就能用 |
| 指标深度 | 自定义范围最广 | 云产品默认指标为主 | 偏外部探测 |
| 告警收敛 | 灵活但需要调优 | 内置常用策略 | 看具体产品 |
| 适合规模 | 50台以上，有运维 | 任何规模云上业务 | 个人站长、初创团队 |
告警规则配置：监控不告警等于没监控
很多团队把监控搭好了，却天天被告警轰炸，最后把告警通知直接屏蔽，这不是工具的问题,是规则没定好。
阈值不能拍脑袋定
不要上来就给CPU设个“超过80%就报警”的死线，要先让监控系统跑两周，观察业务基线的波峰波谷，再按统计分布设阈值，业内专家指出，告警设计比监控采集更考验功力,一个好的规则设置往往比选工具耗时更长。
- 分层设限：分
warning和critical两级，比如CPUwarning设为70%持续10分钟，critical设为90%持续5分钟。 - 多指标联动：单看CPU不高不一定没问题，CPU低但
wa高，可能是磁盘IO瓶颈；带宽低但延迟高，可能是链路抖动，把关联指标放一起看,才不容易误判。
告警收敛避免风暴
一个机房交换机抖动，可能导致几百台服务器同时断连，如果每台都发告警,你根本看不出根因在哪里。
- 聚合：相同时间窗口内同一类型告警只发一条。
- 抑制：检测到宿主机宕机时,自动抑制其下所有虚拟机告警。
- 分级通知：
warning
critical才发短信和电话。
服务器监控工具有哪些：从命令到平台的完整栈
前面聊完了“看什么”和“怎么选”，最后把服务器监控工具有哪些拉通梳理一遍，按使用场景分成三类,你可以按需取用。
命令行工具：应急排查第一梯队
top/htop：CPU与内存实时状态，htop支持树状进程视图。vmstat：看进程阻塞、内存换页、IO等待。iostat：磁盘IO的await和util,定位磁盘瓶颈全靠它。ss/netstat：网络连接和端口监听状态。sar：历史性能数据回溯,出问题时没截图也能看当时走势。
开源监控平台：数据要沉淀才值钱
- Prometheus：负责采集和存储指标,内置强大的PromQL查询语言。
- Grafana：把Prometheus的数据做成可视化仪表盘,告警规则也能在上面配。
- Zabbix：老牌监控，适合传统IT基础设施，模板丰富,网络设备监控尤其方便。
- Alertmanager：Prometheus生态的告警分发组件，支持路由、抑制、静默。
云监控与托管服务：省心但要注意配额
简米云云监控、酷番云云监控都自带基础监控能力，可以配合日志服务把应用日志也纳入监控范围，用云监控时记得查看配额限制,默认的告警短信数量可能不够大促期间用。
Q&A 模块
服务器监控用什么工具最靠谱？
没有唯一答案，取决于你的场景，单台服务器应急排查，直接用top加iostat就能覆盖大部分问题，中小团队图省事，用云厂商自带的云监控完全够，规模大、定制需求多，就选Prometheus加Grafana,这套组合在云原生环境里是事实标准。
云服务器和物理服务器监控有什么区别？
物理服务器要管硬件层，包括IPMI里的温度传感器、电源状态、磁盘SMART信息，这些项目在云服务器里不需要关心，云服务器要关注的是宿主机层面的限制，比如CPU积分耗尽、突发带宽被限流、安全组规则误配，这些在物理机上不存在，物理机监控的痛点是硬件故障不可见,云服务器监控的痛点是配额不可控。
监控告警阈值如何设置才能不误报？
先看历史数据再定阈值，不要凭感觉，比如CPU，跑两周业务后，如果正常时段平均使用率在30%左右，就把warning设在70%、critical设在90%，并且各自加上持续时间作为条件，比如持续10分钟才算触发，而不是瞬时值触发，内存和磁盘同理，磁盘要考虑的是增长趋势，而不是单纯看当前容量，用“预计多少天后写满”代替“当前用了多少GB”会更实用，监控不是目的，提前发现问题才是目的，把基础项目配上合适的工具和规则，让服务器在出状况之前就把信号递到你眼前,这才是整套方案的价值。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/719639.html
