解密:优采云采集器

　　解密:优采云采集器

　　优采云采集器观看人数已达991.5K。如需查询本站相关重量信息，可点击“爱站数据”“Chinaz数据”进入；以目前的网站数据参考，建议大家参考爱站的数据，更多网站价值评价因素如：优采云采集器访问速度、搜索引擎收录和索引量、用户体验等；当然，要评价一个网站的价值，最重要的是满足自己的需求和需要。一些确切的数据需要找优采云采集器的站长协商提供。比如站内IP、PV、跳出率等！

　　总结归纳:浅谈云原生系统日志收集在数栈的实践

　　‍‍‍

　　1.经常玩ELK

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

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

　　二、不谈武德PLG

　　PLG是promtail+loki+grafana的统称，是一个非常适合云原生日志的采集方案。您将熟悉 grafana，这是一个支持多种数据源的出色可视化框架。最常见的是将prometheus的数据可视化。而洛基就是我们今天要讲的主角。这也是grafana的产物，promtail是loki 采集器的官方log。

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

　　(1) 登录新贵loki

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

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

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

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

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

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

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

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

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

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

　　所以我们需要在 k8s 容器内挂载 /var/log/pods 作为主机路径，以便 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，过滤掉不在那个上面的pod主持人。

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

　　（4）PLG最佳实践loki官方推荐的最佳实践是使用DamonSet部署promtail，将节点的/var/lib/pods目录挂载到容器中，利用prometheus的服务发现机制动态添加日志。标签在资源占用和部署维护难度方面非常低。这也是主流的云原生日志采集范式。

　　3.数据栈日志实践

　　(1) 数据栈日志要求

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

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

　　1.logtail模式

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

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

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

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

　　2、路径支持多路径

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

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

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

　　（3）云原生模型传统的云原生模型采用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/*.log

　　由于我们可以在服务创建时通过环境变量设置路径，所以也可以动态设置标签。那么我们都需要什么维度标签呢？这家不同的公司肯定有不同的维度，但必须遵循的一个原则是可以唯一标识吊舱。大体维度有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 注入。并且读取的环境变量是操作者动态设置的环境变量，非常灵活。

　　4.总结

　　（一）数据栈日志采集的优势

　　(2) ✈️ 未来规划

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

　　‍

　　‍

　　更多技术交流方式

　　想进行面对面的技术交流？想及时参加现场活动吗？扫码加入钉钉群“袋鼠云开源框架技术交流群”（群号：30537511）

　　想体验更多数据栈开源项目？可以在 Github 社区搜索“FlinkX”开源项目

　　FlinkX 开源项目地址：