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

石墨文档全部应用部署在Kubernetes上，每时每刻都会有大量的日志输出，我们之前主要使用SLS和ES作为日志存储。但是我们在使用这些组件的时候，发现了一些问题。,SLS个人觉得是一个非常优秀的产品，速度快，交互方便，但是SLS索引成本比较贵,我们经过一番调研后，发现使用Clickhouse能够很好地解决以上问题，并且Clickhouse省存储空间，非常省钱，所以我们选择了Clickhouse方案存储日志。但当我们深入研究后，Clickhouse作为日志存储有许多落地的细节，但业界并没有很好阐述相关Clickhouse采集日志的整套流程，以及没有一款优秀的Clickhouse日志查询工具帮助分析日志，为此我们写了一套Clickhouse日志系统贡献给开源社区，并将Clickhouse的日志采集架构的经验做了总结。先上个Clickhouse日志查询界面，让大家感受下石墨最懂前端的后端程序员。,,我们将日志系统分为四个部分：日志采集、日志传输、日志存储、日志管理。,,以下我们将按照这四大部分，阐述其中的架构原理。,Kubernetes容器内日志收集的方式通常有以下三种方案。,以下是三种采集方式的优缺点：,,我们主要采用DaemonSet方式和网络方式采集日志。DaemonSet方式用于ingress、应用日志的采集，网络方式用于大数据日志的采集。以下我们主要介绍下DeamonSet方式的采集方式。,从上面的介绍中可以看到，我们的DaemonSet会有两种方式采集日志类型，一种是标准输出，一种是文件。,引用元乙的描述：虽然使用 Stdout 打印日志是 Docker 官方推荐的方式，但大家需要注意：这个推荐是基于容器只作为简单应用的场景，实际的业务场景中我们还是建议大家尽可能使用文件的方式，主要的原因有以下几点：,从这个描述中，我们可以看出在docker中输出文件再采集到日志中心是一个更好的实践。所有日志采集工具都支持采集文件日志方式，但是我们在配置日志采集规则的时候，发现开源的一些日志采集工具，例如fluentbit、filebeat在DaemonSet部署下采集文件日志是不支持追加例如pod、namespace、container_name、container_id等label信息，并且也无法通过这些label做些定制化的日志采集。,,基于无法追加label信息的原因，我们暂时放弃了DeamonSet部署下文件日志采集方式，采用的是基于DeamonSet部署下标准输出的采集方式。,以下列举了日志目录的基本情况。,,因为我们采集日志是使用的标准输出模式，所以根据上表我们的LogCollector只需要挂载/var/log，/var/lib/docker/containers两个目录。,1）标准输出日志目录,应用的标准输出日志存储在/var/log/containers目录下，文件名是按照K8S日志规范生成的。这里以nginx-ingress的日志作为一个示例。我们通过ls /var/log/containers/ | grep nginx-ingress指令，可以看到nginx-ingress的文件名。,,nginx-ingress-controller-mt2wx_kube-system_nginx-ingress-controller-be3741043eca1621ec4415fd87546b1beb29480ac74ab1cdd9f52003cf4abf0a.log,我们参照K8S日志的规范：/var/log/containers/%{DATA:pod_name}_%{DATA:namespace}_%{GREEDYDATA:container_name}-%{DATA:container_id}.log。可以将nginx-ingress日志解析为：,通过以上的日志解析信息，我们的LogCollector就可以很方便地追加pod、namespace、container_name、container_id的信息。,2）容器信息目录,应用的容器信息存储在/var/lib/docker/containers目录下，目录下的每一个文件夹为容器ID，我们可以通过cat config.v2.json获取应用的docker基本信息。,,1）配置,我们LogCollector采用的是fluent-bit，该工具是cncf旗下的，能够更好地与云原生相结合。通过Mogo系统可以选择Kubernetes集群，很方便地设置fluent-bit configmap的配置规则。,,2）数据结构,fluent-bit的默认采集数据结构,Clickhouse如果使用@timestamp的时候，因为里面有@特殊字符，会处理得有问题。所以我们在处理fluent-bit的采集数据结构，会做一些映射关系，并且规定双下划线为Mogo系统日志索引，避免和业务日志的索引冲突。,例如你的日志记录的是{"id":1}，那么实际fluent-bit采集的日志会是{"_time_":"2022-01-15...","_log_":"{\"id\":1}" 该日志结构会直接写入到kafka中，Mogo系统会根据这两个字段_time_、_log_设置clickhouse中的数据表。,3）采集,如果我们要采集ingress日志，我们需要在input配置里，设置ingress的日志目录，fluent-bit会把ingress日志采集到内存里,,然后我们在filter配置里，将log改写为_log_,,然后我们在ouput配置里，将追加的日志采集时间设置为_time_，设置好日志写入的kafka borkers和kafka topics，那么fluent-bit里内存的日志就会写入到kafka中,,日志写入到Kafka中_log_需要为json，如果你的应用写入的日志不是json，那么你就需要根据fluent-bit的parser文档，调整你的日志写入的数据结构：https://docs.fluentbit.io/manual/pipeline/filters/parser,Kafka主要用于日志传输。上文说到我们使用fluent-bit采集日志的默认数据结构，在下图kafka工具中我们可以看到日志采集的内容。,,在日志采集过程中，会由于不用业务日志字段不一致，解析方式是不一样的。所以我们在日志传输阶段，需要将不同数据结构的日志，创建不同的Clickhouse表，映射到Kafka不同的Topic。这里以ingress为例，那么我们在Clickhouse中需要创建一个ingress_stdout_stream的Kafka引擎表，然后映射到Kafka的ingress-stdout Topic里。,我们会使用三种表，用于存储一种业务类型的日志。,将数据从Kafka采集到Clickhouse的ingress_stdout_stream数据表中。,将数据从ingress_stdout_stream数据表读取出来，_log_根据Mogo配置的索引，提取字段再写入到ingress_stdout结果表里。,存储最终的数据,,_time_字段用于存储fluent-bit采集的时间,_log_字段用于存放原始日志,app_stdout_stream：将数据从Kafka采集到Clickhouse的Kafka引擎表,app_stdout_view：视图表用于存放mogo设置的索引规则,app_stdout：根据app_stdout_view索引解析规则，消费app_stdout_stream里的数据，存放于app_stdout结果表中,,,以上文档描述是针对石墨Kubernetes的日志采集。