必须用宿主机IP或Docker服务名（如http://prometheus:9090）配置Prometheus数据源URL，勾选Allow server-side requests，再导入官方模板（如ID 1860），并确保PromQL函数使用正确、告警规则加基数保护。
怎么把Prometheus加进Grafana当数据源
必须填对 URL，否则 Grafana 根本连不上 Prometheus。常见错误是填成 localhost:9090 ——这在容器或远程部署时基本必挂，因为 Grafana 容器里没有 localhost 指向宿主机的概念。
正确做法：用宿主机 IP 或 Docker 网络内可解析的服务名。比如 http://prometheus:9090（docker-compose 同网络）或 http://192.168.1.139:9090（物理机直连）。
- 配置页中「Scrape interval」不用改，默认即可；关键要勾选
Allow server-side requests（尤其跨域或容器环境） - 点
Save & test后看到绿色 “Data source is working” 才算真正通了 - 如果报
HTTP Error Bad Gateway，先确认 Prometheus 服务是否真在运行、端口没被防火墙拦住
仪表盘怎么快速建出来，别从零拖面板
新手硬建仪表盘效率极低，还容易配错时间范围和变量。官方模板 ID 是最稳的启动方式，比如 1860（Node Exporter 全监控）、11074（MySQL Exporter）——这些都经过大量生产验证。
导入路径：Grafana 主页 → + → Import → 输入 ID → 点 Load → 下拉选刚配好的 Prometheus 数据源 → Import。
- 导入后若显示 “No data”，先检查 Prometheus 是否真在采集对应指标（比如访问
http://192.168.1.139:9090/graph，输up看目标是否 up=1） - 模板里的变量（如
$instance）默认会自动匹配 Prometheus 中的标签，不需要手动定义 - 别直接改模板 JSON，改坏了很难恢复；想定制就复制一份再调
写 PromQL 查询时最容易翻车的三个地方
PromQL 不是 SQL，rate()、irate()、sum by() 这些函数行为很反直觉，写错一两个括号或标签就全空。
-
rate(counter_Htest_exception_total[1m])必须用 Counter 类型指标，且区间不能小于 scrape_interval（比如 Prometheus 配了 15s 抓一次，[1m]可以，[10s]就会返回空） - 除法要加括号：写成
rate(a[1m]) / rate(b[1m])，而不是rate(a[1m] / b[1m])（后者语法错误） - 聚合时漏掉
by会导致多实例数据被强行合并，比如sum(rate(http_requests_total[1m]))会把所有服务请求加一起，失去定位能力；应写成sum(rate(http_requests_total[1m])) by (job, instance)
为什么告警老不触发，或者一触发就是误报
告警规则不是写完就完事，它依赖两个关键前提：Prometheus 能稳定抓到数据 + 规则表达式能真实反映业务异常。
比如这个经典误报：rate(counter_Htest_exception_total[1m]) / rate(counter_Htest_total[1m]) > 0.1。测试环境只有几个请求，失败一个就 100% 错误率，但其实完全无害。
- 解决办法是加基数保护：改成
rate(counter_Htest_exception_total[1m]) / rate(counter_Htest_total[1m]) > 0.1 and rate(counter_Htest_total[1m]) > 5，确保每秒至少有 5 次请求才参与判断 - 规则文件（如
alert_rules.yml）必须在prometheus.yml的rule_files里显式声明，且路径是 Prometheus 容器内的路径（不是宿主机路径） - 用
promtool check rules alert_rules.yml提前验语法，比等告警失效后再查快得多
真正难的从来不是加个图表或写条规则，而是搞清“什么数据有意义”“多少量级才算异常”——这得靠你盯着业务日志、流量曲线和错误堆栈来回对齐，工具只是把判断过程固化下来而已。
