1. 概述
1.1 版本
| FineBI 版本 | BI运维取数插件 | BI应用共享插件 |
| 6.1.6及以上 | V2.2.2及以上 | V2.3.4及以上 |
| 7.0.0及以上 | V2.2.2及以上 | V2.1.4及以上 |
1.2 应用场景
随着企业数据分析业务的不断深入，BI系统的稳定性和查询性能直接影响到终端用户的体验。为了帮助IT运维人员和系统管理员更好地监控系统健康状态、快速定位性能瓶颈，我们推出了“BI稳定性与性能分析看板”。
该看板主要适用于以下场景：
稳定性&性能巡检：运维人员每日查看系统健康分与性能指标，整体判断系统健康情况。
架构治理：为“应用架构扩容”、“引擎性能存算分离方案”和“抽取与直连模式”的优化提供数据支撑。
1.3 核心设计理念
结果导向：重点关注影响用户体验的“卡顿”和“宕机”现象，核心指标聚焦于 GC 停顿时间（GC Duration）、负载评分（Load Score）以及应用性能指数（Apdex）。
根因归类：通过内存常驻量、GC触发原因、CPU使用率等指标，将问题归类为内存泄漏、配置不合理或计算资源瓶颈。
联动分析：支持时间轴对齐和多维度下钻，精准定位导致性能问题的具体仪表板（Dashboard）或组件（Widget）。
1.4 部署安装说明
该看板安装教程可参考：【BI运维取数】BI运维分析看板部署说明-【需要补充上稳定性和性能分析指标内容】
2. 看板使用说明
本看板主要分为两大模块：BI稳定性看板 和 BI性能分析看板。可通过页面顶部的标签页进行切换。
2.1 全局筛选器
在页面顶部，悬浮着全局筛选器，用于控制整个看板的数据范围。
日期区间：支持自定义时间段。默认建议查看近24小时（日度健康复盘）或近1小时（故障现场还原）。若需追溯历史问题或查看趋势，可选择更长的时间范围（如近30天）。
节点node名称（稳定性看板专属）：单选/多选下拉框。可选择“无限制”或特定节点。建议：在进行稳定性分析时，通常需要聚焦到具体单机进行下钻，不建议默认聚合所有节点数据，以免掩盖单机的OOM风险。
gc类型（稳定性看板专属）：可选择 全部 / Full GC,GC / Young GC。默认勾选 Full GC,GC，因为Full GC对系统稳定性的影响最大。
引擎类型（性能分析看板专属）：可选择 全部 / 抽取（Spider） / 直连（Direct）。不同引擎的优化手段不同，前者通常考虑扩容Worker，后者通常考虑优化SQL或数据库。
仪表板查看用户（性能分析看板专属）：用于排查特定用户的慢查询投诉。
仪表板ID（性能分析看板专属）：直接搜索特定模板ID，进行单模板性能诊断。
2.2 【BI稳定性看板】模块
该模块主要用于监控系统的底层资源（CPU、内存）使用情况和垃圾回收（GC）状态，帮助排查系统卡顿或宕机的根本原因。
2.2.1 核心指标卡片（8宫格）
展示了系统稳定性的8个关键指标及环比变化。
平均负载评分：筛选时间段内所有 GC 负载评分的算术平均值。分数越高代表大部分时间都在处理垃圾回收，业务处理能力越弱。
最高负载评分：筛选周期内所有 GC 负载评分中的最高值（代表最差状态）。只要该分数过高，说明出现过严重的性能抖动。
亚健康负载占比 (负载分>=80)：量化“持续性”卡顿问题。如果占比达到 15% 以上，说明系统存在持续性的严重卡顿。
平均CPU：系统整体的平均CPU使用率。
最高CPU：CPU使用的峰值。
FGC平均耗时 (ms)：触发 Full GC 事件的平均停顿时间。如果该值过高（如 >2000ms），说明系统在业务高峰期存在明显的卡顿。
FGC最高耗时 (ms)：单次 Full GC 停顿时间的最大值。如果最大值达到 30秒以上，足以导致严重的生产事故（如节点无响应），是判断“宕机/假死”的直接证据。
FGC频率：筛选周期内触发 Full GC 的总次数。
亚健康cpu占比 (cpu>=80%)：量化cpu持续负载瓶颈问题问题。如果占比达到 15% 以上，说明系统存在持续性的cpu占用高
回收后堆内占用（G）:老年代回收使用情况。
2.2.2 GC原因分布饼状图
功能：展示不同原因触发的 GC 占比。
分析场景：
如果 Ergonomics（自适应调整）占比高，通常意味着 JVM 认为必须扩容才能满足需求，建议扩容 Heap 内存。
如果 Allocation Failure（分配失败）占比高，说明年轻代空间不足。
2.2.3 趋势与折线图
FGC与负载评分日趋势图：
功能：双轴折线图，展示每日的“负载评分”和“自适应调节GC次数”变化趋势。
分析场景：用于观察系统负载的长期趋势，识别是否存在周期性的压力高峰。
支持min级别钻取分析
cpu使用率折线图：
功能：展示选定节点在时间轴上的 CPU 使用率变化。
分析场景：如果 CPU 飙升的同时发生了 GC，通常是 GC 引发的 CPU 高负载；如果 CPU 飙升但没有 GC，通常是业务逻辑死循环或高并发计算导致。
内存回收基线情况：
功能：双轴折线图，展示“GC前堆内存使用量”和“GC后堆内存使用量”。
分析场景：重点关注“GC后堆内存使用量”（即常驻内存）。正常情况下，每次 GC 后内存应回落到较低水平。若曲线呈现持续上扬趋势，则是典型的内存泄漏，必须报警并排查。
2.2.4 明细数据表
CPU高占用明细表：记录 CPU 使用率异常高的具体时间点和进程信息，帮助定位 CPU 飙升的“真凶”。
GC高负载明细表：基于负载评分筛选出的严重 GC 事件明细，包含 GC 开始时间、原因、回收前后内存变化等，用于深度下钻分析。
2.3 【BI性能分析看板】模块
该模块主要关注业务层面的查询性能，通过 Apdex 指数和慢查询明细，帮助定位拖慢系统的具体仪表板或组件。
2.3.1 核心指标卡片（8宫格）与 Apdex 趋势图
抽取Apdex指标 / 直连Apdex指标：
功能：分别量化抽取引擎（Spider）和直连引擎（Direct）的查询满意度评分。
分析场景：排除数据库性能干扰，纯粹反映 BI 服务器的计算能力（抽取）；或反映底层业务数据库的响应速度（直连）。（优秀：0.98-1.00；良好：0.95-0.98；急需优化：<0.95）
总请求数：系统处理的所有查询请求总量，用于感知业务规模和负载压力。
抽取请求数占比：
功能：抽取请求数 / 总请求数。
分析场景：高占比（>80%）高度依赖 BI 服务器 CPU/内存；低占比（<20%）性能压力在数据库端。可作为架构调整（如存算分离）的依据。
抽取QPM峰值：每分钟抽取查询请求数的最大值，是服务器配置推荐（计算所需 CPU 核数）的核心依据。
2s以内 / (2-8s) / 8s以上请求占比：
功能：将响应时间分段统计。
分析场景：2s以内代表“秒开”率；2-8s是性能优化的主要对象（可容忍但需优化）；8s以上为性能红线（严重告警，极易引发投诉）。
Apdex统计信息 (近30天) 面积图：
功能：展示近30天 Apdex 指数的变化趋势，支持通过右上角 Tab 切换“抽取”或“直连”。
分析场景：用于验证“优化效果”或监控系统性能的长期衰退情况。
2.3.2 缓存与请求汇总
缓存命中率看板：
功能：饼图展示查询命中缓存的比例。
分析场景：缓存是性能的第一道防线。如果命中率极低（如 < 10%），说明系统可能未开启缓存配置，推荐打开以提升性能。
引擎请求&性能指标月汇总数据：
功能：按月汇总请求数、直连/抽取分布、Apdex指标的表格。
分析场景：宏观对比上下月的负载变化。如果请求数翻倍，则性能下降是预期内的，需考虑扩容硬件。
2.3.3 查询耗时并发趋势 (核心诊断区)
这是排查并发和慢查询的核心区域，包含双轴折线图（上图为请求数，下图为引擎查询耗时）。
支持通过右上角 Tab 切换三种视图：
查询耗时并发趋势_明细 ：展示原始采样点，用于定位“几点几分”的尖刺。
查询耗时并发趋势_按小时 ：展示24小时规律，识别“早高峰/晚高峰”。
查询耗时并发趋势_按分钟 ：用于极高精度的排查。
联动分析场景：
场景1（资源饱和）：请求数（上图）升高，耗时（下图）同步升高。结论：硬件资源不足，计算排队，需要扩容节点。
场景2（慢SQL/大表）：请求数（上图）平稳或很低，但耗时（下图）突然出现尖刺。结论：某个人触发了复杂查询（如超大表全表扫描），卡住了线程。需结合下方的“慢看板专区”抓出该查询。
2.3.4 慢看板专区与明细数据
该区域用于精准定位导致性能问题的具体仪表板和组件。支持通过 Tab 切换不同维度的慢看板列表：
2-8s慢看板 ：体验不佳，属于“可优化”范畴。
8s以上慢看板 ：严重故障，属于“必须解决”范畴。
平均耗时慢看板 ：寻找“慢性病”，虽然没超时，但一直都很慢的模板。
明细数据 ：
功能：展示每次查询的详细日志，包括开始/结束时间、仪表盘ID、组件ID、耗时、BI版本号、缓存命中情况等。
分析场景：用于最终的核对和归因。例如，结合“引擎类型”（如果表格中包含），如果是 Direct 且耗时很长，说明是 SQL 问题；如果是 Spider 且耗时很长，说明是 BI 内存计算问题。
分析路径：在列表中找到“引擎查询平均耗时”最长或“慢请求次数”最多的 仪表盘ID 和 组件ID。如果某个组件特别慢，通常是因为绑定了大表且没有做过滤。建议优化该组件（如开启过滤下推或切换为抽取模式）。
上一篇：BI运维数据字典
