k6负载测试结果可视化实战：从数据采集到Grafana监控告警全链路

做k6负载测试最容易被低估的一环，不是脚本怎么写，而是测试结果怎么看。跑完一次压测，控制台会吐出一堆数字：http_req_duration的avg、p95、max，iterations、vus、失败率……这些数据原始、准确，但几乎没有决策价值。你需要把它变成图表、面板、报警，让团队里每个人一眼就能看出系统行不行。这篇文章就围绕k6负载测试可视化，讲清楚从数据采集到最终洞察的完整链路，适合正在用k6做性能测试、但还没把测试结果真正用起来的开发和运维朋友。

1. 为什么负载测试结果需要可视化？从一堆数字到一眼看穿

1.1 控制台摘要只是起点，不是终点

k6跑完之后，终端默认会输出一个summary表格。上面有http_req_duration的各项分位数、http_reqs的速率、vus的峰值，还有每个场景的迭代情况。每次看到这个表格，我都觉得它像一张体检报告单：指标都在，但是要凭这一页纸判断“系统到底行不行”“瓶颈在哪里”“要不要上线”，还是太吃力了。

问题在于摘要只给了聚合统计。比如p95等于800ms，你只知道95%的请求在800ms以内，但不知道这800ms是稳定维持在800，还是从300一路漂上去的。如果是后者，系统可能在测试中途已经出现了资源争抢、连接池耗尽或者慢查询堆积，而这些变化过程恰恰是定位问题的关键线索。可视化的第一个意义，就是把“最终结果”变成“变化过程”，把时间维度拉进来。

另一个痛点是跨角色沟通。给业务方和领导看一堆英文指标名，不如一张曲线图直观。一个折线图、一张热力图，不需要解释太久，大家就能理解“并发上来之后响应时间拐了一个大弯”意味着什么。可视化不是把数据画得好看，而是把结论变成所有人都能看懂的公共语言。

1.2 可视化的三大核心价值：趋势、协作、预警

先说趋势。性能问题很少是瞬间出现的，大多数是渐进恶化的。把每次压测的数据都沉淀下来，形成历史曲线，就能看到系统容量在哪个版本之后开始退化。比如某次重构之后，同样50并发下P95从200ms涨到350ms，单看一次报告不一定能发现问题，但拉出两周内的变化曲线，趋势一目了然。

再说协作。开发和运维看同一块仪表盘，上下文是一致的。开发看到“下单接口的延迟在并发超过100之后暴涨”，运维在服务器面板上看到“数据库CPU同步上涨”，两边一对，根因基本锁定了。没有可视化时，这个消息要靠微信群截图和口头转述，信息损耗非常大。

最后是预警。可视化仪表盘可以做成常态化巡检工具，而不是压测一次就丢到一边。固定时间、固定脚本、固定阈值，每次跑完自动比对，超过红线立刻报警，把性能测试从“上线前的临时动作”变成“日常质量门禁”。这一点后面讲阈值报警时再展开。

2. k6的数据全景：先搞清楚可视化的“原料”

2.1 内建指标：请求耗时与吞吐量的基本盘

想做好可视化，先得知道k6到底能产出哪些数据。k6的内建指标围绕HTTP请求展开，最核心的是这几个：

这些指标分两类：一类是Trend，记录一组数值的分布；一类是Rate或Counter，记录计数和速率。在可视化层面，Trend指标适合看分位数曲线，Rate指标适合看每秒的请求速率和失败率，Gauge适合看当前并发量。理解这个划分很重要，因为你后面在Grafana里选聚合方式时，就要根据指标类型来定。

2.2 阈值和检查：自动标注的“异常点”

k6的阈值（thresholds）是内置的SLO校验机制。你可以直接在options里写上性能目标，k6跑完会告诉你是否通过。比如：

export const options = { thresholds: { http_req_duration: ['p(95)<500', 'max<2000'], http_req_failed: ['rate<0.01'], }, };

这段代码的意思是：95%的请求耗时必须低于500ms，最大请求耗时不能超过2000ms，失败率不能超过1%。任何一个条件不满足，k6的退出码就不是0，CI里就能自动拦截。

阈值是可视化仪表盘上最重要的“红线”。在Grafana面板里，你可以把阈值画成一条虚线，实测曲线一旦越线，红黄状态直接呈现。这个比看数字直观太多。

检查（checks）和阈值不同。阈值针对的是聚合指标，检查针对的是单次请求的断言，比如：

check(res, { 'status is 200': (r) => r.status === 200, 'response time < 500ms': (r) => r.timings.duration < 500, });

检查结果也会被记录成指标，可以做失败率统计，但它更偏功能正确性验证。可视化的重点还是放在阈值和趋势指标上，检查结果可以作为辅助面板，放在仪表盘的下方。

2.3 自定义指标：让数据贴合业务场景

内建指标通用，但业务场景千变万化。压测一个登录接口时，你可能关心“登录成功耗时”；压测一个下单流程时，你可能关心“整个事务的完成时间”。k6提供四种自定义指标类型来应对这种情况：

• Trend：记录耗时分布，适合衡量业务操作耗时
• Counter：累计计数，适合统计业务发生次数
• Gauge：记录瞬时值，适合记录队列长度这类状态
• Rate：记录比率，适合统计事务成功率

自定义指标也很直观。举个例子：

import http from 'k6/http'; import { check } from 'k6'; import { Trend, Rate } from 'k6/metrics'; const createOrderDuration = new Trend('custom_create_order_duration', true); const createOrderSuccess = new Rate('custom_create_order_success'); export default function () { const payload = JSON.stringify({ userId: 'u_001', items: [{ skuId: 'sku_01', count: 1 }], }); const res = http.post('https://test-api.example.com/orders', payload, { headers: { 'Content-Type': 'application/json' }, }); createOrderDuration.add(res.timings.duration); createOrderSuccess.add(res.status === 201); }

这样建出来的两个指标，会在k6内建指标旁边一起输出，也会一并写入InfluxDB或Prometheus。自定义指标的好处是让压测数据与业务语义对齐，仪表盘上展示的不再是抽象的http_req_duration，而是“下单耗时”和“下单成功率”，业务方一看就懂。

3. 可视化方案选型：轻量、中量、全链路怎么选

3.1 零依赖方案：k6内置摘要与HTML报告

如果你只做一次性的小压测，不想搭任何基础设施，k6自带的摘要报告其实够用。跑完之后看到的是一个终端表格，如果想更直观一些，还可以结合k6的实验性Web Dashboard功能。启动方式很简单：

k6 run --web-dashboard script.js

运行后会得到一个本地地址，打开之后能看到实时的请求耗时、VU数量、错误率等图表。这个功能适合单机调试脚本、快速确认压测场景是否合理，不需要安装任何额外组件。

但它的局限也很明显：数据不落盘、不能留存、不能横向对比历史趋势，也不适合团队共享。你可以把它当成“手术台上的监护仪”，适合单次现场观察，不适合做长期记录和回归分析。做正经的容量评估或者发版门禁，还是需要一套能存历史数据的方案。

3.2 经典组合：k6 + InfluxDB + Grafana

这是目前最主流、也最适合中小团队的方案。k6支持直接把指标写入InfluxDB：

k6 run --out influxdb=http://localhost:8086/k6 script.js

然后由Grafana连接InfluxDB数据源，把指标画成面板。InfluxDB是时序数据库，专为这类监控数据设计，写入和查询都很方便；Grafana则是业界通用的可视化平台，面板丰富、告警完善、权限管理也成熟。

这套组合最值得推荐的理由是轻量。两个服务跑起来占用资源很少，一台2核4G的机器就能同时承载InfluxDB和Grafana。对大多数业务系统来说，压测产生的数据量完全在InfluxDB的承受范围内，不需要引入复杂的分布式存储。我自己在多个项目里都是用这套组合，稳定、省心、排查链路短。

3.3 完整链路方案：k6 + Prometheus + Grafana

如果你的团队已经有Prometheus监控体系（或者说已经在用VictoriaMetrics、Mimir等支持Remote Write的时序存储），用k6的Prometheus输出模式会更契合现有基础设施。

k6可以通过Remote Write协议把指标推送到兼容端点：

k6 run --out prometheus=http://your-prometheus-endpoint/api/v1/write script.js

在这个模式下，k6会把Trend类型的指标转换为Histogram指标，Grafana里就能用PromQL查询分位数。比如查询下单接口的P95耗时：

histogram_quantile(0.95, sum(rate(custom_create_order_duration_bucket[1m])) by (le, scenario))

这个方案的好处是指标体系和全公司的监控统一，可以直接复用已有的Grafana、告警规则和权限体系，不需要额外维护一套InfluxDB。代价是配置相对复杂，Remote Write的兼容性、指标命名规则、存储容量都要花时间调。如果团队没有现成的Prometheus全家桶，我不建议为了一个k6可视化专门去搭，InfluxDB方案更省事。

3.4 其他落地方案：S3离线分析与云服务

有一个折中方案是k6输出JSON或CSV文件，然后配合脚本做离线分析。k6支持：

k6 run --out json=result.json script.js

这种方式的数据是最全的，每个指标点都完整保存，适合后续做深度二次分析，比如计算自定义分位数、做多维度的数据透视。缺点是没有实时性，测试跑完才能出结果，不适合边压测边观察。我可以接受这种方案用于“事后复盘”，但不要用它来“现场指挥”。

至于k6的云服务方案，它自带全套可视化面板，一键即可查看历史测试、多地域对比、断点分析。优点是开箱即用，缺点是需要考虑数据出域的问题。对于只有内网环境的项目，还是优先考虑本地部署的InfluxDB或Prometheus方案。

4. 从零搭建一套可视化监控栈：手把手实操

4.1 环境准备：安装k6、InfluxDB和Grafana

我推荐的实操路径是：k6负责生成数据，InfluxDB负责存储，Grafana负责可视化。开始之前先把环境准备好。

k6的安装非常轻量，macOS上执行：

brew install k6

Linux服务器上，使用官方提供的安装脚本，或者直接下载对应发行版的二进制包放到PATH目录下即可。安装完后用k6 version验证。

InfluxDB我强烈建议用1.8版本。k6自带的InfluxDB输出插件针对的是InfluxDB 1.x的写入协议，如果用InfluxDB 2.x，要额外开启兼容API和token配置，很多人都会在这里卡住。为了少踩坑，直接用Docker跑一个1.8：

docker run -d \ --name k6-influxdb \ -p 8086:8086 \ -e INFLUXDB_DB=k6 \ -e INFLUXDB_ADMIN_USER=admin \ -e INFLUXDB_ADMIN_PASSWORD=admin123 \ influxdb:1.8

INFLUXDB_DB=k6这个环境变量会让容器在启动时自动创建名为k6的数据库，后面k6写入就不需要手动建库了。

Grafana同样用Docker跑起来：

docker run -d \ --name k6-grafana \ -p 3000:3000 \ -e GF_SECURITY_ADMIN_USER=admin \ -e GF_SECURITY_ADMIN_PASSWORD=admin123 \ grafana/grafana

两个容器都启动后，打开浏览器访问http://localhost:3000，用admin账号登录Grafana。如果能看到登录页，环境就算准备好了。

注意：Docker容器重启后如果希望数据不丢，记得给InfluxDB挂载数据卷-v influxdb-data:/var/lib/influxdb，给Grafana挂载-v grafana-data:/var/lib/grafana。压测历史数据是可视化对比的基石，容器一删数据全没了，那才是真踩坑。

4.2 编写测试脚本并开启数据输出

环境就绪后，先准备一个简单但完整的测试脚本。这里我以最常见的“用户登录+浏览商品”场景为例：

import http from 'k6/http'; import { check, sleep } from 'k6'; import { Trend, Rate } from 'k6/metrics'; const loginDuration = new Trend('business_login_duration', true); const loginSuccessRate = new Rate('business_login_success'); export const options = { scenarios: { ramping_load: { executor: 'ramping-vus', stages: [ { duration: '2m', target: 50 }, { duration: '5m', target: 100 }, { duration: '2m', target: 0 }, ], }, }, thresholds: { http_req_duration: ['p(95)<800'], business_login_success: ['rate>0.99'], }, }; export default function () { const loginRes = http.post( 'https://test-api.example.com/login', JSON.stringify({ username: 'demo_user', password: 'demo_pass' }), { headers: { 'Content-Type': 'application/json' } } ); loginDuration.add(loginRes.timings.duration); loginSuccessRate.add(loginRes.status === 200); check(loginRes, { 'login status is 200': (r) => r.status === 200, }); const productRes = http.get('https://test-api.example.com/products?page=1'); check(productRes, { 'product list status is 200': (r) => r.status === 200, }); sleep(1); }

这个脚本包含了几层意图：有阶梯式加压场景，能观察系统在并发爬坡时的表现；有自定义业务指标，让仪表盘能直接展示“登录耗时”和“登录成功率”；有阈值，让压测结束时能自动判断是否达标。跑测试的命令是：

k6 run --out influxdb=http://admin:admin123@localhost:8086/k6 script.js

这里的URL格式是http://用户名:密码@主机:端口/数据库名。用户名和密码对应InfluxDB容器启动时的环境变量，数据库名对应INFLUXDB_DB。执行后，k6会把每个时间窗口的聚合指标写入InfluxDB。

4.3 配置Grafana数据源与核心面板

数据开始写入InfluxDB后，回到Grafana配置数据源。进入Configuration -> Data Sources -> Add data source，选择InfluxDB，然后按下表填写：

这里有一个很关键的细节：在较新的Grafana版本里，数据源默认查询语言是Flux，而k6写入InfluxDB的数据需要用InfluxQL查询。所以要在数据源的Query Language选项里切换到InfluxQL，否则后面写查询语句时语法对不上，面板大概率是空的。

数据源配好后，创建一个新的Dashboard，开始加面板。第一个核心面板是请求耗时，用InfluxQL查询：

SELECT PERCENTILE("value", 95) FROM "http_req_duration" WHERE $timeFilter GROUP BY time($__interval), "scenario"

这个查询会按时间窗口计算每个场景下http_req_duration的P95值，画出来就是响应时间的95分位曲线。加上阈值线（比如在面板的Thresholds选项里设置Base=800，红色），曲线一越线，面板就会出现红色告警区域，非常直观。

第二个必加面板是并发用户数：

SELECT mean("value") FROM "vus" WHERE $timeFilter GROUP BY time($__interval)

第三个是请求成功率：

SELECT 1 - mean("value") FROM "http_req_failed" WHERE $timeFilter GROUP BY time($__interval)

把失败率反过来画成成功率，看起来更符合直觉：接近100%是健康，往下掉就是异常。这三个面板一起看，基本能回答“系统到底能不能扛住当前压力”这个核心问题。

如果你不想从零搭面板，Grafana社区有很多现成的k6模板，导入Dashboard的JSON文件，然后改成自己的数据源即可。我的建议是模板只作起点，一定要亲手加自定义指标面板，因为模板不会知道你关心的业务指标是什么。

4.4 用Docker Compose一键拉起整套环境

前面手动敲了三条docker run命令，方便演示，但每次重建环境都要敲一遍还是不专业。实际使用中，我会把整套环境写成一个docker-compose.yml，一键启动：

version: "3.8" services: influxdb: image: influxdb:1.8 container_name: k6-influxdb ports: - "8086:8086" environment: INFLUXDB_DB: k6 INFLUXDB_ADMIN_USER: admin INFLUXDB_ADMIN_PASSWORD: admin123 volumes: - influxdb-data:/var/lib/influxdb grafana: image: grafana/grafana:latest container_name: k6-grafana ports: - "3000:3000" environment: GF_SECURITY_ADMIN_USER: admin GF_SECURITY_ADMIN_PASSWORD: admin123 volumes: - grafana-data:/var/lib/grafana depends_on: - influxdb volumes: influxdb-data: grafana-data:

然后执行：

docker compose up -d

整套监控栈就起来了。压测脚本放在宿主机上跑，k6是二进制，不需要容器化。当然，如果你习惯完全容器化，也可以把k6也放进Compose里，运行时会自动执行脚本、退出，数据照样写入InfluxDB。两种方式我都试过，从日常使用的角度，k6在宿主机跑反而更方便调试，因为改脚本不用重建容器。

5. 数据解读：从曲线变化到性能洞察

5.1 请求耗时的“拐点”就是系统的软肋

面板画好之后，最难的部分才真正开始：怎么从图里读出有价值的结论？

我最常看的是耗时曲线与并发曲线的叠加关系。k6的Grafana面板上通常会有两条线：一条是VU数（并发），一条是耗时。测试开始后，VU数按阶梯上升，耗时曲线如果平缓跟随，说明系统有富裕容量；当VU数爬到某个值，耗时曲线突然出现明显上扬，这个转折点就是系统的容量拐点。

举个例子。50并发时P95稳定在200ms，100并发时P95爬到400ms，150并发时P95直接跳到1.2s。拐点在100到150之间。你可以把拐点对应的业务量当成系统的“安全上限”，超过这个量，响应时间会快速恶化。这个数据对容量规划很值钱：大促峰值预估是多少，机器需要扩多少台，靠一次压测就能给出量化依据。

这里有个容易误判的地方：耗时曲线的小幅波动不要紧张，网络抖动、GC暂停、定时任务都可能导致瞬时尖峰。真正要关注的是持续向上、不再回落的趋势，以及拐点出现后曲线的斜率变化。

5.2 并发、吞吐、错误率要联合判断，不能单看一个

单看响应时间曲线不够，还要拉上吞吐量和错误率一起看。这三者放在同一张图里对照，很多结论会自动浮现。

场景一：响应时间上去了，吞吐量也上去了，错误率没有明显变化。这说明系统只是在压力下变慢，但还没有崩溃，可能是CPU或数据库负载已经很高，进入了排队状态。

场景二：响应时间上去了，吞吐量反而开始下降，错误率同步增长。这说明系统已经进入过载区，典型的标志是“吞吐量触顶后回落”，处理不过来了。这个时候再去调大并发已经没有意义，因为系统已经不接受新的请求了。

场景三：响应时间变化不大，错误率突然飙升。这种往往是限流、熔断、负载均衡策略在起作用，请求根本没到后端业务系统，而是被网关层直接拒绝了。别盯着应用代码看，先去查网关和接入层的限制策略。

把三个维度联合起来看，才能区分“系统慢”和“系统不可用”。这也是可视化区别于控制台报告的最大价值：过程的变化轨迹比最终的平均数字更能说明问题。

5.3 用阈值报警把压测变成常态化巡检

可视化不只是压测时看一眼，还可以配置成持续不断的巡检工具。我推荐的做法是：把k6脚本固定下来，通过定时任务每天跑一次低并发冒烟压测，数据持续写入InfluxDB，Grafana上配置告警规则。

Grafana的告警规则可以绑定到面板查询，比如：

http_req_duration的P95 > 500，持续5分钟，触发Alert

一旦每天的基础巡检发现响应时间越过红线，告警就发到企业微信或钉钉群里，不需要等人主动去跑压测才发现性能回退。这套机制对频繁发版的团队尤其有效，很多性能问题都是改着改着就冒出来的，有持续巡检能在问题上线的第一时间发现。

k6脚本本身也可以加更严格的阈值作为第二道闸门。测试跑完如果超过SLO，k6直接非零退出，CI流程自动拦截，把性能不合格的变更挡在发布之前。

6. 常见问题与排查技巧实录

6.1 数据没写进InfluxDB？先看版本和写入协议

这是所有初学者都会遇到的问题，表现形式是k6跑完了，Grafana面板空空如也。我的排查顺序是这样的：

第一步，确认InfluxDB版本。如果是2.x版本，k6的--out influxdb默认写入的是1.x兼容接口，需要确认2.x实例开启了/write兼容端点，并且URL里要带数据库名和凭据。最稳妥的办法就是直接用1.8镜像，少很多麻烦。

第二步，检查InfluxDB的日志。k6写入失败时，InfluxDB容器日志里通常会有明确的报错，比如认证失败、数据库不存在。看到数据库不存在，就去检查数据库名是否与容器启动时INFLUXDB_DB一致。

第三步，手动验证写入是否成功。在InfluxDB容器里执行：

docker exec -it k6-influxdb influx USE k6 SHOW MEASUREMENTS

如果能列出http_req_duration、http_reqs这些measurement，说明数据已经入库，问题在Grafana侧；如果什么都没有，说明k6到InfluxDB这一段没通。

6.2 面板有数据但刷不出来，问题多半在查询语句

还有一种情况：InfluxDB里明明有数据，但Grafana面板就是空的。大多数时候是查询语言没选对。Grafana默认的InfluxDB数据源语言是Flux，而社区模板和常见的k6面板查询都是InfluxQL语法。进入数据源设置，把Query Language切到InfluxQL，面板基本就能出来了。

另一个隐藏坑是$timeFilter。这个变量是Grafana面板右上角时间范围的映射，如果查询语句里没有写WHERE $timeFilter，面板可能显示全部历史数据，数据一多就超时，看起来像没数据。所有面板查询都要带上这个条件，让查询范围跟着面板右上角的控制走。

6.3 高并发下的数据丢失和时间戳错位

当并发用户数很高、请求量很大时，k6写入InfluxDB的数据点会变多。如果网络或存储跟不上，可能偶尔出现断点、曲线毛刺。我的处理经验是，k6写入InfluxDB的数据本身就是周期性聚合的，不是每个请求一个数据点，正常使用压力不大。如果确认采样间隔太粗导致曲线不平滑，可以调整Grafana面板的最小时间间隔（Min interval），从默认的10秒改到5秒或1秒，但不要低于k6数据输出的实际粒度，否则只是拉平了空点，没有真实信息。

时间戳错位的问题更隐蔽。如果你用多台机器同时跑分布式压测，一定要确保各负载机的系统时间同步，否则不同机器的数据点时间戳不一致，画出来的曲线会出现“多线分叉”的诡异现象。k6也支持在脚本里通过tags给不同负载机组打标签，比如load_zone: zone_a、load_zone: zone_b，Grafana里按标签分组，就能区分不同机器的表现。

多机压测时间不同步是我踩过的坑。一开始两台负载机的系统时间差了十几秒，结果同一个指标在面板上画成了两条错位的曲线，差点让我以为是接口性能不一致。后来在负载机上统一配置时间同步服务，曲线立刻对齐了。

7. 一个完整的可视化压测案例：从发现问题到验证优化

7.1 场景设计：三档压力模型

用一个虚构但常见的场景把整个链路串起来。某团队维护一个模拟电商系统，核心接口是登录和下单。团队计划做一次发布前的容量评估，目标很简单：系统要在150并发下稳定支撑业务，P95响应时间不超过500ms。

我设计了三个压测阶段：第一档50并发持续3分钟，作为基线；第二档150并发持续5分钟，验证目标容量；第三档300并发持续5分钟，找系统的极限点。k6脚本用ramping-vus Executor实现这个阶梯加载，每档之间留一分钟的恢复时间，方便观察系统是否能在压力下降后恢复。

7.2 图表定位：慢在哪、错在哪、堵在哪

压测结束后，打开Grafana仪表盘，整个压测过程的曲线一目了然。50并发阶段，P95稳定在约120ms，错误率几乎为零，系统表现轻松。150并发阶段，P95逐渐爬到约430ms，仍然在500ms的目标线内，但曲线已经显示出上行趋势。300并发阶段，P95直接突破1.6s，错误率上升到约8%。

从面板上最直观的发现是：登录接口的耗时曲线在下单接口的更早出现拐点。下单接口在300并发时P95约900ms，登录接口却已经超过2s。进一步对照服务器监控面板，数据库CPU在150并发阶段就已经很高，这与登录接口的慢查询场景吻合。

团队顺着这个线索去查登录接口的执行计划，发现了一张关键数据表的联合索引缺失，每次登录验证账号时都要走全表扫描。加了索引之后重新压测，同样的300并发场景，P95从1.6s降到了约450ms，错误率降到0.5%。从图中可以清晰看到，优化后的耗时曲线整体下沉了一个量级。

7.3 优化后沉淀下来的实践资产

这个案例之后，团队把三档并发压力的k6脚本固定下来，配套的Grafana仪表盘也保留下来，作为后续每个版本发布前的标准动作。每次发版前跑一轮，把本次的曲线和上次的曲线叠加对比，性能回退基本无处遁形。

我要单独提醒一点：做对比时，压测环境、压测脚本、压测数据量要尽量保持一致。如果这次加了100万条数据库存量，下次存量是10万条，测出来的曲线完全没有可比性。可视化的对比分析很有说服力，但前提是变量可控。把脚本、阈值、环境配置、数据量都固化到团队内部文档里，这个实践才可持续。

说句实在话，我在把k6可视化搭起来之前，压测做完基本就是看一眼summary就结束，很多性能问题都是线上出故障才被发现的。后来固定下来这套InfluxDB加Grafana的监控栈，每次压测的曲线都留档，新旧版本一对比，问题基本暴露得干干净净。如果你也是刚开始做k6负载测试可视化，我的建议很简单：先跑通数据入库，再搭一块核心面板，然后慢慢把阈值、告警、历史对比加进来，这套东西的价值会随着数据积累越来越大。