比起容器日志采集的通用套路，我们找到了更优解法 - 运维 - dbaplus社群：围绕Data、B...

吕瑞 2023-03-14 10:32:51

作者介绍

吕瑞，转转运维，主要负责转转容器技术方向。

转转自 2018 年开始推进容器技术在公司业务服务上的落地。在容器生态中，日志采集是非常重要且不可或缺的组件之一，它不仅仅涉及到业务方错误日志的排查，还涉及到日志数据统计系统，成为战略决策的重要参考依据。

一、裸金属时代

在裸金属时代，转转业务日志的采集端由大数据部门二次开发的scribe+flume组成。当一台服务器上部署了A服务后，如果需要对该服务进行日志采集，需要经过以下几个步骤。

• 由运维部门提交工单，申请在该服务器上，对A服务日志进行采集；

• 工单审核通过；

• 在该服务器上自动化部署日志采集组件 scribe+flume；

• 通过工单中该台主机的日志采集申请数据，渲染出scribe配置文件，指定该服务的日志输出目录为采集目录；

• scribe服务根据自身配置文件，采集目录下的日志文件数据，发送到flume的对应端口，最后由flume将日志分发至kafka，hdfs等组件。

在裸金属时代，服务的部署节点的变化并不大。新服务上线，给该服务分配裸金属服务器进行部署，一般情况下，很长一段时间，该服务的部署节点都不会发生任何变更。只有在活动大促期间对该服务的扩容，以及某台裸金属服务器硬件的损坏，才会导致部署在该主机上的服务，产生部署节点上的变更。

也正是由于在裸金属时代，服务部署节点的超强粘性，转转日志采集的workflow运转正常。

裸金属时代日志采集workflow

二、容器时代

2016年，容器技术在中国开枝散叶，铺天盖地的技术文献在网络上流转。转转是在2018年开始迈入到容器时代。

裸金属到容器时代的转变并不容易，转转选择了一条几乎是“最稳健”的路来完成这场技术革新。这条“最稳健”的路有几点要求。

• 服务部署形式变化对业务方“无感知”，延用裸金属时代的发布系统，兼容容器服务的发布与管理

• 服务器/容器终端登录对业务方“无感知”，延用裸金属时代的堡垒机登录形式，兼容容器环境登录

• 延用裸金属时代的整体日志处理方式

• and so on……

本篇文章我着重讨论这场变革中的日志采集系统。由于日志处理体系是一个庞大且复杂的体系，在容器时代对其进行云原生革命，为了推进容器化，先要花大力气打造日志采集基础设施， 从时间和成本上，对于转转来说都是无法接受的。

容器服务运行特点与条件制约：

• 服务容器跨节点调度频繁

• 微服务框架已标准化日志输出目录

• 容器内的服务仅有文本日志输出，没有stdout

• 原有的裸金属时代日志采集流程无法动摇

• 容器运行后会将标准化的日志输出路径挂载到宿主机目录

1、log-pilot + flume 二次开发方案

当时的大数据团队分析了容器服务运行的特点，针对该特点，打造了一套基于裸金属时代的日志采集兼容方案。在原有日志组件及功能都完全不变的前提下，基于log-pilot+flume二次开发了一套日志转储引擎。

利用log-pilot的容器自动发现功能，提取出需要采集日志的容器元数据信息，并渲染出一个 flume 的配置文件，由 flume 将容器内的日志，采集后转储到本地宿主机的一个目录下，最后由二次开发后的 log-pilot 更新宿主机上的scribe配置文件，并重启 scribe 进程，这样即对接上了之前裸金属时代的后续日志采集流程。

log-pilot日志采集方案

为了兼容裸金属时代不可动摇的日志采集地位，大数据部门贡献了转转过渡到容器化的第一代日志采集系统。

该系统初期运转良好，但随着转转服务容器化率的提升，日志体量越来越大，这种日志的转储模式直接导致了日质量接近翻番，不仅磁盘容量受到巨大考验，日志保留周期从30天逐渐缩短到了3天，而且 CPU iowait 也开始飙升，集群节点每天的 iotuil 长期在 90% 以上，繁重的 IO 负担已经成了阻碍业务进一步容器化不容忽视的阻碍。在保留裸金属时代日志采集流程不变的基础上，运维针对容器场景做了进一步优化。

2、ByteCompass

运维自研的“日志指南者”，主要目的为剔除掉 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

1、 转转方案(hostPath volume场景) 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

2、通用方案(hostPath volume场景)

该通用方案同时适用于 hostPath volume 场景和容器内默认文件系统场景的文本文件日志的采集，并同时附加 pod 元数据信息。

filebeat 中的 add_kubernetes_metadata processor，是专门用来给日志附加 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: 禁用默认的 indexers

• default_matchers.enabled: 禁用默认的 matchers

• sync_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: 根据 pod UID 为查找键进行查找

该通用方案中，add_kubernetes_metadata 负责连接 kube-apiserver 获取元数据信息，并在日志采集路径中 /var/lib/kubelet/pods/<pod UID>/volumes/<volume name>/... 提取 pod UID 信息，并以此为键，进行元数据查找，找到元数据后，将其元数据信息附加到日志条目中。

3、对比

对比转转方案和通用方案，主要区别在于转转方案的定制化程度更高，可以自由选择需要附加的元数据信息，而通用方案默认会附加上容器所有的 label 信息。

从日志采集安全性来说，转转方案也略胜一筹，转转利用日志目录挂载到宿主机的特性，将 filebeat 的日志采集路径直接指向宿主机路径。这样的日志采集，脱离了 pod 数据目录跟随 pod 生命周期的特点，避免由于某些问题导致日志采集速率严重低于日志产出速率，且 pod 被重新调度后，数据目录被清理而导致的日志数据丢失。

总结

云原生时代的日志采集方案百花齐放，没有绝对通用的解决方案，没有绝对完美的解决方案，只有依据自身实际特点，最合适的解决方案，希望本篇文章能带给读者关于日志采集方案中的一些不同思路。

转转的日志采集从裸金属时代的 scribe + flume，到容器时代的 log-pilot + flume + scribe + flume，再到 ByteCompass + scribe + flume，最后到云原生时代的 filebeat + fb-advisor，彻底摆脱了裸金属时代日志采集的影子，并且脱离了 dockerd 的依赖，开始朝着更加云原生的方向继续披荆斩棘。

本篇文章仅介绍了日志采集的宏观 workflow，内部细节有其内部特殊性，无法一一展现，欢迎留言进行深入的细节讨论。

作者丨吕瑞 来源丨公众号：转转技术（ID：zhuanzhuantech） dbaplus社群欢迎广大技术人员投稿，投稿邮箱：[email protected]