监控体系设计

指标采集不是监控体系的终点。每一层都应定义健康信号、告警条件、Dashboard、运行手册和责任人，并从用户影响反推监控优先级。

1. 主机监控

主机层关注 CPU 饱和、内存可用量、磁盘空间与 inode、磁盘 I/O、网络错误、文件描述符和时钟同步。告警应结合持续时间和容量趋势，避免瞬时 CPU 峰值直接升级为严重事件。

2. 应用监控

应用层以 RED 方法为主：请求速率、错误率、延迟。补充线程池、连接池、队列、缓存、依赖调用和进程资源。业务端点与 /metrics 端点应采用不同访问策略，指标不应泄露用户信息或业务密钥。

3. 数据库监控

数据库层关注连接、慢查询、锁等待、缓存命中、复制延迟、事务冲突、存储与备份。数据库资源指标必须结合请求量和业务延迟判断，单一 CPU 阈值无法覆盖索引失效、锁争用和复制中断。

4. 中间件监控

Redis 关注内存、命中率、复制与阻塞；Kafka 关注 Broker 健康、分区、副本、Consumer Lag；消息队列关注积压、消费速率和失败重试。队列积压告警要同时检查生产速率、消费速率和服务处理能力。

5. 业务指标监控

业务指标直接反映用户价值，例如下单成功数、支付失败率、库存同步延迟、任务完成量。它们必须有业务负责人和清楚的数据语义，不能把内部技术计数冒充业务成功。

6. 从 SLO 到告警

先定义服务级目标，再选择信号、阈值与错误预算。例如 API 可用性和延迟 SLO 可基于成功请求比例与 Histogram 计算。将紧急告警保留给即将消耗完错误预算或已造成用户影响的事件；容量趋势和低优先级异常进入工作时段处理。