背景
随着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的状态都是比较难观测的。文章来源：https://www.toymoban.com/news/detail-796289.html
- 环境变量配置之后，无论配置的是否正确，都不会影响业务容器的正常运行。但是logtail是否读到了环境变量里的配置并且进行了正确的处理，这个用户只能看到最终的结果。如果配置错了，用户也不能拿到及时的反馈，只能看到SLS控制台上，logstore没有创建出来或者采集配置没有创建出来，中间到底哪一个步骤报错了，用户也无法感知。
- 一个CR配置之后，从K8s的角度来看，只能看到CR对象创建成功了。但是CRD对象创建成功之后，alibaba-log-controller内的处理流程，对于用户来讲，就像黑盒一样。如果出现异常，用户并不清楚究竟是中间哪一步出了问题。
基于以上的问题，SLS针对Logtail本身以及Logtail的管控组件alibaba-log-controller，采用K8s事件的方式，将处理流程中的关键事件透出，从而让用户能够更清楚的感知其中发生的异常。文章来源地址https://www.toymoban.com/news/detail-796289.html
Logtail事件监控实战
限制说明
- alibaba-log-controller版本大于等于0.3.2
- logtail版本大于等于1.1.2
- logtail中目前涵盖的事件
- 创建project、创建logstore、创建采集配置
- alibaba-log-controller中涵盖的事件
- 创建project、创建logstore、创建采集配置、创建索引、创建ingress日志中心、checkpoint写入
到了这里，关于K8s 场景下 Logtail 组件可观测方案升级-Logtail 事件监控发布的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
