转转容器日志采集的演进之路

在裸金属时代，转转业务日志的采集端由大数据部门二次开发的scribe+flume组成。当一台服务器上部署了A服务后，如果需要对该服务进行日志采集，需要经过以下几个步骤。,在裸金属时代，服务的部署节点的变化并不大。新服务上线，给该服务分配裸金属服务器进行部署，一般情况下，很长一段时间，该服务的部署节点都不会发生任何变更。只有在活动大促期间对该服务的扩容，以及某台裸金属服务器硬件的损坏，才会导致部署在该主机上的服务，产生部署节点上的变更。,也正是由于在裸金属时代，服务部署节点的超强粘性，转转日志采集的workflow运转正常。,裸金属时代日志采集workflow,2016年，容器技术在中国开枝散叶，铺天盖地的技术文献在网络上流转。转转是在2018年开始迈入到容器时代。,裸金属到容器时代的转变并不容易，转转选择了一条几乎是“最稳健”的路来完成这场技术革新。这条“最稳健”的路有几点要求。,本篇文章我着重讨论这场变革中的日志采集系统。由于日志处理体系是一个庞大且复杂的体系，在容器时代对其进行云原生革命，为了推进容器化，先要花大力气打造日志采集基础设施， 从时间和成本上，对于转转来说都是无法接受的。,容器服务运行特点与条件制约,当时的大数据团队分析了容器服务运行的特点，针对该特点，打造了一套基于裸金属时代的日志采集兼容方案。在原有日志组件及功能都完全不变的前提下，基于log-pilot+flume二次开发了一套日志转储引擎。,利用log-pilot的容器自动发现功能，提取出需要采集日志的容器元数据信息，并渲染出一个 flume 的配置文件，由 flume 将容器内的日志，采集后转储到本地宿主机的一个目录下，最后由二次开发后的 log-pilot 更新宿主机上的scribe配置文件，并重启 scribe 进程，这样即对接上了之前裸金属时代的后续日志采集流程。,log-pilot日志采集方案,为了兼容裸金属时代不可动摇的日志采集地位，大数据部门贡献了转转过渡到容器化的第一代日志采集系统。,该系统初期运转良好，但随着转转服务容器化率的提升，日志体量越来越大，这种日志的转储模式直接导致了日质量接近翻番，不仅磁盘容量受到巨大考验，日志保留周期从30天逐渐缩短到了3天，而且 CPU iowait 也开始飙升，集群节点每天的 iotuil 长期在 90% 以上，繁重的 IO 负担已经成了阻碍业务进一步容器化不容忽视的阻碍。在保留裸金属时代日志采集流程不变的基础上，运维针对容器场景做了进一步优化。,运维自研的“日志指南者”，主要目的为剔除掉 log-pilot + flume 这个日志转储组件。少了一次日志的读取和写入，磁盘空间和IO压力会骤减。ByteCompass 为运维全自研组件，以 systemd 管理运行在宿主机。,bytecompass日志采集方案,ByteCompass 借鉴了 log-pilot 感知容器变化的原理，watch 了 dockerd 的 api 接口，实时接收容器变化的事件信息。当有容器新增时，判断其是否带有日志采集标识，如果有，则进一步从容器配置的环境变量信息中读取日志采集的元数据信息，最后将该容器信息根据模板渲染成新的 scribe.conf 配置文件，直接覆盖宿主机中的该文件，并对该宿主机的 scribe 进程执行重启操作。,经过 ByteCompass 对日志采集的优化，剔除掉了冗余的日志转储，无缝衔接了容器技术栈中的服务日志特征和裸金属时代的日志采集流程。与裸金属时代日志采集流程对比如下：,裸金属时代与bytecompass日志采集对比,ByteCompass 改造后的日志采集，实现了集群节点平均 iowait 从 10% 降到 1%，波峰从 25%+ 降低到 3%-；ioutil 全天平均值下降到 7%以下，降幅达到92%；本地日志保留时间也从3天恢复到了7天以上。,在解决了磁盘瓶颈后，转转的容器化进程加速进行。容器时代为了兼容裸金属时代遗留的用户习惯，对容器环境做了很大程度上的妥协。随着服务容器化的逐渐深入，转转开始从容器时代这个过渡阶段，逐步开启云原生时代。,以上裸金属时代和容器时代的日志是按需采集，只有业务申请了日志采集，才会将日志采集走并做数据分析和处理。用户查询 info 及 error 日志排错，依然是很原始的登录到裸金属服务器上或登录到容器中，或通过日志查询平台，直接检索容器服务所在物理机挂载到 hostPath 中的日志文件。,云原生时代给日志采集提出了更高的要求，在保留现有日志分析的基础之上，还要实现全量日志的集中存储与检索。以及考虑到未来 k8s 版本对 dockerd 依赖的剔除和更灵活的宿主机扩缩容，转转运维开始规划全新的日志采集系统以适应云原生时代的需求。,由于转转容器默认会将日志目录挂载到宿主机，开源通用的文本文件采集方案无法将 pod 元数据信息附加到日志中，所以转转运维依托于 filebeat 自研了一个 filebeat 的 “助手” — fb-advisor,转转日志采集方案,受益于转转内部的容器规范，不管容器的日志是否需要采集，容器的日志目录都是以 hostPath 机制挂载到宿主机目录上的。fb-advisor 为转转自研组件，watch kube-apiserver 的 pod api，实时接收本节点的 pod 事件。如果为新增 pod 事件，则读取 pod 元数据信息，识别 pod 中日志目录挂载的宿主机路径，将其保存在 filebeat 的配置文件，放在 config.d 目录下。filebeat 配置自动 reload 即可。,日志采集后，集中生产到 kafka 中间件，再由自研的消费者将日志处理后完成数据的分发，从而替换掉 scribe + flume “黄金组合”。,以下为与 ByteCompass 方案的对比,fb-advisor vs bytecompass,该通用方案同时适用于 hostPath volume 场景和容器内默认文件系统场景的文本文件日志的采集，并同时附加 pod 元数据信息。,filebeat 中的 add_kubernetes_metadata processor，是专门用来给日志附加 pod 元数据信息用的插件。,该通用方案中，add_kubernetes_metadata 负责连接 kube-apiserver 获取元数据信息，并在日志采集路径中 /var/lib/kubelet/pods/<pod UID>/volumes/<volume name>/… 提取 pod UID 信息，并以此为键，进行元数据查找，找到元数据后，将其元数据信息附加到日志条目中。,对比转转方案和通用方案，主要区别在于转转方案的定制化程度更高，可以自由选择需要附加的元数据信息，而通用方案默认会附加上容器所有的 label 信息。,从日志采集安全性来说，转转方案也略胜一筹，转转利用日志目录挂载到宿主机的特性，将 filebeat 的日志采集路径直接指向宿主机路径。这样的日志采集，脱离了 pod 数据目录跟随 pod 生命周期的特点，避免由于某些问题导致日志采集速率严重低于日志产出速率，且 pod 被重新调度后，数据目录被清理而导致的日志数据丢失。,云原生时代的日志采集方案百花齐放，没有绝对通用的解决方案，没有绝对完美的解决方案，只有依据自身实际特点，最合适的解决方案，希望本篇文章能带给读者关于日志采集方案中的一些不同思路。,转转的日志采集从裸金属时代的 scribe + flume，到容器时代的 log-pilot + flume + scribe + flume，再到 ByteCompass + scribe + flume，最后到云原生时代的 filebeat + fb-advisor，彻底摆脱了裸金属时代日志采集的影子，并且脱离了 dockerd 的依赖，开始朝着更加云原生的方向继续披荆斩棘。,本篇文章仅介绍了日志采集的宏观 workflow，内部细节有其内部特殊性，无法一一展现，欢迎留言进行深入的细节讨论。,关于作者,吕瑞，转转运维，主要负责转转容器技术方向