查日志只有ES好使？那是你没这样用Clickhouse……

一、背景

石墨文档全部应用部署在Kubernetes上，每时每刻都会有大量的日志输出，我们之前主要使用SLS和ES作为日志存储。但是我们在使用这些组件的时候，发现了一些问题。

1）成本问题

• SLS个人觉得是一个非常优秀的产品，速度快，交互方便，但是SLS索引成本比较贵
• 我们想减少SLS索引成本的时候，发现云厂商并不支持分析单个索引的成本，导致我们无法知道是哪些索引构建得不够合理
• ES使用的存储非常多，并且耗费大量的内存

2）通用问题

• 如果业务是混合云架构，或者业务形态有SAAS和私有化两种方式，那么SLS并不能通用
• 日志和链路，需要用两套云产品，不是很方便

3）精确度问题

• SLS存储的精度只能到秒，但我们实际日志精度到毫秒，如果日志里面有traceid，SLS中无法通过根据traceid信息，将日志根据毫秒时间做排序，不利于排查错误

我们经过一番调研后，发现使用Clickhouse能够很好地解决以上问题，并且Clickhouse省存储空间，非常省钱，所以我们选择了Clickhouse方案存储日志。但当我们深入研究后，Clickhouse作为日志存储有许多落地的细节，但业界并没有很好阐述相关Clickhouse采集日志的整套流程，以及没有一款优秀的Clickhouse日志查询工具帮助分析日志，为此我们写了一套Clickhouse日志系统贡献给开源社区，并将Clickhouse的日志采集架构的经验做了总结。先上个Clickhouse日志查询界面，让大家感受下石墨最懂前端的后端程序员。

二、架构原理图

我们将日志系统分为四个部分：日志采集、日志传输、日志存储、日志管理。

• 日志采集： LogCollector采用Daemonset方式部署，将宿主机日志目录挂载到LogCollector的容器内，LogCollector通过挂载的目录能够采集到应用日志、系统日志、K8S审计日志等
• 日志传输： 通过不同Logstore映射到Kafka中不同的Topic，将不同数据结构的日志做了分离
• 日志存储： 使用Clickhouse中的两种引擎数据表和物化视图
• 日志管理： 开源的Mogo系统，能够查询日志，设置日志索引，设置LogCollector配置，设置Clickhouse表，设置报警等

以下我们将按照这四大部分，阐述其中的架构原理。

三、日志采集

1、采集方式

Kubernetes容器内日志收集的方式通常有以下三种方案。

• DaemonSet方式采集： 在每个node节点上部署LogCollec