Prometheus性能监控需关注四大黄金信号：延迟（用直方图计算P95/P99，区分成功与失败请求）、流量（rate指标按标签切分评估负载）、错误（显隐式错误结合，按类型和路径分组）、饱和度（关注排队与等待，如load1、MemAvailable、IO等待）。
Prometheus 性能监控不能只盯着 up == 1 这个布尔值。真正反映系统健康状态的，是四个被广泛验证的“黄金信号”——它们不依赖具体技术栈，却能快速定位用户体验断层、容量瓶颈和故障根源。
延迟（Latency）：用户感知的响应快慢
不是平均耗时，而是分位数——P95 和 P99 更关键。一次慢请求可能拖垮整个链路，尤其在微服务中会引发级联超时。
- 用
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, endpoint))计算各接口 P95 延迟 - 必须区分成功与失败请求的延迟：HTTP 500 响应很快，但代表业务异常；这类“快失败”也要单独统计并告警
- 延迟指标必须基于直方图（Histogram），不能用 Summary——前者支持多维度聚合与服务端分位计算
流量（Traffic）：当前负载的真实刻度
它回答“系统正在处理多少请求”，是容量评估和弹性伸缩的直接依据。
- 用
rate(http_requests_total[5m])获取每秒请求数（QPS），按method、path、status标签切分，便于定位热点接口 - 流量突增未必是问题，但若伴随错误率上升或延迟飙升，就是典型过载信号
- 对非 HTTP 服务（如消息队列、数据库），流量可表现为每秒读写次数、连接建立速率等
错误（Errors）：服务质量的底线标尺
错误率不是“有没有错”，而是“错得有多频繁、错在哪儿”。仅看 5xx 不够，200 里藏业务失败更危险。
- 显式错误（如 HTTP 4xx/5xx）可通过 Nginx VTS 或反向代理采集；隐式错误需在应用层埋点，比如解析响应体中的
{"code":5001} - 推荐监控
rate(http_requests_total{status=~"4..|5.."}[5m]) / rate(http_requests_total[5m])得到整体错误率 - 按错误类型、接口路径、上游服务分组，能快速锁定是网关问题、下游超时，还是自身逻辑缺陷
饱和度（Saturation）：资源临界前的预警哨兵
它告诉你“还能撑多久”，不是当前用了多少，而是排队了多少、等待了多久。
- CPU 饱和看
node_load1 / count by(instance)(node_cpu_seconds_total{mode="idle"})，比单纯 CPU 使用率更能反映真实压力 - 内存饱和不止看使用率，更要关注
node_memory_MemAvailable_bytes是否持续下降、OOM Killer 是否触发 - 磁盘 I/O 饱和用
rate(node_io_wait_time_seconds_total[5m])，结合队列长度node_disk_io_now判断是否积压
