服务器监控该看哪些层次？从主机指标到用户请求
从用户是否完成操作开始
监控首页摆满CPU、内存和网卡曲线，仍可能漏掉证书过期、错误跳转或登录失败。用户面对的是完整服务，所以第一层应验证外部可见结果，例如页面能否返回正确内容、接口是否在可接受时间内完成，以及关键流程是否成功。
Google SRE监控章节区分从外部观察行为与从内部采集状态的方式，并提出延迟、流量、错误和饱和度等核心观察方向。这些指标的价值在于回答用户受到了什么影响，以及内部哪些原因可能相关。Google SRE官方章节
对于低访问量网站，真实流量可能不足以快速暴露问题，可以增加轻量外部探测。探测需要验证预期内容，不能只接受任意200响应，否则错误页被包装成成功码时仍会显示正常。
应用层把症状连接到处理过程
第二层观察应用请求量、成功与失败、响应延迟、队列和关键依赖。按接口或业务类型分组，可以区分搜索变慢和登录失败，避免一个总体平均值掩盖重要路径。
假设整体平均响应仍然较低，但少量文件上传持续超时。应分别观察上传接口的延迟分布、请求大小和失败原因，而不是只看首页速度。对于延迟，较高百分位数往往更容易反映一部分用户等待很久的情况，但统计样本量也要一并考虑。
后台任务同样属于应用层。队列积压、最老任务等待时间和完成失败比例，比“工作进程还在”更接近任务是否及时完成。若通知任务长时间积压，网页入口可能完全正常，用户仍会感受到业务异常。
主机层解释资源压力
第三层再看CPU时间、内存可用状态、磁盘空间与延迟、网络吞吐和错误。每项指标应关联到具体实例、文件系统和设备，避免把系统盘剩余空间与数据盘混在一起。
Prometheus Node Exporter可以暴露Linux主机的多类指标，但采集到指标只是起点，仍需按系统实际设备与用途筛选。Node Exporter官方指南
例如假设应用延迟上升，同时数据库所在磁盘的等待增加，存储路径值得继续检查；如果CPU高而业务延迟没有变化，可能是后台批处理在使用空闲资源。单个资源数字需要放在时间线和业务背景中解释，不能自动等同于故障。
内存也不应只看一个“已使用”比例。缓存、可回收空间、交换活动和应用自身限制都会影响判断。容量不足、进程泄漏和正常缓存增长需要不同处置。
用同一时间线连接三层信息
给图表统一时区和时间范围，并标注发布、配置修改、备份与活动开始时间。出现错误时先从外部症状进入，再查看对应应用与主机变化，可以减少在几十张图里随机搜索。
请求标识、应用实例标签和版本信息有助于关联，但标签不宜直接包含每个用户或每次请求的唯一值，否则时间序列数量可能快速增长。详细单次请求放在适当的日志或追踪系统中，指标保留适合聚合的维度。
监控面板也要能区分无数据与正常。采集器停止、权限变化或网络阻断导致曲线消失时，不应自动按零错误处理。为关键采集链路设置独立检查，并确认通知通道可用。
先建立少量能行动的指标
小型站点可以先覆盖一个外部核心流程、应用错误与延迟、关键队列，以及主机容量和资源压力。每个告警都说明影响、负责人和首个检查位置，再根据真实事件补充。
验收时人为制造受控的服务异常或停止测试采集，观察指标、告警与恢复通知是否符合预期。监控不是安装完软件就结束；它需要证明当业务发生问题时，合适的人能够看到足够的信息并采取行动。