背景

契机

arms成本考虑下线

年中的时候研究发现，阿里云的arms功能非常好用，他将我们的前端项目性能数据通过数据可视化的形式呈现，能够让我们快速的定位一些项目中隐藏的问题。但是由于2w一月的使用成本，结合性价比考虑将其下线。

flogger4.0项目全面铺设

目前基本上主要的项目已经普及flogger4.0，flogger4.0会上报海量的数据。kibana虽然功能强大，但是需要一定的学习成本。但是如何利用好这些海量的数据，却是大家常常忽视的。

月报统计需要

由于月报需要填写一些性能数据，之前需要手动的查多张kibana表，一一填写进去。于是想到通过脚本的形式，结合excel库生成文档。一方面大大提高了月报汇总的效率，也能够让脚本在后台静默执行，汇报保持每天、每周的汇报频率

为什么要做？相比已有的kibana分析的优势

1. 速度。数据库查询天然优势，比ES查询速度更快十倍以上。
2. 自动化。脚本自动执行，避免遗忘和积极性丧失。
3. 定制化。定制化开发，摘取有效信息业务痛点。
4. 持久化。数据体系构建，数据持久化存储（es最多查询十几天的数据），利于月报整理和数据分析。

里程碑

1.0. flogger4.0的全面运用 2021.6.11-2021.9.15

8月份和9月份，经过对flogger4.0的bug排查，陆续的将我们的项目运用了flogger4.0.

2.0. 数据报表自动生成&企业微信推送 2021.8.20-至今

为了满足日报、周报、月报统计的需要，通过已有的jobs项目,打造了监控推送体系的雏形（es-jobs-企业微信）。期间完成了诸如flogger3.0升4.0报告，数据高亮等优化。

3.0. 数据可视化初版 2021.10.25-至今

2.0的excel形式，的确是大大的方便了8月之后的月报统计填写，企业微信的推送也在有条不紊的运行着。 但是，excel毕竟是一串串数字，即使每天推送，也少有人去打开分析。看起来会比较累。2.0的可视化，就是让数据以更好的形式呈现出来。同时，做了以下两点升级。

1. 每天的性能数据，会存在redis里面，再次查询的话，不需要再去查询一遍es（es会丢失旧数据）。 数据存储比较简单，相当于是把excel的行数据，写入到redis的一个key里面

2. 数据可视化呈现，基于ejs打造简易的页面，形成前端监控可视化的雏形。结合企业微信api的推送，打造可视化日报。

4.0. 前端监控页面体系化&数据接口体系

5.0. 打造成易用的可移植的类arms监控体系

1.flogger4.0开源 2.易用美观的可视化界面 3.错误报警机制 4.不局限于Flogger数据，额外加入后端日志分析等 5.跨部门分享

-实现

-- Jobs

--- es查询

ElasticSearch是开源的搜索引擎，提供搜集、分析、存储数据三大功能。它提供了restful api接口。

也就是基于ES对于nodejs的支持，使得我们能够在node项目中查询需要的数据。

在nodejs中，使用方式如下，通过官方提供的查询语句构造body，异步请求后即可获得es返回的值 import { Client } from ``'@elastic/elasticsearch'

const singleKpiRes = await client.search({

    ``index: ``'webc-flogger4-*'``,

    ``body: queryBody

})

es的查询功能非常的强大，如bool查询，组合查询等。

举个例子：

即使是并非精通es查询，也不难发现其中的规律，从而通过模板字符串的形式，进行编程式开发

--- 定时任务

juejin.cn/post/684490…

Bull是基于Redis的一个Node.js任务队列管理库,支持延迟队列,优先级任务,重复任务,以及原子操作等多种功能.

Bull的使用分为三个步骤:

1. 创建队列
2. 绑定任务处理函数
3. 添加任务

如下示例:

const Bull = require('bull')
// 1. 创建队列
const myFirstQueue = new Bull('my-first-queue');
// 2. 绑定任务处理函数
myFirstQueue.process(async (job, data) => {
  return doSomething(data);
});
// 3. 添加任务
const job = await myFirstQueue.add({
  foo: 'bar'
});

可以通过cron表达式去控制每天加入队列的时间

--- 企业微信机器人

企业微信提供了通过传递参数，触发响应的接口api，从而让机器人发出推送的功能。具体的操作，阅读官方文档即可。简要说说每天的文档是怎么发出的。

1.在群管理里面新建一个机器人获得它的key，你是拥有者的话，就可获得他的配置参数（key）。建议申请多个机器人，做好环境区分在开发环境调试情况下，不要影响到别人。

2.通过api，触发（以发送文件为例子）。通常，根据query中的key，区分触发是哪个机器人；

--- 模板引擎

模板引擎ejs是在里程碑3.0中，为了实现简易可视化的策略。基于express，可以直接通过访问路由，渲染出响应的模板页面。

ejs提供了一些数据的插槽，可以通过render函数传递进去。由于我们的数据是进页面才调的，所以不过多讨论。

Jobs项目本身具有express层，所以说可以提供相应的接口。

以查询redis为例

在template.ejs中，我们可以调用此同源接口，进行页面的渲染。

记一个小坑↓

因为template.ejs是通过识别特点路径/views的形式渲染的，所以并不能和其他的代码一起打包。造成了打包后，找不到模板文件的现象。原因是打包后的jobs项目，其实是没有views这个路径的

那么我们的目的就是将打包前的代码。复制到打包后的build文件夹中。

在rollup配置中，加入

import copy from ``'rollup-plugin-copy'``...``plugins:[``...``copy({``      ``targets: [{ src: ``'views/template.ejs'``, dest: ``'build/views' }]``    ``})``]``...

-- 数据采集和存储

前文讲到，kibana是一个比较好的工具，但是也有一些劣势。

1.查询速度方面。经过很长一些时间的观察，平均每次查询每天的数据（以40个技术指标*10个项目为例），需要执行400次es查询语句，全部跑完需要大概4-5分钟。如果是周报查询7天的数据，时间会要10分钟以上了。在3.0中，很好的利用的redis，将每天的数据缓存下来。使得下次查询不再需要查询查ES，白白等待几分钟。、

2.数据存储方面。flogger4.0每天会上报海量的数据，一方面使得查询变得更加的慢，另一方面，实测会有旧数据丢失的情况出现。比如11.30号，只能最早查到11.20号的数据了。这对于统计长时间的数据，造成了较大的不便。亟待将数据进行可靠有序的存储。

前端监控指标的数据图如下

上文中，redis存取的只是excel中的单行数据。无论是可读性、可拓展性方面，都太差了，只是一种临时的解决方案。设计mysql表进行存储是更佳的方案，能够存储更大量，丰富的数据。

最终成果

首页

报告页面