图4 新版本日志系统架构图

来审视一下这个链路、极短的日志搜集系统。

配置中心：用来存储worker的IP地址，供客户端获取自己模块所分配的worker集群的ip。

client：客户端启动后，从配置中心拉取分配给自己这个模块的worker集群的IP，并轮询将搜集的日志压缩后发送过去，通过UDP的方式。

worker：每个模块会分配数量不等的worker机器，启动后上报自己的IP地址到配置中心。接受到客户端发来的日志后，解析相应的字段，批量写入clickhouse数据库。

clickhouse：一个强大的数据库，压缩比很高，写入性能极强，按天分片，查询速度佳。非常适合应用于日志系统这种写入极大，查询较少的系统。

dashboard：可视化界面，从clickhouse查询数据展示给用户，具有多条件多维度查询功能。

可以看出，这其中最关键的地方是worker端，它的承接流量、消费性能、入库性能将决定着整个链路能否良好地运转。

主要分别讲解一下client端和worker端的实现。

图5 新日志系统流程示意图

一次请求中，通常要保留的日志信息主要有：

（1）请求的出入参

如果是http web应用，要获取出入参比较简单的方式就是通过自定义filter即可。client的sdk里定义了一个filter，接入方通过配置该filter生效即可搜集到出入参。

如果是其他rpc应用非http请求的，也提供了对应的filter拦截器来获取出入参。

在获取到出入参后，sdk对其中大报文，主要是出参进行了压缩，并将整个数据定义为一个JAVA对象，做protobuf序列化，通过UDP方式往自己对应的worker集群轮询传输。

（2）链路上自己打印的一些关键信息，如调用其他系统的的出入参，自己打印的一些info、error信息

sdk分别提供了log4j、logback、log4j2三个常用日志框架的自定义appender，用户可以通过在自己的日志配置文件（如logback.xml）中，将自定义的appender定义出来即可，那么后续用户在代码里所有打印的info、error等日志都会执行这个自定义appender。

同样，这个自定义appender也是将日志暂存内存，然后异步UDP外送到worker。

这里主要有两个地方需要注意，一是当压缩后的报文依旧超出udp最大报文值时，即通过http送出。二是这一次请求，链路中可能会使用多线程、线程池技术，为避免链路tracer的唯一id在线程池丢失，sdk采用了TransmittableThreadLocal来保持链路的ID，可以查阅进行了解。

总体来说，client端实现较为简单，省略了写本地磁盘、消费文件发MQ等等步骤，整体只有一次Protobuf序列化操作，对CPU、接入方性能影响极小，采用UDP外送，不需要worker的任何回复，也不用考虑tcp模式下worker消费慢导致自己阻塞的问题。整体非常简洁高效。

worker端是调优的重点，由于要接收海量客户端发来的日志，解析后入库，所以worker需要具备很强的缓冲能力。

可以看出，系统的瓶颈点肯定在入库这个阶段，解析日志，抽取字段都是效率很高的，而且完全可以通过控制线程的数量来控制住，而入库将强受限于clickhouse的写入性能。至于clickhouse是如何做的优化，后面会有clickhouse集群负责人来讲一下做了哪些优化。

为了做好这个缓冲，即便日志接收量大于入库量，也要能接下来这些数据，尽量不丢失。首先硬件上，采用大内存机器，8核32G的容器，来尽量多屯一些数据。其次，采用了双缓冲队列，先将所有接收的数据放一个队列，然后多线程消费、解析成可供入库的行数据，再放入一个待入库队列，然后批量入库。

那么做的这些操作，能支撑什么样的数据量呢？

通过线上的应用和严苛的压测，这样一台单机docker容器，每秒可以处理原始日志1-5千万行，譬如一条用户请求，中途产生了共计1千多行日志，那么这样的一台worker单机，每秒可以处理2万客户端QPS。对外写clickhouse数据库，每秒可以写160M-200M比较稳定。

通过对上文的了解，可以知道，这些数据都是被压缩过的，直至库里面的都是压缩过的，只有当最终用户查询时，才会进行解压。所以，这200M，基本相当于原始数据1G多的大小。

也就是说，只要clickhouse写入速度跟的上，这个系统仅需100台就可以极其高效地处理原始秒级百G的日志。对比写MQ的方案，中途所有会出现瓶颈的点如MQ写磁盘速度、消费拉取速度等，都将不复存在。这是一个纯内存交换的链路系统。