Linux Grafana 可视化监控实践

最常见原因是 grafana-server 默认绑定 127.0.0.1:3000，导致外部无法访问；需修改 grafana.ini 中 http_addr = 0.0.0.0 并重启服务。 为什么 启动后访问不了 3000 端口 最常见原因是服务没真正监听在 ，而是绑定了 （默认行为），导致宿主机外无法访问。 检查方式： ，看 列是不是 或 ；如果是 ，就得改配置。 修改 ，找到 段，把 改成 确认 是 （别被防火墙或 systemd socket 占用） 重启服务： ，再查一遍 输出 如果用 Docker 启动，必须加 ，且镜像内配置仍需设为 ，否则容器网络层不转发 添加 Prometheus 数据源时显示 “Failed to fetch” 不是 Grafana 配置错，而是它根本连不上 Prometheus 的 接口。Grafana 运行在服务端，所有请求都从服务端发起，不是浏览器发的 —— 所以填 在容器或远程部署时必然失败。 典型错误场景：Prometheus 跑在本机 Docker，Grafana 跑在另一台服务器；或者两者都在同一台机器但用了不同网络模式（如 host vs bridge）。 填数据源 URL 时，用能被 Grafana 进程直接访问的地址，比如 （确保 DNS 或 hosts 可解析） 如果 Prometheus 开了认证，必须在数据源配置里勾选 并填用户名密码，不能只靠反向代理透传 检查 Grafana 日志： ，搜 和 关键字 临时验证连通性：进 Grafana 容器或服务器执行 ，看是否返回 JSON 和 在面板里数值跳变太大 这不是 bug，是函数设计使然： 基于时间窗口内总增量平滑计算每秒速率，适合观察长期趋势； 只取最近两个样本点算瞬时变化率，对短周期抖动极度敏感 —— 尤其当 Prometheus 抓取间隔不稳、或指标本身采样稀疏时。 Docker Desktop（linux） 当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。 下载 比如抓取间隔是 15s，但某次延迟到 40s， 就会把这 40s 的增量全摊到“最后 2 个点之间”，造成虚高。 监控 QPS、HTTP 错误率这类业务指标，优先用 ，5m 是稳妥下限 调试突发毛刺时才用 ，且必须配合足够密的抓取间隔（≤10s）和稳定 scrape_target 避免在 外再套 等聚合，会放大误差；先聚合再算速率更合理 如果面板刷新频繁（irate() 图形会疯狂闪烁，建议调大面板刷新间隔或换 仪表盘导入后变量不生效、下拉为空 变量（Variables）是 Grafana 的运行时逻辑，不会随 JSON 导入自动重建 —— 导入只是覆盖面板布局和查询语句，变量定义必须单独配置。 现象：导入 JSON 后，面板里写着 ，但顶部变量下拉框是空的，查询也报 。 进该 dashboard 设置 → → 点右上角 ，手动补全名称、类型（如 ）、数据源、查询语句（如 ） 注意变量名大小写必须和面板查询里完全一致（ ≠ ） 如果变量类型是 或 ，它们不依赖数据源，但需确认是否被 dashboard JSON 里的 正确引用 某些旧版导出 JSON 里变量定义嵌在顶层字段，新版 Grafana 可能忽略；建议统一用 UI 创建变量，再导出 变量逻辑跑在前端还是后端不重要，关键是 Grafana server 启动后要能执行变量查询语句并缓存结果。任何一步断开（权限、语法、超时），下拉就为空。