服务器监控指标主要涵盖CPU、内存、磁盘、网络、负载这五大基础维度，以及进程、日志等应用层指标，缺一不可。
搞运维最怕什么？不是半夜被电话吵醒，而是服务器挂了却说不清到底哪里先出了问题，我见过太多新入行的朋友，一上来就盯着CPU使用率不放，结果内存爆了都不知道，今天咱们就摊开聊聊，服务器监控到底该盯哪些指标，每个指标又该怎么看。
服务器监控指标有哪些
业内专家指出,监控这件事，本质上是给服务器做体检，指标选得全，问题定位就快；指标选得偏，故障排查就只能靠猜，下面这套清单，基本覆盖了从硬件到应用层的全部关键维度。
五大黄金指标：CPU、内存、磁盘、网络、负载
这五个指标是所有监控体系的基石,缺任何一项，你的监控面板都是瘸腿的。
- CPU使用率：反映处理器忙碌程度，但不要只看总使用率。关键要看us（用户态）和wa（I/O等待）的占比，如果wa长期高于30%，说明磁盘拖了后腿，光加CPU没意义。
- 内存使用率：包括物理内存和交换分区（Swap）的使用情况。重点观察Swap的使用量，只要Swap开始频繁读写，内存基本就到了警戒线，应用卡顿是迟早的事。
- 磁盘空间：别等磁盘满了才发现问题。建议对根分区和数据分区单独设阈值，因为日志写满根分区导致服务崩溃的案例，十起里至少有三起。
- 磁盘I/O：每秒读写的吞吐量和I/O等待时间，数据库服务器尤其要盯着这个指标，iowait过高时，任何SQL优化都白搭，得先看底层存储是否扛得住。
- 网络流量：包括入向出向带宽、连接数、丢包率，带宽跑满是容量问题，连接数爆了是并发问题，丢包率升高则是链路质量问题，三者要分开看。
运行时长和系统负载
运行时长（Uptime）这个指标常被忽略，但它很诚实，如果服务器莫名其妙的重启了，连续运行时间会突然归零，这往往是内核崩溃或者电源故障的直接证据。
系统负载（Load Average）则是整体压力的温度计，它同时考量了正在运行和等待I/O的进程数。行业共识认为，负载值长期超过CPU核数的70%，系统响应就会明显变慢，比如一台四核机器，负载长期顶着3.5以上，说明该扩容了，和服务器性能监控指标相关的流量回放压测，在排查这类问题时特别实用，可以帮你确认瓶颈到底在哪个环节。
进程与端口状态
服务器上跑的服务是不是活着,比硬件指标更直接。一定要监控关键进程是否存在，以及对应端口是否在监听，很多故障的真相是：硬件一切正常，但进程崩了，或者端口被占用，如果能把进程崩溃时的核心转储（Core Dump）也存下来，事后排查会省很多力气。
云服务器监控指标有哪些独特点
如果你用的是云服务器,除了上面那些通用项，还得额外关注几个云环境特有的指标。
- 实例的CPU积分：这是入门级云服务器特有的概念，用完了突发性能积分，CPU会被强制限流到基准线，表现就是业务高峰期突然卡顿，云厂商控制台一般都有积分余额图表，建议盯一下。
- 底层宿主机健康状态：云服务器是跑在物理宿主机上的，宿主机一旦出问题，你的实例可能被重启甚至迁移，需要留意云平台发出的底层维护或宕机通知。
- 公网带宽上限：云服务器的带宽是独立的计费项。当流量接近你购买的带宽峰值时，丢包和延迟会急剧增加，这不是服务器性能问题，而是钱没给够的问题。
服务器监控用什么工具
工具选型别跟风,关键看你的场景和预算，刀耕火种的原始命令能救急，专业平台能省心，各有各的用武之地。
命令行工具，应急排查必备
| 指标 | 命令 | 核心输出 |
|---|---|---|
| CPU | top / mpstat -P ALL |
各核心使用率、用户/系统态比例 |
| 内存 | free -m |
总量、已用、缓存、Swap使用量 |
| 磁盘I/O | iostat -x 1 |
%util、await（平均I/O响应时间） |
| 网络流量 | sar -n DEV |
实时吞吐量和丢包统计 |
| 整体负载 | uptime |
1/5/15分钟平均负载 |
这些命令的必要性在于：平台监控看的是趋势，命令看的是即时细节，很多现场排查，最终还是靠这些基础命令一步定位。
开源监控系统，中小团队的首选
- Prometheus + Grafana：目前社区最活跃的组合，Prometheus负责采集和告警，Grafana负责画图。告警规则用PromQL编写，灵活度极高，适合有一定动手能力的运维，所有指标都通过一个叫exporter的组件暴露出来，包括前面提的node_exporter（硬件指标）和mysqld_exporter（数据库指标）。
- Zabbix：老牌全栈监控，支持agent和SNMP两种采集模式，优点是一体化程度高，自带Web管理界面，不需要额外搭一套可视化系统，模板库丰富，拿来即用。
商业监控服务，省心但费钱
国内云厂商自带的监控服务（如简米云云监控、酷番云可观测平台）胜在开箱即用，主机刚创建好，基础指标就已经在采集了，付费的APM类产品（如听云、博睿）则擅长链路追踪，能看清楚一次请求从浏览器到数据库每一跳的耗时，如果你的服务是微服务架构，这类工具的价值会非常明显，要是问服务器监控用什么工具成本最低，那么自建Prometheus是首选；如果更看重省事和稳定，直接用云厂商自带服务也不亏。
服务器监控指标报警阈值怎么设
阈值设得太松,报警等于摆设；设得太紧，值班同学一晚上接几十条短信，最后都麻木了，设置原则参考下面这批经验值，按业务类型微调即可。
基础指标推荐阈值
- CPU使用率：持续5分钟超过85%触发警告，超过95%触发严重告警，加一条规则盯iowait，超过30%就要着手排查。
- 内存使用率：持续超过90%且Swap使用率超过30%时，触发严重告警，只盯内存使用率远远不够，要把Swap放进来。
- 磁盘空间：磁盘使用率超过80%警告，超过90%严重，日志分区建议单独设阈值，超过70%就提醒清理。
- 磁盘I/O：%util持续超过80%，或await持续超过100ms时触发告警。
- 网络连接数：TCP连接数或TIME_WAIT状态连接数出现持续增长且无回落迹象时，需要触发告警检查是否存在连接泄漏。
告警策略的四个讲究
- 设置持续时间：瞬时波动不算故障，持续3-5分钟才算，用持续时间过滤掉偶发毛刺，能有效减少误报。
- 分级别通知：警告走邮件，严重走电话或短信。凡是会打扰到睡觉的告警，必须是值得起床处理的问题。
- 告警要做聚合：同一台机器的CPU、内存、磁盘同时告警，多半是同一个根因，应该合并成一条事件，而不是三连冲击。
- 保留原始数据：告警触发后，自动记录当时的进程快照、网络连接状态和系统日志，方便事后复盘，这一步叫告警上下文留存。
常见问题速答
问题：服务器监控指标里的CPU使用率和系统负载，到底看哪个更准？
看CPU使用率有助于理解处理器的忙碌程度,看负载则有助于理解系统整体的排队压力，单核机器上，负载1.0就是满负荷；四核机器跑到4.0才算满载，负载还包含了I/O等待，所以磁盘慢的机器，负载会高得离谱但CPU却很闲，建议两个指标结合在一起看，互相印证。
问题：开源的Prometheus和商业监控相比，有什么明显的区别？
Prometheus的采集和展示能力很强,但告警配置、用户权限管理、高可用方案都需要自己搭建和完善，人力成本不低，商业监控服务则通过简单的SDK接入，通常还附带智能告警和根因分析能力，积攒了不同行业的监控经验。业务比较标准，用开源方案；业务复杂且团队人手有限，选商业服务更具性价比，据行业公开讨论，多数中型互联网公司采用的是Prometheus + 云厂商告警服务互补的混合方案，用开源做数据底座，用云服务兜底告警通道。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/788974.html
