1裸机时代裸机时代，转转的业务日志采集端由大数据部门重新开发的scribe+flume组成。A服务部署到服务器后，如果需要收集该服务的日志，需要经过以下步骤。运维部门提交工单，申请在服务器上采集A的服务日志。工单审核通过自动部署日志采集组件scribe+flume在服务器上自动部署，通过工单中宿主机的日志采集应用数据并渲染导出scribe配置文件并指定日志输出目录服务作为集合目录。scribe服务根据自己的配置文件收集目录下的日志文件数据，发送到Flume对应的端口。最后，Flume将日志分发到kafka、hdfs等组件，在裸机时代，服务的部署节点没有太大变化。当有新服务上线时，会分配一台裸机服务器给该服务部署。一般情况下，服务的部署节点在很长一段时间内不会发生变化。只有促销期间服务的扩容和裸金属服务器硬件损坏，才会导致部署在宿主机上的服务在部署节点上发生变化。正是由于裸机时代服务部署节点的超强粘性，转转日志采集的工作流才能正常运行。裸机时代的日志采集工作流程2容器时代2016年，容器技术在国内蔓延开来，网络上流传着铺天盖地的技术文献。转转从2018年开始进入容器时代，从裸机到容器时代的过渡并不容易，转转选择了一条近乎“稳健”的道路来完成这次技术革新。这个“最稳健”的路径有几个要求。服务部署形式的改变对业务方是“不知情”的，将继续沿用裸机时代的发布系统，兼容容器服务的发布管理服务器/容器端登录将“不知情”业务端，而裸机时代的堡垒机登录会继续使用Form，兼容容器环境登录继续使用裸机时代的整体日志处理方式，所以本文我会重点讨论本次改造的日志采集系统。由于日志处理系统是一个庞大而复杂的系统，要想在容器时代进行一场云原生革命，推进容器化，首先要下大力气建设日志采集基础设施。是不可接受的。容器服务的运行特点和条件限制了服务容器频繁的跨节点调度。微服务框架已经标准化。日志输出目录是标准化的。容器中的服务只有文本日志输出，没有标准输出。裸机时代原有的日志采集流程无法撼动。2.1log-pilot+flume二次开发方案当时的大数据团队分析了容器服务运行的特点，并基于这些特点打造了一套兼容裸机时代的日志采集方案。在原有日志组件和功能完全不变的前提下，基于log-pilot+flume重新开发了一套日志转储引擎。使用log-pilot的容器自动发现功能，提取需要收集日志的容器的元数据信息，并渲染一个flume配置文件，flume会收集容器中的日志，dump到本地主机的一个目录中，最后通过二次开发后的log-pilot更新宿主机上的scribe配置文件，重启scribe进程，从而衔接之前裸机时代后续的日志采集流程。log-pilot日志采集方案为了兼容裸机时代不可动摇的日志采集现状，大数据部门贡献了第一代向容器化过渡的日志采集系统。系统初期运行良好，但随着中转服务容器化率的提高，日志量越来越大。这种日志转储方式直接导致每天的质量提升近一倍。不仅磁盘容量受到极大考验，日志保留周期也从30天逐渐缩短到3天，CPUiowait也开始飙升。集群节点每日iotuil长期在90%以上。沉重的IO负担已经成为阻碍业务进一步容器化的障碍，不容忽视。运维在保持裸机时代日志采集流程不变的基础上，进一步优化了容器场景。2.2ByteCompass运维自研的“logguide”，主要目的是剔除log-pilot+flume的logdump组件。日志读写少一个，磁盘空间和IO压力都会急剧下降。ByteCompass是完全自主研发的运维组件，运行在宿主机上，systemd管理。ByteCompass日志收集方案ByteCompass，借鉴log-pilot原理感知容器变化，监听dockerd的API接口，实时接收容器变化事件信息。当有新容器加入时，判断是否有日志收集标志。如果是，则进一步从容器配置的环境变量信息中读取日志采集的元数据信息，最后根据模板将容器信息渲染到新的scribe中。.conf配置文件，直接覆盖宿主机中的文件，重启宿主机的scribe进程。ByteCompass优化日志采集后，剔除冗余日志转储，将容器技术栈中的服务日志特性与裸机时代的日志采集流程无缝对接。与裸机时代日志采集流程对比如下：裸机时代与bytecompass日志采集对比ByteCompass修改日志采集，集群节点的平均iowait从10%降低到1%，并且峰值已从25%+降低到3%-；ioutil日均跌破7%，跌幅92%；本地日志保留时间也从3天恢复到7天以上。3云原生时代，解决了磁盘瓶颈后，转转容器化进程加速。为了兼容裸机时代遗留下来的用户习惯，容器时代在很大程度上对容器环境进行了妥协。随着服务容器化的逐步深入，转转从容器时代的过渡阶段开始逐步开启云原生时代。以上裸机时代和容器时代的日志，按需收集。只有业务申请了日志采集，才会采集日志进行数据分析和处理。用户在查询信息和错误日志进行故障排查时，登录裸机服务器或者容器，或者直接通过日志获取容器服务所在物理机上hostPath挂载的日志文件，还是很原始的查询平台。云原生时代对日志采集提出了更高的要求。在保留现有日志分析的基础上，还需要实现所有日志的集中存储和检索。并且考虑到未来k8s版本消除对dockerd的依赖以及宿主机更灵活的扩缩容，转转运维开始规划新的日志采集系统来满足云原生时代的需求。由于转转容器默认会将日志目录挂载到宿主机，开源通用的文本文件采集方案无法将pod元数据信息附加到日志中，所以转转运维依赖filebeat开发了一个filebeat“助手”---fb-advisor3.1转转方案（hostPath卷场景）fb-advisor转转日志收集方案得益于转转内部容器规范。无论是否需要收集容器日志，容器的日志目录都是根据hostPath机制挂载在宿主机目录上的。fb-advisor是一个自研组件，监听kube-apiserver的podapi，实时接收本节点的pod事件。如果是新的pod事件，读取pod元数据信息，识别出pod中log目录挂载的主机路径，保存到filebeat配置文件中，放到config.d目录下。Filebeat可以配置为自动重新加载。日志采集完成后，集中生产到kafka中间件，再由自研的消费者对日志进行处理，完成数据分发，从而取代scribe+flume的“黄金组合”。下面是与ByteCompass方案的对比。fb-advisorvsbytecompass3.2通用方案（hostPath分卷场景）本通用方案既适用于hostPath分卷场景，也适用于容器内默认文件系统场景下收集文本文件日志，同时附加pod元数据信息。filebeat中的add_kubernetes_metadata处理器是一个专门用于将pod元数据信息添加到日志中的插件。处理器：-add_kubernetes_metadata:in_cluster:falsehost:10.140.24.108kube_config:/pathto/kubeconfignamespace:defaultdefault_indexers.enabled:falsedefault_matchers.enabled:falsesync_period:60mindexers:-pod_uids:matches_pathers:var:log'/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：构造一个匹配的查找键由索引创建的标识符matches.logs_path：使用从存储在该字段中的日志路径中提取的标识符查找pod元数据。matchers.logs_path.logs_path：k8s数据目录绝对路径根据podUID为搜索key进行搜索在这个通用方案中，add_kubernetes_metadata负责连接kube-apiserver获取元数据信息，在日志采集路径/var/lib/kubelet/pods/
