企业官网建设流程全解析

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内置的时序数据库（TSDB，Time Series Database）。时序数据的特点就是每条数据都带着一个时间戳，格式大致是：指标名{标签=值} 数值 时间戳。比如：

node_cpu_seconds_total{cpu="0", mode="idle"} 83473.23 1700000000000

这个结构看着复杂，但你理解它只需要抓住两点：指标名+标签组合唯一定义了一组数据序列，时间戳+数值定义了这个序列在某个时刻的状态。标签（Labels）非常关键，它相当于给指标做维度分类。同样是CPU指标，你可以按cpu编号分，按mode（idle、system、user）分，查询的时候想怎么切就怎么切。

查询的语言叫PromQL（Prometheus Query Language），语法简洁但威力很大。最常见的几类操作：

# 查询当前CPU空闲率（Gauge类型，直接取值） node_cpu_seconds_total{cpu="0", mode="idle"} # 计算过去5分钟的速率（Counter类型，必须用rate） rate(node_cpu_seconds_total{cpu="0", mode="idle"}[5m]) # 计算CPU使用率百分比 (1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)) * 100

给小白一个建议：遇到Counter类型的指标（只增不减的计数器，比如请求总数、累计字节数），一定要包一层rate()或increase()再展示，否则图表没法看，只是一条不断上升的斜线。这是PromQL里最容易踩的第一个坑。

2.3 告警规则与Alertmanager

Prometheus自己也有一套告警引擎，但它的职责只到"判断是否需要告警"为止。你需要在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{mode="idle"}[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_PASSWORD=admin123 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。接下来几步非常固定：

1. 点击左侧菜单的齿轮图标（Configuration），选择Data sources。
2. 点击Add data source，在列表里选Prometheus。
3. URL填http://prometheus:9090（如果你用的是Docker Compose，同一个网络里可以直接用服务名；如果是跨机器，就填Prometheus所在机器的IP）。
4. 拉到页面底部，点Save & Test。

如果一切正常，你会看到绿色的Successfully queried the Prometheus API提示。这里有一个很常见的坑：在Grafana容器里填localhost:9090是访问不到Prometheus的，因为localhost指向Grafana容器自己。容器间互访要用服务名或者宿主机IP，这个坑我见过无数次，每次都得强调一遍。

4.3 第一个监控看板搭建

数据源配好了，接下来导入看板模板。点击左侧Dashboards→Import，输入模板ID1860（node_exporter官方推荐模板），加载出来后再选一下数据源，点击Import，就能看到一堆花花绿绿的图表了。

如果你想自己做一个最简单的面板，操作流程是：

1. 新建Dashboard，添加一个Panel。
2. 在查询编辑器里选择数据源Prometheus。
3. 输入PromQL查询语句，比如rate(node_network_receive_bytes_total[5m])查看网卡接收速率。
4. 右侧面板设置里改标题、单位、图例等。
5. 保存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变了（比如你删了重新添加过数据源），旧面板的记录就失效了。

解决办法有几个：

1. 打开Dashboard的JSON模型，搜datasource字段，找到类似"datasource": {"type": "prometheus", "uid": "im7_otuvz"}的内容，把uid改成当前实际数据源的UID。
2. 更省事的办法：直接编辑面板，重新选择一次数据源，Grafana会自动修复引用。
3. 如果整个Dashboard多个面板都报错，建议直接导出JSON，全局替换UID再重新导入。

这个报错本身不影响数据采集，纯粹是Grafana版本迁移的兼容性问题，遇到别慌。

5.2 告警收不到：先查链路再查配置

告警配置完没反应，是Prometheus生态里被问得最多的问题之一。我一般按下面的链路排查：

1. Prometheus端：在http://prometheus:9090/alerts页面查看规则是否正常加载，状态是不是OK。如果显示ERR或者规则没加载，检查prometheus.yml里rule_files路径是否正确。
2. 规则是否真的触发：在Prometheus的Graph页面手动执行告警规则里的PromQL，看是否真的有数据返回、是否大于阈值。如果查询结果为空，说明规则本身写得有问题，比如指标名拼错、标签匹配不上。
3. Alertmanager是否收到：打开http://alertmanager:9093，看有没有告警条目。如果有但没发出去，看通知配置；如果这里也是空的，说明Prometheus根本没推送过来，检查alerting配置里的alertmanagers地址。
4. 消息渠道是否正常：邮件、钉钉、企微这些渠道各自的调试方法不太一样，但共同点是先测试能不能发通，再去排查告警内容格式。

这套链路走下来，90%的"告警收不到"都能定位到问题。核心思路就一句话：看数据走到哪一步断了。

5.3 镜像下载慢、版本不匹配问题

国内拉取Docker镜像慢是个老问题，Prometheus和Grafana的官方镜像都在Docker Hub上，直接拉确实容易卡住。我的建议是配置镜像加速器，或者用一些云厂商提供的镜像源。配置好加速器后，docker pull prom/prometheus通常在几分钟内就能完成。

版本不匹配的问题更隐蔽。比如你用Grafana 9，Prometheus用的是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卷里，定期做快照，出问题回滚很快。这一手在实操里能帮你省下不少时间。