采集系统上云(【开源】云原生——站式数据中台PaaS )

　　采集系统上云(【开源】云原生——站式数据中台PaaS

)

　　本文整理自：浅谈云原生系统日志采集在数据栈中的实践

　　Digital Stack是一个云原生站数据平台PaaS。我们在github上有一个有趣的开源项目：FlinkX，欢迎给我们点star！星星！星星！

　　FlinkX 是基于 Flink 的批流统一数据同步工具。可以是采集静态数据，如MySQL、HDFS等，也可以是采集实时变化的数据，如MySQL binlog、Kafka等，全局不同。集成构建和批处理流的数据同步引擎。有兴趣的请到github社区来和我们一起玩吧~

　　一、正常玩ELK

　　说到日志采集，估计大家第一个想到的就是ELK，比较成熟的方案。如果是专门针对云原生的，那就把采集器稍微改成Fluentd就可以形成EFK了。其实以上两种方案没有本质区别，只是采集器变了。最终的存储、查询等还是elasticsearch。

　　Elasticsearch 确实功能丰富，功能强大，但也极其昂贵。Elasticsearch 使用全文索引，对存储和内存要求比较高，而换取这些成本的功能在日常日志管理中并不常用。这些缺点在主机模式下其实还可以接受，但是在云原生模式下就显得臃肿了。

　　二、不说武德PLG

　　PLG是promtail+loki+grafana的统称，是很适合云原生日志的采集解决方案。每个人都会熟悉 grafana，这是一个支持多数据源的出色可视化框架。最常见的是可视化普罗米修斯数据。而洛基就是我们今天要说的主角。这也是grafana家族的产物，promtail是loki采集器的官方日志。

　　与elk相比，这套方案非常轻量、实用、简单易用，并且在展示中使用grafana减少了可视化框架的引入，在展示终端上的统一也对用户有利。

　　(一）log 暴发户 loki

　　Loki is a horizontally scalable and highly available multi-tenant log aggregation system inspired by Prometheus. Its design is cost-effective and easy to operate. It does not index the content of the log, but sets a set of tags for each log stream.

　　Compared with other log aggregation systems, Loki

　　The log is not indexed in full text. By storing compressed, unstructured logs and indexing only metadata, Loki is easier to operate and lower running costs.

　　The log stream is indexed and grouped using the same tags as Prometheus, allowing you to seamlessly switch between metrics and logs using the same tags as Prometheus.

　　Especially suitable for storing Kubernetes Pod logs. Metadata such as Pod tags are automatically crawled and indexed.

　　Grafana native support (Grafana v6.0 or above is required).

　　This paragraph is an introduction by loki on GitHub. It can be seen that this is a lightweight log aggregation system built for cloud native. The community is currently very active. Moreover, using prometheus' similar labeling ideas, it is connected with grafana for visual display, both in thinking and usage are very "cloud native".

　　(二） ‍♂️ Promtail son

　　Promtail is the official log of loki 采集器, and its code is in the loki project. Natively supports journal, syslog, file, docker type logs. The essence of 采集器 is nothing more than finding the file for 采集 according to the pattern, then monitoring the file similar to tail, and then sending the content of the written file to the storage promtail. The same is true of the above types. They are all files, but the format of these types of files is an open and stable specification, and promtail can perform deeper analysis and encapsulation in advance.

　　(三） Promtail Service Discovery

　　1、 找到文件作为一个采集器，其第一步自然是要找到文件在哪里，然后才能做下面的采集与打标签推送等功能。普通静态类型的日志是很好发现的，直接将你在配置文件中写的路径信息进行匹配即可，比如 promtail 中path为 "/var/log/*.log"即将 /var/log目录下所有的以.log 结尾的后缀文件作为要采集的对象即可。而要采集 k8s 模式内的日志就稍显麻烦。

　　首先我们想一下k8s 上跑的服务的日志到底是在哪里？

　　所以我们需要将这/var/log/pods 作为hostpath 挂载进 k8s 的容器内部，才能让 promtail 访问到这些日志。

　　2、 打上标签

　　日志promtail可以访问到了，但是还有一个问题还是如何为区分这些日志，loki采用类似prometheus的思想，将数据打上标签。也就是将日志打上pod的标签，那么单单凭借这个路径自然是无法知道该pod上有哪些标签信息的。这里就需要用到服务发现了。

　　promtail的服务发现是直接采用的prometheus的服务发现做的。熟悉prometheus 的同学肯定配置过prometheus的服务发现的配置，kubernetes_sd_configs与relabel_configs。

　　这里promtail直接引入prometheus的代码，与prometheus不同的是prometheus请求的资源对对象比较多，node、ingress、pod、deployment 等等都有，最终拼接的是metric的请求url，而promtail请求的对象为pod，并且过滤掉了不在该主机上的 pod。

　　拿到该主机的pod的信息后，再根据namespace， pod 的 id 拼接路径，由于这个目录已经挂载进去容器了，那么promtail 就可以关联起容器的标签与容器的日志了。剩下的就是监控与推送了。

　　（四） PLG 最佳实践

　　loki 官方推荐的最佳实践为采用 DamonSet部署 promtail 的方式，将 node 的 /var/lib/pods目录挂载进容器内部，借助prometheus 的服务发现机制动态的为日志加上标签，无论是资源的占用程度还是部署维护难度都是非常低。这也是主流的云原生日志采集范式。

　　三、数栈日志实践

　　（一） 数栈日志需求

　　（二） ️ 主机模式

　　数栈主机模式日志聚合采用类似PLG DameonSet 的模式。每台主机部署一台 promtail，然后整个集群部署一套服务端 loki 与可视化端grafana。

　　promtail 采用static_configs定义采集的日志。但是promtail 毕竟还是太年轻了，定位偏向于云原生，所以针对主机功能还不够完善，因此我们做了一些二次开发满足我们的需求：

　　1、logtail 模式

　　原生 promtail 并不支持从文件尾部开始采集，当 promtail 启动后，会将监控的所有文件的内容都进行推送，这样的情况在云原生并没有太大问题.

　　主机模式下如果要监控的日志已经存在并且有大量的内容的话，promtail 启动会将文件的内容从头开始推送，短时间内造成大量的日志往loki推送，很大的概率会被 loki 限流导致推送失败。

　　所以最好的方式就是有类似 filebeat 的 logtail 的模式，及只推送服务启动后的文件写入的日志。

　　这个地方我们对此作了二次开发，增加一个logtail 模式的开关，如果该开关为 true，这第一次启动 promtail 的时候将不会从头推送日志。

　　2、path 支持多路径

　　原生 promtail 不支持多路径 path 参数只能写一个表达式，但是现实的需求可能是既要看业务的日志还要看 gc 的日志。

　　但是他们又是属于同一类别的标签。单个path的匹配无法涵盖其两个，不改代码的解决方法就是再为其写一个 target。

　　这样做繁琐且不利于维护。所以我们这里也对其做了二次开发

　　（三） 云原生模式

　　传统的云原生模式采用 PLG 的主流模式就好了，但是数栈作为一整套系统对企业交付的时候有诸多限制会导致demoset模式并不可用，最大的挑战是权限，只有一个 namespace 的权限，不能挂载/var/lib/pods

　　在这种情况下如何使用 PLG呢？

　　其实主要变化的地方在于promtail的使用，这里首先要声明的一点是，数栈的服务的日志都为文件输出。

　　首先是选择damonset 模式部署还是sidecar模式部署，demonset模式的优点是节省资源，缺点是权限有要求。sidecar模式与之相反，为了适用更严格的交付条件，我们选择采用 sidecar 的模式进行采集。

　　sidecar 模式就是为当每个服务进行部署的时候就自动为其添加一个log容器，该容器与服务容器共同挂载一个共同的空的数据卷，服务容器将日志写入该数据卷中，log容器对数据卷下的日志进行采集。

　　1、⛳ promtail 在数栈如何动态配置标签

　　通过sidecar的模式我们让log Container与Master Container共享一个日志目录，这样就promtail容器内就可以拿到了日志的文件，但是promtail还不知道要采集哪些日志，以及他的标签是什么。

　　因为你可能只想采集.log的日志，也可能只想采集.json的日志，或者都有的服务这个配置可能是不同的，所以也不能写死，那如何解决这个问题呢？

　　promtail 在 v2.10中新增加了一个feature ，就是可以在配置文件中引用环境变量，通过这个特性我们可以将promtail的path参数写成${LOG_PATH}，然后将服务的logpath以环境变量的方式设置进去比如LOG_PATH=/var/log/commonlog/*.log

　　既然我们可以通过环境变量的方式在服务创建的时候设置path，那么标签我们也可以动态的设置进去。那么我们都需什么维度的标签呢？这个不同的公司肯定有不同的维度，但是必须遵循的一个原则就是可以唯一确定该pod。一般的维度有deployment、podid、node等。这些标签在创建的时候就通过环境变量注入进去，而podid 这些环境变量利用的是k8s 的 downward api 的方式注入的。

　　注意：这里不可用使用 promtail 的服务发现机制配置标签，因为promtail 的服务发现的原理是请求 APIServer 获取所有pod 的标签。然后利用路径进行匹配，将标签与日志关联。在没有挂载宿主机/var/log/pods目录到promtail 时，即使拿到了标签也无法与日志进行关联。

　　2、⏰ promtail 在数栈如何部署

　　为每个服务增加一个Log Container如果手工操作的话实在是太繁琐了，而且不利于维护。最好的方式就将原本的服务抽象为是注册一个CRD，然后编写 k8s operator通过list&watch该类型的对象，在该对象创建的时候，动态的注入一个LogContainer，以及相应的环境变量和为其挂载共同目录。

　　这样当该CR创建的时候，promtail就作为sidecar注入了其中。并且读到的环境变量就是operator 动态设置的环境变量，灵活度非常高。

　　四、总结

　　（一） 数栈日志采集优势

　　（二）✈️未来规划

　　最后给大家分享一下数栈当前日志模块可视化的效果，是不是超级酷炫？