本文整理自：浅谈云原生系统日志收集在数栈的实践
数栈是云原生—站式数据中台PaaS，我们在github上有一个有趣的开源项目：FlinkX，欢迎给我们点个star！star！star！
https://github.com/DTStack/flinkx
FlinkX是一个基于Flink的批流统一的数据同步工具，既可以采集静态的数据，比如MySQL，HDFS等，也可以采集实时变化的数据，比如MySQL binlog，Kafka等，是全域、异构、批流一体的数据同步引擎，大家如果有兴趣，欢迎来github社区找我们玩~
一、常规打法ELK
谈到日志收集，估计大家第一个想到的就是ELK这个比较成熟的方案，如果是特别针对云原生上的，那么将采集器稍微变一下为 Fluentd 组成 EFK 即可。以上两种方案其实没有本质上的区别，采集器换了换而已。最终存储、查询等等采用的还是 elasticsearch 这一套。
elasticsearch确实功能丰富、非常强大，但是代价也是极其昂贵的，elasticsearch 采用全文索引的方式，对存储以及内存的要求比较高，而这些代价换来的功能对于日常日志管理来说却是不常用的。这些缺点在主机模式下其实是可以容忍的，但在云原生模式下就显得比较臃肿了。
二、不讲武德PLG
PLG 是 promtail+loki+grafana 的合称，这是一套非常适合云原生下日志的采集方案。grafana 大家会比较熟悉，一个非常棒的可视化的框架，支持多种数据源。最常见的就是将prometheus的数据进行可视化展示。而loki就是今天我们要谈的主角，这个也是grafana 家的产品，promtail 则是 loki 的官方日志采集器。
与elk相比这一套方案非常轻量级，功能实用，使用起来简单易用，并且在展示上采用 grafana 减少引入可视化的框架，展示终端上的统一也有利于用户的使用。
（一） 日志新贵loki
Loki是受Prometheus启发的水平可扩展，高度可用的多租户日志聚合系统。它的设计具有很高的成本效益，并且易于操作。它不索引日志的内容，而是为每个日志流设置一组标签。
与其他日志聚合系统相比，Loki
这段是loki 在 GitHub 上的介绍，可以看出这是一款为云原生而打造的轻量级日志聚合系统。目前社区非常活跃。而且采用 prometheus 类似的标签的思想，与 grafana 打通进行可视化展示，无论是思想还是用法都非常的“云原生”。
（二） ♂️ 亲儿子Promtail
promtail 是 loki 的官方日志采集器，本身代码就在 loki 项目中。原生支持journal、syslog、file、docker类型的日志。采集器的本质无非都是根据模式找到要采集的文件，然后对着个文件进行类似tail的监控，再把写入文件的内容发送给存储端promtail 也是这样，上面这些类型的本质也都是文件，只不过这些类型的文件的格式是公开稳定的规范，promtail 可以预先对其进行进行更深解析与封装。
（三） Promtail 服务发现
1、 找到文件作为一个采集器，其第一步自然是要找到文件在哪里，然后才能做下面的收集与打标签推送等功能。普通静态类型的日志是很好发现的，直接将你在配置文件中写的路径信息进行匹配即可，比如 promtail 中path为 "/var/log/*.log"即将 /var/log目录下所有的以.log 结尾的后缀文件作为要采集的对象即可。而要采集 k8s 模式内的日志就稍显麻烦。
首先我们想一下k8s 上跑的服务的日志到底是在哪里？
- 文件类型的日志
这种自然是还在你自定义的路径上，如果这个路径目录没有被挂载出来，那么就在容器内部，如果挂载到了宿主机或者 pv 内，那么在 宿主机与 pv 内也是可见的，这种类型的日志 promtail 是无法动态发现的，必须手工设置进去。 - 标准输出的日志
这类日志其实是k8s推荐的日志输出方式，这类日志其实是我们日常用 kubectl log 看到的日志，这类日志存储路径在宿主机遵循/var/log/pods/
{namespace}_/{pod_id}_UUID/{container_name}/*.log这种格式
所以我们需要将这/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 的服务发现机制动态的为日志加上标签，无论是资源的占用程度还是部署维护难度都是非常低。这也是主流的云原生日志采集范式。
三、数栈日志实践
（一） 数栈日志需求
- 全局 grep
根据关键字，搜索系统中所有出现的地方 - 快速定位日志
根据机器名、ip、服务名等条件快速定位日志 - 主机与云原生统一技术栈
减少使用学习成本，降低系统复杂性
（二） ️ 主机模式
数栈主机模式日志聚合采用类似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 动态设置的环境变量，灵活度非常高。
四、总结
（一） 数栈日志收集优势
- 一套日志聚合分析框架解决主机与云原生两种场景，减少了系统复杂度
- 日志可视化采用 grafana，可视化效果较好，而且grafana 与 prometheus已经是云原生监控的是事实上的标准了，开发运维都比较熟悉，减少了学习成本
- loki 查询语法简单，但是功能强大
- 与 ELK 相比，更加轻量级
（二）✈️未来规划
- 当前使用 sidecar 模式，资源占用较多，后续考虑在进一步优化
- loki 分布式部署优化
最后给大家分享一下数栈当前日志模块可视化的效果，是不是超级酷炫？