Kubernets日志采集配置模式介绍与对比

日志服务支持通过Logtail采集Kubernetes(简称K8S)集群日志,并支持CRD(CustomResourceDefinition)和控制台等方式进行采集配置管理。


为提供更优的扩展性、灵活性,Logtail采集的配置与K8S中的Deploy/Pod配置完全解耦,两者可以一起部署也可以独立部署,具体取决于您的实际应用和业务需求。


下面我们介绍几种典型的配置方式,以便于您在实际应用中进行参考。


前提


  1. K8S环境中安装好Logtail相关服务组件,若未安装请参考Kubernetes日志采集部署相关组件。
  2. 假设您对K8S中服务部署已经具备一定基础知识。


注意事项


  1. K8S集群Logtail组件部署完毕后,会默认创建一个自定义标识的机器分组,后续所有的配置直接应用到该分组即可。
  2. Logtail容器在K8S中以DaemonSet的模式部署,后续您的集群缩扩容时不需关心。
  3. 无论是容器的标准输出还是容器文件,均支持IncludeEnvExcludeEnv用来过滤指定的容器,推荐使用环境变量的方式进行配置,具体含义请参考容器标准输出容器内文本文件
  4. 不建议使用容器的标准输和容器文件中的IncludeLabelExcludeLabel中的label是容器的label,和K8S中的label并不是同一概念。


入门型


Kubernets日志采集配置模式介绍与对比


作为初次接触日志服务的用户,建议您在第一次部署采集配置时使用该方式:只使用一个配置采集所有容器的stdout。(具体操作细节请参考Kubernetes日志采集入门


具体方式为:


  1. 在日志服务控制台Logstore列表单击数据接入向导图标,进入配置流程。
  2. 单击自建软件中的Docker标准输出,并单击下一步。
  3. 无需修改基础配置,直接单击下一步,并应用到机器组。
  4. 后续提示无需关心,一直点击下一步直到确认。


按照以上简单配置方式,您就可以将整个集群中所有容器的标准输出(stdout和stderr)全部采集到一个Logstore中。


同时若您的所有容器中日志文件保存路径均一致,也可以通过一个容器文本文件配置全部采集。


伴随型


Kubernets日志采集配置模式介绍与对比


若您的集群中每个应用都需独立采集到一个logstore中,您可以使用伴随型的方式来进行日志采集部署:


  1. 在部署您的业务应用时,为需要采集的容器增加一个特殊环境变量。
  2. 部署应用同时,也加上对应的CRD配置,其中IncludeEnv配置为步骤1的特殊环境变量。


例如,当需要新部署应用app-comment时,为该容器增加环境变量ALIYUN_LOG_COLLECTION=app-comment, 在部署脚本(yaml文件)后增加对应的CRD配置,配置中指定IncludeEnvALIYUN_LOG_COLLECTION=app-comment


规划型


Kubernets日志采集配置模式介绍与对比


若您的公司、业务中对于日志管理较为健全,可以使用此种方式进行日志采集的管理:


  1. 对于需要采集的业务种类、日志形式、日志格式、日志路径等进行提前规划。
  2. 根据规划创建对应的容器标准输出以及容器文件的采集配置,配置中使用IncludeEnv进行特殊环境变量标识。
  3. 部署业务应用容器时,若该容器需采集若干种日志,则为该容器添加步骤2中对应的特殊环境变量。
  4. 若有对应新的业务日志或新的类型日志需要接入,则继续步骤2、3的流程。


例如,对于某个电商类的K8S集群,业务类日志规划为:前端访问日志、购物车日志、订单日志、交易日志、评论日志等;系统类日志规划为:kernel日志、Trace日志、Debug日志、Crash监控日志、应用异常日志。


其中对于Debug日志,统一存储在容器的/app/logs/debug/debug.log,配置采集的IncludeEnvALIYUN_LOG_DEBUG_LOG_COLLECTION=TRUE;对于Trace日志,统一存储在容器的/app/logs/trace/trace.log,配置采集的IncludeEnvALIYUN_LOG_TRACE_LOG_COLLECTION=TRUE....


最终部署服务时,若该容器需要采集Debug、Trace日志,则为其增加环境变量ALIYUN_LOG_DEBUG_LOG_COLLECTION=TRUEALIYUN_LOG_TRACE_LOG_COLLECTION=TRUE


混合型


Kubernets日志采集配置模式介绍与对比


混合型即为充分利用Logtail配置灵活的方式,可使用但并不仅限于以下方式:


  1. 对于全集群统一采集的配置,不配置IncludeEnv,只配置ExcludeEnv,如有特殊需求不被采集的容器可通过添加对应的环境变量排除采集。
  2. 对于类型比较确定的日志,可使用规划型的方式,提前创建配置,部署服务时通过为容器添加环境变量进行关联
  3. 对于比较特殊的应用日志,可使用伴随型的方式,只对该容器进行采集。


类型对比


下述是各种配置模式的对比,其中简单型最容易上手,只推荐入门的用户使用;伴随型灵活性较高,但此种方式配置数过多且对应用日志没有约束;规划型的配置数较少,且各类应用日志都遵循规范输出,日志格式化程度高,最终可分析性较强,目前阿里云中很多产品内部都基于此方式进行日志采集和分析,强烈建议使用;混合型继承了伴随型和规划型的优劣势,若您目前系统很难完成规划型改造,建议使用混合型逐批向规划型迁移。

简单型

伴随型

规划型

混合型

配置复杂性

极低

较高

较低

较高

配置数

1/2个

取决于应用数

取决于日志分类数

取决于日志分类数+特殊应用数

灵活性

极低

较高

一般

日志规范性

无要求

无要求

要求各类应用按规范打日志

部分日志需遵循规范

可分析性

极低

一般

较高

推荐指数

1星

3星

5星

4星


相关帮助文档参考


上一篇:JAVA图形操作中FPS的计算(附带随机生成乱数球体用例)


下一篇:《Linux内核设计的艺术:图解Linux操作系统架构设计与实现原理》——2.9 初始化进程0