3、核心工具选型：流量发生器与监控告警体系
工具选型这事儿，说白了就是给调试链找几把趁手的兵器。我这些年折腾下来，发现很多团队上来就追求“最火”的工具，结果要么太重，要么跟自己的场景根本不搭。今天咱们就聊聊流量发生器、监控和告警这三块，怎么挑、怎么搭。
核心思路：流量发生器负责“制造问题”，监控负责“发现问题”，告警负责“通知问题”。三者缺一不可，但选型标准完全不同。
3.1 流量发生器：wrk / ab / locust 怎么选？
先说说压测工具。我见过有人用 ab 压 WebSocket 接口，结果测了半天数据全是错的——工具压根不支持。所以选型第一步，得搞清楚你的场景。
| 工具 | 协议支持 | 并发模型 | 脚本能力 | 适合场景 |
|---|---|---|---|---|
| wrk | HTTP/1.1, HTTP/2 | 多线程 + epoll | Lua 脚本（有限） | 简单 HTTP 接口、短连接压测 |
| ab | HTTP/1.0, HTTP/1.1 | 单进程 + 多线程 | 无 | 快速验证、单机简单压测 |
| locust | HTTP, WebSocket, gRPC 等 | 协程（gevent） | Python 脚本（灵活） | 复杂业务场景、分布式压测 |
我个人习惯：快速验证用 ab，几秒钟就能跑一轮。wrk 适合做稍微正式点的压测，它的 Lua 脚本虽然有限，但写个自定义 header、body 模板足够了。至于 locust，我一般在需要模拟用户登录、下单、支付这种完整业务流程时才用它。
小技巧：wrk 的 -s 参数可以加载 Lua 脚本。比如你想模拟带 Token 的请求，写个几十行的 Lua 脚本就行，比用 Postman 手动点靠谱多了。
3.1.1 实战：用 wrk 压测一个 REST API
举个例子。我之前帮一个电商团队排查下单接口的瓶颈。他们的接口需要传一个动态的 Token，ab 搞不定，wrk 正好。
# 安装 wrk（macOS）
brew install wrk
# 简单压测：10 个线程，100 个连接，持续 30 秒
wrk -t10 -c100 -d30s http://api.example.com/orders
# 带 Lua 脚本的压测
wrk -t4 -c200 -d60s -s token.lua http://api.example.com/orders那个 token.lua 脚本长这样：
-- token.lua
wrk.method = "POST"
wrk.body = '{"product_id": 123, "quantity": 1}'
wrk.headers["Content-Type"] = "application/json"
-- 每次请求前生成新的 Token
function request()
local token = generate_token() -- 自定义函数
wrk.headers["Authorization"] = "Bearer " .. token
return wrk.format()
end注意：wrk 的 Lua 脚本不支持异步操作，所以生成 Token 的逻辑不能太复杂。如果 Token 生成需要查数据库，那还是用 locust 吧。
避坑指南：我曾经用 ab 压测一个 HTTPS 接口，结果发现 CPU 跑满了但 QPS 上不去。后来排查发现 ab 默认不支持 HTTP/2 的复用，每个请求都要重新握手。换成 wrk 后，QPS 直接翻了 3 倍。所以压测前，先确认工具是否支持你的协议版本。
3.2 监控工具：Prometheus + Grafana 黄金组合
监控这块，Prometheus + Grafana 基本是业界标配了。为什么？因为 Prometheus 的拉模型（Pull）比传统推模型（Push）更稳定，Grafana 的仪表盘又足够灵活。
你想想看，如果监控系统挂了，推模型的 Agent 可能会把数据积压在内存里，等恢复后再一股脑推过来，直接把监控系统冲垮。Prometheus 的拉模型就不会——它定期去抓，抓不到就等下一轮，不会造成雪崩。
3.2.1 Prometheus 核心概念
- 指标（Metric）：比如
http_requests_total，记录请求总数。 - 标签（Label）：给指标打标签，比如
method="POST"、status="200"。 - 采集器（Exporter）：把业务数据转成 Prometheus 格式。比如
node_exporter采集系统指标，redis_exporter采集 Redis 指标。 - 告警规则（Alert Rule）：在 Prometheus 里定义阈值，触发后发给 Alertmanager。
我建议：刚开始别搞太复杂。先装一个 node_exporter 把 CPU、内存、磁盘监控起来，再装一个 blackbox_exporter 做 HTTP 探活。等跑顺了再慢慢加业务指标。
3.2.2 Grafana 仪表盘实战
Grafana 的配置其实不复杂。我一般这么干：
- 添加 Prometheus 数据源（URL 填
http://prometheus:9090）。 - 导入现成的仪表盘模板（比如 Node Exporter Full 的 ID 是 1860）。
- 根据业务需求，自己拖几个图表出来。
举个例子，监控下单接口的 QPS 和延迟：
# PromQL 查询 QPS
rate(http_requests_total{endpoint="/orders", status="200"}[1m])
# PromQL 查询 P99 延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{endpoint="/orders"}[1m]))把这些查询加到 Grafana 的 Panel 里，一个实时监控面板就出来了。
经验之谈：Grafana 的 Alert 功能虽然能用，但我更推荐把告警逻辑放在 Prometheus 里。因为 Prometheus 的告警规则更灵活，而且可以跟 Alertmanager 深度集成。Grafana 的告警更适合做“通知型”的，比如“磁盘空间不足”这种简单场景。
3.3 告警系统：Alertmanager 的降噪艺术
告警系统最怕什么？怕“狼来了”。如果每天收到几百条告警，真正需要处理的没几条，那团队很快就会麻木。Alertmanager 的核心价值，就是帮你做告警降噪。
3.3.1 Alertmanager 三大核心功能
| 功能 | 说明 | 我的建议 |
|---|---|---|
| 分组（Grouping） | 将相似的告警合并成一条通知 | 按服务名 + 告警类型分组，避免刷屏 |
| 抑制（Inhibition） | 当某个告警触发时，抑制其他相关告警 | 比如“服务器宕机”触发后，抑制所有该服务器的业务告警 |
| 静默（Silence） | 在指定时间段内屏蔽特定告警 | 用于计划内维护，避免误报 |
我记得有一次线上出了故障，数据库主库挂了。结果告警系统一口气发了 200 多条消息——从“主库延迟”到“从库复制异常”到“订单写入失败”，全来了。运维同学手机直接炸了。后来我配置了抑制规则：只要“主库不可用”触发，所有跟数据库相关的告警都自动静默。从那以后，告警量降了 80%。
3.3.2 配置示例
一个典型的 Alertmanager 配置：
# alertmanager.yml
route:
group_by: ['service', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'team-ops'
receivers:
- name: 'team-ops'
webhook_configs:
- url: 'http://webhook.example.com/alert'
send_resolved: true这里的关键参数：
group_wait：等待 30 秒，把同一组的告警攒一波再发。group_interval：同一组告警，5 分钟内不再重复发送。repeat_interval：如果告警一直没恢复，4 小时后再提醒一次。
避坑指南：我曾经把 repeat_interval 设成了 5 分钟，结果一个磁盘告警没处理，团队一晚上收到了 100 多条重复消息。第二天大家集体把告警群屏蔽了……所以重复间隔别太短，4 小时是个不错的起点。
3.4 整体架构图
下面这张图展示了流量发生器、监控和告警的协作关系。你可以看到，压测工具负责制造流量，Prometheus 采集指标，Grafana 展示，Alertmanager 负责通知。
3.5 选型总结
最后给个总结吧。工具没有最好的，只有最合适的。
- 流量发生器：简单场景用 ab，常规 HTTP 用 wrk，复杂业务流程用 locust。
- 监控：Prometheus + Grafana 是标配，别折腾别的了。
- 告警：Alertmanager 的降噪能力是关键，分组、抑制、静默三个功能用好，告警量能降 90%。