性能基准测试核心是评估exporter对被监控目标的资源影响，需聚焦cpu、内存、系统调用延迟及上下文切换，尤其在高频采集或高密度容器场景中；通过控制scrape_interval和指标粒度（如禁用非必要收集器）进行测试，并在真实业务负载下验证量化指标。

性能基准测试不是给 Prometheus Server “测压力”，而是看它在真实监控场景中是否稳定、低开销、不反噬被监控系统。关键在于分清责任边界：采集开销归 exporter，规则计算开销归 Prometheus Server，告警逻辑开销归 Alertmanager——三者要分开测、分别调优。

聚焦 exporter 的资源影响

node_exporter、cAdvisor、mysqld_exporter 这些才是真正的“采集执行者”。它们运行在目标机器上，会真实消耗 CPU、触发系统调用、增加上下文切换。

• 用 pidstat -w -p 1 对比启动前后每秒上下文切换次数变化
• 用 bpftrace 或 perf trace 捕获 exporte r频繁调用的系统调用（如 getdents64、stat、read），观察延迟是否随采集频率升高而明显拉长
• 容器环境下重点关注 cAdvisor 启动后 kubelet 的 cpu.stat.throttled_time 是否上升，这是 CPU 被节流的直接证据

控制 scrape_interval 和指标粒度

同一 exporter 在不同配置下开销可能差 3–5 倍。不能只看“能跑”，要看“跑得有多轻”。

• 从 5s → 15s → 60s 逐级测试 scrape_interval，记录 exporter 进程的 RSS 内存增长和 CPU 占用峰值
• 禁用非必要收集器：比如 node_exporter 加上 --no-collector.textfile --no-collector.systemd，常可降低 30%+ CPU 开销
• 生产环境优先保留 cpu、memory、diskstats、netdev 四类基础指标，其余按需开启，避免“全量采集”惯性

在真实业务负载下验证

空闲机器上 exporter 可能只占 0.2% CPU，但加上业务压力后可能飙升至 8%——这正是瓶颈所在。

• 用 stress-ng --cpu 4 --io 2 --vm 2 --vm-bytes 1G 模拟中等负载再测 exporter 表现
• Kubernetes 场景下部署 50+ Pod，观察 cAdvisor 是否拖慢 kubelet 的 sync loop（开启 --log-level=4 查日志）
• 对数据库 exporter，在慢查询高峰期检查其抓取耗时是否接近或超过 scrape_timeout，超时即说明已成采集瓶颈

用量化指标替代主观判断

拒绝“好像变慢了”“感觉卡顿”这类描述。所有结论必须基于可复现、可对比的数据。

• 采集延迟中位数（ms）：查 prometheus_target_scrapes_duration_seconds 的 histogram 指标，关注 p50 和 p95
• 规则评估耗时：查 prometheus_rule_evaluation_duration_seconds，P95 应稳定低于 1s
• 样本吞吐量：用 sum(rate(prometheus_rule_evaluation_samples_total[5m])) 看单位时间处理样本数，结合硬件配置设定合理上限