刚接触服务器监控，很容易被大量指标曲线搞得眼花缭乱。仪表盘密密麻麻的各色线条不停跳动，但排查故障的时候，真正核心的指标就分成几大类，持续观察这些内容，多数故障都能提前察觉。
最先查看CPU相关数据，但不能只看使用率百分比，这个数值存在误导性。一台服务器CPU使用率50%，运行状态可能十分稳定，也可能濒临崩溃，差异体现在负载与等待值。Linux系统的load average参考价值更高，1分钟、5分钟、15分钟三组数值放一起，能够判断变化趋势。1分钟负载突然冲高，15分钟数值依旧偏低，代表短时突发任务占用资源。iowait经常被忽略，这个数值代表CPU等待磁盘读写的耗时，如果长期偏高，瓶颈不在计算能力，而是磁盘。
内存指标同样不能只看已使用容量。Linux系统会把空闲内存拿来做文件缓存，所以已用内存数值高不一定代表内存不足，重点查看available剩余内存。一旦swap分区开始大量读写，说明物理内存容量不够，性能会断崖下跌。Swap in/out读写速率比swap总占用量更有参考意义，少量波动没有影响，持续读写就代表内存压力严重。
磁盘模块，剩余空间是最直观的指标，inode数量同样需要留意。磁盘空间还有很多，inode耗尽之后，依旧无法写入新文件。IO性能需要IOPS、吞吐量、延迟三项结合查看。IOPS数值高不一定属于异常，一旦延迟同步上涨，队列长度持续增加，代表磁盘读写跟不上业务请求。云服务器还要留意突发性能额度，磁盘平时运行正常，额度耗尽之后IO性能会大幅下降。
网络指标里带宽、数据包总量属于基础项，错误计数和丢包率更值得持续关注。网卡errors或者dropped数值持续上涨，代表链路或者驱动层面存在问题。TCP连接数也要观察，ESTABLISHED连接数量高可能只是业务流量大，但TIME_WAIT大量堆积，大概率是短连接请求过于频繁。服务器部署反向代理或者负载均衡，额外监控并发连接数和请求队列。
硬件状态是独立的监控分支。温度、风扇转速、电源状态平时变动很小，一旦数值异常，基本属于严重故障。定期检查RAID卡状态，不要等到硬盘损坏才发现阵列已经降级。硬盘SMART信息不能忽视，重分配扇区计数、待映射扇区计数这类参数上涨，说明硬盘即将损坏，尽快准备更换硬盘。
服务监控分为两层。第一层检测进程存活状态、端口监听情况。这项操作简单，但容易漏报，进程正常运行不等于业务服务可用。第二层是应用层指标，HTTP状态码、响应耗时、错误率、QPS。响应时间P99分位数据比平均值更有参考价值，平均响应时间看着正常，P99数值达到数秒，代表一部分用户访问缓慢。数据库额外监控连接数量、慢查询、锁等待、缓存命中率。消息队列查看消息堆积量，线程池监控活跃线程与队列长度。
日志监控经常被当成附属功能，实际是最早的预警渠道。错误日志数量突然增加，哪怕服务还没有宕机，预示故障即将发生。设置关键字告警比全量日志收集更实用，OutOfMemory、Connection refused、Timeout这类关键词触发通知。
监控指标不是越多越好，仪表盘堆砌几十条曲线，故障发生时很难快速定位问题。每一项指标都要对应可行的处理动作。CPU负载高知道排查进程，磁盘满了清理文件，响应时间上涨查看下游依赖。如果指标异常之后没有对应的处理方案，就不需要放在核心监控面板。优先盯住CPU、内存、磁盘、网络、服务可用性五项，设置合理告警阈值，系统就能在故障爆发前推送提醒。