分布式日志系统

为什么需要分布式日志系统

目前大部分互联网系统，都会涉及到分层，分离，分布式，以及集群。再加上负载均衡和反向代理，这样就会导致一个请求过来，我们根本不知道他走了那台应用服务器，路过了哪些服务，访问了哪些缓存服务和应用数据库；导致我们无法跟踪请求，分析系统，以及给解决问题带来了很大的难度。

所以分布式日志，此时应运而生。分布式日志是基于每个请求，以该请求的线程为依据，跟踪请求经过的每个节点并留下足迹；并记录该请求访问的每一个服务及各个应用数据库。分布式日志洗头具有以下特点或功能：

要能做到追踪每个请求的完整调用链路，

收集调用链路上每个服务的性能数据，

计算性能数据和比对性能指标（SLA），

甚至在更远的未来能够再反馈到服务治理中，

当然我们也可以根据自己的需求在此基础上附加以些功能。 下图是一个案例，先睹为快：

分布式日志系统架构

上图就是分布式日志系统的典型架构。

1. 埋点：各应用系统和服务都需要进行日志的埋点，记录下每个线程执行留下的痕迹

2. 日志收集处理系统

3.  日志处理系统

4. 日志分析系统

5. 日志分析结果输出与展现

埋点部分

各个应用系统的埋点部分是关键，对日志分析结果有着至关重要的作用。当然这里也要结合具体的分析需求和具体的业务进行埋点。

埋点原理如下图:

简单说在系统的入口（http的api），生成一个 requestId，并初始化rpcNum为0 ；

在整个请求执行过程中，入口应用A初始化为0 ，当A调用B 和C 以及消息服务时，分别分配 0.1,0.2,0.3;B调用FG时，分配0.1.1；0.1.2；C调用G时分配0.2.1；以此类推。然后经过处理即可得到上图的树形日志结构。

我们的日志系统：

先整体看一下

我们的分布式日志系统，分为4部分：

数据采集--》数据分析--》数据存储--》平台接口

数据采集：RPC, http，平台内部接口，Response接口

数据分析：用spark/ELK（tail -f ...| scp ...）

数据存储：Hbase/hive

平台接口：Rest，分析结果的一个试图展现。

本次分享重点是  : 数据采集 部分

http 对应的是 API（Controller）拦截器               LogAspect的实现

Rpc 对应的是remote（rpc接口）拦截器               LogAspect的实现

原理是：

1.拦截如上入口，在进入应用逻辑前，埋下埋点（在ThreadLocal中记录下RequestId和sequence），在处理应用逻辑处理完后，记录日志。

2.在访问资源的地方，DB,Redis,MC拦截打印对应的日志。

BaseResourceLog下

memcache的 MemCacheDataSource

redis的 ShardedJedisClient

DB对应 mybatis的 插件MybatisLogPlugin

本版本不足：

还不能把日志穿起来，形成链路。无法很好的完成链路分析。

下版的计划或者目的：（注：此处是军哥的剧透加上我的理解，以及网上相关文章的总结）

1. 统一入口，入口进行埋点，API为唯一入口

2. 后续调用均使用埋点中requestId 和正确的维护 sequence。

3. RPC调用时携带RequestId和sequence

4. 如果需要分析 Service相关信息，可再定义一个Service拦截器。

sequence的维护如下：