1. 从一张图看懂 Grafana 到底解决什么问题监控系统搭起来容易看懂难。我见过太多团队Prometheus 跑得好好的指标采集了几百个但一出故障还是靠人肉登机器敲命令。问题不在数据在于没有一个能把数据讲清楚的窗口。Grafana 就是干这个的——它本身不存数据也不采集数据它只做一件事把散落在各种数据源里的数字变成人能一眼看懂的图表和告警。你可以把 Grafana 理解成一个“万能仪表盘”。不管你的数据在 Prometheus、MySQL、Elasticsearch 还是 ClickHouse 里它都能接进来用同一套界面展示。这对运维和开发来说意义很大不用为了看不同系统的指标来回切换工具一个面板全搞定。这篇文章适合谁看如果你是刚接触监控的新手我会从安装部署讲到第一个面板搭建如果你已经在用 Grafana 但只会看现成面板我会把 SQL 数据源、告警接入、常见报错排查这些进阶内容拆开讲。所有步骤都是我在实际环境里跑过的参数和配置可以直接抄。提示Grafana 的版本迭代很快本文基于 Grafana 10.x 和 Prometheus 2.x 的稳定组合来写Docker 部署方式为主兼顾二进制安装的关键差异。2. 安装部署Docker 和二进制两条路怎么选2.1 为什么我优先推荐 Docker 部署Grafana 的依赖很简单就是一个二进制文件加配置目录理论上二进制安装也不复杂。但实际运维中Docker 部署有三个绕不开的好处版本回滚快、配置挂载清晰、和 Prometheus 一起编排方便。尤其是当你需要同时跑 Prometheus Grafana 的时候用 Docker Compose 一把梭比手动装两个服务省心得多。镜像下载是第一个坎。国内环境直接拉grafana/grafana:latest经常超时我的做法是明确指定版本号比如grafana/grafana:10.2.3然后配置镜像加速。Prometheus 同理用prom/prometheus:v2.48.0这种带版本号的标签避免latest带来的不可控升级。version: 3.8 services: prometheus: image: prom/prometheus:v2.48.0 volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prom_data:/prometheus ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana:10.2.3 volumes: - grafana_data:/var/lib/grafana - ./grafana-provisioning:/etc/grafana/provisioning ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDyour_strong_password depends_on: - prometheus restart: unless-stopped volumes: prom_data: grafana_data:这个 Compose 文件里有两个细节值得说。第一GF_SECURITY_ADMIN_PASSWORD环境变量直接设初始密码避免第一次登录还要改密码。第二grafana-provisioning目录挂载进去后面做数据源自动配置会用到。depends_on只保证启动顺序不保证 Prometheus 就绪所以 Grafana 刚起来时数据源可能连不上等几十秒刷新即可。2.2 二进制安装的关键差异点有些生产环境不允许跑容器那就得走二进制。Grafana 的二进制包在官网下载页有 tar.gz 和 deb/rpm 两种。我一般用 tar.gz解压后目录结构是bin/、conf/、public/、data/。启动命令就是./bin/grafana-server web但直接跑会有两个问题默认监听 3000 端口可能被占数据目录权限可能不对。配置文件在conf/defaults.ini但不要直接改这个文件正确做法是复制一份到conf/custom.ini然后启动时指定--config。这样升级版本时自定义配置不会丢。关键配置项我列一下配置项默认值建议值说明http_port30003000被占用时改这里datadata/var/lib/grafana生产环境放独立分区logsdata/log/var/log/grafana日志单独管理admin_passwordadmin强密码首次启动后立即改二进制安装还有一个坑systemd 服务文件要自己写。我见过有人用nohup跑结果机器重启后 Grafana 没起来监控面板全黑。正确做法是写一个 unit 文件RestartalwaysUsergrafana把数据目录权限给这个用户。2.3 首次登录后必须做的三件事不管哪种安装方式第一次登录http://ip:3000用 admin 账号进去后别急着建面板先把这三件事做了。第一改密码。默认密码是 admin不改等于门开着。第二检查数据源。左侧齿轮图标进 Configuration → Data Sources如果 Prometheus 已经跑着点 Add data source 选 PrometheusURL 填http://prometheus:9090Docker 内部或http://localhost:9090二进制点 Save Test出现绿色对勾才算通。第三设置时区。默认是 UTC国内团队看面板会差 8 小时在 Preferences 里改成Asia/Shanghai不然排查故障时时间对不上能把人逼疯。注意数据源测试失败时先别怀疑 Grafana。用curl http://prometheus:9090/-/healthy确认 Prometheus 本身活着再检查网络连通性。Docker 环境下两个容器不在同一 network 里是常见原因。3. 数据源接入Prometheus 之外的 Grafana SQL 玩法3.1 Prometheus 数据源的正确配置姿势Prometheus 是 Grafana 最经典的搭档但配置里有个细节很多人忽略Scrape interval 要和 Prometheus 的采集间隔一致。Grafana 默认是 15s如果你的 Prometheus 配的是 30s查询时会出现数据点稀疏、图表断线的情况。在数据源配置页的 Interval 设置里改成和 Prometheus 一致图表会平滑很多。另一个关键参数是 HTTP method。默认 GET查询语句长的时候可能超 URL 长度限制改成 POST 更稳。还有 Custom HTTP Headers如果 Prometheus 前面挂了反向代理需要认证在这里加 Authorization 头。配置完成后进 Explore 页面测试查询。输入up这个指标应该能看到所有采集目标的 1/0 状态。如果返回空检查三件事Prometheus 的 targets 页面里目标是不是 UP、Grafana 数据源 URL 是不是写错、查询时间范围是不是选得太窄。3.2 用 Grafana SQL 直接查业务库这是 Grafana 被低估的能力。很多人以为它只能看时序指标其实接 MySQL、PostgreSQL 做业务数据可视化一样好用。我做过一个订单监控面板数据源直接连 MySQL用 SQL 查当日订单量、支付成功率、平均客单价比写一套后端接口快多了。配置 MySQL 数据源时连接串格式是host:port数据库名单独填。关键在查询语句的写法Grafana 支持变量和宏比如$__timeFilter(created_at)会自动替换成面板选择的时间范围。下面是一个查每小时订单量的例子SELECT $__timeGroupAlias(created_at, 1h), COUNT(*) AS order_count FROM orders WHERE $__timeFilter(created_at) GROUP BY 1 ORDER BY 1$__timeGroupAlias是 Grafana 的宏第一个参数是时间字段第二个是分组粒度。这样写出来的 SQL 会自动适配面板右上角的时间选择器不用手动改 WHERE 条件。实测下来查千万级表加好索引响应在秒级。提示SQL 数据源查询慢会拖垮 Grafana 前端。建议在数据库侧对时间字段建索引并且面板时间范围不要默认选“Last 30 days”改成“Last 6 hours”更实用。3.3 多数据源混用的场景与坑一个面板里同时用 Prometheus 和 MySQL 的数据Grafana 是支持的叫 Mixed Data Source。做法是新建面板时数据源选-- Mixed --然后每个 Query 单独指定数据源。我一般用这个做“指标业务”对照比如上面板显示 CPU 使用率Prometheus下面板显示同时段订单量MySQL故障时能快速判断是资源问题还是业务问题。但混用有个坑时间对齐。Prometheus 的时间戳是毫秒精度MySQL 的created_at可能是秒精度两个图叠在一起会有细微偏移。解决办法是在 SQL 里用UNIX_TIMESTAMP(created_at)*1000转成毫秒或者接受这个误差毕竟看趋势不影响。4. 面板搭建从零做一个能用的监控大盘4.1 面板类型选择与查询语句编写Grafana 的面板类型有十几种常用的就五个Time series时序图、Stat单值、Gauge仪表盘、Table表格、Bar chart柱状图。选错类型会让数据很难看。我的经验是看趋势用 Time series看当前值用 Stat看占比用 Gauge看明细用 Table。以 CPU 使用率为例Prometheus 查询语句是100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)这条语句的意思是先算每个实例 5 分钟内的空闲 CPU 速率乘以 100 得到空闲百分比再用 100 减去它就是使用率。rate函数专门用于 Counter 类型指标[5m]是时间窗口窗口太小曲线抖动太大反应迟钝5 分钟是折中值。写完查询后在面板右侧的 Legend 里填{{instance}}图例就会显示实例 IP而不是一串看不懂的指标名。这个细节能让面板可读性提升一个档次。4.2 变量让面板活起来硬编码 IP 的面板没有生命力换台机器就得改查询。Grafana 的变量功能解决这个问题。在 Dashboard Settings → Variables 里新建一个变量类型选 Query数据源选 PrometheusQuery 填label_values(up, instance)这样变量下拉框会自动列出所有采集实例。然后在面板查询里把 IP 替换成$instance100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle, instance$instance}[5m])) * 100)这样切换下拉框面板就跟着变。我一般还会加一个$env变量区分环境Query 用label_values(up{env~$env}, instance)实现环境级联筛选。变量是 Grafana 最实用的功能之一花十分钟配好后面省几百次改查询的时间。4.3 阈值与告警线的视觉设置面板不只是看曲线还要能一眼看出“正常还是异常”。在 Time series 面板的 Thresholds 设置里可以加两条线黄色表示警告红色表示严重。比如 CPU 使用率80% 画黄线90% 画红线。这样值班的人扫一眼就知道有没有问题不用去读具体数值。设置阈值时有个细节颜色要跟告警规则一致。如果 Grafana 面板里 80% 是黄色但 Alertmanager 里 85% 才告警就会出现面板黄了但没告警的困惑。我的做法是先定告警阈值再反过来设面板阈值保证两者对齐。5. 告警接入Grafana 与 Alertmanager 的配合5.1 Grafana 自带告警和 Alertmanager 的分工Grafana 从 8.0 开始有了 Unified Alerting能自己发告警。那为什么还要接 Alertmanager因为 Alertmanager 的强项是告警路由和静默。比如同一条告警工作时间发钉钉半夜发电话或者某台机器在维护临时静默两小时。这些 Grafana 自带告警做起来很别扭Alertmanager 是专业干这个的。我的建议是简单场景用 Grafana 自带告警复杂路由用 Alertmanager。两者可以共存Grafana 面板负责展示Alertmanager 负责分发。配置方式是在 Grafana 的 Alerting → Contact points 里加一个 Alertmanager 类型的 contact point填 Alertmanager 的地址。5.2 Prometheus 告警规则怎么写才不误报Alertmanager 本身不产生告警告警规则写在 Prometheus 里。一个典型的 CPU 告警规则groups: - name: host_alerts rules: - alert: HighCpuUsage expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 5m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} CPU 使用率过高 description: CPU 使用率已持续 5 分钟超过 85%当前值 {{ $value }}%for: 5m是关键表示连续 5 分钟满足条件才告警。没有这个CPU 偶尔飙一下就会触发告警疲劳就是这么来的。annotations里的{{ $value }}会把实际值填进去收到告警时能直接看到多高不用再去查。5.3 告警从触发到通知的完整链路排查告警不生效时按这个顺序查Prometheus 的 Alerts 页面看规则状态是不是 Firing如果是 Inactive 说明表达式没匹配到数据如果是 Pending 说明还没到for的时间如果是 Firing 但没收到通知去 Alertmanager 的 UI 看告警有没有进来再看 silence 和 route 配置。我踩过的一个坑Alertmanager 的group_wait默认 30sgroup_interval默认 5mrepeat_interval默认 4h。这意味着同组告警第一次等 30s 发之后每 5 分钟更新4 小时才重复。如果测试时改了规则想立刻看效果得手动在 Alertmanager UI 里点 Resolve 或者等 repeat_interval。测试阶段我会临时把repeat_interval改成 1m上线前再改回去。6. 常见报错与排查技巧实录6.1 “failed to upgrade legacy queries datasource im7_otuvz was not found” 怎么解这个报错我遇到过好几次原因是面板引用的数据源 UID 在当前 Grafana 里不存在。通常发生在导入别人分享的 Dashboard JSON 时那个 JSON 里写死了原环境的数据源 UID你的环境里没有这个 UID就报这个错。解决办法有两个。一是导入时在 JSON 里把datasource字段的值改成你环境里实际的数据源名称或 UID。二是导入后进面板编辑手动重新选一次数据源Grafana 会自动修正引用。批量处理的话用sed把 JSON 里的旧 UID 全局替换成新的再导入。提示导出 Dashboard 给别人时在 Save as 里勾选“Export for sharing externally”Grafana 会把数据源引用转成变量形式别人导入时就能自己选避免这个报错。6.2 数据源连不上与查询超时的排查表现象可能原因排查命令解决Save Test 报错URL 写错或网络不通curl http://prometheus:9090/-/healthy改 URL 或检查 network查询返回空时间范围不对或指标名错在 Prometheus UI 直接查调整时间范围查询超时数据量太大或没索引看 Prometheus 查询日志加 recording rule 或索引图表断线采集间隔不一致对比 scrape_interval统一间隔面板加载慢查询太多或时间范围大看浏览器 Network减少 query 或缩小范围这张表是我从多次故障里总结的基本覆盖 90% 的常见问题。排查时按顺序来先确认数据源活着再确认查询语句对最后看性能。6.3 性能优化让大盘加载快起来Grafana 面板加载慢八成是查询太重。优化手段有几个一是用 Recording Rules 在 Prometheus 侧预计算把复杂 PromQL 变成简单指标二是限制面板时间范围默认别超过 6 小时三是减少单面板的 Query 数量一个面板最多 3 到 5 条查询多了拆成多个面板。还有一个容易被忽略的点Dashboard 的 Refresh 间隔。默认可能是 5s 或 10s如果面板多、查询重浏览器会一直发请求。我一般设成 30s 或 1m除非是核心大屏才用 10s。实测把刷新间隔从 5s 改成 30sGrafana 的 CPU 占用能降一半。7. 我踩过的坑和几条实用建议Grafana 的 Dashboard 版本管理是个痛点。它自带的版本历史只能存最近几次而且不好对比。我的做法是把 Dashboard JSON 导出到 Git 仓库每次改动提交一次这样谁改了什么一目了然。导出时用 API 批量拉比手动点省事。另一个建议是给面板加描述。在面板编辑的 Panel options 里有个 Description 字段写上这个面板看什么、正常范围是多少、异常时怎么处理。新人接手时不用问人看描述就懂。这个习惯我坚持了两年团队的值班效率明显提升。最后说一个关于告警的体会告警不是越多越好。我见过一个团队配了 200 条告警规则结果每天收到几百条通知最后所有人都把通知静音了真出事反而没人看。告警要精只对影响用户的问题告警其他的做成面板看就行。这个度需要根据业务来调没有标准答案但“少而准”永远比“多而杂”强。