准实时前端监控探索

实时数据能立即反映线上业务情况，对业务来说能很快看到业务变化带来的实时影响，对技术人员来说能实时观察线上出现的一些波动，有利于及时发现线上问题。

数据埋点上报经过数据部门处理后，有两个离线表，天表和小时表，天表是第二天才能看到前一天的数据，小时表是可以看到当天过去的时间内的数据，为了更早看到数据效果，尝试采用小时表来进行数据监控。

流程基本如下：

过程介绍

架设服务基于Egg.js，Egg 对定时任务支持很好，新建一个定时任务文件在app/schedule 下即可，每个文件都是一个独立的定时任务。

js 复制代码

const Subscription = require('egg').Subscription;

class ScheduleTask extends Subscription {
	static get schedule() {
		return {
			interval: '5m', // 每5分钟执行一次任务
			type: 'worker',
		};
	
	}
	// subscribe 是真正定时任务执行时被运行的函数
	async subscribe() {
		const pageTypes = getConfig(); // 加载录入的埋点
		await this.ctx.service.task.runData(pageTypes);
		this.ctx.service.task.refreshTask(); // 刷新任务，获取查询结果
	}
}

module.exports = ScheduleTask;

查询结果

查询每个小时埋点结果前，先要确定从哪个时间节点开始查询，这里手动指定一个，查询当前时间2个小时前的数据，比如当前是12点，我们就从10点开始查。

注意用这个时间作为游标，需要缓存起来，后面移动游标的时候需要用到。

在 task 这个service 中，执行 sql 查询，sql如下：

sql 复制代码

const sql = `
SELECT
	pagetype,
	hour,
	count(token) as c
FROM
	page_action_1h
WHERE
	pagetype in ('${pageTypes.join('\',\'')}')
	and actiontype='pv'
	and dt='${dateCursor.format('YYYY-MM-DD')}'
	and hour='${queryHour < 10 ? '0' + queryHour : queryHour}'
group by hour, pagetype

`;

dateCursor 就是缓存的游标，page_action_1h 是表名，表中有用户标识token, pagetype，actiontype，dt，hour，等字段。

注意这里是一条sql 查询多个 pagetype，任务提交后并不会立即返回所有数据，可能单独一个pagetype 有结果后就返回，所以需要循环查询任务执行进度，只有所有的页面结果都返回后才可以执行数据处理，间隔时间根据服务执行效率灵活调整，这里间隔时间设置1分钟。

数据处理

假设sql执行请求的到了如下结果：

json 复制代码

[
  [ 'page1', '10', '4818' ],
  [ 'page2', '10', '2932' ],
  [ 'page3', '10', '1474' ]
]

10点这个时段的数据查询出来了，然后就可以对时间游标dateCursor 加1，这样下一次定时任务查询的就是下一个小时的数据了，本次的数据先存储起来，然后进行对比。

存储方式选择存储到redis中，redis存储结构如下： monitor_key:

json 复制代码

{
  "page1": {
    "10": "4818",
    "11": "5945"
  },
  "page2": {
    "10": "2932",
    "11": "1509"
  },
  "page3": {
    "10": "1474",
    "11": "3438"
  }
}

当下一个小时数据执行完成时，就有了两个时段的数据，对比两个时段的数据量就能看到数据变化趋势，并进行报警。

数据存储一个key中，因为是以小时时段存储的，没有记录日期，所以依赖的是任务不断执行，不断刷新下一个小时的数据，以当前时间为节点，只有当前时间之前的数据查询返回之后才进行下一个时段的查询。

另一个方案是每个小时存储一个key，设置24小时过期时间，直接查询所有匹配的小时即可，保留下来的数据就是一天的数据量。

报警规则

我们可以指定当数据量下降一定比例的时候，上升一定比例的时候发送报警信息。基于已有数据还可以指定其他报警规则：

区间段内的平均值
区间段内的尖刺值
最大值预警，最小值预警

上线效果

数据累计之后便可以绘制页面访问量级趋势图，报警的时候一并发送会更直观得观察趋势异常情况。

线上持续运行后，发现一个关键问题，小时表的数据生成时间很不稳定，可能是数据量计算所占任务时间长短不一，有时候可以一小时内生成上一个小时的数据，有时候则需要两三个小时甚至更长时间。这对于一个本身实时性不那么强的报警来说，时效性又打了一层折扣。最终效果并没有达到预期。

通过以上的探索，我们尝试了准实时前端监控的方案，利用小时表来获取更快的实时数据反馈。我们搭建了定时任务来定期查询并存储数据，利用 Redis 存储结构来对比数据变化趋势，并设置报警规则来实时监测异常情况。

然而，在线上实践中发现了小时表数据生成时间不稳定的问题，导致实时性不如预期。这对于一个实时性要求不高的报警系统来说，影响并不是很大，但也暴露了需要进一步优化的空间。

所以在未来我们将需找其他方式的实时数据报警，以提供更准确、实时的数据反馈和监控功能，助力业务发展和故障排查。