K8s 场景下 Logtail 组件可观测方案升级-Logtail 事件监控发布

背景

随着K8s和云的普及，越来越多的公司将业务系统部署到云上，并且使用K8s来部署应用。Logtail是SLS提供的日志采集Agent，能够非常好的适应K8s下各种场景的日志采集，支持通过DaemonSet方式和Sidecar方式采集Kubernetes集群的容器标准输出或者文件日志。Logtail作为一个K8s场景下非常重要一个组件，其自身运行状态需要有更好的可观测方案。

K8s中Logtail管控原理

K8s场景下，除了控制台管控之外，Logtail还提供了环境变量和CRD两种配置方式，用来配置容器日志采集。

环境变量方式

环境变量的配置方式，参考文档

环境变量方式管控原理：

• Logtail会去扫描所有的容器信息，并获取容器中的环境变量信息
• 过滤其中包含aliyun_logs_前缀的字段，然后组合成采集配置信息，Logtail同时会用改环境变量作为采集配置中容器过滤的条件
• Logtail端收到采集配置的变化后，会调整本地的采集配置，从而实现整个控制流程的闭环。

CRD方式

CRD方式创建采集配置流程，参考文档。

CRD配置原理如上图所示：

• K8S内部会注册自定义资源（CRD，CustomResourceDefinition）AliyunLogConfig，并部署alibaba-log-controller
• CR对象创建/变化/删除之后，alibaba-log-controller会监听到CR对象的变化，从而对CR对象中指定的logstore、采集配置进行相应的操作
• Logtail端收到采集配置的变化后，会调整本地的采集配置，从而实现整个控制流程的闭环。

无论是环境变量的配置方式，还是CRD的配置方式，Logtail的状态都是比较难观测的。

• 环境变量配置之后，无论配置的是否正确，都不会影响业务容器的正常运行。但是logtail是否读到了环境变量里的配置并且进行了正确的处理，这个用户只能看到最终的结果。如果配置错了，用户也不能拿到及时的反馈，只能看到SLS控制台上，logstore没有创建出来或者采集配置没有创建出来，中间到底哪一个步骤报错了，用户也无法感知。
• 一个CR配置之后，从K8s的角度来看，只能看到CR对象创建成功了。但是CRD对象创建成功之后，alibaba-log-controller内的处理流程，对于用户来讲，就像黑盒一样。如果出现异常，用户并不清楚究竟是中间哪一步出了问题。

基于以上的问题，SLS针对Logtail本身以及Logtail的管控组件alibaba-log-controller，采用K8s事件的方式，将处理流程中的关键事件透出，从而让用户能够更清楚的感知其中发生的异常。

Logtail事件监控实战

限制说明

• alibaba-log-controller版本大于等于0.3.2
• logtail版本大于等于1.1.2
• logtail中目前涵盖的事件
• 创建project、创建logstore、创建采集配置
• alibaba-log-controller中涵盖的事件
• 创建project、创建logstore、创建采集配置、创建索引、创建ingress日志中心、checkpoint写入