背景

之前的几篇文章都是对于之前提到的低代码平台的。

这个大的我的项目以 low code 为外围，囊括了编辑器前端、编辑器后端、C 端 H5、组件库、组件平台、后盾管理系统前端、后盾管理系统后盾、统计服务、自研 CLI 九大零碎。

明天就来说一下其中的统计服务：目标次要是为了实现 H5 页面的分渠道统计(其实不仅仅是分渠道统计，外围是想做一个自定义事件统计服务，只是目前有分渠道统计的需要)，查看每个渠道具体的 PV 状况。(具体会在 url 下面体现，会带上页面名称、id、渠道类型等)

先放一下整体流程图吧：

日志收集

常见的日志收集形式有手动埋点和主动埋点，这里咱们不关注于如何收集日志，而是如何将收集的日志的发送到服务器。

在常见的埋点计划中，通过图片来发送埋点申请是一种常常被驳回的，它有很多劣势：

  • 没有跨域
  • 体积小
  • 可能实现整个 HTTP 申请+响应（只管不须要响应内容）
  • 执行过程无阻塞

这里的计划就是在 nginx 上放一张 1px * 1px 的动态图片，而后通过拜访该图片（http://xxxx.png?env=xx&event=xxx）,并将埋点数据放在query参数上，以此将埋点数据落到nginx日志中。

iOS 上会限度 get 申请的 url 长度，但咱们这里实在场景发送的数据不会太多，所以目前临时采纳这种计划

这里简略论述一下为什么图片地址的query key 要这么设计，如果单纯是为了统计渠道和作品，很有可能会把key设计为channel、workId这种，但下面也说到了，咱们是想做一个自定义事件统计服务，那么就要思考字段的可扩展性，字段应更有通用语义。所以参考了很多统计服务的设计，这里采纳的字段为：

  • env
  • event
  • key
  • value

之后每次拜访页面，nginx就会自动记录日志到access_log中。

有了日志，上面咱们来看下如何来对其进行拆分。

日志拆分

为何要拆分日志

access.log日志默认不会拆分，会越积攒越多，零碎磁盘的空间会被耗费得越来越多，未来可能面临着日志写入失败、服务异样的问题。

日志文件内容过多，对于后续的问题排查和剖析也会变得很艰难。

所以日志的拆分是有必要也是必须的。

如何拆分日志

咱们这里拆分日志的外围思路是：将以后的access.log复制一份重命名为新的日志文件，之后清空老的日志文件。

视流量状况（流量越大日志文件积攒的越快），按天、小时、分钟来拆分。能够把access.log按天拆分到某个文件夹中。

log_by_day/2021-12-19.loglog_by_day/2021-12-20.loglog_by_day/2021-12-21.log

但下面的复制 -> 清空操作必定是要主动解决的，这里就须要启动定时工作，在每天固定的工夫（我这里是在每天凌晨 00:00）来解决。

定时工作

其实定时工作不仅在日志拆分的时候会用到，在前面的日志剖析和日志革除都会用到，这里先简略介绍一下，最终会整合拆分、剖析和革除。

linux中内置的cron过程就是来解决定时工作的。在node中咱们个别会用node-schedule或cron来解决定时工作。

这里应用的是cron：

/**    cron 定时规定 https://www.npmjs.com/package/cron    *    *    *    *    *    *    ┬    ┬    ┬    ┬    ┬    ┬    │    │    │    │    │    │    │    │    │    │    │    └ day of week (0 - 6) (Sun-Sat)    │    │    │    │    └───── month (1 - 12)    │    │    │    └────────── day of month (1 - 31)    │    │    └─────────────── hour (0 - 23)    │    └──────────────────── minute (0 - 59)    └───────────────────────── second (0 - 59) */

具体应用形式就不开展阐明了。

编码

有了下面这些储备，上面我就来写一下这块代码，首先梳理下逻辑：

1️ 读取源文件 access.log

2️ 创立拆分后的文件夹（不存在时需主动创立）

3️ 创立日志文件（天维度，不存在时需主动创立）

4️ 拷贝源日志至新文件

5️ 清空 access.log

/** * 拆分日志文件 * * @param {*} accessLogPath */function splitLogFile(accessLogPath) {  const accessLogFile = path.join(accessLogPath, "access.log");  const distFolder = path.join(accessLogPath, DIST_FOLDER_NAME);  fse.ensureDirSync(distFolder);  const distFile = path.join(distFolder, genYesterdayLogFileName());  fse.ensureFileSync(distFile);  fse.outputFileSync(distFile, ""); // 避免反复，先清空  fse.copySync(accessLogFile, distFile);  fse.outputFileSync(accessLogFile, "");}

日志剖析

日志剖析就是读取上一步拆分好的文件，而后依照肯定规定去解决、落库。这里有一个很重要的点要提一下：node在解决大文件或者未知内存文件大小的时候千万不要应用readFile，会冲破 V8 内存限度。正是思考到这种状况，所以这里读取日志文件的形式应该是：createReadStream创立一个可读流交给 readline 逐行读取解决

readline

readline 模块提供了用于从可读流每次一行地读取数据的接口。 能够应用以下形式拜访它：

const readline = require("readline");

readline 的应用也非常简单：创立一个接口实例，传入对应的参数：

const readStream = fs.createReadStream(logFile);const rl = readline.createInterface({  input: readStream,});

而后监听对应事件即可：

rl.on("line", (line) => {  if (!line) return;  // 获取 url query  const query = getQueryFromLogLine(line);  if (_.isEmpty(query)) return;  // 累加逻辑  // ...});rl.on("close", () => {  // 逐行读取完结，存入数据库  const result = eventData.getResult();  resolve(result);});

这里用到了line和close事件：

  • line事件：每当 input 流接管到行尾输出（\n、\r 或 \r\n）时，则会触发 'line' 事件
  • close事件：个别在传输完结时会触发该事件

逐行剖析日志后果

理解了readline 的应用，上面让咱们来逐行对日志后果进行剖析吧。

首先来看下access.log中日志的格局：

咱们取其中一行来剖析：

127.0.0.1 - - [19/Feb/2021:15:22:06 +0800] "GET /event.png?env=h5&event=pv&key=24&value=2 HTTP/1.1" 200 5233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36" "-"

咱们要拿到的就是url的query局部，也就是咱们在h5中自定义的数据。

通过正则匹配即可：

const reg = /GET\s\/event.png\?(.+?)\s/;const matchResult = line.match(reg);console.log("matchResult", matchResult);const queryStr = matchResult[1];console.log("queryStr", queryStr);

打印后果为：

queryStr可通过node中的querystring.parse()来解决：

const query = querystring.parse(queryStr);console.log('query', query){  env: 'h5',  event: 'pv',  key: '24',  value: '2'}

剩下的就是对数据做累加解决了。

但如何去做累加，咱们要想一下，最开始也说了是要去做分渠道统计，那么最终的后果应该能够清晰的看到两个数据：

  • 所有渠道的数据
  • 每个渠道独自的数据

只有这样的数据对于经营才是有价值的，数据的好坏也间接决定了前面在每个渠道投放的力度。

这里我参考了 Google Analytics中的多渠道漏斗的概念，由上到下分维度记录每个维度的数据，这样就能够清晰的晓得每个渠道的状况了。

具体实现也不麻烦，咱们先来看下刚刚从一条链接中失去的有用数据：

{  env: 'h5',  event: 'pv',  key: '24',  value: '2'}

这里的env代表环境，这里统计的都是来源于h5页面，所以env为h5，然而为了扩大，所以设置了这个字段。

event示意事件名称，这里次要是统计访问量，所以为pv。

key是作品 id。

value是渠道 code，目前次要有：1-微信、2-小红书、3-抖音。

再来看下最终统计失去的后果吧：

{  date: '2021-12-21',  key: 'h5',  value: { num: 1276}}{  date: '2021-12-21',  key: 'h5.pv',  value: { num: 1000}}{  date: '2021-12-21',  key: 'h5.pv.12',  value: { num: 200}}{  date: '2021-12-21',  key: 'h5.pv.12.1',  value: { num: 56}}{  date: '2021-12-21',  key: 'h5.pv.12.2',  value: { num: 84}}{  date: '2021-12-21',  key: 'h5.pv.12.3',  value: { num: 60}}

这是截取了2021-12-21当天的数据，我给大家剖析一波：

1️ h5：当天 h5 页面的自定义事件上报总数为 1276

2️ h5.pv：其中 所有 pv（也就是 h5.pv）为 1000

3️ h5.pv.12：作品 id 为 12 的 pv 一共有 200

4️ h5.pv.12.1：作品 id 为 12 的在微信渠道的 pv 为 56

5️ h5.pv.12.2：作品 id 为 12 的在小红书渠道的 pv 为 84

6️ h5.pv.12.2：作品 id 为 12 的在抖音渠道的 pv 为 60

这样就能分明的失去某一天某个作品在某条渠道的拜访状况了，后续再以这些数据为撑持做成可视化报表，成果就高深莫测了。

统计后果入库

目前这部分数据是放在了mongoDB中，对于node中应用mongoDB就不开展说了，不相熟的能够参考我另外一篇文章Koa2+MongoDB+JWT 实战--Restful API 最佳实际

这里贴下model吧：

/** * @description event 数据模型 */const mongoose = require("../db/mongoose");const schema = mongoose.Schema(  {    date: Date,    key: String,    value: {      num: Number,    },  },  {    timestamps: true,  });const EventModel = mongoose.model("event_analytics_data", schema);module.exports = EventModel;

日志删除

随着页面的继续拜访，日志文件会疾速减少，超过肯定工夫的日志文件存在的价值也不是很大，所以咱们要定期革除日志文件。

这个其实比较简单，遍历文件，因为文件名都是以日期命名的(格局：2021-12-14.log)，所以只有判断工夫距离大于 90 天就删除日志文件。

贴一下外围实现：

// 读取日志文件const fileNames = fse.readdirSync(distFolder);fileNames.forEach((fileName) => {  try {    // fileName 格局 '2021-09-14.log'    const dateStr = fileName.split(".")[0];    const d = new Date(dateStr);    const t = Date.now() - d.getTime();    if (t / 1000 / 60 / 60 / 24 > 90) {      // 工夫距离，大于 90 天，则删除日志文件      const filePath = path.join(distFolder, fileName);      fse.removeSync(filePath);    }  } catch (error) {    console.error(`日志文件格式谬误 ${fileName}`, error);  }});

定时工作整合

到这里，日志的拆分、剖析和革除都说完了，当初要用cron来对他们做整合了。

首先来创立定时工作：

function schedule(cronTime, onTick) {  if (!cronTime) return;  if (typeof onTick !== "function") return;  // 创立定时工作  const c = new CronJob(    cronTime,    onTick,    null, // onComplete 何时进行工作    true, // 初始化之后立即执行    "Asia/Shanghai" // 时区  );  // 过程完结时，进行定时工作  process.on("exit", () => c.stop());}

而后每一阶段都在不同的工夫阶段去解决（定时拆分 -> 定时剖析 -> 定时删除）

定时拆分

function splitLogFileTiming() {  const cronTime = "0 0 0 * * *"; // 每天的 00:00:00  schedule(cronTime, () => splitLogFile(accessLogPath));  console.log("定时拆分日志文件", cronTime);}

定时剖析并入库

function analysisLogsTiming() {  const cronTime = "0 0 3 * * *"; // 每天的 3:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态  schedule(cronTime, () => analysisLogsAndWriteDB(accessLogPath));  console.log("定时剖析日志并入库", cronTime);}

定时删除

function rmLogsTiming() {  const cronTime = "0 0 4 * * *"; // 每天的 4:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态  schedule(cronTime, () => rmLogs(accessLogPath));  console.log("定时删除过期日志文件", cronTime);}

而后在利用入口按序调用即可：

// 定时拆分日志文件splitLogFileTiming();// 定时剖析日志并入库analysisLogsTiming();// 定时删除过期日志文件rmLogsTiming();

总结

ok，到这里，一个繁难的统计服务就实现了。