【github社区】数栈是云原生—站式数据中台PaaS

　　【github社区】数栈是云原生—站式数据中台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 upstart loki

　　

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

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

　　不要对日志执行全文索引。通过存储压缩的非结构化日志和仅索引元数据，Loki 更易于操作并降低运行成本。

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

　　特别适合存储 Kubernetes Pod 日志。 Pod 标签等元数据将被自动抓取并编入索引。

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

　　这一段是loki在GitHub上的介绍。可以看出这是一个为云原生打造的轻量级日志聚合系统。社区目前非常活跃。并且使用prometheus类似的标注思路，用grafana进行视觉展示，无论是思想还是用法都非常“云原生”。

　　(二）‍♂️儿子Promtail

　　promtail 是 loki采集器 的官方日志，其代码在 loki 项目中。本机支持日志、系统日志、文件、docker 类型的日志。 采集器的本质无非就是按照pattern为采集寻找文件，然后*敏*感*词*类似tail的文件，然后将写入的文件内容发送到存储promtail。上述类型也是如此。它们都是文件，但这些类型文件的格式是开放稳定的规范，promtail可以提前进行更深入的分析和封装。

　　(三）Promtail 服务发现

　　1、 找一个文件作为采集器，第一步自然是找到文件在哪里，然后就可以做下面的采集、标记和推送功能了。普通的静态日志很容易找到。只需匹配您在配置文件中写入的路径信息即可。比如promtail中的路径是“/var/log/*.log”，即/var/log目录下的所有以.log结尾的后缀文件都可以作为采集的对象。 采集k8s模式登录稍微麻烦。

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

　　所以我们需要将这个 /var/log/pods 作为主机路径挂载到 k8s 容器中，以便 promtail 可以访问这些日志。

　　2、 标记

　　日志promtail可以访问，但是如何区分这些日志还是个问题。 Loki 使用类似的普罗米修斯思想来标记数据。也就是日志是用pod打上了标签的，所以单靠这条路径自然是不可能知道pod上是什么标签信息的。这里需要用到服务发现。

　　promtail的服务发现是由prometheus的服务发现直接完成的。熟悉prometheus的同学一定配置过prometheus的服务发现配置，kubernetes_sd_configs和relabel_configs。

　　这里promtail直接介绍了prometheus的代码。与prometheus的区别在于prometheus为对象请求更多的资源，比如node、ingress、pod、deployment等，最后拼接的是metric的请求url，而promtail请求的对象是一个pod，而没有on的pods主机被过滤掉。

　　得到宿主机的pod信息后，根据namespace和pod id拼接路径。既然这个目录已经挂载到容器中，那么promtail就可以将容器标签与容器日志关联起来。剩下的就是监控和推送。

　　(四）PLG 最佳实践

　　loki 官方推荐的最佳实践是使用 DamonSet 部署 promtail，将节点的 /var/lib/pods 目录挂载到容器中，并使用 prometheus 的服务发现机制动态标记日志，无论是两者的程度资源占用和部署维护难度都非常低。这也是主流的云原生日志采集范式。

　　

　　三、数字栈日志实践

　　(一）数据栈日志需求

　　(二）️主机模式

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

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

　　1、logtail 模式

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

　　在host模式下，如果要监控的日志已经存在并且内容量很大，promtail会从头开始推送文件内容，导致大量日志被推送到loki中很短的时间，而且很有可能会被洛基限制住。流导致推送失败。

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

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

　　2、path 支持多路径

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

　　但它们是属于同一类别的标签。单条路径的匹配无法覆盖两者。不改变代码的解决方案是为它编写另一个目标。

　　这样很麻烦，不利于维护。所以我们也在这里做了二次开发

　　

　　(三）云原生模式

　　传统的云原生模型采用了主流的PLG模型，但是作为一整套系统，数据栈在交付给企业的时候有很多限制，导致demoset模型不可用。最大的挑战是权威。只有一个命名空间。权限，/var/lib/pods 不能挂载

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

　　其实主要的变化在于promtail的使用。这里首先要说明的是，数据栈服务的日志是作为文件输出的。

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

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

　　

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

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

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

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