本期推荐的项目主要为海量日志（秒级GB级）的搜集、传输、存储而设计的全套方案。
项目介绍
区别于传统的如ELK系列套件，该项目主要是为了解决超大量级的日志（出入参、链路跟踪日志）从搜集到最后检索查询的中途产生的高昂硬件成本、性能低下等问题。
较ELK系列方案（filebeat、mq传输、es存储等常见方案），该框架拥有10倍以上的性能提升，和70%以上的磁盘节省。这意味着，在日志这个功能块上，使用相同的硬件配置，原本只能传输、存储一秒100M的日志，采用该方案，一秒可以处理1GB的日志，且将全链路因日志占用的磁盘空间下降70%。
背景
京东App作为一个巨大量级的请求入口，涉及了诸多系统，为了保证系统的健壮性、和请求溯源，以及出现问题后的问题排查，通常我们保存了用户请求从出入参、系统中途关键节点日志（info、error）、链路日志等，并且会将日志保存一段时间。
日志系统基本划分为几个模块：收集（filebeat、logstash等），传输（kafka、tcp直传等），存储（es，mysql、hive等），查询（kibana、自建）。
以传统日志解决方案为例，当有一个G的日志产生后，日志写本地磁盘（占用磁盘1G），读取后写入mq（mq占用2G，单备份），消费mq写入es（es占用1G），共需占用磁盘4GB，附带着网络带宽占用，和同体量的服务器资源占用（单服务器秒级处理100M）。
则以京东App的体量，当秒级百G日志产生时，所耗费的硬件资源相当庞大，成本已到了难以承受的地步。
该日志框架即为在有所取舍的情况下，支撑海量日志的场景所研发，如前文所讲，该方案在同等硬件配置下，较filebeat+mq+es的模式秒级 日志吞吐量提升10倍，且全链路磁盘占用下降了70%以上 。
方案简介
从这个通用流程中，其实我们很容易就能发现，我们经历了很多读写，每次读写都伴随着磁盘的读写（包括MQ也是写磁盘的），和频繁的序列化反序列化，以及翻倍的网络IO。
我们发现，其实写本地磁盘、和MQ都是没有必要的，我们完全可以将日志数据写到本地内存，然后搞个线程，定时通过UDP将日志直接发送到worker端即可。
worker接收到之后，解析一下，写入自己的内存队列，再起数个异步线程，批量将队列的数据写入ClickHouse数据库即可。
日志搜集系统
基本流程为通过filter获取web请求出入参、自定义log4j、logback的appender搜集中途打印的日志，通过请求入口时生成的tracerId进行关联，写入本地内存（取代写磁盘），进行压缩（字符串空间占用减少80%以上），通过Udp发往worker端（取代mq），worker接收数据抽取索引字段，并入库clickhouse，除未来查询要用的索引字段外，其他内容全程压缩直至入库。
配置中心：用来存储worker的IP地址，供客户端获取自己模块所分配的worker集群的ip。
client：客户端启动后，从配置中心拉取分配给自己这个模块的worker集群的IP，并轮询将搜集的日志压缩后发送过去，通过UDP的方式。
worker：每个模块会分配数量不等的worker机器，启动后上报自己的IP地址到配置中心。接受到客户端发来的日志后，解析相应的字段，批量写入clickhouse数据库。
clickhouse：一个强大的数据库，压缩比很高，写入性能极强，按天分片，查询速度佳。非常适合应用于日志系统这种写入量极大，查询量较少的系统。
dashboard：可视化界面，从clickhouse查询数据展示给用户，具有多条件多维度查询功能。
Client端聚合日志
（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。
Worker端消费日志并入库
worker端是调优的重点，由于要接收海量客户端发来的日志，解析后入库，所以worker需要具备很强的缓冲能力。
通过线上的应用和严苛的压测，这样一台单机docker容器，每秒可以处理原始日志1-5千万行，譬如一条用户请求，中途产生了共计1千多行日志，那么这样的一台worker单机，每秒可以处理2万客户端QPS。对外写clickhouse数据库，每秒可以写200多M比较稳定。
多条件查询控制台
做好数据的分片，如按天分片。用好prewhere查询功能，可以带来性能的提升。做好索引字段的设计，譬如检索常用的时间、pin。
