2026-08-22
先给结论：监控的目标不是收集越多图表越好，而是尽早发现用户可感知的问题并快速定位原因。公网网站至少要覆盖外部可用性、请求错误率与延迟，以及CPU、内存、磁盘、网络、进程和关键任务。告警应优先针对症状、可行动且有持续时间，避免每次瞬时波动都通知。
本文更新时间：2026年8月22日。阈值应根据业务基线、容量和SLO设定，本文示例是设计方法，不是所有服务器通用的固定数值。
| 层面 | 关键指标 | 回答的问题 |
|---|---|---|
| 用户体验 | 外部HTTP成功率、TLS、DNS、P95/P99延迟 | 用户现在能否正常访问和完成关键操作？ |
| 应用 | 请求量、错误率、延迟、队列、任务成功时间 | 哪类接口或任务正在失败？ |
| 系统 | CPU、负载、可用内存、Swap、磁盘等待、inode | 主机资源是否成为瓶颈？ |
| 依赖 | 数据库连接、慢查询、缓存命中、外部API耗时 | 故障是否来自下游依赖？ |
| 容量 | 磁盘增长、带宽峰值、连接数、证书到期时间 | 是否会在未来几天或几周达到上限？ |
CPU百分比要与运行队列、负载、请求延迟和吞吐量一起看。单次100%不一定是事故，持续饱和且用户延迟上升才需要立即处理。多核主机的load average也要结合CPU核数和I/O等待解释。
Linux会利用空闲内存做缓存，因此“free很少”不等于内存不足。更有价值的是MemAvailable、Swap活动、OOM记录和应用工作集。Swap持续换入换出并伴随延迟上升，应调查进程和容量。
除了空间百分比，还要监控inode、读写延迟、I/O等待和增长速度。日志突然膨胀可能在几小时内写满磁盘，仅设置“超过90%”的静态告警可能来不及处理。
容量规划可结合煜钧云云服务器，公网带宽指标可参考带宽速度与并发计算，异常流量应结合DDoS识别与应急清单判断。
不一定。应结合持续时间、用户延迟、吞吐量和负载模式。批处理短时占满CPU可能正常，在线接口持续变慢则应告警。
服务器内部正常不代表DNS、CDN、TLS和公网路径正常；外部探测更接近用户真实体验，也能发现监控系统本身随主机一起失效。
