【生产环境K8S从搭建到运维的实录（五）】K8S环境日志采集方案
1.前述
今天想跟大家聊一聊在k8s环境里关于日志采集的解决方案。主要介绍一下我们的系统都有哪些日志文件，以及各种日志文件是如何被采集和应用的。
2.日志种类
这里的分类是按照我们现有生产环境所处理的log进行划分，按照集群划分，可以分为以下3种：
- K8S集群log
- PKS集群log
- 监控机器log
按照业务种类划分，又可以分为以下2种：
- 业务log
- 系统log
3.Log Systerm构成
下面构成图中关于PKS Cluster，K8S Cluster，Monitor System的详细介绍请参照本系列文章的其他章节。
3-1 日志收集
-
PKS集群日志收集备份
PKS集群中所有服务器的系统log都是通过syslog服务从集群中将log转送到监控服务器所挂载的NAS中。
-
K8S集群日志收集备份
K8S集群，也就是所谓Node节点上的log分为两种：系统log和业务log。
系统log和PKS集群一样，也是通过syslog服务进行转送，将Node节点上的系统log转送到监控服务器挂载的NAS中。
业务log则是通过fluent-bit服务进行收集，然后转送到监控服务器中，再由监控服务器上的fluentd服务进行聚合处理。最终的log文件存贮在NAS中。这里我们需要注意的是，最终存储在NAS中的log文件并不是K8S集群中的原始文件，是经过fluent-bit和fluentd加工处理过得log文件。
-
监控服务器日志收集备份
监控服务器是独立于K8S集群和PKS集群的虚拟服务器，这台机器上的log收集备份，通过脚本来实现，我们设定了Crontab，定期执行，最终也是备份到NAS里。
3-2 fluent-bit VS fluentd
上面我们提到K8S集群各个节点上的业务log是通过fluent-bit和fluentd来进行收集和聚合的，那么我们来简单介绍一下这两个服务。
fluent bit是一个用c写成的插件式、轻量级、多平台开源日志收集工具。它允许从不同的源收集数据并发送到多个目的地。完全兼容docker和kubernetes生态环境。概括来说，fluent-bit是一个简单日志收集，处理工具。而fluentd与fluent-bit类似，也是一个日志收集，处理工具，但是相较fluent-bit来说，fluentd有更强大的聚合功能。这里我列出它们的对比进行参考。
| fluentd | fluent-bit | |
|---|---|---|
| 范围 | 容器/服务器 | 容器/服务器 |
| 语言 | C和Ruby | C |
| 大小 | 约40MB | 约450KB |
| 性能 | 高性能 | 高性能 |
| 依赖关系 | 作为Ruby Gem构建，主要依赖gems | 除了一些安装编译插件（GCC、CMAKE）其它零依赖。 |
| 插件支持 | 超过650个可用插件 | 大约35个可用插件 |
| 许可证 | Apache许可证2.0版 | Apache许可证2.0版 |
3-3 日志监控
日志采集最关键的一个作用就是用于监控，关于监控，我们有专门的章节进行说明，这里我只简单的介绍一下日志采集与监控的设计概要。K8S集群中每一个Node节点上都有运行着一个flunet-bit服务，用来采集log信息。监控服务器上的fluntd将fluent-bit采集到的log信息进行聚合，过滤。prometheus对fluntd处理之后的信息进行监控，最终通过grafana将监控信息可视化展示。这里需要说明的一点，K8S集群中fluent-bit是以Pod形式存在，而监控服务器中的fluentd，prometheus，grafana都是容器形式运行。
4.结束语
用来进行日志采集分析的工具以及解决方案有很多，但是不论用什么方法进行采集，日志删除也是需要考虑的一个问题。如果不定期删除，Node节点会因为磁盘空间被日志文件占满而崩溃。我们的环境在运行过程中就遇到过这样的问题，因为一些业务log没有及时被删除，而导致运行在Node节点上的其他Pod无法正常工作，其中就包括flunt-bit，因此log也无法正常被收集。
作者：rm * 小组
日期：2020/9/20