应使用 scrape_config 配置静态 targets 或服务发现实现多服务器指标统一采集，而非每台服务器独立运行 Prometheus；长期服务必须暴露 /metrics 端点并由中心 Prometheus 主动拉取，短周期任务才用 Pushgateway。
多服务器怎么把指标统一推给Prometheus
不是靠 prometheus 主动去每个服务器抓，而是让每台服务器自己把数据“送”过去——用 pushgateway 或直接暴露 /metrics 端点，前者适合短周期任务（比如脚本、ci）、后者才是长期运行服务的标准做法。
常见错误是：在每台机器上都起一个独立的 prometheus.yml，然后前端连一堆地址。这等于放弃 Prometheus 的联邦能力，后期维护爆炸。
- 长期服务（如 Nginx、MySQL Exporter）必须走
scrape_config配置静态 targets 或用服务发现（consul_sd_configs/file_sd_configs） -
pushgateway只用于批处理、定时脚本等非持续进程，且记得加job和instance标签区分来源，否则指标会覆盖 - 如果服务器在不同内网或 NAT 后，别硬开防火墙让 Prometheus 去抓；改用
remote_write把指标发到中心 Prometheus 实例（例如通过prometheus-remote-write-proxy或直接配remote_write到公网可写 endpoint）
Grafana 看板里怎么显示“某组服务器”的聚合视图
关键不在前端选什么图表，而在 Prometheus 查询时是否正确打标和分组。默认所有 exporter 上报的 instance 是 IP:port，但 IP 会变、不直观，必须提前注入语义标签。
典型翻车现场：看板里看到 10 个一模一样的 CPU 使用率曲线，点开才发现全是同一台机器的重复采集，因为 relabel_configs 没配好，或者用了 pushgateway 却没带唯一 job。
- 在 Prometheus 的
scrape_configs里用static_configs+labels手动打标：env: "prod",role: "api" - 用
relabel_configs从 hostname 解析出区域：source_labels: [__address__],regex: "(.*?)-(\d+)\.example\.com",target_label: region - Grafana 查询写成：
100 - avg by(region, env) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100，而不是裸写node_cpu_...
为什么 Grafana 看板加载慢或数据断层
不是 Grafana 慢，是查询没压住时间范围和分辨率，或者 Prometheus 存储压力大导致响应延迟。多服务器场景下，指标基数（series count）指数级上升，一个没注意就突破百万 series。
立即学习“前端免费学习笔记（深入）”；
最常被忽略的是 scrape_interval 和 evaluation_interval 的配合。比如你设了 15s 抓一次，但 alert rule 每分钟算一次，中间大量数据其实白存了。
- 对非核心指标（如磁盘 inodes、网络连接数），把
scrape_interval放宽到60s，加scrape_timeout: 10s防卡死 - 在 Prometheus 启动参数里加
--storage.tsdb.min-block-duration=2h（默认 2h），避免小块文件过多；同时配--storage.tsdb.max-block-duration=24h - Grafana 面板设置里关掉
Dynamic min step，手动设Min step: 30s，防止 zoom 时触发超高精度查询
如何让不同团队只看到自己的服务器看板
Prometheus 本身没 RBAC，权限得靠外层拦截——要么用 Grafana 的 folder + permission 控制，要么在反向代理层（如 Nginx、Traefik）按请求头或路径过滤 label 查询。
别信“在 Prometheus query 里加 {team="foo"} 就安全了”。用户只要懂 PromQL，就能删掉这个条件查全量数据。
- Grafana 中建 team-specific folder，把 dashboard 移进去，只给对应 team 成员
Viewer或Editor权限 - 用
recording rules预聚合并打标：job:node_cpu_usage:avg1m{team="backend"} = 100 - avg by(job, instance, team) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100，然后只授权查这类预计算指标 - 更彻底的做法：为每个 team 部署独立 Prometheus 实例，用
remote_read聚合中心数据，但只读指定 label 子集（需配合metric_relabel_configs过滤）
真正麻烦的从来不是配置几行 YAML，而是指标生命周期管理：谁负责清理过期 job？哪些 exporter 版本已不兼容？instance 标签变更后告警规则有没有同步更新？这些细节堆在一起，才决定监控系统到底能不能用。
