2、性能监控体系：监控指标设计、Prometheus + Grafana 搭建、告警规则配置
性能调优这件事，说白了就是「先发现问题，再解决问题」。但问题怎么发现？靠猜吗？当然不是。你得有一双眼睛，时刻盯着系统的每一个角落。这双眼睛，就是监控体系。
我这些年经手过的分布式系统，但凡出过大故障的，十有八九都是监控没做到位。要么指标没采全，要么告警没配好，等用户投诉了才发现系统早就不行了。嗯，今天我们就来聊聊，怎么搭一套靠谱的监控体系。
2.1 监控指标设计：到底该看什么？
很多人一上来就堆指标，CPU、内存、磁盘、网络……全给整上。结果呢？告警风暴来了，一天几千条，最后谁都不看。我个人习惯，指标设计要遵循一个原则：少而精，分层看。
我把监控指标分成四个层次，你想想看，是不是这个理：
| 层次 | 关注点 | 典型指标 |
|---|---|---|
| 基础设施层 | 机器还活着吗？ | CPU使用率、内存使用率、磁盘IO、网络带宽 |
| 中间件层 | 组件工作正常吗？ | Kafka积压量、Redis命中率、MySQL慢查询数 |
| 应用层 | 业务跑得顺吗？ | QPS、响应时间P99、错误率、接口调用量 |
| 业务层 | 用户受影响了吗？ | 订单成功率、支付耗时、用户登录失败数 |
我在项目中遇到过一件事：有个服务CPU飙到90%，但业务层指标一切正常。后来发现是后台一个离线任务在跑，根本没影响用户。你看，只看底层指标容易误判，得结合业务层一起看。
2.2 Prometheus + Grafana 搭建：从零开始
选Prometheus做监控，说白了就是看中它两点：一是拉模式，二是自带时序数据库。不用额外搭存储，省心。Grafana呢，就是给数据穿衣服的，让数字变成图表，一眼就能看出问题。
搭建其实不复杂，我直接给你看最简配置。
2.2.1 部署 Prometheus
先下载，再启动。就这么简单。
# 下载 Prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar -xzf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64
# 编辑配置文件 prometheus.yml
# 我习惯把目标服务写在 scrape_configs 里
配置文件长这样：
global:
scrape_interval: 15s # 每15秒拉一次数据
evaluation_interval: 15s # 每15秒评估一次告警规则
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['localhost:9100'] # 采集本机指标
- job_name: 'my_app'
metrics_path: '/metrics'
static_configs:
- targets: ['192.168.1.100:8080'] # 采集应用指标
启动命令：
./prometheus --config.file=prometheus.yml
访问 http://localhost:9090，看到界面就说明成功了。
2.2.2 部署 Grafana
Grafana更简单，一条命令搞定：
docker run -d -p 3000:3000 --name=grafana grafana/grafana:latest
访问 http://localhost:3000，默认账号密码都是 admin。进去之后第一件事，添加数据源，选Prometheus，填上地址 http://localhost:9090。
然后你就可以开始画图了。我个人习惯，先建一个「系统总览」面板，把CPU、内存、QPS、错误率放一起。这样一打开Grafana，心里就有数了。
2.3 告警规则配置：别让监控变成摆设
监控搭好了，图也画了，但你不能24小时盯着屏幕吧？告警就是你的替身，出了问题它喊你。
Prometheus的告警规则写在单独的文件里，然后在主配置里引用。我举个例子：
# alert_rules.yml
groups:
- name: example_alerts
rules:
- alert: HighCPUUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "实例 {{ $labels.instance }} CPU 使用率超过 80%"
description: "当前值: {{ $value }}%"
- alert: ServiceDown
expr: up{job="my_app"} == 0
for: 1m
labels:
severity: critical
annotations:
summary: "服务 {{ $labels.instance }} 挂了"
然后在 prometheus.yml 里加上：
rule_files:
- "alert_rules.yml"
- expr：告警条件，用PromQL写。比如CPU超过80%就触发。
- for：持续时间。持续5分钟才告警，避免瞬时的毛刺误报。
- severity：严重级别。我一般分 warning 和 critical，critical 直接打电话。
告警规则配好后，还得配告警接收器。Prometheus本身不负责发消息，它把告警推给 Alertmanager。Alertmanager 再负责发邮件、钉钉、企业微信什么的。
配置 Alertmanager 也很简单：
# alertmanager.yml
route:
receiver: 'default-receiver'
routes:
- match:
severity: critical
receiver: 'critical-receiver'
receivers:
- name: 'default-receiver'
email_configs:
- to: 'team@example.com'
from: 'alert@example.com'
smarthost: 'smtp.example.com:587'
auth_username: 'alert@example.com'
auth_password: 'password'
- name: 'critical-receiver'
webhook_configs:
- url: 'http://dingtalk-webhook:8080/send'
for: 5m，世界清净了。记住，告警要「稳准狠」，别搞成「狼来了」。
2.4 实战经验：监控体系落地三步走
光有工具不行，得落地。我总结了三步：
- 先采后看：先把所有服务的指标暴露出来，用 Prometheus 采集。别急着画图，先保证数据进来了。
- 再画再看：在 Grafana 里建几个核心面板。我建议先建「服务概览」和「错误追踪」两个面板。
- 最后告警：等跑了一两周，摸清了系统的正常水位，再配告警规则。这样阈值才准。
你想想看，如果一上来就配告警，你连系统正常值是多少都不知道，那不是瞎配吗？
好了，这一章的内容就到这。监控体系搭好了，你就等于给系统装上了「心电图」。下一章我们聊聊怎么用这些数据做性能分析，找到真正的瓶颈。