从一次"说不清原因的涨幅"说起：用 OpenObserve 搭出第一块生产级可视化看板
【免费下载链接】openobserveOpen source observability platform for logs, metrics, traces, RUM (web, android, ios), Session replay, pipelines, SLO and LLM observability. A sophisticated, simple and highly performant alternative to Datadog, Splunk, and Elasticsearch with 140x lower storage costs and single binary deployment.项目地址: https://gitcode.com/GitHub_Trending/op/openobserve
凌晨两点，CPU 使用率曲线突然抬高三倍，值班同事盯着旧监控页问同一句话："到底是哪个服务、哪台机器、哪个请求把资源吃掉的？"——曲线是有了，但原因没有。这就是数据可视化在可观测性场景里最常见的困境：你看到了"发生了什么"，却没有工具回答"为什么发生"。
OpenObserve 是一个开源的可观测性平台，覆盖日志（logs）、指标（metrics）、链路追踪（traces）与前端监控（RUM），它的数据可视化能力集中在仪表板（Dashboard）模块：同一个面板可以同时写 SQL 和 PromQL 两种查询，日志、指标、追踪三类数据可以摆在一起交叉分析。本文不讲功能清单，而是带你按真实工作流的顺序，从零搭出一块能上生产的监控看板，并顺带讲清每一步背后的概念。
第一步：带着问题进仪表板，而不是从空白页开始
新建仪表板之前，先想清楚一个具体问题。比如上面的场景，你的目标应该是"定位 CPU 尖峰的来源"，而不是"画好看的图"。问题定清楚了，后续每个面板才有存在理由。
进入 Web 界面的 Dashboards 页面，点击新建。OpenObserve 的仪表板由网格布局（grid）组成，每个格子放一个 panel（面板）。拖入第一个面板后，你会看到两栏编辑区：左边写查询，右边配置图表。这是理解整个模块的关键——一个 panel = 一次查询 + 一种图表类型，而不是先建图表再"绑数据"。这个设计决定了你随时可以只改其中一半而不破坏另一半。
第二步：先写查询，再选图表类型
新手常犯的顺序错误是先挑"好看的图表"再填数据。正确做法相反：先让查询返回你想要的答案。
面板查询支持两种语言：
- SQL：面向日志和追踪明细，例如按服务分组统计请求量与 P99 延迟，
SELECT service, count(*) AS cnt FROM my_logs GROUP BY service这类语句就能回答"哪个服务最忙"； - PromQL：面向指标序列，例如
rate(http_requests_total[5m])回答"QPS 变化趋势"。
两者可以出现在同一个仪表板里，甚至同一个面板里做对比。当你写的是 SQL 查询时，前端的字段转换逻辑在 web/src/utils/dashboard/convertSQLData.ts；PromQL 结果则由同目录下的 convertPromQLData.ts 处理，想理解"为什么我的查询结果画出来长这样"，可以对照这两个文件。
查询有了结果，图表类型只是表达方式。选择原则只有一条：趋势用折线/面积图，构成用柱状或饼图，占比结构用 treemap，多维关系才考虑散点与矩阵。比如定位 CPU 尖峰时，第一张图应该是"总 CPU 面积图"看拐点，第二张按主机拆分的柱状图找异常个体，第三张才是该主机的详细指标。
除了基础类型，平台还内置了一批进阶图表。web/src/assets/dashboard/CustomChartAssets/ 目录里可以看到全部效果预览图，比如条形竞赛图（bar race，适合看排名随时间变化）、3D 散点、雷达图、漏斗等。
第三步：把面板组织成"能读"的故事
单块面板画完，真正决定看板质量的是排列顺序。建议按"总览 → 拆解 → 明细"三层组织：
顶部放一个总览面板，例如全集群 QPS 与错误率曲线，让人三秒内知道系统当前是绿是红；中间层按维度拆解——按服务、按机房、按接口分别展示；底部留给明细，比如某个可疑接口的耗时分布或原始日志切片。
这一层组织不需要写代码，全部在网格布局里完成。面板编辑器的代码位于 web/src/components/dashboards/，其中PanelEditor/负责单个面板的编辑状态，addPanel/下的DashboardQueryBuilder.vue就是你在界面里写 SQL 的那个查询编辑器——遇到交互上的疑问时，顺着这条路径看前端实现会很快。
再给面板加上"时间上下文"：为每个面板标注统计窗口（比如"最近 1 小时"与"昨天同时段"两条曲线对比），尖峰是不是历史性问题、是不是业务高峰导致，一眼可辨。很多看似突发的事故，加一条同比曲线后就消失了。
让仪表板活起来
看板画完只是起点，下面四件事决定了它是"静态报表"还是"值班工具"。
变量与筛选联动。在仪表板层定义变量（如service、region），所有面板的查询引用同一变量。顶部下拉框切换一个值，整块看板的每个面板同步刷新——这就是多图表联动的实现方式：不是面板之间"互相通信"，而是它们共同服从同一组变量。排查时选定service=payment，全部图表瞬间聚焦到支付链路。
告警阈值画进曲线里。OpenObserve 的告警不只是列表页，阈值可以直接可视化到面板曲线上。给 CPU 面板画一条 80% 的参考线，曲线贴近红线的时刻就是告警触发的时刻，复盘时"图上的红线"和"告警列表里的时间戳"能对上，这在事后分析时非常关键。告警配置界面如下：
告警的目的地支持 Webhook、邮件、IM 集成等多种通道，配置入口与看板查询用的是同一套元数据服务，后端实现在 src/core/src/alerts/。
自动刷新。值班场景下给仪表板开启定时刷新（如 30 秒一次），曲线会持续向前推进。刷新频率别贪小：对聚合类查询 30 秒通常是甜蜜点，5 秒刷新在大集群上会显著增加查询压力，收益却有限。
下钻路径。面板支持从汇总视图跳转到明细视图，例如从"各服务错误率柱状图"跳到"payment 服务错误日志"。设计看板时顺手把下钻链路（服务 → 接口 → 请求明细 → 关联追踪）打通，排障时间会明显缩短。追踪明细本身的可视化效果参考下方截图：
避坑与反模式
以下四条是新手最容易踩的，前两条影响性能，后两条影响可用性。
坑一：明细查询直接上大屏。对千万级日志跑SELECT *再让前端画图，查询和渲染都会卡死。正确做法是在查询层聚合：GROUP BY到分钟粒度、LIMIT兜底，把"画布上最多显示多少个数据点"当成硬性约束。需要下钻明细时，交给独立的明细面板，而不是让总览面板兼职工。
坑二：一张看板塞二十个面板。每个面板都是一次查询，面板数 × 刷新频率 = 真实查询负载。值班看板建议核心面板控制在 6~8 个，其余按"拆解层"拆到第二页。判断标准很简单：如果一页看板要滚动两次才看完，说明它该拆了。
坑三：为炫技选 3D 图和花哨图表。3D 散点、螺旋竞赛图确实存在（见 CustomChartAssets 目录），但它们适合汇报展示，不适合值班场景——立体投影会损失数值精度，值班时没人有耐心转三维图。生产看板的图表语言应当保守：折线、柱状、表格、热力图四件套能解决 90% 的问题。
坑四：指标口径在多个面板里各写一遍。同一个"错误率"在三个面板里手写三次查询，改口径时必然漏改。用变量统一时间窗口和过滤条件，口径类逻辑收敛到一处查询里，是看板长期可维护的前提。
下一步行动清单与关键入口
按这个顺序做，一小时可以拿到第一块能用的看板：
- 选一个你最近真实遇到的线上问题，写下"我要回答什么"；
- 用 SQL 写出第一个聚合查询，验证数据能回答它；
- 按"总览 → 拆解 → 明细"排布 6 个面板；
- 加一个变量（如 service）实现整板联动；
- 画一条阈值线并配置告警目的地；
- 开启 30 秒自动刷新，交给值班同事用一周，收集反馈。
关键资源入口（均为仓库内路径）：
- 仪表板前端 API 服务：web/src/services/dashboards.ts
- 面板与查询编辑器组件：web/src/components/dashboards/
- 图表效果预览素材：web/src/assets/dashboard/CustomChartAssets/
- 告警模块（后端）：src/core/src/alerts/
- 前端说明文档：web/README.md
指标涨了说不清原因的日子，到此可以结束了——先让曲线说话，再让变量、阈值和下钻帮你把原因挖出来。
【免费下载链接】openobserveOpen source observability platform for logs, metrics, traces, RUM (web, android, ios), Session replay, pipelines, SLO and LLM observability. A sophisticated, simple and highly performant alternative to Datadog, Splunk, and Elasticsearch with 140x lower storage costs and single binary deployment.项目地址: https://gitcode.com/GitHub_Trending/op/openobserve
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
