1. 为什么Prometheus非要配个Grafana说实话Prometheus自带的表达式浏览器就是那个Graph页面确实能用但也就停留在能用的水平。你让开发看一下QPS曲线他得先学会PromQL你让老板看一眼线上状态他对着满屏的时序数字直接懵掉。这就像你手里有一台上好的单反但只有一块黑白取景屏拍出来的照片得靠脑补才知道长什么样。Grafana在这套监控体系里扮演的角色很简单把Prometheus里那些时序数据变成看得懂的图表、面板和仪表盘。它不负责采集也不负责存储告警规则它就负责一件事——好看、好用、好分析地把数据呈现出来。而且它天生就是为Prometheus而生的两者之间的配合几乎是无缝的数据源一加查询一写图表立刻出来。这套组合能干的事远不止画几条曲线。举个我自己的场景上个月帮朋友排查一个线上接口的慢查询问题Prometheus负责采集MySQL的慢查询指标Grafana把每个索引的扫描行数、查询耗时、锁等待时间画在同一个面板上再叠加一个告警线。问题定位只花了十分钟——不是查询语句写得烂而是某个时间段定时任务和业务高峰撞在一起磁盘IO被打满了。没有Grafana的一图流可视化这种问题光靠看Prometheus的命令行输出够你翻半天。所以这篇内容就是写给谁看的给那些已经装好Prometheus、正在能用阶段挣扎的人。你不需要是前端专家也不需要懂什么设计美学跟着做就能搭出一套像模像样的可视化监控系统。2. 先搞懂Grafana在整个监控链路里的位置很多人一上来就急着装Grafana、配数据源、导Dashboard结果遇到问题一头雾水。我建议先花两分钟理清这套监控系统的整体架构后面出了任何问题你都知道该去查哪一环。一条典型的Prometheus监控链路长这样采集端Exporter把指标暴露成HTTP接口 - Prometheus定时拉取并存储 - Grafana通过PromQL查询Prometheus的数据并渲染成图表 - Alertmanager接收Prometheus推送的告警事件并负责通知。Grafana在这条链路里的位置是最上层它只和数据源打交道不直接碰采集端。这意味着你排查问题的时候得按链路一层层来——图表没数据先查Grafana能不能连上Prometheus再查Prometheus有没有采集到目标最后才查Exporter是不是正常。跨层排查是新手最容易犯的错一上来就怀疑Grafana配置有问题其实Prometheus那边压根就没数据。Grafana能接入的数据源远不止Prometheus一个。MySQL、PostgreSQL、Elasticsearch、InfluxDB、Loki甚至Excel它都能接。但在这套监控体系里最核心的数据源就是Prometheus所以我下面每一步操作都围绕Grafana Prometheus这个组合来展开。2.1 Grafana和Prometheus的分工边界Prometheus负责数据采集、指标存储、PromQL查询、告警规则评估。Grafana负责数据可视化、Dashboard管理、告警展示、用户权限管理、多数据源聚合展示。有一条边界必须刻在脑子里Grafana不是一个数据存储系统它不保存历史指标数据。每次你打开一个Dashboard图表发起的查询都是实时打到Prometheus上的。所以经常有人问为什么Grafana里看不到几个月前的数据——答案很简单Prometheus默认只保留15天数据除非你调整了保留策略Grafana再神通广大也不可能画出不存在的数据。提示如果你需要长期保存历史数据做趋势分析方案是把Prometheus的数据通过Thanos或VictoriaMetrics做远程存储Grafana那边不用动数据源地址指向远程存储的查询接口就行。2.2 版本选型Grafana的版本迭代非常快目前主流版本已经到10.x甚至11.x了。我的建议很直接别用最新的也用太老的去官方下载页挑一个9.x或10.x的稳定版就行。为什么这么说新版功能确实多但很多插件和Dashboard模板还没跟上容易遇到兼容性问题。而太老的版本会有一些已经修复的bug重新踩一遍。我目前生产环境用的是10.4.x跑了半年多没出过幺蛾子。部署方式有三种二进制包、Docker、Kubernetes。个人学习或小规模场景直接Docker跑最省事一条命令搞定生产环境如果是物理机或虚拟机就装二进制版本管理起来更直观如果你本身就在K8s里面跑Prometheus那Grafana也直接以Deployment方式扔进去跟整个集群一起管。3. Grafana的安装部署两种方式二选一3.1 Docker方式部署如果你是刚接触这套体系我强烈建议先从Docker方式开始省去各种依赖问题的折腾。先拉镜像docker pull grafana/grafana:10.4.2然后启动容器docker run -d \ --namegrafana \ -p 3000:3000 \ -v grafana-storage:/var/lib/grafana \ -e GF_SECURITY_ADMIN_PASSWORDadmin123 \ grafana/grafana:10.4.2这里有几个细节值得说一下。端口我默认映射到3000这是Grafana的默认端口如果你机器上3000被占了就改成别的宿主端口。-v参数挂载了一个名为grafana-storage的Docker卷这个很重要Grafana的配置、数据库、插件都存这里面。如果不挂载容器一删你辛辛苦苦配好的数据源和面板全没了这个坑我踩过别重蹈覆辙。-e参数设置的是admin初始密码Grafana默认用户名是admin第一次登录必须改密码。用环境变量注入的好处是首次登录不用走强制改密流程直接就能进去操作。注意生产环境建议把GF_SECURITY_ADMIN_PASSWORD放在容器编排工具的安全变量里不要明文写在启动命令中。3.2 二进制包方式部署如果是在内网环境Docker不一定能用二进制包更稳妥。到Grafana官网下载页选对应操作系统的包比如Linux amd64架构wget https://dl.grafana.com/oss/release/grafana-10.4.2.linux-amd64.tar.gz tar -zxvf grafana-10.4.2.linux-amd64.tar.gz cd grafana-10.4.2启动之前先改一下配置文件配置文件在conf/defaults.ini但官方建议不要直接改它而是复制一份custom.ini再改cp conf/defaults.ini conf/custom.ini在custom.ini里确认以下几个关键配置项[server] http_port 3000 root_url http://你的服务器IP:3000 [security] admin_user admin admin_password admin123 [auth.anonymous] enabled falseroot_url这个配置容易被忽略但它很关键。如果你以后要配置通过Nginx反向代理访问Grafana或者告警通知里的链接要能正确跳转root_url必须设置成客户端实际访问的地址。否则你收到告警邮件点开里面的链接发现跳到localhost那场面很尴尬。启动方式也很简单./bin/grafana server web或者注册成systemd服务管理这就看你那边的基础设施习惯了。3.3 首次登录和数据源配置无论哪种方式装好打开浏览器访问http://IP:3000用admin账号登录。第一次进去Grafana会让你修改密码然后就进入主界面了。接下来的第一件事就是配数据源。点击左侧菜单栏的Connections - Data sources - Add data source找到Prometheus点进去。需要填的核心配置就三项配置项填写内容说明URLhttp://Prometheus的IP:9090必须是Grafana能访问到的地址AccessServer默认表示由Grafana服务端去请求PrometheusScrape interval15s拉取频率和Prometheus的采集频率保持一致这里最常见的坑就是URL填错。很多人直接填http://localhost:9090如果Grafana和Prometheus不在同一台机器上这样是连不通的。填Prometheus所在服务器的内网IP不要填外网地址内网走一次代理纯粹是给自己找麻烦。实操心得Prometheus和Grafana如果都用Docker跑并且容器不在同一个网络里需要额外处理网络互通问题。最简单的办法是启动容器时加--network host参数或者创建自定义Docker网络让两个容器都加入。配置好后拉到页面底部点Save test如果看到绿色提示Successfully queried the Prometheus API数据源就算通了。4. Dashboard面板从零搭建还是直接导入4.1 直接导入现成模板别什么都自己画我见过很多人在Grafana里从零开始画Dashboard画出来的东西丑不说还很费时间。这完全是重复造轮子。Grafana社区有海量现成的Dashboard模板去grafana.com的Dashboards页面搜一下或者访问Grafana Labs官网的Dashboard仓库你会发现Prometheus官方、Node Exporter、MySQL Exporter、Redis Exporter等常用监控场景全都有现成面板。导入方式有两种我个人更推荐第一种方式一通过Dashboard ID直接导入在Grafana左侧菜单点击Dashboards - New - Import填入模板ID点Load然后选择你已经配好的Prometheus数据源确认导入即可。常用的几个模板ID我先记在这里模板ID监控对象适用场景1860Node Exporter全节点监控Linux服务器CPU、内存、磁盘、网络、IO全方位11305Prometheus自身监控查看Prometheus本身的抓取目标、数据量、内存占用7362K8s集群监控Kubernetes节点、Pod、容器监控12229MySQL监控数据库连接数、慢查询、InnoDB状态763Docker容器监控容器CPU、内存、网络IO方式二下载JSON文件手动导入如果你在内网隔离环境上不了外网可以先在外网环境把模板的JSON文件下载下来再通过Import页面的Upload dashboard JSON file上传导入。这里有个经验提醒导入模板后经常发现图上没数据或者指标名对不上。原因是模板作者用的PromQL查询语句里的指标名比如node_cpu_seconds_total和你Prometheus实际采集到的指标名不一致。常见原因有Exporter版本不同导致指标名变了、Prometheus配置文件里的job名和模板中选用的job名不一致。这时候不要慌点开出问题的图表编辑查询语句把自己环境里真实存在的指标名替换进去就行。4.2 从零创建一个简单面板的完整过程虽然推荐用模板但有时候你需要自己画一些特定业务的面板。我拿一个最简单的示例——监控一台服务器的CPU使用率——来走一遍完整流程。新建Dashboard后点击Add - New - Visualization进入图表编辑页面。最关键的是右边Options区域上方的查询编辑器Query Editor在这里写PromQL。CPU使用率的标准查询写法是100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100)我来逐段拆解这个查询是什么意思。node_cpu_seconds_total是Node Exporter暴露的CPU累计使用时间指标mode标签区分了cpu的不同工作模式idle表示空闲。rate()函数计算的是5分钟时间窗口内的每秒增长率因为计数器类型的指标需要用速率才直观。avg是取平均值。最后用100减去空闲率的百分比得到的就是CPU使用率。把这条语句填进查询编辑器后右侧的图表预览区应该立刻出现曲线。接着在Panel options里把标题改成CPU使用率在Standard options里把Unit设为Percent (0-100)一个最简单的面板就完成了。写PromQL有几个容易踩的坑新手经常犯我提一句指标名换来换去。不同版本的exporter可能改了指标名比如老的node exporter用node_cpu新版用node_cpu_seconds_total。不确定的时候去Prometheus的Graph页面用{__name__~node_cpu.*}查一下实际有哪些指标。忘记加rate函数。Counter类型指标只增不减的那种直接绘图出来是一条一直往上的斜线看不出任何波动必须套rate()或irate()。标签匹配写错。modeidle这种标签值需要用双引号不是单引号写错了查询直接报错。4.3 Dashboard变量让你的面板活起来模板用多了你会发现很多面板左上角会有下拉框可以切换实例、切换命名空间、切换集群。这个功能就是Dashboard变量Variables它让同一个面板在不同环境下复用而不是为每一台服务器单独建一个面板。创建一个变量的入口在Dashboard右上角的Settings - Variables - Add variable。举一个典型例子——给服务器监控面板加一个选择实例下拉框。变量类型选QueryQuery Expression填label_values(node_uname_info, instance)这条语句的含义是从node_uname_info这个指标里把所有不同的instance标签值列出来作为下拉框的选项。instance就是Prometheus抓取目标时自动加的标签值类似于192.168.1.10:9100这样的地址。定义好变量后面板里的查询语句就可以引用它了。把原来的查询改成100 - (avg(rate(node_cpu_seconds_total{modeidle, instance$instance}[5m])) * 100)这样你下拉框选哪台机器图表就显示哪台机器的CPU数据。一套面板管整个服务器集群省下的时间够你摸好一阵鱼。注意变量下拉框的Value groups/tags和All value选项也值得研究一下。设置Include All option后查询语句里用instance~$instance的写法在选All时会把所有实例的数据都聚合起来展示。5. 告警接入把预警信息送出去Grafana本身也有告警引擎Alerting但在Prometheus这套体系里我更推荐让Prometheus负责告警规则判断、Alertmanager负责告警通知、Grafana只负责展示。职责清晰排查方便规则统一。不过Grafana的告警也不是不能用它有一个优势可以基于多个数据源做告警判断比如Prometheus里的CPU高 MySQL慢查询多同时满足才触发。这种跨数据源告警是Prometheus单独不好做的。如果你的告警场景简单在Grafana里直接配告警规则也能用。让我先说说主流的方案Prometheus Alertmanager告警链路。这条链路的工作流程是Prometheus周期性评估你在rules.yml里写的告警规则发现问题时生成一条告警事件并推给Alertmanager。Alertmanager负责后续的分发工作——去重、分组、抑制然后通过邮箱、钉钉、企业微信、Webhook等方式通知人。以节点宕机告警为例在Prometheus的rules文件里配一条groups: - name: node_alerts rules: - alert: InstanceDown expr: up 0 for: 1m labels: severity: critical annotations: summary: 实例 {{ $labels.instance }} 不可用 description: Prometheus无法抓取到该实例持续超过1分钟这条规则表示当up指标的值等于0即抓取失败持续1分钟就产生一个告警。Prometheus发现这个情况后会把它推到Alertmanager。Alertmanager接到告警后通过你配置的接收器把消息推送出去。比如用钉钉群机器人配置一个webhook地址消息就能发到钉钉群receivers: - name: webhook webhook_configs: - url: http://你的钉钉机器人webhook地址 send_resolved: truesend_resolved: true很重要告警恢复后也要通知一声不然报警了没人知道问题已经解决了。5.1 在Grafana上直观展示告警状态告警从Alertmanager推送出去之后Grafana这边还能再做一层可视化告警。Grafana有专门的Alerting页面可以从Prometheus数据源里的ALERTS指标获取到当前所有告警的状态。点击左侧菜单的Alerting - Alert rulesGrafana会自动列出Prometheus里评估出来的所有告警规则及其当前状态Inactive、Pending、Firing。在这个页面你还能看到每条告警的标签、严重性、最近一次评估时间等信息。更重要的一点你把告警状态接到Grafana后可以在Dashboard上放一个告警总览面板用如下PromQLcount(ALERTS{alertstatefiring}) by (alertname)这条查询会统计当前处于firing状态的告警按告警名称分组计数。放到Dashboard上后只要有告警触发面板上的数字就会跳动。再配合Grafana的value mapping功能把0映射成绿色、大于0映射成红色一眼就能看出系统健康状态。这个告警可视化的做法常被忽略但实际用起来非常爽。告警邮件通知是异步的人可能不会立刻看到但监控大屏上红彤彤的数字不可能看不到。5.2 Grafana自身的告警配置如果你的告警场景不复杂、也不想折腾AlertmanagerGrafana内置的告警功能也可以扛一扛。在Dashboard图表编辑页面点击右侧Alert标签9.x版本在Alert rules里新建规则配置一个告警条件。用Grafana原生告警创建一条CPU使用率超80%的规则进入Alerting - Alert rules - New alert rule设置规则名称为CPU usage high查询条件选Prometheus数据源查询语句填100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100)然后设置阈值为IS ABOVE 80设置Evaluate every为1m即每分钟评估一次在Contact point里选择通知渠道需要先在Alerting - Contact points里配置好邮箱或WebhookGrafana原生告警的好处是配置全在页面里不用改YAML文件坏处是它依赖Grafana本身一直在线一旦Grafana挂了告警也跟着失效。所以生产环境核心告警走Prometheus Alertmanager链路更稳妥Grafana告警可以作为补充。6. 多数据源与多环境的接入技巧6.1 一套Grafana管多套Prometheus生产环境里通常不只一套Prometheus。比如测试环境一套、生产环境一套、某个特定业务线自己又搭了一套。每个Prometheus都配一个独立的Grafana实例完全没必要。Grafana支持添加多个Prometheus数据源用数据源切换功能在一个面板里快速来回切换。操作方案有三种方案一多个数据源手动切换在Dashboard的图表编辑页面每个查询语句上面有个数据源下拉框你可以给同一个面板添加多个查询分别指定不同的数据源然后图表上就会出现多条对比曲线。这在对比生产环境和预发环境的性能数据时特别有用。方案二数据源变量之前讲的Dashboard变量不止能做实例下拉框还能做数据源下拉框。创建一个变量类型选Data source数据源类型选Prometheus。然后面板查询语句的第一行$datasource这样Dashboard左上角就会出现一个数据源切换器一键切换整个面板的数据来源。方案三Prometheus联邦Grafana只接一个口如果不想让Grafana连接多个Prometheus可以搭建一套Prometheus联邦架构。让一套中心Prometheus通过federation接口从各个子Prometheus拉取数据子Prometheus只采集自己那部分指标中心Prometheus做汇聚。Grafana只需要连接中心Prometheus一个数据源。这个方案适合Prometheus实例特别多的大型环境。6.2 对接Alertmanager时容易忽略的配置Grafana的Alerting页面要想展示Alertmanager里正在处理的告警需要把Alertmanager配成Grafana的一个数据源。在Connections - Data sources里添加一个类型为Alertmanager的数据源。填URL时要注意Alertmanager默认监听9093端口但很多人的Alertmanager容器只映射到了宿主机上的某个随机端口比如9095。这里填的是宿主机的映射端口不是容器内部的9093。还有一个常见问题Grafana 10.x版本的Alerting页面可能看不到Alertmanager的对接选项。这是因为新版Grafana把Alertmanager数据源设置挪到了Alerting - Admin - Data sources里不再是通用Data sources列表。如果没找到就去Alerting页面里翻。7. 常见问题速查与排障实录7.1 图表没有数据一片空白这是遇到最多的一个问题。我的排查顺序是固定的第一步先去Prometheus自带的Graph页面查一下相同指标有没有数据。如果Prometheus页面上也没数据问题出在采集链路Exporter没启动、Prometheus没配置抓取任务、抓取目标地址不通和Grafana无关。第二步如果Prometheus上有数据Grafana上没有检查数据源配置里的URL和Access方式。Access方式选了Browser的话浏览器的跨域限制可能让你看不到数据改成Server模式就好。第三步确认查询语句里的时间范围。Grafana面板右上角有一个时间选择器如果时间范围选了Last 5 minutes而你的数据源停更了很久那肯定没数据。把时间范围拉长到Last 24 hours试试。7.2 面板出现N/A或NaN这个问题集中在PromQL查询结果上。出现NaNNot a Number通常是因为PromQL里的除法操作中分母为0比如(rate(node_network_receive_bytes_total[5m]) / 1024 / 1024)如果某段时间网络流量是0分子和分母同时为0结果就是NaN图上自然显示N/A。解决办法是用PromQL提供的一些函数规避这种边界情况。例如根据场景判断是否需要返回0或忽略这种情况rate(node_network_receive_bytes_total[5m]) / 1024 / 1024实际使用时网络位大多数会显示为0Mbps或很低的数值所以NaN情况相对少见。更常见的是在计算内存使用率时(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100如果容器环境里node_memory_MemTotal_bytes的值有波动或被约束可能在某时刻为0就会出现NaN。7.3 变量下拉框是空的出现这个情况先确认你的query表达式查出来是否有结果。在变量设置的Preview of values区域可以看到查询返回的变量值列表。如果这里就是空的说明label_values查询没有找到对应的标签值。可能的原因有指标名本身不存在、指标存在但该标签没有值、Prometheus数据源没有连对。逐个检查就行。7.4 插件安装失败Grafana插件比如某些图表类型或数据源插件在grafana.com的插件市场里可以一键安装但内网环境没法直接在线安装。解决方法是准备好离线安装包一个zip文件解压到Grafana的plugins目录下然后在配置文件的[plugins]部分加上allow_loading_unsigned_plugins 你的插件名重启Grafana后插件就能加载了。注意有些社区的图表插件可能比较老旧安装后在新版Grafana上不一定兼容。出现插件相关的报错时先看看Grafana版本和插件支持的版本是否匹配。7.5 Grafana忘记admin密码这问题遇到一次就懂解法了。有一个CLI命令可以直接重置admin密码不用重新装grafana-cli admin reset-admin-password 新密码如果是Docker部署进容器里执行docker exec -it grafana grafana-cli admin reset-admin-password 新密码执行成功后重启容器新密码就生效了。7.6 时间不统一导致的坑Grafana的图表数据对时间一致性要求很高。服务器时区不一致、Prometheus和Grafana所在机器时间偏差大会导致曲线错位、数据延迟显示等奇怪问题。排查问题时先统一所有相关机器的时间同步NTP别问我怎么知道的——我被图表曲线比实际时间慢8分钟这个问题折腾过一个下午最后发现是测试服务器的系统时间没同步。8. 进阶之路用Grafana做监控大屏与告警联动当你把数据源、Dashboard、告警规则都跑通后这套系统还是是一个个独立的页面。真正让监控系统看起来高级的是把关键指标汇总到一张大屏上让所有人路过都能看到当前系统的健康状态。Grafana有一个非常实用的功能Playlist播放列表。把你最关心的几个Dashboard加进一个Playlist设置自动轮播间隔比如30秒切换一个面板全屏播放就能做成一个循环滚动的监控大屏。操作入口在左侧菜单的Dashboards - New - New playlist。另一个我个人很推荐的技巧是在Dashboard里使用文本面板和图片面板来搭框架。比如在大屏最上方加一行文本面板写上生产环境核心监控下面再把各个图表面板拖拽排列好。Grafana的拖拽布局本身就支持自由排版你有充分的余地做出一个好看的大屏布局。告警联动方面Grafana可以通过Webhook对接企业微信、钉钉、飞书这些办公软件。配置方式统一在Alerting - Contact points里新建一个contact point类型选Webhook把群机器人的Webhook地址填进去然后在Notification policies里把告警路由到该联系人即可。这里聊一个细节——告警风暴。如果你的系统某个瞬间出现大量告警比如数据库挂了导致所有依赖它的服务全部报错Alertmanager的告警分组和抑制机制就能派上用场。以Alertmanager的group_by配置为例按alertname分组后同一条规则产生的大量告警会被合并成一条消息不会刷屏。这个机制可以在告警策略里设置也可以借助Grafana在告警链路中的聚合展示进一步降噪。9. 最后再分享一套我私藏的Grafana使用习惯写到这里该交代的部署、配置、排障方法都覆盖了。收尾之前我把这些年用Grafana积累的几条个人习惯整理一下省得大家再走弯路。第一给所有面板统一命名规则。我习惯用环境-监控对象-指标类型的格式比如生产-Web服务器-CPU内存面板。这样面板多了之后搜索和归类都轻松不至于一百个面板全是未命名面板(2)。第二善用Grafana的用户管理功能。团队协作时不要让大家共用同一个admin账号。在Administration - Users里创建多个用户给只读成员分配Viewer角色给负责调优的同事分配Editor角色管理员权限就保留给真正需要的人。这不仅是安全考虑也是避免有人误操作改了面板布局后很难排查是谁干的。第三定期备份Grafana的配置文件和数据。上面提过Grafana的数据库存储了用户、数据源、面板等信息默认在/var/lib/grafana/grafana.db把这个文件定期拷贝一份就够了。恢复的时候也简单新装一个Grafana停止服务用备份文件覆盖数据库文件再启动服务面板和数据源配置就全回来了。第四用标签管理面板和告警规则。给每个Dashboard和告警规则打上标签比如teambackend、envproduction后面在面板列表页和告警页面按标签筛选会非常方便。标签越规范后期维护成本越低。这套组合拳打下来你手里的Prometheus从数据采集器升级成了一套完整的可观测性平台展示、分析、告警、协作都有了。后面如果再往里接日志Loki和链路追踪Tempo你就可以从监控迈进全栈可观测的领域了。
