3、基础设施层监控：CPU、内存、磁盘、网络的基础监控指标与告警阈值设置
聊到搜索引擎的稳定性，我第一个想到的就是基础设施层。说白了，这是所有上层服务的「地基」。地基不稳，再牛的算法、再快的缓存都是白搭。我在项目里见过太多次了——业务方反馈搜索变慢，查了半天，最后发现是磁盘 IO 打满了。嗯，这种坑踩过一次，你就知道基础设施监控有多重要了。
3.1 CPU 监控：别只看使用率
CPU 是服务器的「大脑」。但很多人只盯着一个「CPU 使用率」看，这其实不够。我个人习惯至少看三个维度：
- CPU 使用率（user + system）：整体负载情况。
- CPU 等待 I/O（iowait）：这个指标特别容易被忽略。如果 iowait 高，说明 CPU 在等磁盘干活，这时候加 CPU 核心数没用。
- CPU 上下文切换（context switches）：切换太频繁，说明系统在「瞎忙活」。我记得有一次排查线上抖动，就是发现上下文切换每秒几十万次，最后定位到是某个线程池配置不合理。
告警阈值建议：
- CPU 使用率 > 80%：Warning（持续 5 分钟）
- CPU 使用率 > 95%：Critical（持续 3 分钟）
- iowait > 30%：Warning（结合磁盘监控一起看）
- 上下文切换突增 > 基线 2 倍：Warning
我的小技巧： 别用单一的绝对值阈值。搜索引擎的流量有波峰波谷，我建议用「动态基线 + 百分比偏移」的方式。比如，CPU 使用率比过去 7 天同一时刻高出 30%，就触发告警。这样能避免半夜流量低峰期误报。
3.2 内存监控：Swap 是性能杀手
内存不够，系统就会用 Swap（磁盘当内存用）。你想想看，磁盘速度比内存慢几个数量级，一旦开始 Swap，搜索响应时间直接崩掉。我曾经在凌晨 3 点被电话叫醒，就是因为一台索引节点 Swap 使用率飙到了 60%，查询延迟从 10ms 变成了 500ms。
内存监控我重点关注这几个：
- 可用内存（Available Memory）：不是 free 命令里的那个 free，而是真正可用的物理内存。Linux 的 free 命令显示的 available 才是靠谱的。
- Swap 使用率：理想情况是 0。一旦开始用 Swap，就要警惕。
- 内存页错误（Page Faults）：特别是 major page faults，说明内存不够，频繁从磁盘换入换出。
告警阈值建议：
- 可用内存 < 20%：Warning
- 可用内存 < 10%：Critical
- Swap 使用率 > 0%：Warning（持续 10 分钟）
- Swap 使用率 > 20%：Critical
注意： Java 应用（比如 Elasticsearch）的堆外内存很容易被忽略。JVM 的堆内存监控了，但堆外（Direct Memory、MMAP）用超了，直接 OOM。我建议把进程的 RSS（ Resident Set Size）也纳入监控。
3.3 磁盘监控：不只是看空间
磁盘监控，新手只看「磁盘使用率」。但搜索引擎这种 IO 密集型应用，更关键的是性能指标。我遇到过磁盘空间还剩 50%，但写入延迟已经高到离谱的情况——后来发现是磁盘坏了，坏道导致的。
磁盘监控清单：
- 磁盘使用率：这个还是要看的，别等到写不进去了才报警。
- 磁盘 IOPS（每秒读写次数）：看是否达到磁盘上限。
- 磁盘吞吐量（Throughput）：读写带宽。
- 磁盘延迟（Latency）：平均 I/O 等待时间。这是最核心的指标。
- Inode 使用率：小文件太多，inode 用完了，磁盘空间还有，但写不了新文件。这个坑我踩过。
告警阈值建议：
- 磁盘使用率 > 80%：Warning
- 磁盘使用率 > 90%：Critical
- 磁盘延迟（读/写）> 50ms：Warning
- 磁盘延迟（读/写）> 200ms：Critical
- Inode 使用率 > 80%：Warning
避坑指南： 我曾经把告警阈值设成磁盘使用率 95% 才报警，结果有一次凌晨数据灌入，磁盘瞬间写满，索引直接挂了。后来我改成 80% Warning，85% 就开始提前扩容或清理。别等到最后一刻。
3.4 网络监控：丢包和重传是重点
网络是搜索引擎的「血管」。节点之间要同步数据、转发查询请求，网络一抖，整个集群都受影响。我记得有一次线上故障，查了三天，最后发现是网卡固件 bug，导致 TCP 重传率飙升。
网络监控核心指标：
- 带宽使用率：别让带宽打满，否则延迟会急剧上升。
- 丢包率（Packet Loss）：哪怕 0.1% 的丢包，对搜索引擎这种实时系统都是灾难。
- TCP 重传率（Retransmission Rate）：重传意味着网络不稳定。
- 连接数（TCP Connections）：特别是 TIME_WAIT 状态的连接数，太多会耗尽端口。
- 网络延迟（Latency）：节点间的 RTT（往返时间）。
告警阈值建议：
- 带宽使用率 > 70%：Warning（考虑扩容或限流）
- 丢包率 > 0.1%：Warning
- 丢包率 > 0.5%：Critical
- TCP 重传率 > 2%：Warning
- TCP 重传率 > 5%：Critical
- TIME_WAIT 连接数 > 10000：Warning
注意： 网络监控的采样周期要短。我建议至少 10 秒一次。因为网络抖动往往是瞬时的，如果采样间隔是 1 分钟，你可能根本抓不到问题。另外，别忘了监控网卡的错误计数器（errors、dropped、overruns）。
3.5 综合告警策略：别让告警变成噪音
指标设好了，阈值也定了，但告警太多等于没告警。我见过一个团队，一天收到 2000 条告警，最后运维直接把告警群屏蔽了——这很危险。
我的经验是：
- 告警分级：P0（立即处理）、P1（15 分钟内）、P2（1 小时内）、P3（日报）。CPU 使用率 80% 是 P2，但如果是 95% 且持续 5 分钟，就是 P0。
- 关联告警：别单独看 CPU、内存、磁盘。比如，CPU iowait 高 + 磁盘延迟高 + 磁盘使用率高，这三个同时出现，大概率是磁盘瓶颈。这时候只发一条聚合告警就够了。
- 静默期：同一个指标在 30 分钟内不要重复告警。否则半夜值班的人会疯掉。
最后说一句： 基础设施监控是搜索引擎稳定性的「第一道防线」。别嫌它基础，基础的东西往往最致命。我每次接手一个新集群，第一件事就是把 CPU、内存、磁盘、网络的监控补齐。嗯，这步做扎实了，后面才能睡个安稳觉。