十二赞日志收集与报警系统简介

先快速介绍一下十二赞的日志收集系统:十二赞的日志收集系统,分为两块,一块是线上系统的各种报错、异常的日志收集,主要是各种线上代码运行期间产生,我们称之为log-collect,一块是用户行为操作的日志收集,主要是由各个业务系统根据用户的行为来上报,比如用户A访问了xx页面,用户B收藏了某某商品等,我们称之为eventdb。

基于这两块的日志收集,我们实现了一些自己非常自豪的特性。比如,基于log-collect,我们做到了能够主动去发现问题,抢在大多数客户发现异常之前,就把问题处理掉,从而做到不断地提高Saas系统的可用率和稳定性;基于eventdb,我们能做到非常完善的行为收集,将我们的返利模块、分销模块的准确度、实时性大幅度提高。

下面我们介绍一下系统的架构。

从需求上,我们认为log-collect是为了及时发现问题,并马上解决掉。但是这些日志,在我们解决掉问题之后,是不需要再保留这个日志的。比如,举个例子,用户注册的时候,可能输了一个12012345678的号码,这个号码是不对的,导致我们的验证短信发不出去,短信模块就会报错。我们的log-collect会收集到这条报错日志,马上告警。开发同学收到告警通知时,就马上去处理这个问题,用户输入120这个号段时,提示用户该号段是不被支持的,以后就再也不需要处理这个了,因为这条告警日志,我们是不存的,只存档15天就丢弃掉。

但是对于eventdb,我们的目标是为了对这些数据做分析,这些行为一般会跟财务相关,比如用户A通过用户B分享的链接进到了系统,5分钟之后有户A购买了商品付款了200元,2天后用户A退掉了其中的80元。这些数据,会影响到商家给用户B结算cps款项。类似这些数据,我们是永久存储的,不会抛弃。同时,这类数据,我们是要在保证准确性的基础上不断提高实时性的。所以对这类数据,我们有两条线来处理,一条是在线实时,一条是离线的一个小时跑一次数据的。

log-Collect

基于这种差异,我们在架构上也有不同。下面是log-collect的架构图:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/48370500.8048.png

我们每一台服务端机器上都有一个live tail,实时监控日志文件,一旦日志文件有新的写入,就立刻发送到http的一个日志网关。这个网关就立刻把这条件日志推送给一个广播服务器,并写入到一个数据库(数据库会清掉7天之前的数据。)这个数据丢给广播服务器了之后,会在特定的频道进行广播。我写了一些客户端,订阅广播,根据日志内容的不同,将日志发给倍洽上不同的告警频道。(关于bearychat/中文名倍洽,大家可以自行去其官网上了解)。手机上装了倍洽,就可以随时接受告警通知了:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/82177300.jpeg

eventDB

下图是eventDB的架构图:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/87788400.6795.png

与log-collect相同的,收到新的行为事件后,网关也会在一个特定的频道进行广播。不同的有两点,一点是另一条链路先把行为事件写入到阿里云的oss存储起来,然后写了crontab每小时、每天定期从oss文件里导入到eventDB这个数据库;另一点是广播客户端工作的事情也变成了实时写入到eventDB这个数据库。

在事件收集上,也不一样,log-collect是在所有的服务器上部署了LiveTail来从日志文件中读取,而eventDB是需要各个业务系统自己向日志网关来汇报事件的。

存入数据库之后,后续就是再对这些数据进行分析,查找用户的来源渠道,计算佣金等等操作了。

 

“十二赞日志收集与报警系统简介”的一个回复

发表评论