十二赞日志收集与报警系统一览

先快速介绍一下十二赞的日志收集系统：十二赞的日志收集系统，分为两块，一块是线上系统的各种报错、异常的日志收集，主要是各种线上代码运行期间产生，我们称之为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的架构图：

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

eventDB

下图是eventDB的架构图:

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

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

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