Grafana 这玩意儿第一次打开的人十有八九会懵——满屏的空白面板左边一排图标不知道点哪个右上角那个加号点进去又是 Data Source 又是 Dashboard 又是 Explore到底该从哪儿下手我见过太多人装完 Grafana 之后卡在数据源连不上或者面板画不出来这两步然后就放弃了转头继续用top和tail -f看日志。其实 Grafana 的核心逻辑特别简单它本身不存数据只负责把别处查来的数据画成图。想明白这一点后面所有操作都是顺理成章的。这篇内容适合两类人一是刚把 Prometheus 或 MySQL 接进来、准备搭第一块仪表盘的新手二是已经能用但总觉得画出来的图差点意思、想搞清楚阈值告警和查询编辑器细节的老用户。我会从数据源接入讲到面板配置再到阈值告警和几个高频踩坑点尽量把每一步为什么这么点说清楚。1. 先把数据源这件事捋明白1.1 Grafana 不生产数据它只是数据的搬运工很多人对 Grafana 有个误解以为它像 Kibana 那样自带存储。不是的。Grafana 的定位是可视化层它通过 Data Source 插件去连接外部系统查询语句由你写结果由它渲染。所以你在 Grafana 里看到的每一条曲线、每一个数字背后都是一次真实的查询请求。这就解释了一个常见现象为什么 Grafana 面板加载慢因为每次刷新页面它都在向数据源发查询。如果你的 Prometheus 查询范围是 7 天、步长 15 秒那一次面板刷新可能触发几十条 PromQL数据源扛不住就会超时。理解这一点后面优化面板性能时你就知道该从哪儿下手了。数据源的类型决定了你能写什么样的查询。Prometheus 数据源写的是 PromQLMySQL 数据源写的是 SQLElasticsearch 数据源写的是 Lucene 或 KQL。查询语言不同但 Grafana 的展示层是统一的——这就是它最大的价值不管你底层是时序库还是关系库最终都能画在同一块仪表盘上。1.2 接入 Prometheus 数据源的完整操作Prometheus 是 Grafana 最常见的搭档接入步骤不复杂但有几个字段容易填错。进入Configuration → Data Sources → Add data source选 Prometheus。关键配置项如下配置项填写内容说明NamePrometheus自定义名称后续面板引用HTTP URLhttp://localhost:9090Prometheus 服务地址AccessServer (default)由 Grafana 后端代理请求Scrape Interval15s需与 Prometheus 配置一致HTTP MethodGET默认即可填完点Save Test出现绿色提示 Data source is working 才算成功。如果报错八成是这三个原因URL 写成了https但服务是httpGrafana 跑在容器里却用了localhost容器内的 localhost 指向容器自己应该用宿主机 IP 或容器网络别名Prometheus 开了认证但没填 Basic Auth。提示Grafana 和 Prometheus 都用 Docker 部署时建议放在同一个自定义网络里数据源 URL 直接写容器名比如http://prometheus:9090比写 IP 稳定得多。1.3 多数据源混用的场景与坑实际项目里经常需要多数据源Prometheus 看指标MySQL 看业务数据Elasticsearch 看日志。Grafana 支持在同一个面板里用Mixed数据源但这里有个坑——不同数据源的查询结果时间戳精度可能不一致混在一起画会出现曲线错位。我的做法是能用单一数据源解决的绝不混用。确实需要混用时给每个数据源起清晰的名字比如prom-metrics、mysql-business在面板里通过变量切换而不是硬塞进一个 Mixed 查询。另外MySQL 数据源查询大表时一定要加时间范围过滤Grafana 内置的$__timeFilter(time_column)宏就是干这个的不加的话每次刷新都是全表扫描数据库迟早被你拖垮。2. 仪表盘和面板从空白到能看2.1 新建仪表盘时先想清楚给谁看我见过太多人一上来就堆面板结果做出来的仪表盘自己都不想看第二眼。仪表盘的本质是信息传达不是数据堆砌。动手之前先问自己这块盘是给谁看的给运维自己看可以密一点CPU、内存、磁盘、网络全上方便排查。给领导看只放核心业务指标大数字面板Stat比折线图更直观。给开发看接口延迟、错误率、QPS 三件套配合日志跳转链接。想清楚受众面板的密度、颜色、单位就都有依据了。新建仪表盘走Dashboards → New → New Dashboard → Add visualization先选数据源再写查询。2.2 查询编辑器里那几个必须搞懂的开关以 Prometheus 数据源为例查询编辑器里有一排开关新手最容易忽略它们但它们直接决定图对不对。Legend图例决定曲线旁边显示什么名字。默认显示的是完整的指标名加标签又长又乱。正确做法是用{{label_name}}模板比如{{instance}}或{{job}}这样图例就清爽了。Min step最小步长控制数据点密度。不填的话 Grafana 会自动算但自动算的结果有时太密导致曲线毛刺多。一般设成 scrape interval 的 1 到 2 倍比如 15s 或 30s。Resolution分辨率是 1/1 到 1/10 的档位数值越小点越密。它和 Min step 配合使用调的时候盯着图看找到曲线平滑但不失真的那个点。Format选 Time series 还是 Table 很关键。想看趋势选 Time series想做 TopN 排行选 Table。选错了后面 Transform 都救不回来。2.3 面板类型怎么选折线、柱状还是 StatGrafana 的面板类型有十几种常用的就五个选对了事半功倍。Time series折线图看趋势的首选CPU 使用率、QPS、延迟都适合。Stat大数字单个关键指标比如当前在线人数、今日订单量。配上阈值颜色一眼就知道正不正常。Bar chart柱状图对比不同维度的值比如各接口的调用次数。Table表格需要看具体数值和多个字段时用比如慢查询列表。Gauge仪表盘有明确上下限的指标比如磁盘使用率、内存占用。选面板类型有个简单原则看趋势用折线看当前值用 Stat看对比用柱状看明细用表格。拿不准的时候先用 Time series大部分场景它都能兜住。3. 阈值、告警与视觉提示3.1 面板阈值和告警阈值是两回事这是新手最容易混淆的地方。面板阈值Thresholds只影响颜色显示不触发任何通知告警阈值Alert rules才会真正发通知。很多人配了面板阈值以为告警就生效了结果出事时一条消息都没收到。面板阈值在面板编辑器的Thresholds区域配置比如给 CPU 使用率设绿色 60%黄色 60%-85%红色 85%。这样曲线超过 85% 时自动变红肉眼扫一眼就知道有问题。告警阈值则要在Alerting → Alert rules里单独建规则指定查询、条件、持续时间for、通知渠道。两者独立配置互不影响。3.2 配置一条能用的告警规则以CPU 使用率持续 5 分钟超过 85%为例完整步骤如下进入Alerting → Alert rules → New alert rule。填 Rule name比如High CPU Usage。选数据源和查询PromQL 写100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)。在Expressions里加一个 ReduceFunction 选 Last把时序压成单值。加一个 Threshold 表达式条件设Is above 85。Evaluate every设 1mfor设 5m——意思是连续 5 分钟都满足才告警避免毛刺误报。配置 Notification 渠道保存。这里for参数是精髓。不设for的话CPU 瞬间飙一下就会告警一天能给你发几百条。设成 5m 或 10m只有持续异常才通知信噪比高得多。3.3 告警通知渠道的配置要点Grafana 支持邮件、Webhook、钉钉、企业微信等通知方式。配置入口在Alerting → Contact points。以 Webhook 为例填一个接收告警 JSON 的地址即可Grafana 会把告警详情 POST 过去。注意Grafana 8 之后告警体系改成了 Unified Alerting和老版本的 Dashboard Alert 不兼容。升级时如果发现原来的告警不生效检查一下是不是这个原因。老告警需要手动迁移到新体系。通知模板Notification templates可以自定义消息格式默认的英文模板对国内团队不友好。可以在 Contact point 里关联自定义模板把标题改成中文把关键标签instance、severity拼进正文收到消息一眼就能定位问题。4. 那些文档里不写的实操经验4.1 面板加载慢先查查询范围面板转圈半天出不来第一反应不该是Grafana 卡了而是去看查询范围。右上角时间选择器如果设的是 Last 30 days而数据源是 Prometheus那一次查询要拉 30 天的数据点不慢才怪。我的习惯是默认时间范围设成 Last 1 hour需要看长周期时手动调。另外在 Dashboard Settings → Time options 里把常用范围固定下来比如 5m、15m、1h、6h、24h、7d避免每次手输。4.2 变量Variables让一块盘顶十块盘如果每台机器都建一块仪表盘那维护成本会爆炸。正确做法是用Variables。在 Dashboard Settings → Variables 里建一个instance变量Query 写label_values(node_cpu_seconds_total, instance)然后在面板查询里用$instance引用。这样一块盘就能切换查看所有机器。变量类型有 Query、Custom、Interval 等。Query 类型从数据源动态拉取值机器增减时自动更新最省心。Custom 类型适合固定选项比如环境切换prod/staging/dev。4.3 导入现成仪表盘别从零画Grafana 官方社区有大量现成仪表盘ID 直接导入即可。比如 Node Exporter 的经典盘 ID 是 1860导入后稍作调整就能用。导入路径Dashboards → New → Import填 ID 或粘贴 JSON。但导入的盘不能直接用必须检查数据源引用和变量。很多社区盘用的是DS_PROMETHEUS这种占位符导入时要映射到你自己的数据源。变量名也可能对不上需要手动改。花十分钟调整比从零画省两小时。4.4 常见报错速查报错信息原因解决Datasource was not found数据源被删或改名重新映射面板数据源failed to upgrade legacy queries老版本查询格式手动重写查询或降级context deadline exceeded查询超时缩小时间范围或加 steptoo many outstanding requests并发查询过多减少面板数或加缓存failed to upgrade legacy queries这个错我踩过原因是 Grafana 升级后老面板的查询格式不兼容。解决办法是打开面板把查询删掉重写一遍或者用 Grafana 自带的迁移工具。预防措施是升级前先导出所有仪表盘 JSON 备份。5. 把 Grafana 用顺手的几个习惯5.1 命名规范从第一天就定好仪表盘、面板、变量、告警规则的命名一开始不定规矩后面就是一团乱麻。我的命名习惯是仪表盘用[业务]-[层级]-[用途]比如订单-应用-概览面板标题直接写指标含义比如订单创建 QPS别写Panel 1变量名用小写加下划线比如instance、job。命名规范的好处是搜索时能快速定位。Grafana 的搜索支持标签Tags给仪表盘打上prod、order、core这类标签找起来比翻列表快得多。5.2 用 Snapshot 分享别直接给链接需要把仪表盘分享给同事看时直接发链接对方可能没权限或者数据实时变化导致看到的和你不一样。这时候用Snapshot在仪表盘右上角 Share → Snapshot生成一个静态快照包含当前时刻的数据任何人打开都能看到同样的内容。Snapshot 分本地和云端两种。本地快照存在 Grafana 实例里云端快照需要配置外部存储可以生成公开链接。分享排查现场时特别有用把出问题那一刻的图固定下来事后复盘有据可查。5.3 定期清理别让仪表盘变成垃圾场用久了仪表盘会越积越多很多是临时建的、早就没用的。建议每个月清理一次把废弃的盘归档或删除。Grafana 没有自动清理功能得手动来。判断标准很简单过去一个月没人打开过的盘基本可以删了。另外面板里的查询也要定期 review。业务变了指标名可能也变了老查询会返回空数据面板上就是一条平线或者 No data。看到 No data 别放着不管要么修查询要么删面板。5.4 性能优化的三个实操点第一给高频查询加缓存。Grafana 企业版有查询缓存开源版可以用数据源自带的缓存或者在前端加一层。第二减少面板数量。一块盘上 30 个面板每次刷新就是 30 次查询砍到 10 个以内体验会好很多。第三合理设置刷新间隔。默认 5s 刷新对大多数场景太频繁改成 30s 或 1m服务器压力小很多肉眼也看不出差别。我自己的生产环境仪表盘刷新间隔统一设 1m关键告警盘设 30s既保证及时性又不给数据源添堵。这套配置跑了两年多没出过因为 Grafana 查询把 Prometheus 拖垮的情况。最后分享一个我用了很久的小技巧把常用的仪表盘链接固定在浏览器书签栏按业务分组。Grafana 的 URL 支持带参数比如?var-instanceweb-01fromnow-1htonow可以直接跳到指定机器、指定时间范围。排查问题时点一下书签就到位比每次手动选快得多。