采集系统上云(【github社区】数栈是云原生—站式数据中台PaaS)

　　采集系统上云(【github社区】数栈是云原生—站式数据中台PaaS)

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

　　DataStack 是云原生的一站式数据中心 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，这是一个支持多种数据源的出色可视化框架。最常见的是将prometheus的数据可视化。而洛基就是我们今天要讲的主角。这也是grafana的产物，promtail是loki 采集器的官方log。

　　与elk相比，这套解决方案非常轻量级，功能强大且易于使用。另外，在显示上使用grafana，减少视觉框架的引入，在显示终端上的统一也有利于用户。

　　(一） 记录暴发户 loki

　　​

　　Loki 是一个受 Prometheus 启发的水平可扩展、高可用的多租户日志聚合系统。它被设计成具有成本效益且易于操作。它不索引日志的内容，而是为每个日志流设置一组标签。

　　与其他日志聚合系统相比，Loki

　　没有日志的全文索引。通过存储压缩的非结构化日志和仅索引元数据，Loki 更易于操作且运行成本更低。

　　使用与 Prometheus 相同的标签对日志流进行索引和分组，使您能够使用与 Prometheus 相同的标签在指标和日志之间无缝切换。

　　特别适合存储 Kubernetes Pod 日志。Pod 标签等元数据会被自动爬取和索引。

　　Grafana 原生支持（需要 Grafana v6.0 或更高版本）。

　　这是GitHub上对loki的介绍。可以看出这是一个为云原生构建的轻量级日志聚合系统。社区目前非常活跃。而且它采用了类prometheus标签的思路，与grafana连接，进行可视化展示。无论是想法还是使用都非常“云原生”。

　　(二） ‍♂️ 儿子 Promtail

　　promtail 是 loki 采集器 的官方日志，它自己的代码在 loki 项目中。本机支持日志、系统日志、文件和 docker 类型日志。采集器的本质是根据模式找到要为采集的文件，然后像tail一样*敏*感*词*一个文件，然后将写入文件的内容发送到存储端promtail。上述情况也是如此。类型的本质也是文件，但这些类型文件的格式是开放且稳定的规范，promtail可以提前更深入的解析和封装。

　　(三） Promtail 服务发现

　　1、 以采集器的形式查找文件，首先要找出文件在哪里，然后进行采集、标签推送等功能。普通静态类型的日志很容易找到。你可以直接匹配你在配置文件中写的路径信息。例如promtail中的路径是“/var/log/*.log”，表示/var/log目录下的所有文件，以.log结尾的后缀文件可以作为采集@的对象>。采集 k8s 模式登录稍微麻烦一些。

　　首先我们想一想k8s上运行的服务的日志在哪里？

　　所以我们需要在 k8s 容器内挂载 /var/log/pods 作为主机路径，以便 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，将节点的/var/lib/pods目录挂载到容器中，并借助prometheus的服务发现机制动态给日志添加标签，无论是是资源占用。部署和维护的程度和难度都非常低。这也是主流的云原生日志采集范式。

　　​

　　三、数据栈日志实践

　　(一） 堆栈日志要求

　　(二）️主机模式

　　数据栈主机模式日志聚合采用类似于PLG DameonSet的模式。每个主机部署一个promtail，然后将一组服务器端loki和视觉端grafana部署到整个集群。

　　promtail 使用 static_configs 来定义 采集 日志。不过promtail毕竟还太年轻，而且定位偏向云原生，所以对于宿主机的功能并不完善，所以我们做了一些二次开发来满足我们的需求：

　　1、logtail 模式

　　本机 promtail 不支持从文件末尾采集。promtail启动时会推送所有被监控文件的内容，这在云原生中问题不大。

　　在host模式下，如果要监控的日志已经存在并且内容量很大，promtail会从头开始推送文件的内容，这样会导致大量日志被推送到loki中短时间。失败。

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

　　在这个地方，我们进行了二次开发，增加了logtail模式的开关。如果开关为true，则第一次启动promtail时不会从头开始推送日志。

　　2、path 支持多路径

　　原生promtail不支持多路径路径参数，只能写一个表达式，但实际需求可能是同时看业务日志和gc日志。

　　但它们又是属于同一类别的标签。单一路径的匹配不能同时涵盖两者。不更改代码的解决方案是为其编写另一个目标。

　　这既乏味又不利于维护。所以我们在这里也对其进行了二次开发。

　　​

　　(三） 云原生模式

　　传统的云原生模型采用PLG的主流模型。但是，当数据栈作为一个完整的系统交付给企业时，存在很多限制，这会导致demoset模型无法使用。最大的挑战是许可。只能使用一种命名空间权限。挂载 /var/lib/pods

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

　　其实主要的变化就是promtail的使用。这里首先要声明的是，数据栈服务的日志全部输出到文件中。

　　首先是选择是部署在damonset模式还是sidecar模式。演示模式的优点是节省资源，缺点是需要权限。与sidecar模式相比，为了应用更严格的交付条件，我们为采集选择使用sidecar模式。

　　sidecar 模式是在每个服务部署的时候自动添加一个日志容器。容器和服务容器共同挂载一个共同的空数据卷。服务容器将日志写入数据卷，日志容器采集将数据卷下的日志写入。

　　​

　　1、⛳ promtail 如何动态配置数据栈中的标签

　　通过sidecar模式，我们让logContainer和Master Container共享一个日志目录，这样就可以在promtail容器中获取日志文件，但是promtail还是不知道哪些日志到采集，它们的什么标签是。

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

　　Promtail 在 v2.10 中增加了一个新特性，即可以在配置文件中引用环境变量。通过这个特性，我们可以把promtail的path参数写成${LOG_PATH}，然后用服务的logpath作为环境变量的方式来设置，比如LOG_PATH=/var/log/commonlog/*。日志

　　由于我们可以在服务创建时通过环境变量设置路径，所以也可以动态设置标签。那么我们都需要什么维度标签呢？这家不同的公司肯定有不同的维度，但必须遵循的一个原则是可以唯一标识吊舱。大体维度有deployment、podid、node等，这些标签在创建的时候是通过环境变量注入的，而这些环境变量podid是使用k8s的向下api注入的。

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

　　2、⏰如何在数据栈中部署promtail

　　为每个服务添加一个Log Container，手动做起来太麻烦，也不利于维护。最好的方法是将原创服务抽象为注册一个CRD，然后编写k8s算子来list & watch该类型的对象。创建对象时，动态注入一个LogContainer，以及对应的环境变量并挂载。公共目录。

　　因此，当创建 CR 时，promtail 作为 sidecar 注入。并且读取的环境变量是操作者动态设置的环境变量，非常灵活。

　　​

　　四、总结

　　(一） 数据栈日志采集优势

　　(二）✈️未来规划

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

　　​