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

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

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

https://ylpicture.oss-cn-beij...

eventDB

下图是eventDB的架构图:

https://ylpicture.oss-cn-beij...

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

在事件收集上，也不同，log-collect是在全部的服务器上部署了LiveTail来从日志文件中读取，而eventDB是须要各个业务系统本身向日志网关来汇报事件的。

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