1. 采集目标多：需要采集宿主机日志、容器内日志、容器stdout。针对每种数据源都有对应的采集软件，但缺乏一站式解决方案。
2. 弹性伸缩难：k8s是一个分布式的集群，服务、环境的弹性伸缩对于日志采集带来了很大的困难，采集的动态性以及数据完整性是非常大的挑战。
3. 运维成本大：现有的方案只能使用多种软件组合采集，各个软件组装起来的系统稳定性难以保障，且缺乏中心化的管理、配置、监控手段，运维负担巨大。
4. 侵入性高：Docker Driver扩展需要修改底层引擎；一个Container对应一个采集Agent又会产生资源竞争和浪费。
5. 采集性能低：正常情况下一个Docker Engine会运行数十个甚至数百个Container，此时开源Agent日志采集性能以及资源消耗十分堪忧。

1. 上下文查询，从茫茫数据中快速定位异常数据，并支持定位异常所在Container/Pod的上下文日志
2. 实时的海量数据分析，1秒即可完成1亿条数据的统计分析
3. 自带报表、告警功能，老板、开发、运维全搞定
4. 流计算对接：storm、flink、blink、spark streaming等等都支持
5. 外接可视化：Grafana、DataV轻松对接
6. 日志归档投递：支持投递OSS归档存储，也支持投递MaxCompute进行离线分析

1. 部署Logtail的DaemonSet。体力消耗：一条wget名，vi 修改3个参数，执行一条kubectl命令
2. 日志服务控制台创建自定义标识机器组(后续集群动态伸缩无需额外操作)。体力消耗：web控制台点击几次，输入一个ID
3. 日志服务控制台创建采集配置(所有采集均为服务端配置，无需本地运维)。体力消耗：stdout采集 web控制台点击几次；文件采集 web控制台点击几次，输入2个path

• 除k8s外，日志服务还支持标准docker部署方式

1. 机器组除支持静态ip设置外，也支持自定义标识的方式：所有Logtail只要定义了该标识则自动关联到对应的机器组。
2. 一个Logtail可属于多个机器组，一个机器组可包含多个Logtail，实现Logtail与机器组的解耦。
3. 一个采集配置可应用到多个机器组，一个机器组可关联多个采集配置，实现机器组与采集配置的解耦。

1. 一个k8s集群对应一个自定义标识的机器组。同一集群的Logtail使用相同配置，k8s集群伸缩时对应Logtail的DaemonSet自动伸缩，Logtail启动后立即就会获取和该机器组关联的所有配置。
2. 一个k8s集群中配置多种不同采集配置。根据不同Pod需求设置对应的采集配置，所有涉及容器采集的配置均支持IncludeLabel、ExcluseLabel过滤
3. 同一配置可应用到多个k8s集群。如果您有多个的k8s集群，若其中有部分服务日志采集逻辑相同，您可以将同一配置应用到多个集群，无需额外配置。

1. 获取所有容器信息到docker engine事件监听建立期间的这部分的增量信息会丢失
2. 事件监听可能会因为某些异常情况而终止，终止后到监听重新建立期间的增量信息会丢失

1. 首先注册监听事件，其次再全量扫描
2. 每隔一段时间执行一次全量扫描，全量更新meta信息（时间间隔高到对docker engine压力无影响）

1. Logtail会根据配置的容器路径，查找容器对应路径在宿主机上的映射关系
2. 根据宿主机路径以及容器的元数据信息（container name、pod、namespace...）渲染出正常的采集配置
3. Logtail文件采集模块加载渲染的配置并采集数据
4. 当容器销毁时删除相应渲染的配置

1. 容器stdout和stderr的checkpoint独立保存
2. checkpoint保存策略：定期dump所有容器当前的checkpoint；配置更新/进程退出时强制保存
3. 配置加载时，默认从checkpoint处开始采集，若无checkpoint，则从5秒前采集
4. 考虑到配置删除时并不会删除checkpoint，后台定期清除无效checkpoint

1. 除文件采集的checkpoint需保存外，还需保存容器meta的映射关系
2. checkpoint加载前需提前加载容器与文件之间的映射关系
3. 考虑到停止期间无法感知容器状态变化，所以每次启动时会渲染所有当前的配置。Logtail保证多次加载同一容器配置的幂等性。