摘要: 今天, 日志服务再次升级 Kubernetes(k8s)的日志解决方案 1 分钟内即可完成整个集群部署, 支持动态扩容, 提供采集宿主机日志容器日志容器 stdout 等所有数据源的一站式采集
背景
众所周知, Docker 很火, Docker 中 Kubernetes(简称 k8s)最火相对物理机 VM,Docker 提供了更加简单轻量高性价比的部署与运维方法; 而 k8s 在 Docker 之上, 更进一步提供了对管理基础设施的抽象, 形成了真正意义上的一站式部署与运维方案
k8s 提供了强有力工作调度水平扩展健康监测维护高可用性等能力, 同时提供了网络文件系统的抽象与管理, 所以对于已有应用上 k8s 或者基于 k8s 部署应用十分便捷但这里有一部分令开发和运维人员比较头疼日志采集
难点分析
基于 VM 或者物理机部署的应用, 日志采集相关技术都比较完善, 有比较健全的 LogstashFluentdFileBeats 等但在 Docker 中, 尤其在 k8s 中, 日志采集并没有很好的解决方案, 主要原因如下:
1. 采集目标多: 需要采集宿主机日志容器内日志容器 stdout 针对每种数据源都有对应的采集软件, 但缺乏一站式解决方案
2. 弹性伸缩难: k8s 是一个分布式的集群, 服务环境的弹性伸缩对于日志采集带来了很大的困难, 采集的动态性以及数据完整性是非常大的挑战
3. 运维成本大: 现有的方案只能使用多种软件组合采集, 各个软件组装起来的系统稳定性难以保障, 且缺乏中心化的管理配置监控手段, 运维负担巨大
4. 侵入性高: Docker Driver 扩展需要修改底层引擎; 一个 Container 对应一个采集 Agent 又会产生资源竞争和浪费
5. 采集性能低: 正常情况下一个 Docker Engine 会运行数十个甚至数百个 Container, 此时开源 Agent 日志采集性能以及资源消耗十分堪忧
基于阿里巴巴多年来容器服务日志采集的经验积累, 并结合阿里云 Kubernetes 内测以来广大用户的反馈与诉求, 今天, 日志服务为 k8s 带来真正意义上的一站式日志解决方案
方案介绍
方案简介
如上图所示, 我们只需要在 Kubernetes 集群中的每个节点上部署一个 Logtail 的容器, 即可实现该节点上宿主机日志容器日志容器 stdout 等所有数据源的一站式采集我们针对 k8s 提供了 DaemonSet 部署模板, 1 分钟内即可完成整个集群部署, 并且后续集群动态伸缩无需对采集做任何二次部署具体请参见使用方式章节
日志服务客户端 Logtail 目前已有百万级部署, 每天采集上万应用数 PB 的数据, 历经多次双 11 双 12 考验
依托阿里云日志服务强大的功能, 对于采集到的日志数据, 我们提供:
1. 上下文查询, 从茫茫数据中快速定位异常数据, 并支持定位异常所在 Container/Pod 的上下文日志
2. 实时的海量数据分析, 1 秒即可完成 1 亿条数据的统计分析
3. 自带报表告警功能, 老板开发运维全搞定
4. 流计算对接: stormflinkblinkspark streaming 等等都支持
5. 外接可视化: GrafanaDataV 轻松对接
6. 日志归档投递: 支持投递 OSS 归档存储, 也支持投递 MaxCompute 进行离线分析
采集方案优势
关于日志服务整体的优势这里不再赘述, 本文主要探讨日志服务 Kubernetes 采集方案的相关优势这里我们主要总结了以下几点:
方案对比
相对 LogstashFluentd 主流日志采集方式, 对比如下:
使用方式
部署 k8s 的日志采集只需分为 3 个步骤, 1 分钟内即可完成集群部署(详细帮助文档参见 k8s 采集帮助), 这可能是你见过的最简单的 k8s 日志采集部署方案:
1. 部署 Logtail 的 DaemonSet 体力消耗: 一条 wget 名, vi 修改 3 个参数, 执行一条 kubectl 命令
2. 日志服务控制台创建自定义标识机器组 (后续集群动态伸缩无需额外操作) 体力消耗: web 控制台点击几次, 输入一个 ID
3. 日志服务控制台创建采集配置 (所有采集均为服务端配置, 无需本地运维) 体力消耗: stdout 采集 web 控制台点击几次; 文件采集 web 控制台点击几次, 输入 2 个 path
除 k8s 外, 日志服务还支持标准 docker 部署方式
核心技术简介
自定义标识机器组
日志采集支持 k8s 弹性伸缩的关键就是 Logtail 的自定义标识机器组通常采集 Agent 远程管理的方案都以 IP 或者 hostname 作为标识, 此方案在集群规模较小以及环境变化性不强的情况下较为适用, 当机器规模扩大弹性伸缩成为常态时运维成本承指数级升高
基于集团内数年来的 Agent 运维经验总结, 我们设计了一种灵活性更高使用更加便捷耦合度更低的配置 & 机器管理方式:
1. 机器组除支持静态 ip 设置外, 也支持自定义标识的方式: 所有 Logtail 只要定义了该标识则自动关联到对应的机器组
2. 一个 Logtail 可属于多个机器组, 一个机器组可包含多个 Logtail, 实现 Logtail 与机器组的解耦
3. 一个采集配置可应用到多个机器组, 一个机器组可关联多个采集配置, 实现机器组与采集配置的解耦
以上概念映射到 k8s 中, 可实现各种灵活的配置:
1. 一个 k8s 集群对应一个自定义标识的机器组同一集群的 Logtail 使用相同配置, k8s 集群伸缩时对应 Logtail 的 DaemonSet 自动伸缩, Logtail 启动后立即就会获取和该机器组关联的所有配置
2. 一个 k8s 集群中配置多种不同采集配置根据不同 Pod 需求设置对应的采集配置, 所有涉及容器采集的配置均支持 IncludeLabelExcluseLabel 过滤
3. 同一配置可应用到多个 k8s 集群如果您有多个的 k8s 集群, 若其中有部分服务日志采集逻辑相同, 您可以将同一配置应用到多个集群, 无需额外配置
容器自动发现
Logtail 和很多软件 (LogspoutMetricBeatsTelegraf 等) 一样内置了容器的自动发现机制当前开源的容器自动发现均采用一次扫描 + 事件监听的方式, 即: 初次运行时获取当前所有的容器信息, 后续监听 docker engine 的事件信息, 增量更新信息
此种方式效率相对最高, 但有一定概率遗漏部分信息:
1. 获取所有容器信息到 docker engine 事件监听建立期间的这部分的增量信息会丢失
2. 事件监听可能会因为某些异常情况而终止, 终止后到监听重新建立期间的增量信息会丢失
考虑以上问题, Logtail 采用了事件监听与定期全量扫描的方式实现容器的自动发现:
1. 首先注册监听事件, 其次再全量扫描
2. 每隔一段时间执行一次全量扫描, 全量更新 meta 信息(时间间隔高到对 docker engine 压力无影响)
容器文件自动渲染
容器日志采集只需要配置容器内的文件路径, 并且支持各种采集模式: 极简 Nginx 模板正则分隔符 JSON 等相对传统的绝对路径采集, 容器内日志采集动态性极强, 为此我们专门实现了一套容器路径的自动匹配与配置渲染方案:
1.Logtail 会根据配置的容器路径, 查找容器对应路径在宿主机上的映射关系
2. 根据宿主机路径以及容器的元数据信息 (container namepodnamespace) 渲染出正常的采集配置
3.Logtail 文件采集模块加载渲染的配置并采集数据
4. 当容器销毁时删除相应渲染的配置
可靠性保证
日志采集中的可靠性保证是非常重要也非常困难的工作在 Logtail 的设计中, 进程退出异常终止程序升级被认为是常态, 在这些情况发生时 Logtail 需尽可能保证数据的可靠性针对容器数据采集的动态特点, Logtail 在之前可靠性保证的基础上, 新增了容器标准输出以及容器文件的 checkpoint 维护机制
容器标准输出 checkpoint 管理
1. 容器 stdout 和 stderr 的 checkpoint 独立保存
2.checkpoint 保存策略: 定期 dump 所有容器当前的 checkpoint; 配置更新 / 进程退出时强制保存
3. 配置加载时, 默认从 checkpoint 处开始采集, 若无 checkpoint, 则从 5 秒前采集
4. 考虑到配置删除时并不会删除 checkpoint, 后台定期清除无效 checkpoint
容器文件 checkpoint 管理
1. 除文件采集的 checkpoint 需保存外, 还需保存容器 meta 的映射关系
2.checkpoint 加载前需提前加载容器与文件之间的映射关系
3. 考虑到停止期间无法感知容器状态变化, 所以每次启动时会渲染所有当前的配置 Logtail 保证多次加载同一容器配置的幂等性
总结
阿里云日志服务提供的解决方案完美地解决了 k8s 上日志采集难的问题, 从之前需要多个软件几十个部署流程精简到 1 款软件 3 个操作即可轻松上云, 让广大用户真正体验到一个字: 爽, 从此日志运维人员的生活质量大大提高
来源: http://geek.csdn.net/news/detail/255106