典型日志系统架构及其缺点

典型日志系统架构

image.png

典型的日志架构如图所示，简单介绍下基本流程

日志通过filebeat或者api写入到kafka或者其它队列系统，这个队列通常是企业内部的流数据总线

从kafka出来，再用flink,kafka stream，或者spark streaming ,spark structedstreaming,或者mlsql,或者streamsets或者nifi等等流计算系统，对日志进行流式处理。

流计算框架处理后的日志，再写入到elasticsearch或者clickhouse供搜索，查询，分析，统计等等

日志查询平台有kibana，或者grafana，或者是企业内部自研的查询web ui。
国内典型的日志平台架构绝大多数架构都与此类似。

谈几个问题

1、为什么要用上面的架构？

我认为主要有2点原因吧，
第一、为什么需要一个kafka这样的队列系统？因为日志的流量太大了，kafka的写效率很高，一方面可以抗住大流量，让日志数据快速持久化下来，下游可以灵活的消费，回放等等，同时可以对接流计算框架，对日志做流式处理。

第二、为什么弄一个流计算框架？因为日志需要解析，一方面是分析的需要，另一方面主流的日志存储服务不是完全schema free的，clickhouse不用说了，写数据之前需要创建表，定义表结构，写入数据要跟表字段对应上；es虽然类似稀疏表，没有clickhouse那么严格，但是也需要做field mapping，而且有些不在mapping中的字段，会按照第一次写入的数据类型给它设置默认的数据类型，如果这个字段下次写进来一个别的类型，写入失败。
因为字段类型的限制，必须要在写入数据库之前，对字段进行处理，抽取，增强等等，并且要做好字段对照。

2、这种架构的缺点

架构看起来简单而且合理，但是有很多问题

第一个问题： kafka topic以及流处理程序的管理

一个公司内部可能有成百上千种日志，那么一种日志创建一个topic还是所有的日志写入同一个topic?
首先kafka性能其实跟topic数量，partition总数是有关系的，不适合过多topic、过多partition的场景 (这个不在今天讨论范围内，从功能上讲，可以使用Pulsar或者Pravega代替，解决多topic或者partition的问题)，有些日志流量较大，有些流量较小，那么就需要一个kafka管理平台申请topic,partition，同时能够管理partition扩容的问题。
另外不管是创建单独的topic还是所有日志写入同一个topic，下游都需要为每一种不同格式的日志配套一个流计算作业，即便是所有的日志用同一个作业处理，那么每增加一个新的日志格式，也要修改作业逻辑，重新提交作业。
那么维护这样的流处理逻辑本身也是一个很麻烦的事情，因为解析逻辑可能会经常变，业务日志格式变了，这个作业逻辑就要变。同时流计算作业消耗的机器资源也会随着日志流量或者topic数量线性增加。

第二个问题：存储后端数据的管理

es需要创建index,设置shard个数，每种日志因为字段数量、数据类型不同，需要单独创建index，冷热数据策略，retention策略等等，需要外部系统定时任务处理，热点数据排查等等，需要高超的运维能力。
clickhouse架构其实一点不比es省心，一大堆配置。并且n副本就要n倍的硬件资源。虽然它写入性能卓越，数据分析性能吊打es，但是字符串的搜索能力完全不能满足实时搜索的要求，所以clickhouse只能完成数据分析，不能胜任检索的责任。
因为不是shema free的系统，上游日志结构调整，或者中间流计算作业解析逻辑调整，都要重新创建新的数据表。
两套系统都需要运维，查询和分析割裂，上层应用需要对接不同的系统，不同的查询语言，这其实很糟糕，硬件消耗也巨大。

第三个问题：流计算框架的维护

因为引入流计算框架，那么管理人员必须要掌握一套流计算框架体系，能够运维、能够开发相应的作业，理解一大堆抽象的概念，窗口、反压、source、sinker，能够解决排查常见的问题等等，而解析日志实际上性能消耗不大，使用flink集群做处理，机器资源还存在巨大的浪费。

第四个问题：外围体系的建设

账号体系，权限管理： 有些公司要求权限做到日志的某个字段级别；报警体系建设，监控规则，报警器对接钉钉，微信，短信，邮件等等；自定义dashboard，web ui等等。

第五个问题：常用的功能不易实现

比如live tail, 比如日志上下文还原，正则搜索，查询时字段的再解析，enrich，转换，灵活的聚合函数等等，通过这套架构不易实现。

第六个问题：资源消耗大，性价比低

日志流量达到一定规模后，kafka能接住的数据，要让es低延时的接住，并且提供查询，那么资源消耗数倍或者数十倍，同时es数据膨胀严重，磁盘IO消耗巨大，读写不分离，机器load容易飙高，这时候实际需要的机器资源一般公司根本无法承受，每天上T的数据量已经是es集群的天花板了。clickhouse虽然压缩比较高，但是不能完全胜任日志场景的工作，特别是搜索的场景。

小结

简单来说这种架构其实非常不合理，根本原因是存储后端不适合日志管理与分析的真实场景，一段时间以来，开源世界没有一套真正针对日志场景设计的系统，es宣称适合大规模日志存储，所以大家都会想当然的上这套架构，只有真正躺过这个大坑，才能发现性价比极低，运维复杂度极高，极不适合。

尽管最近几年有loki这样的新秀开源出来，它在很大层度上降低了硬件成本，但是loki同样有很多缺点，也有很多核心问题没有解决，比如日志量巨大的时候，查询性能的问题，计算函数不够丰富，产品成熟度不够高等等，当然它的index-free、高性价比的设计思想是非常值得肯定的，过段时间会专门分析这个东西。

目前国内多数商业日志产品底座还是es,有些公司宣称对es进行优化，性能提高2倍;也有不少大厂自研非es底座的日志存储分析产品，本质上也都是基于索引的，比如阿里云的SLS，架构更加臃肿。这些基于索引的方案，架构无法得到真正的优化，不可能做到真正的性价比提升。