还在用ES查日志吗，快看看石墨文档 Clickhouse 日志架构玩法

1 背景

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

• 成本问题：

• • SLS个人觉得是一个非常优秀的产品，速度快，交互方便，但是SLS索引成本比较贵

  • 我们想减少SLS索引成本的时候，发现云厂商并不支持分析单个索引的成本，导致我们无法知道是哪些索引构建的不够合理

  • ES使用的存储非常多，并且耗费大量的内存

• 通用问题：

• • 如果业务是混合云架构，或者业务形态有SAAS和私有化两种方式，那么SLS并不能通用

  • 日志和链路，需要用两套云产品，不是很方便

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

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

2 架构原理图

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

• 日志采集：LogCollector采用Daemonset方式部署，将宿主机日志目录挂载到LogCollector的容器内，LogCollector通过挂载的目录能够采集到应用日志、系统日志、K8S审计日志等

• 日志传输：通过不同Logstore映射到Kafka中不同的Topic，将不同数据结构的日志做了分离

• 日志存储：使用Clickhouse中的两种引擎数据表和物化视图

• 日志管理：开源的Mogo系统，能够查询日志，设置日志索引，设置LogCollector配置，设置Clickhouse表，设置报警等

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

3 日志采集

3.1 采集方式

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

• DaemonSet方式采集：在每个 node 节点上部署LogCollector，并将宿主机的目录挂载为容器的日志目录，LogCollector读取日志内容，采集到日志中心。

• 网络方式采集：通过应用的日志 SDK，直接将日志内容采集到日志中心 。

• SideCar方式采集：在每个 pod 内部署LogCollector，LogCollector只读取这个 pod 内的日志内容，采集到日志中心。

以下是三种采集方式的优缺点：

我们主要采用DaemonSet方式和网络方式采集日志。DaemonSet方式用于ingress、应用日志的采集，网络方式用于大数据日志的采集。以下我们主要介绍下DeamonSet方式的采集方式。

3.2 日志输出

从上面的介绍中可以看到，我们的DaemonSet会有两种方式采集日志类型，一种是标准输出，一种是文件。

引用元乙的描述：虽然使用 Stdout 打印日志是 Docker 官方推荐的方式，但大家需要注意：这个推荐是基于容器只作为简单应用的场景，实际的业务场景中我们还是建议大家尽可能使用文件的方式，主要的原因有以下几点&