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

网络人上人

1裸金属时代2容器时代2.1log-pilot+flume二次开发方案2.2ByteCompass3云原生时代3.1转转方案(hostPathvolume场景)fb-advisor3.2通用方案(hostPathvolume场景)3.3对比4总结转转自2018年开始推进容器技术在公司业务服务上的落地。在容器生态中，日志采集是非常重要且不可或缺的组件之一，它不仅仅涉及到业务方错误日志的排查，还涉及到日志数据统计系统，成为战略决策的重要参考依据。1裸金属时代在裸金属时代，转转业务日志的采集端由大数据部门二次开发的scribe+flume组成。当一台服务器上部署了A服务后，如果需要对该服务进行日志采集，需要经过以下几个步骤。由运维部门提交工单，申请在该服务器上，对A服务日志进行采集工单审核通过在该服务器上自动化部署日志采集组件scribe+flume通过工单中该台主机的日志采集申请数据，渲染出scribe配置文件，指定该服务的日志输出目录为采集目录scribe服务根据自身配置文件，采集目录下的日志文件数据，发送到flume的对应端口，最后由flume将日志分发至kafka，hdfs等组件在裸金属时代，服务的部署节点的变化并不大。新服务上线，给该服务分配裸金属服务器进行部署，一般情况下，很长一段时间，该服务的部署节点都不会发生任何变更。只有在活动大促期间对该服务的扩容，以及某台裸金属服务器硬件的损坏，才会导致部署在该主机上的服务，产生部署节点上的变更。也正是由于在裸金属时代，服务部署节点的超强粘性，转转日志采集的workflow运转正常。裸金属时代日志采集workflow2容器时代2016年，容器技术在中国开枝散叶，铺天盖地的技术文献在网络上流转。转转是在2018年开始迈入到容器时代。裸金属到容器时代的转变并不容易，转转选择了一条几乎是“最稳健”的路来完成这场技术革新。这条“最稳健”的路有几点要求。服务部署形式变化对业务方“无感知”，延用裸金属时代的发布系统，兼容容器服务的发布与管理服务器/容器终端登录对业务方“无感知”，延用裸金属时代的堡垒机登录形式，兼容容器环境登录延用裸金属时代的整体日志处理方式andsoon本篇文章我着重讨论这场变革中的日志采集系统。由于日志处理体系是一个庞大且复杂的体系，在容器时代对其进行云原生革命，为了推进容器化，先要花大力气打造日志采集基础设施，从时间和成本上，对于转转来说都是无法接受的。容器服务运行特点与条件制约服务容器跨节点调度频繁微服务框架已标准化日志输出目录容器内的服务仅有文本日志输出，没有stdout原有的裸金属时代日志采集流程无法动摇容器运行后会将标准化的日志输出路径挂载到宿主机目录2.1log-pilot+flume二次开发方案当时的大数据团队分析了容器服务运行的特点，针对该特点，打造了一套基于裸金属时代的日志采集兼容方案。在原有日志组件及功能都完全不变的前提下，基于log-pilot+flume二次开发了一套日志转储引擎。利用log-pilot的容器自动发现功能，提取出需要采集日志的容器元数据信息，并渲染出一个flume的配置文件，由flume将容器内的日志，采集后转储到本地宿主机的一个目录下，最后由二次开发后的log-pilot更新宿主机上的scribe配置文件，并重启scribe进程，这样即对接上了之前裸金属时代的后续日志采集流程。log-pilot日志采集方案为了兼容裸金属时代不可动摇的日志采集地位，大数据部门贡献了转转过渡到容器化的第一代日志采集系统。该系统初期运转良好，但随着转转服务容器化率的提升，日志体量越来越大，这种日志的转储模式直接导致了日质量接近翻番，不仅磁盘容量受到巨大考验，日志保留周期从30天逐渐缩短到了3天，而且CPUiowait也开始飙升，集群节点每天的iotuil长期在90%以上，繁重的IO负担已经成了阻碍业务进一步容器化不容忽视的阻碍。在保留裸金属时代日志采集流程不变的基础上，运维针对容器场景做了进一步优化。2.2ByteCompass运维自研的“日志指南者”，主要目的为剔除掉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天以上。3云原生时代在解决了磁盘瓶颈后，转转的容器化进程加速进行。容器时代为了兼容裸金属时代遗留的用户习惯，对容器环境做了很大程度上的妥协。随着服务容器化的逐渐深入，转转开始从容器时代这个过渡阶段，逐步开启云原生时代。以上裸金属时代和容器时代的日志是按需采集，只有业务申请了日志采集，才会将日志采集走并做数据分析和处理。用户查询info及error日志排错，依然是很原始的登录到裸金属服务器上或登录到容器中，或通过日志查询平台，直接检索容器服务所在物理机挂载到hostPath中的日志文件。云原生时代给日志采集提出了更高的要求，在保留现有日志分析的基础之上，还要实现全量日志的集中存储与检索。以及考虑到未来k8s版本对dockerd依赖的剔除和更灵活的宿主机扩缩容，转转运维开始规划全新的日志采集系统以适应云原生时代的需求。由于转转容器默认会将日志目录挂载到宿主机，开源通用的文本文件采集方案无法将pod元数据信息附加到日志中，所以转转运维依托于filebeat自研了一个filebeat的“助手”---fb-advisor3.1转转方案(hostPathvolume场景)fb-advisor转转日志采集方案受益于转转内部的容器规范，不管容器的日志是否需要采集，容器的日志目录都是以hostPath机制挂载到宿主机目录上的。fb-advisor为转转自研组件，watchkube-apiserver的podapi，实时接收本节点的pod事件。如果为新增pod事件，则读取pod元数据信息，识别pod中日志目录挂载的宿主机路径，将其保存在filebeat的配置文件，放在config.d目录下。filebeat配置自动reload即可。日志采集后，集中生产到kafka中间件，再由自研的消费者将日志处理后完成数据的分发，从而替换掉scribe+flume“黄金组合”。以下为与ByteCompass方案的对比fb-advisorvsbytecompass3.2通用方案(hostPathvolume场景)该通用方案同时适用于hostPathvolume场景和容器内默认文件系统场景的文本文件日志的采集，并同时附加pod元数据信息。filebeat中的add_kubernetes_metadataprocessor，是专门用来给日志附加pod元数据信息用的插件。processors:  - add_kubernetes_metadata:      in_cluster: false      host: 10.140.24.108      kube_config: /pathto/kubeconfig      namespace: default      default_indexers.enabled: false      default_matchers.enabled: false      sync_period: 60m      indexers:        - pod_uid:      matchers:        - logs_path:            logs_path: '/var/lib/kubelet/pods/'            resource_type: 'pod'in_cluster:是否运行在容器环境中host:主机名kube_config:kubeconfig文件绝对路径namespace:监听的命名空间，如果不写，默认监听所有命名空间default_indexers.enabled:禁用默认的indexersdefault_matchers.enabled:禁用默认的matcherssync_period:指定列出历史资源的超时时间indexers:使用pod元数据为每个pod创建唯一标识符indexers.pod_uid:使用pod的UID标识pod元数据matchers:构造与索引创建的标识符匹配的查找键matchers.logs_path:使用从存储在该字段中的日志路径中提取的标识符查找pod元数据matchers.logs_path.logs_path:k8s数据目录绝对路径matchers.logs_path.resource_type:根据podUID为查找键进行查找该通用方案中，add_kubernetes_metadata负责连接kube-apiserver获取元数据信息，并在日志采集路径中/var/lib/kubelet/pods/ /volumes//...提取podUID信息，并以此为键，进行元数据查找，找到元数据后，将其元数据信息附加到日志条目中。3.3对比对比转转方案和通用方案，主要区别在于转转方案的定制化程度更高，可以自由选择需要附加的元数据信息，而通用方案默认会附加上容器所有的label信息。从日志采集安全性来说，转转方案也略胜一筹，转转利用日志目录挂载到宿主机的特性，将filebeat的日志采集路径直接指向宿主机路径。这样的日志采集，脱离了pod数据目录跟随pod生命周期的特点，避免由于某些问题导致日志采集速率严重低于日志产出速率，且pod被重新调度后，数据目录被清理而导致的日志数据丢失。4总结云原生时代的日志采集方案百花齐放，没有绝对通用的解决方案，没有绝对完美的解决方案，只有依据自身实际特点，最合适的解决方案，希望本篇文章能带给读者关于日志采集方案中的一些不同思路。转转的日志采集从裸金属时代的scribe+flume，到容器时代的log-pilot+flume+scribe+flume，再到ByteCompass+scribe+flume，最后到云原生时代的filebeat+fb-advisor，彻底摆脱了裸金属时代日志采集的影子，并且脱离了dockerd的依赖，开始朝着更加云原生的方向继续披荆斩棘。本篇文章仅介绍了日志采集的宏观workflow，内部细节有其内部特殊性，无法一一展现，欢迎留言进行深入的细节讨论。关于作者吕瑞，转转运维，主要负责转转容器技术方向