日志服务支持通过Logtail采集Kubernetes(简称K8S)集群日志,并支持CRD(CustomResourceDefinition)和控制台等方式进行采集配置管理。
为提供更优的扩展性、灵活性,Logtail采集的配置与K8S中的Deploy/Pod配置完全解耦,两者可以一起部署也可以独立部署,具体取决于您的实际应用和业务需求。
下面我们介绍几种典型的配置方式,以便于您在实际应用中进行参考。
前提
- K8S环境中安装好Logtail相关服务组件,若未安装请参考Kubernetes日志采集部署相关组件。
- 假设您对K8S中服务部署已经具备一定基础知识。
注意事项
- K8S集群Logtail组件部署完毕后,会默认创建一个自定义标识的机器分组,后续所有的配置直接应用到该分组即可。
- Logtail容器在K8S中以DaemonSet的模式部署,后续您的集群缩扩容时不需关心。
- 无论是容器的标准输出还是容器文件,均支持
IncludeEnv
和ExcludeEnv
用来过滤指定的容器,推荐使用环境变量的方式进行配置,具体含义请参考容器标准输出和容器内文本文件。 - 不建议使用容器的标准输和容器文件中的
IncludeLabel
和ExcludeLabel
中的label是容器的label,和K8S中的label并不是同一概念。
入门型
作为初次接触日志服务的用户,建议您在第一次部署采集配置时使用该方式:只使用一个配置采集所有容器的stdout。(具体操作细节请参考Kubernetes日志采集入门)
具体方式为:
- 在日志服务控制台Logstore列表单击数据接入向导图标,进入配置流程。
- 单击自建软件中的Docker标准输出,并单击下一步。
- 无需修改基础配置,直接单击下一步,并应用到机器组。
- 后续提示无需关心,一直点击下一步直到确认。
按照以上简单配置方式,您就可以将整个集群中所有容器的标准输出(stdout和stderr)全部采集到一个Logstore中。
同时若您的所有容器中日志文件保存路径均一致,也可以通过一个容器文本文件配置全部采集。
伴随型
若您的集群中每个应用都需独立采集到一个logstore中,您可以使用伴随型的方式来进行日志采集部署:
- 在部署您的业务应用时,为需要采集的容器增加一个特殊环境变量。
- 部署应用同时,也加上对应的CRD配置,其中
IncludeEnv
配置为步骤1的特殊环境变量。
例如,当需要新部署应用app-comment
时,为该容器增加环境变量ALIYUN_LOG_COLLECTION=app-comment
, 在部署脚本(yaml文件)后增加对应的CRD配置,配置中指定IncludeEnv
为ALIYUN_LOG_COLLECTION=app-comment
。
规划型
若您的公司、业务中对于日志管理较为健全,可以使用此种方式进行日志采集的管理:
- 对于需要采集的业务种类、日志形式、日志格式、日志路径等进行提前规划。
- 根据规划创建对应的容器标准输出以及容器文件的采集配置,配置中使用
IncludeEnv
进行特殊环境变量标识。 - 部署业务应用容器时,若该容器需采集若干种日志,则为该容器添加步骤2中对应的特殊环境变量。
- 若有对应新的业务日志或新的类型日志需要接入,则继续步骤2、3的流程。
例如,对于某个电商类的K8S集群,业务类日志规划为:前端访问日志、购物车日志、订单日志、交易日志、评论日志等;系统类日志规划为:kernel日志、Trace日志、Debug日志、Crash监控日志、应用异常日志。
其中对于Debug日志,统一存储在容器的/app/logs/debug/debug.log,配置采集的IncludeEnv
为 ALIYUN_LOG_DEBUG_LOG_COLLECTION=TRUE
;对于Trace日志,统一存储在容器的/app/logs/trace/trace.log,配置采集的IncludeEnv
为 ALIYUN_LOG_TRACE_LOG_COLLECTION=TRUE
....
最终部署服务时,若该容器需要采集Debug、Trace日志,则为其增加环境变量ALIYUN_LOG_DEBUG_LOG_COLLECTION=TRUE
和ALIYUN_LOG_TRACE_LOG_COLLECTION=TRUE
。
混合型
混合型即为充分利用Logtail配置灵活的方式,可使用但并不仅限于以下方式:
- 对于全集群统一采集的配置,不配置
IncludeEnv
,只配置ExcludeEnv
,如有特殊需求不被采集的容器可通过添加对应的环境变量排除采集。 - 对于类型比较确定的日志,可使用规划型的方式,提前创建配置,部署服务时通过为容器添加环境变量进行关联
- 对于比较特殊的应用日志,可使用伴随型的方式,只对该容器进行采集。
类型对比
下述是各种配置模式的对比,其中简单型最容易上手,只推荐入门的用户使用;伴随型灵活性较高,但此种方式配置数过多且对应用日志没有约束;规划型的配置数较少,且各类应用日志都遵循规范输出,日志格式化程度高,最终可分析性较强,目前阿里云中很多产品内部都基于此方式进行日志采集和分析,强烈建议使用;混合型继承了伴随型和规划型的优劣势,若您目前系统很难完成规划型改造,建议使用混合型逐批向规划型迁移。
简单型 |
伴随型 |
规划型 |
混合型 |
|
配置复杂性 |
极低 |
较高 |
较低 |
较高 |
配置数 |
1/2个 |
取决于应用数 |
取决于日志分类数 |
取决于日志分类数+特殊应用数 |
灵活性 |
极低 |
较高 |
一般 |
高 |
日志规范性 |
无要求 |
无要求 |
要求各类应用按规范打日志 |
部分日志需遵循规范 |
可分析性 |
极低 |
一般 |
高 |
较高 |
推荐指数 |
1星 |
3星 |
5星 |
4星 |