3、性能监控体系：监控三大支柱与告警设计
性能监控这事儿，我做了十几年SaaS，踩过的坑比走过的路还多。说实话，很多团队一开始都忽视监控，等线上出了故障才手忙脚乱。今天咱们聊聊监控体系的三大支柱——指标、日志、链路追踪，以及怎么用Prometheus+Grafana搭一套靠谱的监控平台。
3.1 监控三大支柱：缺一不可
我习惯把监控体系比作「三脚架」。少一条腿，整个系统就站不稳。哪三条？指标（Metrics）、日志（Logging）、链路追踪（Tracing）。
3.1.1 指标（Metrics）——系统的体温计
指标是数字化的，说白了就是「系统现在怎么样」。比如CPU使用率、QPS、错误率、延迟P99。这些数据是聚合的，不关心单个请求，只关心整体趋势。
我在项目中遇到过，有个服务内存泄漏，指标曲线像爬坡一样慢慢往上走。要不是Prometheus的告警，等用户反馈时估计已经挂了。指标的价值就在这里——提前发现异常。
- RED指标：Rate（请求速率）、Errors（错误数）、Duration（延迟）
- USE指标：Utilization（利用率）、Saturation（饱和度）、Errors（错误数）
- 四大黄金信号：延迟、流量、错误、饱和度
3.1.2 日志（Logging）——系统的病历本
指标告诉你「系统发烧了」，日志告诉你「为什么发烧」。日志是结构化的文本，记录每个请求的详细信息。比如错误堆栈、请求参数、响应结果。
嗯，这里要注意：日志不是越多越好。我曾经见过一个团队，一天产生10TB日志，结果查询一次要等半小时。日志要分级——ERROR、WARN、INFO、DEBUG，线上只保留ERROR和WARN，DEBUG只在调试时开启。
- 统一日志格式：时间戳 + 级别 + 请求ID + 类名 + 消息
- 使用结构化日志（JSON格式），方便ELK或Loki检索
- 敏感信息脱敏：密码、身份证号、银行卡号绝对不能打出来
3.1.3 链路追踪（Tracing）——系统的X光片
微服务架构下，一个请求可能经过十几个服务。如果某个环节慢了，你怎么定位？链路追踪就是干这个的。它记录一次请求经过的所有服务、每个服务的耗时、调用关系。
我记得有一次，用户反馈下单很慢。指标看CPU正常，日志也没报错。最后靠Jaeger的链路追踪发现，是某个老服务调用了第三方API超时重试了3次。没有链路追踪，这种问题排查起来就像大海捞针。
3.2 Prometheus + Grafana 搭建实战
讲完理论，咱们动手搭一套。Prometheus负责采集和存储指标，Grafana负责可视化。这对组合是业界的黄金搭档。
3.2.1 Prometheus 架构与部署
Prometheus的核心是拉模型——它主动去目标服务抓取指标数据。每个服务暴露一个/metrics端点，Prometheus定期来拉。
# prometheus.yml 配置文件示例
global:
scrape_interval: 15s # 每15秒拉一次
evaluation_interval: 15s # 每15秒评估一次告警规则
scrape_configs:
- job_name: 'api-service'
static_configs:
- targets: ['localhost:8080']
- job_name: 'user-service'
static_configs:
- targets: ['localhost:8081']
- job_name: 'node-exporter'
static_configs:
- targets: ['localhost:9100'] # 监控服务器硬件指标部署方式我推荐用Docker Compose，简单又方便。生产环境建议用Kubernetes Operator管理。
scrape_interval：采集频率，太频繁浪费资源，太慢错过异常evaluation_interval：告警评估频率，一般和采集频率一致retention：数据保留时间，默认15天，根据磁盘容量调整
3.2.2 Grafana 可视化配置
Grafana是展示层，把Prometheus的数据变成图表。我个人习惯先建几个核心仪表盘：
| 仪表盘名称 | 包含面板 | 用途 |
|---|---|---|
| 服务概览 | QPS、错误率、P99延迟 | 快速判断服务健康状态 |
| 资源监控 | CPU、内存、磁盘、网络 | 排查资源瓶颈 |
| 数据库监控 | 连接数、慢查询、缓存命中率 | 数据库性能分析 |
| 业务监控 | 注册数、订单数、支付成功率 | 业务指标跟踪 |
Grafana的查询语法是PromQL，举个例子：
# 查询最近5分钟的P99延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# 查询错误率（状态码非200的请求占比）
sum(rate(http_requests_total{status!~"2.."}[5m])) / sum(rate(http_requests_total[5m]))3.3 告警规则设计：别让告警变成噪音
告警设计是监控体系里最考验功力的部分。设计不好，要么漏报（出事了没通知），要么误报（半夜被无关告警吵醒）。
3.3.1 告警分级
我习惯把告警分成三级：
- P0（紧急）：服务不可用、大量错误、核心功能受损。需要立即响应，5分钟内必须有人处理。
- P1（严重）：延迟升高、错误率上升、资源接近饱和。需要30分钟内响应。
- P2（警告）：磁盘使用率超过80%、QPS异常波动。工作时间处理即可。
3.3.2 告警规则示例
# alert.rules.yml 告警规则文件
groups:
- name: service-alerts
rules:
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "{{ $labels.job }} 错误率超过5%"
description: "服务 {{ $labels.instance }} 在过去5分钟内错误率 {{ $value | humanizePercentage }}"
- alert: HighLatency
expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.job }} P99延迟超过2秒"
description: "服务 {{ $labels.instance }} P99延迟 {{ $value }}s"
- alert: DiskSpaceLow
expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.1
for: 10m
labels:
severity: critical
annotations:
summary: "磁盘空间不足10%"
description: "服务器 {{ $labels.instance }} 磁盘剩余 {{ $value | humanizePercentage }}"for参数一定要设置。如果不设，指标一抖动就触发告警，你会被「假告警」淹没。我一般设2-5分钟，确认问题持续存在才发通知。
3.3.3 告警通知与值班
告警发出去得有人看。我推荐用Alertmanager统一管理通知渠道：
- P0：电话 + 短信 + 钉钉/企业微信，确保第一时间通知到
- P1：钉钉/企业微信 + 邮件，要求快速响应
- P2：仅邮件，第二天上班处理
还有一点很重要——告警静默。比如凌晨2点的P2告警，可以设置静默到早上9点。别让运维兄弟半夜爬起来看磁盘用了81%还是80%。
- 可操作性：收到告警后，你明确知道该做什么
- 可避免性：告警应该能通过自动化或流程避免重复发生
- 可容忍性：允许短时间的小波动，别过度告警
好了，监控体系这块就聊到这儿。指标、日志、链路追踪，三者缺一不可。Prometheus+Grafana搭起来不难，难的是告警规则的设计——既要及时发现问题，又不能变成「狼来了」。你想想看，如果告警天天响，大家就麻木了，真正出问题时反而没人重视。所以，设计告警时多花点心思，后面能省很多事。