我曾接手过一个 Grafana 实例，上面有 47 个仪表盘面板。CPU 利用率、内存使用量、磁盘 I/O、网络字节、JVM 堆——你能想到的每个指标都有。所有指标都是绿色的。一直如此。
两天后，API 宕机了 4 个小时。没有一个告警被触发。
为什么？因为 CPU 是 22%，内存是 45%，磁盘是 30%。全都"健康"。真正的问题是连接池耗尽——一个没人关注的指标。
四大黄金信号（仅此而已）
Google 的 SRE 书籍对此一针见血。你只需要四个信号：
1. 延迟 — 请求需要多长时间？ 不是平均延迟——那会掩盖问题。追踪 P50、P95 和 P99：
- P50 = 200ms 意味着半数用户能在 200ms 内得到响应（良好）
- P95 = 800ms 意味着每 20 个用户中有 1 个需要等待 800ms（可接受）
- P99 = 5000ms 意味着每 100 个用户中有 1 个需要等待 5 秒（有问题）
你的 P99 才是真正的性能表现。平均值会撒谎。
2. 流量 — 你正在处理多少请求？ 这是你的基准线。如果周二下午 2 点流量骤降 80%，即使其他所有指标都是绿色的，也一定出了问题。
3. 错误 — 请求失败的百分比是多少？ 追踪错误率，而不是错误数量。100 万次请求中出现 100 次错误（0.01%）没问题。200 次请求中出现 100 次错误（50%）就是一次宕机。
4. 饱和度 — 你的系统有多满？ 数据库连接、内存、队列深度、线程池。当任何资源利用率达到 80% 时，你就需要采取行动——不是因为系统已经崩溃，而是因为你已经失去了缓冲空间。
我实际的监控配置
对于 Nexural 平台：
