看过一些介绍kafka的文章，并且在工作当中也接触过一些。给人的印象kafka是比较适合做消息中间件的，生产和消费速度都非常的快，大致的原因是因为技术上采用了顺序写入和MMFile。今天我想分享一下除了kafka可以作为消息中间件之外还可以作为日志聚合工具。传统的开源日志聚合工具有三种：
1.ELK
2.Graylog
3.Fluentd
ELK遇到的挑战是，当实时日志量很大超过了es实时处理能力的时候就会出现丢数据和es服务不可用的情况。另外遇到的一个问题是实时创建的segment需要定期merge，这个过程同样会给es带来很大的压力。有一种做法就是建很多ELK集群外面套层gateway服务做转发，但是不管怎样，都会带来很多运维工作。graylog更像是一个pipeline工具，通过管道处理之后存储还是es，所以同样会遇到上面的问题。另外graylog本身对日志的数量也有限制，我们有600个日志会需要创建很多graylog服务来分摊，这个是因为和graylog本身内部统一分发有关。
在放弃了上述两种架构之后，我们重新梳理一下。es虽然很强大，但是也付出了很大的代价——实时建索引。实际上用户真正用到的日志量极少，我们却投入了大量的资源去创建根本使用不到的日志索引。根据用户使用场景当中提炼出来，我们更倾向于时序数据库做为日志存储，通过用户输入的时间做过滤查询日志，这样就可以限定到少部分的日志内容在返回给用户。通过调研hbase，influxdb，logdevice等等，最终我们选择了kafka作为底层存储。hbase需要单独设计rowkey，另外在并发和日志记录的上下级关系上都需要而外的设计，这样就增加了开发的复杂度，influxdb集群版本是需要付费的，logdevice一开始是首选的日志存储方案，但是因为是C++版本，在技术栈能力上也不要擅长，所以放弃了。另外需要分享的是，facebook研发logdevice的初衷和我们的场景很相似，网上也有专门的解释有兴趣的同学可以去看下。个人觉得在并发和搜索能力上logdevice相比kafka潜力要大很多，当然kafka通过源码级别的改造也能够满足，比如可以基于broker级别的日志过滤，读写分离等等。
下面也截图去一段官网上的说明，关于日志聚合工具上kafka具备的能力。
在选型kafka作为底层存储之后，需要有个web console作为用户查看、搜索日志的平台。我们选用了一款开源软件logsniffer作为web console。其设计页面功能非常的丰富，支持tail，more，search，告警等功能。但是logsniffer底层是用文件式存储，在最初的运行过程当中，查询小日志量的文件是可以满足用户需求的，但是日志量稍微大一点，比如一个小时生成4-5G的文件，搜索起来就有点耗时了。经过对其底层存储的改造，在使用体验上速度明显快了很多，日志量大的采用多分区方式可以增加读取kafka并发能力。我们做了下对比，在单分区每小时产生4G大小左右的搜索，如果搜索内容不是和生僻的话，秒级都能在。对比用文件式存储几分钟都未必能返回结果。
传统的日志收集平台都需要单独搭建日志存储服务，通过使用kafka作为存储服务之后，非常高性价比的日志聚合平台架构就浮现出来了。和传统的ELK平台相比，优点是不需要很多机器用来部署es+kibana，也不需要额外的运维人员对es做性能调优、运维和基于ELK的二次开发。缺点是搜索体验上不如ELK做的那么强大，当然基于kafka存储也可以在体验上有所改进，特别可以基于KSQL查询引擎提升用户的体验也可以在此让用户配置个性化告警功能，另外在统计分析上的缺失，这部分一种可靠的方式是将日志非实时的写入es当中再做分析也是一种选项。
总结：kafka在作为日志存储做查询、搜索上能很好的满足用户需求，但是在日志分析上还有所欠缺。但是kafka本身基于MMFile机制造就高效的批量数据发送能力，未来用kafka作为存储研发日志分析功能未尝不值得一试。
