企业官网建设流程全解析

1. 从一块空面板到能看业务曲线：为什么我从工具清单里选中了Grafana

我第一次正经用Grafana，是被一条告警逼的。一个线上服务在凌晨三点CPU飙到90%，等我睡醒打开服务器看了半天top，早就掉下去了，连个现场照片都没留下。那一刻我突然明白，光有监控数据没有用，得有一块能把历史曲线画出来、还能在出问题时主动喊我的面板。Grafana就是当时筛了一圈之后留下来的那个答案。

有朋友问，时序数据库有Prometheus，告警有Alertmanager，Prometheus自带的表达式浏览器也能看图，为什么非要再插一个Grafana进来？我的回答是：Prometheus的UI定位是“调试工具”，适合你临时敲一条PromQL验证结果；但当你需要同时盯CPU、内存、磁盘IO、接口QPS、错误率，还要把它们并排摆成一块适合人类快速扫一眼的面板时，Grafana这种专门的“可视化工作台”才是正确选择。它接数据源的方式跟浏览器接网址一样自然，画出来的东西也真的能放进汇报PPT里。

这篇教程我打算直接按照“从零搭一套能用的监控可视化环境”的思路走，覆盖安装部署、数据源接入、面板创建、面板迁移、告警对接，最后把我在实际使用中踩过的一个典型报错也展开讲讲。内容不追求把每个按钮都介绍一遍，而是给你一条能直接走通的路径，再把每条路径上容易绊倒人的地方指出来。

2. 安装部署：Docker Compose拉起Grafana和Prometheus，附带持久化与常见坑

2.1 为什么选Docker Compose而不是单容器启动

现在网上搜“Prometheus Grafana安装部署”，答案基本都是docker run两行命令。我一开始也是这么干的，Grafana一个容器、Prometheus一个容器，各跑各的。等用到第三天我就后悔了——Prometheus改了配置要重启，Grafana升个级也要重启，每次都得翻历史命令，而且两个容器之间的网络关系全靠在同一个宿主机上碰运气。后来我全部改成Docker Compose管理，一条docker compose up -d把整套监控栈拉起来，配置改了也是自动重建，清爽太多了。

如果你还没有装Docker环境，先确认一下docker和docker compose插件是否就位：

docker --version docker compose version

如果这两个命令都能正常返回版本号，就可以直接进入下一步。装好的跳过，没装的先去把Docker装好，这一节我们主要解决的是编排问题。

我用的目录结构是这样的：

/opt/monitor/ ├── docker-compose.yml ├── prometheus/ │ └── prometheus.yml └── grafana/ ├── data/ └── dashboards/

2.2 docker-compose.yml的关键写法

这是我当时用的compose文件，注释我都写在旁边，你可以直接对照着抄：

version: '3.8' services: prometheus: image: prom/prometheus:v2.45.0 container_name: prometheus restart: always volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus ports: - "9090:9090" command: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' - '--storage.tsdb.retention.time=15d' grafana: image: grafana/grafana:9.5.2 container_name: grafana restart: always environment: - GF_SECURITY_ADMIN_USER=admin - GF_SECURITY_ADMIN_PASSWORD=admin123 - GF_USERS_ALLOW_SIGN_UP=false volumes: - grafana_data:/var/lib/grafana - ./grafana/dashboards:/var/lib/grafana/dashboards ports: - "3000:3000" depends_on: - prometheus volumes: prometheus_data: grafana_data:

几点说明：

• 版本固定：镜像TAG一定要写具体版本号，别用latest。我见过太多人今天装的Grafana是9.x，过两天重启变成10.x，然后面板插件不兼容，一脸懵。固定版本，升级是主动行为，不是被动事故。
• 持久化：Grafana里你辛辛苦苦配好的数据源、创建的面板全部存在/var/lib/grafana这个目录里，Prometheus的时序数据存在/prometheus里。这两个目录不挂出来，容器一删数据全没。我用的是docker volume，你也可以改成宿主机的绝对路径挂载，./grafana/data:/var/lib/grafana这种，两种都行，看个人习惯。
• 环境变量：GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD是Grafana初始化时的管理员账号密码，等容器启动完，你就可以拿这个账号登录了。GF_USERS_ALLOW_SIGN_UP=false是关掉注册入口，内网环境其实无所谓，但关掉更干净。
• 自动重启：restart: always保证机器重启后监控栈能自己活过来，不至于服务器的监控自己先挂了。

Prometheus的配置我放在prometheus.yml里，因为这篇不是专门的Prometheus教程，所以我只给最小能跑通的样子：

global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] - job_name: 'node' static_configs: - targets: ['你的服务器IP:9100']

node这个job是给你的服务器装上node_exporter之后采集主机指标的，IP写成实际地址。初次部署你可以先把node那段注释掉，等后续需要监控主机了再放开。

执行启动命令：

cd /opt/monitor docker compose up -d

启动后验证一下：

docker compose ps

看到prometheus和grafana都是Up状态，再分别访问http://服务器IP:9090和http://服务器IP:3000。Grafana第一次打开会跳转到登录页，用刚才配的admin/admin123登录，登录后会提示修改密码，内网自用直接跳过也可以。

2.3 部署阶段最容易被忽略的细节

我在这一步帮朋友排查过好几个问题，基本都是几个固定原因：

第一，Grafana容器里访问Prometheus不要用localhost。这两个是独立的容器，在Grafana里添加Prometheus数据源时，如果用http://localhost:9090，它实际指向的是Grafana容器自己的网络空间，根本找不到Prometheus。正确写法是http://prometheus:9090，因为Compose会为服务之间创建内部DNS，服务名prometheus就是Prometheus容器的地址。这是新手最容易问的问题，这里先埋个伏笔，下一章还会说到。

第二，防火墙/安全组放行端口。云服务器的话别光顾着改Docker配置，安全组里得把3000端口（Grafana）、9090端口（Prometheus）、9100端口（node_exporter）都验证一遍。我见过太多部署成功但页面死活打不开的例子，十有八九是安全组那边没放开。

第三，时区问题。Grafana容器默认用UTC时间，如果你看面板发现时间跟服务器对不上，在compose文件里的环境变量加一行GF_DEFAULT_INSTANCE_NAME不重要，真正关键的是：

environment: - TZ=Asia/Shanghai

这行加在grafana和prometheus两个服务下都有效，省得后面看告警时间总觉得“差8小时”。

部署完成，接下来核心工作就是让Grafana能拉到数据。

3. 数据源接入：让Grafana真正“有数可用”

3.1 Prometheus数据源的添加步骤

Grafana本身只是一个画图工具，它要有数据来源才能干活。Grafana支持几十种数据源，从关系型数据库MySQL、PostgreSQL，到时序库Prometheus、InfluxDB、VictoriaMetrics，再到日志系统Loki、Elasticsearch都有。但我们这里就聚焦Prometheus这个最主流的搭配。

登录Grafana后，左侧菜单找到Connections->Data sources->Add data source，然后选择Prometheus。这一步在Grafana 9.x的界面里是这么走的，高版本可能汉字描述略有不同，但逻辑是一样的。

进去以后最关键的一项配置是URL：

• 如果你是按我上面的Compose方式部署的，这里填http://prometheus:9090
• 如果你是本机单独跑的Prometheus，可以填http://localhost:9090
• 如果Prometheus跑在另一台机器，填http://那台机器的IP:9090

填完点页面底部的Save & test，如果出现绿条提示“Successfully queried the Prometheus API”，说明数据源已经通了。

3.2 为什么数据源连接总是失败

这一节专门写连接失败的情况。在给朋友远程排查的时候，我发现大多数失败场景就是上面对话框里URL填错了。用localhost去连一个容器里的Prometheus，当然不通。

还有一种情况是URL没问题、网络也没问题，但明确告诉你Data source connected but no labels received。这个意思其实是连接成功了，但Prometheus那边没采集到任何带标签的指标。这种情况多是Prometheus的scrape_configs里targets没有实际暴露指标，或者抓取目标地址写错了。先去Prometheus的http://服务器IP:9090/targets页面看一眼每个target的State是不是UP，如果显示DOWN，去看一下被监控的exporter是不是没启动或端口不对。

我建议你数据源接通后，先去Explore页面（侧边栏指南针图标）手敲几个指标试试。先输入：

up

如果你没装node_exporter，那至少会看到up{job="prometheus"}返回1，代表Prometheus自己在线。如果这条查询有数据返回，说明Grafana和Prometheus整条链路已经通了，接下来开始创建第一个面板。

4. 手把手创建一个业务监控面板：从PromQL到图表美化

4.1 Dashboard与Panel的关系

Grafana里有两个概念要先捋清楚：Dashboard（仪表盘）和Panel（面板）。

一个Dashboard就像一块拼接大屏，里面可以放多个Panel；每个Panel是独立的一块图表，比如一个时间序列折线图、一个数值统计方块、一个柱状图。你最终在屏幕上看到的那个监控大屏，就是若干Panel拼起来的Dashboard。

先创建一个Dashboard：左侧菜单Dashboards->New dashboard->Add visualization，这时会让你选数据源，选我们刚才配好的Prometheus，然后就会进入面板编辑器。

很多人第一次进面板编辑器会发懵，页面布局是左边一个大的查询编辑区，右边一个图表预览区。别急，核心主要就是两个区域：Query（查询）和Panel options（面板选项）。

4.2 核心PromQL表达式：能解决90%需求的四条

我见过有人学Grafana先抱着PromQL手册苦背一星期，完全没必要。日常监控，能把下面这四条用明白，面板就已经能打80分了。

第一条，CPU使用率：

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

这个表达式的含义是：找到所有CPU空闲模式下的累计时间，算最近5分钟内每秒增长了多少（rate函数），求平均值再乘100得到空闲百分比，最后用100减去它，就是CPU使用百分比。

第二条，内存使用率：

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

原理很直白：内存总量减去可用量，再除以总量，换算成百分比。

第三条，磁盘使用率：

100 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100)

注意mountpoint要填你实际要监控的分区，我这里是根分区，你要是想监控数据盘，就改成你的挂载点。

第四条，网络入流量：

rate(node_network_receive_bytes_total[5m])

1分钟内网络接收字节数，除以时间得到每秒速率。

把上面任意一条粘到Query editor的输入框里，然后点击右上角Run queries，右边预览区立刻会出现实时数据曲线。

4.3 把图表调整到“能见人”的状态

数据出来之后，面板右边的配置区是画龙点睛的地方。几个高频设置的路径：

在Panel options下设置标题为“CPU使用率”，在Standard options里把Unit选成Percent (0-100)。如果不设单位，Y轴就只是0到1的小数，展示效果非常不直观。设置好单位之后，图表底部会出现0%到100%的标尺，一眼就能看出机器负载情况。

Thresholds是设置阈值变色的地方，比如我想让CPU超过80%就显示红色。默认的Base是绿色，我通常会再加两个阈值：80对应黄色，90对应红色。这个不只是为了好看，后面配置告警的时候，阈值规则也是从这里沿用的，现在先养成分级阈值的习惯。

时间范围默认是Last 6 hours，如果你想让大屏显示的趋势更清晰，右上角改成Last 24 hours或者Last 7 days都行，看你的实际需求。

最后别忘了保存。Grafana的Dashboard不会自动保存，你折腾了半天，一个浏览器崩溃就全没了，所以有了阶段性成果，立刻Ctrl+S保存，这是疼出来的经验。

4.4 用变量让一个面板适配多台机器

这是我从新手跨到老手的分水岭。你为一个服务器建好了CPU、内存、磁盘三个面板，然后发现你有10台服务器要监控。如果一台台复制面板再改PromQL里的instance，那不是人干的活。

Grafana的解决办法叫变量（Variables）。在Dashboard的设置里，找到Variables->Add variable，定义方式如下：

• 名称：instance
• 类型：Query
• 数据源：Prometheus
• 查询语句：label_values(node_cpu_seconds_total, instance)

这个查询的结果会自动把Prometheus里所有instance标签的值列出来，也就是所有被监控的主机地址。Grafana会把这些值变成一个下拉列表框，放在Dashboard顶部。

然后在每个Panel的PromQL里，把写死的instance="xxx"替换成instance="$instance"。

比如原来写的是：

100 - (avg by (instance) (rate(node_cpu_seconds_total{instance="192.168.1.10:9100",mode="idle"}[5m])) * 100)

改成：

100 - (avg by (instance) (rate(node_cpu_seconds_total{instance="$instance",mode="idle"}[5m])) * 100)

保存后点Dashboard顶部的下拉框，选哪台机器，下面所有面板自动切换成那台机器的数据。10台机器一个Dashboard全部搞定，后续再加机器，只要node_exporter的标签出现在Prometheus里，下拉框就自动多了选项，完全不用改面板。

5. 面板的复制、导出与跨实例迁移：别再一台台手工重建了

5.1 拷贝单个Panel和拷贝整个Dashboard的方法

“Grafana拷贝整个面板”这个热搜词我自己也搜过，因为之前确实被这个问题卡住过。场景是这样的：我在A环境（比如测试环境）精心调好了一个Dashboard，布局、颜色、阈值都合心意，然后要把它搬到B环境（生产环境），总不能重新手画一遍。

Grafana的Panel层面拷贝其实非常简单：打开目标Dashboard，鼠标悬停在某个Panel上，会出现一个下拉菜单，选择More->Copy，然后到另一个Dashboard里粘贴，这个Panel连同它的查询逻辑、样式、阈值全都带过去了。

但这只适合少量面板迁移。当你有一整个Dashboard要复制，正确思路是导出/导入JSON。

5.2 JSON导入导出的底层逻辑

Grafana的每个Dashboard本质上就是一个JSON结构体，里面记录了面板的排列位置、每个Panel的数据源引用、PromQL查询、颜色、单位等所有信息。所以迁移Dashboard的正确姿势是：

导出：打开Dashboard ->Share（分享图标）->Export选项卡 -> 勾选Export for sharing externally（如果你要跨实例迁移） -> 点击Save to file，得到一个JSON文件。

导入：登录目标Grafana ->Dashboards->New dashboard->Import，把保存的JSON上传，或者直接粘贴JSON内容，选择数据源后确认导入。

关于跨实例导入，有一个必须注意的点：数据源名称要一致。Dashboard的JSON里记录的是数据源的名字（比如“Prometheus”），导入到新环境时，这个名字对不上，图表会显示datasource was not found或者直接报错。所以要么在新环境把数据源建成一样的名字，要么导入后手动重新指定每个面板的数据源。这个问题会在后面的踩坑章节更详细地讲。

5.3 从Grafana官方库直接抄作业

还有一条捷径，我自己建面板的时候也常用：Grafana官网有一个面板市场（Grafana Dashboards，大多数人叫它“官方模板库”），里面全是社区贡献的现成Dashboard。

访问https://grafana.com/grafana/dashboards/，搜索关键词比如node-exporter，会看到很多现成的主机监控模板，下载量高的那几款基本可以闭眼用。

使用方式是拿到模板的Dashboard ID（一个数字），然后回到自己的Grafana：Dashboards->New->Import，在Import via grafana.com输入框里填这个ID，点击Load，选好数据源，导入即可。

这种现成面板的好处是里面的Panel非常多，从CPU、内存到磁盘IO、网络连接数，常用的都帮你画好了。等你能看懂这些模板里的PromQL，你的Grafana水平又会提升一个台阶。

6. 告警闭环：把Grafana面板和Alertmanager用告警规则串起来

6.1 为什么需要把Grafana和Alertmanager接到一起

数据可视化只是Grafana的一半功能，另一半是告警。你可能已经有一个Prometheus Alertmanager在跑，负责给钉钉、企业微信、邮件发通知。Grafana作为一个前端可视化平台，同样也有能力产生告警。两者可以同时存在，也理应配合：

• Prometheus负责持续采集指标，根据规则计算是否触发告警，把告警推给Alertmanager去分发；
• Grafana则在面板上根据阈值标识异常状态，同时也可以作为告警的“裁判”，当查询结果满足条件时直接发通知，或者转发给Alertmanager统一处理。

我自己的用法是：Prometheus负责生数据层面的告警（比如target挂掉了、指标采集失败），这些属于“基础设施级告警”；Grafana负责业务层面的告警（比如接口成功率低于99%、某个服务的QPS突然掉到0），因为业务指标往往依赖面板里复杂的PromQL，直接用Grafana告警更直观。

6.2 配置一条最简单的Grafana告警规则

以“CPU使用率超过85%持续2分钟”为例，在Grafana里配置的路径如下：

打开某个Panel ->Edit-> 右侧Alert选项卡 -> 点击New alert rule。

这一步需要注意Grafana的版本差异。在Grafana 8及以前，告警是在Panel内部配置的；Grafana 9之后，告警变成了独立对象：Alerting->Alert rules->New alert rule，然后选择这个规则关联的数据源、查询表达式和所属文件夹。

创建时关键是设置几个参数：

• Condition（条件）：默认是查询结果最后一个值，即last() > 85。注意这里的单位，如果你查询结果本来就是0到100的百分数，那直接写85就行；如果你的查询返回的是0到1的小数，这里要写成> 0.85，别搞混。
• Evaluate every / Evaluate for（评估频率和持续时间）：我设的是每1分钟评估一次，持续2分钟满足条件才触发。这个设计是为了过滤掉瞬时尖峰引起的误报，让告警更“稳”。
• Folder和Group（告警归属）：建议按业务模块建文件夹，比如“线上业务核心指标”，方便后续管理。

保存后，这个告警规则就生效了。你可以到Alerting->Alert rules页面看到它的状态。正常状态是Normal，一旦CPU超过阈值持续2分钟，状态会变成Pending，再过一会变成Alerting，这时就会触发通知。

6.3 接通Alertmanager：Grafana告警统一走通知渠道

如果光在Grafana里看到状态变成Alerting，那是没有意义的——你的手机不会响。所以还要把告警推送到你日常能收到消息的渠道。

联系渠道的配置在Alerting->Contact points。Grafana内置了很多类型的通知源：Webhook、钉钉、企业微信、邮件、Slack、Telegram都有。以最通用的Webhook为例：

添加一个Webhook类型的Contact point，填写你想把告警消息推送到的地址。很多团队这里填的是自己封装的消息推送服务，或者直接填钉钉/企业微信机器人的Webhook地址。

钉钉机器人的配置方式一般是：在钉钉群里添加一个自定义机器人，拿到一个https://oapi.dingtalk.com/robot/send?access_token=xxxx这样的Webhook地址，把它填进Contact point的URL栏即可。注意钉钉机器人通常要设置加签，如果机器人设置了加签，Grafana这边还得在HTTP Headers里加上对应的密钥。

然后在Alerting->Notification policies里，把某条告警规则指向刚才配置的联系点。默认会有一个root policy，不过我更建议你按告警规则来指定：编辑某条告警规则，在Labels and notifications部分选择对应的Notification policy标签，这样不同告警走不同通知渠道，不会所有告警都往一个群里扔。

配置好之后怎么验证？直接把告警阈值临时调低，比如CPU阈值改成5%，让你的服务器稍微跑几个计算任务，一两分钟内就该收到通知了。验证完把阈值调回去，然后等告警恢复的通知也进来了，链路就算全部走通。

6.4 告警消息里的模板变量

通知消息默认会包含告警名称、当前值和标签信息。不过我实测发现，默认消息比较啰嗦，群里看着不够清晰。在Notification templates里，可以自己调整消息模板。

举一个最精简的模板片段，我用在钉钉机器人通知里，效果是在群里显示“告警名称 + 当前值 + 面板跳转链接”：

{{ define "tingting.message" }} 【告警】{{ .Alerts.Firing | len }} 个规则触发 {{ range .Alerts }} - 名称: {{ .Labels.alertname }} - 当前值: {{ .Values.B }} - 面板: {{ .GeneratorURL }} {{ end }} {{ end }}

这个模板不一定照抄，因为每个人的字段结构略有不同，但思路是值得借鉴的——让告警消息自己会说话，群里的值班同学不用点开链接就知道发生了什么。

7. 踩坑实录：failed to upgrade legacy queries这个报错的完整排查链路

7.1 报错场景复现

如果你在Grafana 8以上版本操作面板，有概率在某次切换查询方式时看到这么一条报错：

datasource im7_otuvz was not found failed to upgrade legacy queries datasource im7_otuvz was not found

我第一次看到这个报错时一脸问号，因为数据源明明就在列表里，面板的其他图表也都能正常展示，只有某些旧面板报错。去网上搜了一圈，发现遇到这问题的人还不少，但回答都模棱两可。

7.2 报错的根因分析

想理解这个报错，需要知道Grafana的一个历史包袱。

在Grafana 7及更早版本，面板里的查询方式叫Legacy queries，那时数据源在面板的JSON里记录的是它的一个随机生成的内部ID（类似im7_otuvz这种一串字符）。随着Grafana升级到8.0，查询引擎大改，引入了新式的查询模型，要求面板通过数据源的uid来引用数据源，而不是那种旧的内部ID。

于是Grafana提供了一个自动迁移机制：当你打开一个旧面板时，它会尝试把面板JSON里的旧数据源引用“升级”成新的格式。问题来了，如果这条迁移链路上出现了故障——比如数据源在新版本里注册的顺序不对、或者是旧数据源已经被删除导致ID找不到，就会直接抛出：

failed to upgrade legacy queries datasource im7_otuvz was not found

这个报错中的im7_otuvz，就是面板JSON里引用的那个旧数据源内部ID。它在新版本的数据源列表里已经不存在了，导致升级失败。

7.3 排查与修复的完整路径

如果你也想排查这个问题，参考下面这个链路：

第一步，确认面板JSON里到底引用了什么。打开出问题的Dashboard，点击右上角Settings-> 切到JSON Model，在JSON里搜索datasource，找找看面板里记录的到底是"type": "prometheus", "uid": "im7_otuvz"这样的旧ID，还是新的数据源uid。

第二步，对比当前数据源的实际uid。到Connections->Data sources，打开你正在用的Prometheus数据源，地址栏里能看到它的uid，是一段类似cdabc12345abcde的字符串。如果面板JSON里的im7_otuvz跟当前数据源的uid对不上，就是这个原因。

第三步，对症下药。如果面板数量少，最简单的做法是：把面板里相关的Panel删除，重新新建，通过数据源下拉框选一次正确的Prometheus。这样查询语句会用最新的uid格式，不会再有旧引用。如果面板数量多，那就别手改了，直接在JSON Model里全局替换旧的im7_otuvz为新的数据源uid，保存后看是否恢复。

第四步，如果面板数据源存在但仍是旧格式。有一个隐藏技巧：手动打开面板JSON，找到panels数组下的每一处datasource对象，把"uid": "im7_otuvz"改成当前Prometheus数据源的实际uid，同时清掉多余的"legacyQueryId"字段。这个操作相当于手动完成了一次“升级”，我已经帮两台机器上的Grafana这么干过，效果稳定。

7.4 从根上避免这个坑

解决方案说完了，更重要的其实是预防。经历了那次事故之后，我给自己定了几条规矩，现在分享给你：

第一，升级Grafana大版本之前，先备份。Grafana的备份很简单，把/var/lib/grafana/grafana.db（SQLite数据库文件）和/var/lib/grafana/dashboards目录复制一份就行。真出了问题，直接恢复卷回去。

第二，迁移Dashboard，优先用导出导入。从旧环境导出JSON的时候，勾选Export for sharing externally，这会帮你自动脱敏和清理旧的内部引用，导入到新环境时兼容性最好。手动从一个Grafana实例硬修JSON复制到另一个实例，最容易带上这种legacy引用的毛病。

第三，能不升级就不主动触发大版本升级。Grafana的LTS版本（长期支持版）用起来省心，比如9.x和10.x的系列版本，小版本之间升级问题不大，但跨大版本升级一定要在测试环境先跑一遍，验证所有面板、告警规则、数据源都正常后再动生产。

8. 一些最后的补充建议：把Grafana用顺手的几个小习惯

最后再分享几个我日常使用中觉得很有价值的小习惯。这些不属于某一节教程，但长期下来真的能提升效率。

第一个习惯：给所有Dashboard建好文件夹，并设置好权限。别把所有面板都堆在General下面，人一多就乱。我习惯按“主机监控”、“中间件监控”、“业务监控”三个维度建文件夹，配合Grafana的Viewer、Editor、Admin三种角色权限，新同事只给Viewer权限，能看不能改，出不了大乱子。

第二个习惯：善用Favorites和Star。在Dashboard列表页，点击星标可以把常用面板置顶。多个环境的操作后台，我一般把最常用的生产环境面板都加上星标，切换环境后第一屏就能点进去，不用每次翻列表找。

第三个习惯：面板数量不要过度膨胀。一个Dashboard里塞三四十个Panel，视觉效果反而很差。我在实践中更倾向于拆分成多个Dashboard，每个Dashboard聚焦一个主题：基础资源看一个、应用性能看一个、数据库看一个。Grafana支持在Dashboard顶部设置链接（Dashboard links），在几个Dashboard之间做跳转，这样整个监控体系既清晰又不失关联。

第四个习惯：把Prometheus的采集周期和Grafana的刷新周期对齐。Prometheus默认15秒抓一次数据，Grafana面板的自动刷新在右上角时间选择器旁边，设置成30秒比较合适。如果设置成1秒刷新，Grafana会疯狂请求Prometheus，面板多了之后对Prometheus压力很大，真心没必要。

从部署到接入数据源，从创建第一张图表到完成告警闭环，再到解决一个典型的升级报错，这套流程完整走下来，Grafana对你来说就不只是一个“画图的工具”了。它更像一个窗口，让服务器每分每秒的状态变化都能被你看见、被你在关键时刻收到提醒。先把这篇文章里提到的内容动手实践一遍，遇到问题欢迎在评论区把你的报错信息发出来，我会尽量根据我处理过的类似情况帮你定位。