1. 为什么小白总把Prometheus和Grafana搞混1.1 两个工具的名字为啥总被一起提起我接触监控系统这些年遇到最多的一个问题就是Prometheus和Grafana到底有什么区别是不是装一个就够了每次有新同事入职我都要花半小时解释这件事。后来发现搞混这两个工具的人实在太多了根子在于——你打开任何一篇监控搭建教程几乎都是Prometheus Grafana捆绑出现好像它们是一个软件的两半装的时候一起装配的时候一起配出图的时候也是一起出图。但本质上这俩是完全不同的东西。打个不怎么严谨但很好懂的比方Prometheus是仓库和账房负责把你货物的数量、规格、进出时间全部记下来、存好Grafana是展厅和报表室负责把仓库里那些枯燥的数字变成老板看得懂的图表。仓库可以不配展厅展厅也可以去展示别人的货物但最经典的玩法就是这俩配合着用。我见过不少小白把Prometheus的配置文件里塞满了Grafana的配置项也见过有人直接在Grafana里找怎么采集数据这从一开始就把两个工具的职责边界搞混了。想搞清楚它们你先记住一句话Prometheus负责有没有数据、数据长什么样Grafana负责数据怎么呈现、怎么报警。1.2 先给结论一个管数据一个管展示直接上结论方便你看完开头心里就有底Prometheus开源监控系统负责采集指标、存储指标、查询指标。它自带一个时间序列数据库TSDB还带一套查询语言叫PromQL。它默认的界面极其简陋只有一个表达式浏览器Expression Browser能查数据、看表格、画最简单的折线图但离好看差得远。Grafana开源数据可视化平台本身不采集任何数据只负责连接各种数据源Prometheus、MySQL、Elasticsearch、InfluxDB等把数据渲染成图表、仪表盘Dashboard并支持基于这些数据配置告警通知。简而言之Prometheus是后端Grafana是前端。你甚至可以只装Prometheus用它的表达式浏览器凑合看数据只是体验不太好你也可以只装Grafana接上MySQL展示业务报表完全不碰Prometheus。两者没有强制的依赖关系只是在一起用的时候效果最好、生态最成熟。这个区别如果你能牢牢记住后面学什么都顺了。接下来我拆开讲把这俩各自的原理、配置、常见坑都给你过一遍。2. Prometheus到底在做什么2.1 采集端主动拉取机制Prometheus最核心的设计之一就是拉取模型Pull Model而不是像传统监控那样靠被监控端主动推数据Push Model。什么意思呢你想监控一台服务器的CPU使用率你得先在服务器上装一个exporter——这是一个小代理程序比如监控Linux系统用node_exporter监控MySQL用mysqld_exporter监控Redis用redis_exporter。Exporter暴露一个HTTP端口把指标以文本格式挂在/metrics路径下。Prometheus服务器会按照你配置的间隔比如每15秒主动去访问这个地址把指标拉回来存进自己的时序数据库。这个设计有啥好处我自己的体会是排查问题特别方便。如果Prometheus拉不到某个目标的数据你直接在浏览器里访问http://目标IP:9100/metrics看看能不能拿到数值。能拿到那就是Prometheus和目标之间的网络或者配置问题拿不到那就是exporter没装好或者服务没起来。问题边界一下子清晰了不用像推模型那样到处查数据是不是丢了、推到哪儿去了。配置拉取任务的写法也很固定在prometheus.yml里scrape_configs: - job_name: node-exporter static_configs: - targets: [192.168.1.10:9100]这里targets就是你要监控的目标地址列表。Prometheus会按照global里定义的scrape_interval默认60秒建议改短到15秒去拉取。2.2 存储与查询TSDB和PromQL拉回来的数据存哪儿存Prometheus内置的时序数据库TSDBTime Series Database。时序数据的特点就是每条数据都带着一个时间戳格式大致是指标名{标签值} 数值 时间戳。比如node_cpu_seconds_total{cpu0, modeidle} 83473.23 1700000000000这个结构看着复杂但你理解它只需要抓住两点指标名标签组合唯一定义了一组数据序列时间戳数值定义了这个序列在某个时刻的状态。标签Labels非常关键它相当于给指标做维度分类。同样是CPU指标你可以按cpu编号分按modeidle、system、user分查询的时候想怎么切就怎么切。查询的语言叫PromQLPrometheus Query Language语法简洁但威力很大。最常见的几类操作# 查询当前CPU空闲率Gauge类型直接取值 node_cpu_seconds_total{cpu0, modeidle} # 计算过去5分钟的速率Counter类型必须用rate rate(node_cpu_seconds_total{cpu0, modeidle}[5m]) # 计算CPU使用率百分比 (1 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)) * 100给小白一个建议遇到Counter类型的指标只增不减的计数器比如请求总数、累计字节数一定要包一层rate()或increase()再展示否则图表没法看只是一条不断上升的斜线。这是PromQL里最容易踩的第一个坑。2.3 告警规则与AlertmanagerPrometheus自己也有一套告警引擎但它的职责只到判断是否需要告警为止。你需要在prometheus.yml里引入告警规则文件比如rule_files: - alert_rules.yml在alert_rules.yml里定义规则groups: - name: node-alerts rules: - alert: NodeCPUUsageHigh expr: (1 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)) * 100 85 for: 5m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} CPU 使用率过高 description: CPU 使用率已超过 85%当前值为 {{ $value }}%然后配置Alertmanager来负责告警的接收、去重、分组和发送。Alertmanager是一个独立组件Prometheus把命中的告警推送给它它再根据你配置的接收渠道邮件、企业微信、钉钉、Slack等发出去。很多人以为告警是Grafana干的活其实不是。Grafana确实也有告警功能后面会说但在Prometheus生态里传统的告警链路是Prometheus算规则 → Alertmanager收拢分发 → 各种通知渠道。搞清楚这条链路排查告警问题时就能少走很多弯路。3. Grafana到底在做什么3.1 数据可视化核心功能Grafana说白了就是一个画图工具但它画图的功底很深。它支持几十种数据源包括Prometheus、MySQL、PostgreSQL、Elasticsearch、InfluxDB、Loki、CloudWatch等。你只要在Grafana里把数据源配好它就能去对应的系统里查数据然后渲染成折线图、柱状图、饼图、仪表盘、热力图等各种可视化组件。Grafana的界面设计是它的强项。Prometheus自带的表达式浏览器只能显示一个简单的表格或者折线图而Grafana可以随心所欲地拖拽布局、定义变量、设置阈值线、配置图例单位。你甚至可以把多个面板组合起来做成一个完整的大屏放在办公室电视上滚动播放运维同学路过就能看到集群状态。它还有个特色功能叫变量Variables。比如你监控了10台服务器想做一个下拉框随意切换查看哪台机器就不需要为每台机器单独建一个图表而是用变量实现。查询语句里通过$instance引用变量Grafana渲染的时候自动替换。这个功能用好了一个Dashboard能顶十几个管理起来省心太多。3.2 数据源接入机制Grafana本身不存数据它只做连接查询展示。每接入一种数据源其实就是配置一个连接参数。以Prometheus为例在Grafana里添加数据源时只需要填一个URL比如http://localhost:9090然后点Save Test界面提示Data source is working就算接上了。这里有个容易迷惑的点Grafana和Prometheus的认证配置。如果Prometheus开启了认证比如用反向代理加了Basic Auth你需要在Grafana数据源里填对应的用户名密码或Token如果没开认证那就光填URL就行。小白经常在这里卡住明明Prometheus页面能打开Grafana里却报401 Unauthorized十有八九是认证信息没填对。还有一个必须注意的版本兼容问题老版本的Grafana和Prometheus在查询接口上存在兼容性差异。如果你用的Grafana版本较老而Prometheus版本较新或者反过来连接数据源的时候可能报错。我的建议是都尽量用最新的稳定版避免跨大版本搭配。3.3 看板Dashboard与告警可视化Grafana的看板生态是它最大的护城河。你不需要从零画图官网有官方的Dashboard市场Grafana Dashboards上面有各种现成的看板模板输入ID就能一键导入。比如监控Linux主机最常用的node_exporter看板ID是1860在Grafana里选择Import填入1860选好数据源几秒钟就能得到一个包含CPU、内存、磁盘、网络等几十个面板的漂亮看板。Grafana也有告警功能。新版本8.0以上的Grafana告警系统经历过一次大改版统一了告警引擎。你可以基于任何数据源的查询创建告警规则比如CPU超过85%就触发告警然后在Notification policies里配置通知渠道比如邮箱、Webhook或者钉钉。告警触发后Grafana还可以在图表上标注告警状态红色阴影区域代表告警发生的时间段方便直接定位异常窗口。所以你看Prometheus和Grafana都具备告警能力但定位不同。Prometheus的告警偏向于对采集到的原始指标做持续计算和判断Grafana的告警则偏向于在可视化查询结果之上做业务维度的监控。初学者不用纠结选哪个入门用Grafana告警就够了等用到多集群、大流量的场景再上 Alertmanager 不迟。4. 两者怎么配合从零搭建一套监控4.1 部署方案选择搭建这套监控小白最常见的做法是在一台机器上装齐Prometheus、Grafana和几个exporter。你可以用二进制包、Docker、或者Kubernetes里用Helm。我给新手的建议是先学Docker Compose玩法它能把所有依赖一次性拉起来改配置方便重来也方便没有历史包袱。一个最基本的docker-compose.yml大概长这样version: 3.8 services: prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus-data:/prometheus ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 volumes: - grafana-data:/var/lib/grafana restart: unless-stopped node-exporter: image: prom/node-exporter:latest container_name: node-exporter ports: - 9100:9100 restart: unless-stopped volumes: prometheus-data: grafana-data:注意几个细节Grafana第一次登录默认账号是admin密码是admin但如果你设置了环境变量GF_SECURITY_ADMIN_PASSWORD就用你设置的值。node-exporter默认监听9100端口Prometheus去拉它的数据。4.2 配置Grafana接入Prometheus数据源容器起来之后打开浏览器访问http://服务器IP:3000用账号密码登录Grafana。接下来几步非常固定点击左侧菜单的齿轮图标Configuration选择Data sources。点击Add data source在列表里选Prometheus。URL填http://prometheus:9090如果你用的是Docker Compose同一个网络里可以直接用服务名如果是跨机器就填Prometheus所在机器的IP。拉到页面底部点Save Test。如果一切正常你会看到绿色的Successfully queried the Prometheus API提示。这里有一个很常见的坑在Grafana容器里填localhost:9090是访问不到Prometheus的因为localhost指向Grafana容器自己。容器间互访要用服务名或者宿主机IP这个坑我见过无数次每次都得强调一遍。4.3 第一个监控看板搭建数据源配好了接下来导入看板模板。点击左侧Dashboards→Import输入模板ID1860node_exporter官方推荐模板加载出来后再选一下数据源点击Import就能看到一堆花花绿绿的图表了。如果你想自己做一个最简单的面板操作流程是新建Dashboard添加一个Panel。在查询编辑器里选择数据源Prometheus。输入PromQL查询语句比如rate(node_network_receive_bytes_total[5m])查看网卡接收速率。右侧面板设置里改标题、单位、图例等。保存Dashboard。自己做一遍面板你对Grafana的前端渲染定位就会有切身的理解——它所有图的背后都是一条PromQL查询图好不好看取决于你查询语句写得对不对、图表配置得巧不巧。5. 常见问题与排查技巧实录5.1 Grafana报错failed to upgrade legacy queries datasource was not found这个报错在Grafana升级后非常常见新版Grafana在打开老版本保存的Dashboard时会尝试把旧的查询格式升级成新格式如果升级过程中找不到对应的数据源ID就会报错failed to upgrade legacy queries datasource im7_otuvz was not found这是什么原因老旧的Dashboard面板里记录的是数据源ID而新版Grafana把数据源的引用改成了数据源UID。升级后如果数据源的UID变了比如你删了重新添加过数据源旧面板的记录就失效了。解决办法有几个打开Dashboard的JSON模型搜datasource字段找到类似datasource: {type: prometheus, uid: im7_otuvz}的内容把uid改成当前实际数据源的UID。更省事的办法直接编辑面板重新选择一次数据源Grafana会自动修复引用。如果整个Dashboard多个面板都报错建议直接导出JSON全局替换UID再重新导入。这个报错本身不影响数据采集纯粹是Grafana版本迁移的兼容性问题遇到别慌。5.2 告警收不到先查链路再查配置告警配置完没反应是Prometheus生态里被问得最多的问题之一。我一般按下面的链路排查Prometheus端在http://prometheus:9090/alerts页面查看规则是否正常加载状态是不是OK。如果显示ERR或者规则没加载检查prometheus.yml里rule_files路径是否正确。规则是否真的触发在Prometheus的Graph页面手动执行告警规则里的PromQL看是否真的有数据返回、是否大于阈值。如果查询结果为空说明规则本身写得有问题比如指标名拼错、标签匹配不上。Alertmanager是否收到打开http://alertmanager:9093看有没有告警条目。如果有但没发出去看通知配置如果这里也是空的说明Prometheus根本没推送过来检查alerting配置里的alertmanagers地址。消息渠道是否正常邮件、钉钉、企微这些渠道各自的调试方法不太一样但共同点是先测试能不能发通再去排查告警内容格式。这套链路走下来90%的告警收不到都能定位到问题。核心思路就一句话看数据走到哪一步断了。5.3 镜像下载慢、版本不匹配问题国内拉取Docker镜像慢是个老问题Prometheus和Grafana的官方镜像都在Docker Hub上直接拉确实容易卡住。我的建议是配置镜像加速器或者用一些云厂商提供的镜像源。配置好加速器后docker pull prom/prometheus通常在几分钟内就能完成。版本不匹配的问题更隐蔽。比如你用Grafana 9Prometheus用的是2.30版本一般没什么问题但如果你用了特别老的Grafana版本连接新版的Prometheus可能会出现数据源能连上但查询报错的情况。最稳妥的做法是都用官方最新稳定版同时关注发行说明里的兼容性提示。还有一个小技巧Grafana和Prometheus的官方Docker镜像都支持在启动时指定版本标签比如grafana/grafana:10.4.0。生产环境我强烈建议固定版本号不要用latest否则哪天重新部署镜像更新了行为变了排查起来很麻烦。5.4 时间不同步导致的数据混乱监控系统对时间非常敏感如果被监控的机器和Prometheus服务器之间存在明显的时间偏差会出现曲线错位、数据点对不上、告警误报等问题。Prometheus在拉取数据时会给每个样本打上自己服务器的时间戳如果目标机器的exporter返回的数据本身带有时间两者一对比误差就出来了。排查方法就是在所有机器上运行date命令看看时间然后部署NTP时间同步服务。这个问题在生产环境里非常常见尤其是云上自建机房混用的时候所以我每次搭监控都会顺手把时间同步装上。6. 选型建议、工作分工与我的使用体会6.1 什么场景只用Prometheus就够了如果你的诉求非常简单只需要一个后台能存指标、能写PromQL查数据不追求好看的图表那单装一个Prometheus完全够用。它的表达式浏览器虽然简陋但功能一个不少能执行查询、能看表格、能画简略图。配合Alertmanager告警也能完整打通。还有一个场景你已经有一套现成的可视化平台比如公司的自研监控大屏只需要一个指标存储和查询的后端那Prometheus也很合适它对外提供标准的HTTP API其他系统可以灵活对接。6.2 什么场景只用Grafana就够了反过来如果你手上已经有好几套数据系统——MySQL里有业务表Elasticsearch里有日志云平台的监控API能返回指标——你只是想在一个页面上把这些数据统一展示出来那Grafana才是主角。它不需要Prometheus直接连接这些数据源就能用。我见过不少团队把Grafana当作战指挥中心左边是数据库慢查询、中间是应用日志关键词趋势、右边是云资源账单全部来自不同数据源。6.3 什么场景必须两者配合一旦你决定自建一套完整的、面向服务器和应用的基础设施监控那最成熟的开源组合就是Prometheus Grafana。我的分工建议是Prometheus团队负责所有采集器exporter的部署和管理负责指标命名规范、PromQL查询性能和告警规则的维护。Grafana团队负责看板设计、数据源管理、用户权限和通知渠道的配置。共同维护告警规则的评审和监控项的新增/下线需要两边共同确认避免出现图表里有数据但没人告警或者告警一直响但图上没异常的脱节情况。这个分工不是死的小团队可能一个人全包但脑子里的职责边界一定要清晰。6.4 我踩过几次坑之后的体会最后说点个人经验。我最早接触这套组合时犯过几个现在想起来很蠢的错误把Prometheus的配置改错了重启起不来折腾半天发现是YAML缩进多了两格在Grafana里填localhost去连Prometheus怎么都连不通还有一次升级Grafana后旧看板全部报错只好一个个重新选数据源……但这些坑踩过之后你对这套体系的边界会理解得更深。我做监控这几年的体会是不要一上来就追求大而全。先搭一个最小可用的环境一台机器装Prometheus一台机器装Grafana接一个node_exporter把一条完整链路跑通——采集、存储、查询、画图、告警、通知——然后再逐步扩展。链路没跑通之前其他都是空谈。把Prometheus和Grafana的区别搞清楚了你后面学任何监控技术都不会再犯晕。最后再分享一个小技巧如果你在Grafana里做实验把数据搞乱了别急着删容器先用docker volume挂载的数据卷做备份。Prometheus的数据在prometheus-data卷里Grafana的配置和数据在grafana-data卷里定期做快照出问题回滚很快。这一手在实操里能帮你省下不少时间。