新手的第一份可观测性大盘，核心就画四块：基础设施、应用性能、业务核心指标、告警速览，每块控制在5个图表以内，别一开始就追求“大而全”。
很多新手接触可观测性时,容易被各类炫酷的大屏模板带偏，上来就堆几十个面板，结果排障时要翻好几页，关键信息全被淹没，第一份大盘的定位不是“展示”，而是“定位”让任何人打开它，30秒内能判断系统是否健康，出了问题先看哪里。
新手可观测性大盘怎么画才不跑偏
先想清楚大盘给谁看
你画的不是艺术品,是工具，给老板看的、给运维同事看的、给自己看的，完全是三套逻辑，第一份大盘优先服务自己和值班同事，这两个角色的共同诉求是：快速知道“现在有什么异常”以及“异常大概在哪个层面”。
基于这个目标,大盘的筛选条件要极简，时间选择器、环境选择器、服务选择器，三个下拉框足够，别加一堆花哨的联动筛选，新手做联动逻辑时，经常把整个大盘拖死。
数据源统一是前提
动手画图之前,先确认你的指标数据、日志数据、链路数据是不是在同一个平台里查询，如果指标在Prometheus，日志在ELK，链路在Jaeger，那你第一份大盘应该先做“入口汇总”，而不是强行全部接入。
业内专家指出,相当一部分新手大盘之所以沦为摆设，就是因为数据口径不统一，同一台机器的CPU使用率，一个面板来自node_exporter，另一个来自云厂商监控，数值对不上，看盘的人直接懵掉。
第一份大盘必画的四个核心模块
基础设施层：别把所有机器堆在一张图上
新手最容易犯的错,是把所有服务器的CPU、内存、磁盘画成一个巨大的多系列折线图，颜色超过五种，基本就失去可读性了。
正确做法是按角色拆分,比如Web服务器一组、数据库一组、消息队列一组，每个角色只展示三个图：CPU使用率、内存使用率、磁盘I/O，那磁盘空间呢？放告警就行，不需要占大盘位置。
表格：基础设施模块推荐图表
| 图表用途 | 推荐类型 | 数据源 |
|---|---|---|
| CPU使用率 | 单值+趋势组合 | node_exporter |
| 内存水位 | 面积图 | node_exporter |
| 磁盘I/O | 折线图 | node_exporter |
| 网络吞吐 | 双轴折线图 | node_exporter |
应用性能层：从用户请求视角出发
这一层是排查“服务变慢”的主战场，核心指标就三个：请求量、错误率、响应时间，但要注意，响应时间别只画平均值，平均值会掩盖长尾问题，建议直接画百分位，P50、P95、P99三条线。
如果你的服务有外部调用,比如访问数据库或第三方API，加一个“依赖服务响应时间”的图，很多慢请求的根因不在自身，而是下游超时。
业务核心指标：用一两个图回答“有没有影响用户”
技术指标再正常,业务可能已经崩了，比如支付成功率、订单创建量、搜索点击率，新手不一定清楚自己系统的业务指标是什么，那就去问产品经理或运营同事，要一个“每天都要盯”的数字。
这个模块画一个当前值加一个趋势就够,它最大的作用是，当技术指标告警但业务指标平稳时，你可以把故障级别降一档，不用半夜爬起来处理。
告警速览：只显示正在发生的故障
这个模块的逻辑是“以终为始”，把Prometheus里的Alerts都读出来，按severity标签过滤，只展示warning以上级别，每条告警显示四个字段：级别、服务名、告警内容、触发时间。
为什么这很重要？因为告警邮件、企业微信通知都可能被刷屏，但大盘上的“告警速览”是任何人打开都能看到的实时状态，它承担的是“最终一致”的兜底作用。
监控大盘搭建实操步骤：从零到一的具体路径
选型：别重复造轮子
多数团队的第一套可观测性平台,大概率是Prometheus加Grafana加Alertmanager的组合，这是目前资料最多、踩坑成本最低的方案，如果你家里用的是云厂商，比如简米云或酷番云，直接用它们的监控服务也行，新手没必要为了“自建可控”而自己从零搭存储引擎，成本远高于收益。
配置：用Grafana模板还是手写
Grafana官网有大量社区模板,新手可以直接导入，但导入后必须做两件事：改数据源变量，删掉多余的面板，社区模板为了展示效果，通常会画得很宽泛，你只需要保留与自己业务相关的部分。
如果你用Prometheus作为数据源,几个常用的查询语句要记牢：
- CPU使用率：
100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) 100 - 内存使用率：
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) 100 - 请求错误率：
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) 100
配置文件夹的命名规范
给每个面板的JSON文件加清晰的前缀,比如01-基础设施-主机-概览.json，文件命名按模块序号来，Grafana的导入顺序就会整齐一些，这一点在团队协作时尤其重要，不然别人根本找不到想看的图。
布局逻辑：从上到下，从概览到细节
第一行放告警速览,第二行放业务核心指标，第三行放应用性能，第四行放基础设施，这样看的人从上往下扫一遍，就能完成“有没有故障、影响什么业务、哪层出问题”的判断链路。
在Grafana里用Row来分组,每个Row点击可以折叠，排障时收起暂时不关心的模块，界面会清爽很多，图表之间的间距保持均匀，别把面板拖得稀稀拉拉。
新手监控大盘搭建中容易踩的坑
坑一：时间范围选错，画的图全失真
新手常常忘记关联时间选择器,大盘右上角选的是“最近1小时”，但某个面板单独设成了“最近7天”，数据看起来完全不在一个时空，解决办法很简单：每个面板的查询选项里，时区强制跟大盘一致，别用“浏览器时区”。
坑二：单位不统一，数字没意义
有的面板显示字节,有的显示兆字节，有的直接显示1.2k，你第一眼根本分不清这个数值是正常的还是异常的，创建面板时，在标准选项里把单位固定，内存用bytes，网络用bps，时间用ms，全盘统一。
常见问题解答
可观测性大盘和监控大盘是一回事吗
可观测性包含监控,但补充了日志和链路，你第一份大盘可以先做监控，因为日志和链路更适合在排查具体请求时临时打开查看，而不是固定放在一个总览面板上，等基础大盘用顺手了，再逐步把日志的关键错误率指标接进来。
一个服务有很多指标，怎么取舍
问问自己：这个指标异常了，我会立刻采取行动吗？如果不会，它就不配出现在第一份大盘上，通常是“黄金四指标”，请求量、错误率、响应时间、饱和度，外加你的业务关键指标，先画少一点，用一周时间观察实际使用体验，再决定要加什么，新增指标比删减容易得多，所以第一次宁缺毋滥。
大盘画好后，后续怎么维护
把大盘的更新纳入到每次架构变动的流程里,系统里新增了一个数据库实例，或上线了新的微服务，原计划里就要包含“更新大盘”这一项，行业共识认为，绝大多数监控大盘的荒废，都是因为一年都不更新一次，图表和数据源早已过时，每季度做一次检查，把连续三个月点击量为零的面板删掉，让大盘保持克制和聚焦。
现在关掉那些模板库里的花哨大屏,先按这四个模块把基本盘立起来，它也许不够惊艳，但一定能帮你更快定位故障，等熟悉了自己的系统，再慢慢添砖加瓦。