作者：刘卯银｜火山引擎日志体系架构师
本文整理自火山引擎开发者社区 Meetup 第八期讲演，首要介绍了火山引擎 TLS 日志服务的架构完成、规划优化以及实践事例。
谈到日志体系，首要要从日志说起，日志在 IT 体系里无处不在，也是 IT体系大数据的要害来源。日志的品种和款式十分多，以在线教育体系为例，日志包含客户端日志、服务端日志。服务端日志又包含事务的运行/运维日志以及事务运用的云产品产生的日志。要办理诸多类型的日志，就需求一套一致的日志体系，对日志进行收集、加工、存储、查询、剖析、可视化、告警以及消费投递，将日志的生命周期进行闭环。
Kubernetes 下日志收集的开源自建计划
开源自建
火山引擎前期为了快速上线事务，各团队基于开源项目树立了自己的日志体系，以满意根本的日志查询需求，例如运用典型的开源日志渠道 Filebeat+Logstash+ES+Kibana 的计划。
但是在运用过程中，咱们发现了开源日志体系的缺乏：
- 各事务模块自己树立日志体系，形成重复建设。
- 以 ES 为中心的日志架构能够运用 ES 查询便利的优势，但是资源开支大、本钱高。并且 ES 与 Kibana 在界面上强绑定，不利于功用扩展。
- 开源计划一般选用单机 yaml 做收集装备，当节点数很多的时候，装备十分繁琐。
- 开源体系的收集装备难以办理，数据源也比较单一。
Kubernetes 下的日志收集
Kubernetes 下怎么收集日志呢？ 官方推荐了四种日志收集计划：
- DaemonSet：在每台宿主机上树立一个 DaemonSet 容器来布置 Agent。事务容器将容器规范输出存储到宿主机上的文件，Agent 收集对应宿主机上的文件。
- Streaming Sidecar：有一些事务体系的日志不是规范输出，而是文件输出。Streaming Sidecar 的方法能够把这些文件输出经过 Sidecar 容器转换成容器的规范输出，然后收集。
- Sidecar Logging Agent：事务 Pod 内单独布置 Agent 的 Sidecar 容器。这种方法的资源阻隔性强。
- API/SDK：直接在容器内运用 API 或 SDK 接口将日志收集到后端。
以上前三种收集计划都只支撑收集容器的规范输出，第四种计划需求改造事务代码，这几种方法对收集容器文件都不友好。但用户关于日志文件有分类的需求，规范输出将一切日志混在一同，不利于用户进行分类。假如用户要把一切日志都转到规范输出上，还需求开发或许装备，难以推广。因而 Kubernetes 官方推荐的计划无法彻底满意用户需求，给咱们的实际运用带来了很多不方便。
自建日志收集体系的困境与挑战
云原生场景下日志品种多、数量多、动态非永久，开源体系在收集云原生日志时面对诸多困难，首要包含以下问题：
一、收集难
- 装备杂乱 ： 体系规划越来越大，节点数越来越多，每个节点的装备都不一样，手工装备很简单犯错，体系的变更变得十分困难。
- 需求不满意 ： 开源体系无法彻底满意实际场景的用户需求，例如不具备多行日志收集、完好正则匹配、过滤、时间解析等功用，容器文件的收集也比较困难。
- 运维难度高 ： 大规划场景下大量 Agent 的晋级是个挑战，体系无法实时监控 Agent 的状态，当Agent 状态反常时也没有毛病告警。
二、 产品化才能缺乏
- 可用性低： 由于缺少流控，突发的事务简单使后端体系过载，事务之间简单相互影响。
- 资源运用功率低 ： 假如装备的资源是固定的，在突发场景下简单形成功用缺乏的问题；但假如装备的资源过多，普通场景下资源运用率就会很低；不同的组件装备不均衡还会导致功用瓶颈浪费资源。ES 的原始数据和索引运用相同的资源装备，也会导致高本钱。
- 功用缺乏 ： 比如 ES 的投递和消费才能弱、剖析才能固化、没有告警才能、可视化才能有限。
火山引擎一致日志渠道 TLS
在遇到这些问题今后，咱们研发了一套一致的日志办理渠道——火山引擎日志服务（Tinder Log Service，简称为 TLS)。TLS 的整体架构如下：
面对各种日志源，TLS 经过自研的 LogCollector/SDK/API，可支撑专有协议、 OpenTelemetry 和 Kafka 协议上传日志。支撑多品种型的终端、多种开发语言以及开源生态规范协议。
收集到的日志首要会存入高速缓冲集群，削峰填谷，随后日志会匀速流入存储集群，依据用户装备再流转到数据加工集群进行日志加工，或许到索引集群树立索引。 树立索引后用户能够进行实时查询和剖析。TLS 供给规范的 Lucene 查询语法、SQL 92 剖析语法、可视化仪表盘以及丰厚的监控告警才能。
当日志存储达到一定周期，不再需求实时剖析之后，用户能够把日志投递到本钱更低的火山引擎目标存储服务中，或许经过 Kafka 协议投递到其他云产品。假如用户有更高阶的剖析需求，TLS 也支撑把日志消费到实时核算、流式核算或离线核算进行更深化的剖析。
TLS 的体系规划遵从高可用、高功用、分层规划的准则。
- 高可用：经过存算别离，一切服务都是无状态的，毛病快速恢复。
- 高功用：一切集群都可横向扩展，没有热门。
- 分层规划：各模块之间低耦合，模块之间定义规范接口，组件可替换。
以上便是火山引擎自研的日志存储渠道 TLS 的体系架构，下面将详细介绍 TLS 相较于开源体系做的优化。
体系优化
中心化白屏化的装备办理
当日志体系中收集 Agent 数量较多时，不再合适在每台机器上手工装备，因而咱们开发了中心化、白屏化的装备办理功用，支撑动态下发收集装备，并支撑检查 Agent 运行状态监控、支撑客户端主动晋级。
中心化装备的完成流程如下：
- 客户端主动向服务端建议心跳，携带本身版别信息；
- 服务端收到心跳，检查版别；
- 服务端判断是否需求下发装备信息给客户端；
- 客户端收到装备信息，热加载到本地装备，以新的装备进行收集。
中心化装备办理的优势在于：
- 牢靠：中心化办理，装备不丢失，白屏化装备不简单犯错。
- 高效：各种环境下一切的装备都是一致处理，不管 LogCollector 布置在移动端、容器还是物理机上，用户都能够在服务端相同的界面上装备，装备以机器组为单位批量下发，快速高效。
- 轻松运维：用户能够在服务端检查客户端的运行状态，对客户端的反常宣布告警。经过中心化装备，TLS 能够向客户端推送最新版别，主动晋级。
CRD 云原生装备方法
中心化、白屏化的装备方法是合适运维人员的装备方法。在开发测试主动化的场景下，最优的方法是 CRD。传统的方法经过 API 接口去做收集装备，用户一般需求写数千行代码来完成。TLS 供给了云原生 CRD 的方法来进行装备，用户只需求在 yaml 文件里装备要收集的容器、容器内的日志途径以及收集规矩即可完成收集装备。由于不再需求编写代码，CRD 方法大幅提高了日志接入功率。
CRD 的装备流程如下：
- 运用 Kubectl 指令创立 TLS LogConfig CRD；
- TLS Controller 监听到 CRD 装备更新；
- TLS Controller 依据 CRD 装备向 TLS Server 发送指令，创立 topic、创立机器组，创立日志收集装备；
- LogCollector 定时请求 TLS Server，获取新的收集装备并进行热加载；
- LogCollector 依据收集装备收集各个容器上的规范输出或文本日志；
- LogCollector 将收集到的日志发送给 TLS Server。
合适大规划、多租户场景的客户端
开源日志收集客户端一般只支撑一个 Output，多个 Input 选用相同的 Pipeline，相互影响。为了适应大规划、多租户场景，火山引擎自研了日志收集的客户端 LogCollector。LogCollector 对不同的 Input 选用不同的 Pipeline 做资源阻隔，减少多租户之间的相互影响。一个 LogCollector 支撑多个 Output，能够依据不同的 Output 单独做租户鉴权。一起咱们还在 LogCollector 内完成了自适应反压机制，假如服务端繁忙，LogCollector 会主动推迟退避，服务端空闲时再发送，减少算力担负。
产品优化
可用性提高
在可用性方面，TLS 支撑多级全局流控，能根绝因事务突发导致的毛病分散问题。
- 在日志收集到高速缓冲集群时，依照用户的 Shard 数操控写入高速缓冲区的流量。
- 当数据从高速缓冲区流向存储集群时，按存储集群操控单个存储集群的流量。
- 从存储集群到索引集群，按索引集群操控单个索引集群的写入流控以及查询剖析并发数。
功率提高
索引和原始数据别离
ES 的索引和数据存在一同，咱们在规划过程发现索引和原始数据别离会更优，首要表现在：
- 提高数据流动性：存储集群支撑批量消费接口，消费数据不经过索引集群。相关于从索引集群先查询后消费的形式，直接从存储集群消费功用更高，有用提高数据流动性。
- 下降本钱：索引和存储能够选用不同本钱的存储，整体的存储本钱就会下降。用户能够随时按需创立索引，进一步下降索引本钱。
- 提高可用性：索引能够异步创立，流量突发时创立索引慢不会影响存储写入速率。
索引办理和调度
索引的流量是不行预测的，因而咱们在功率方面的另一个优化是支撑索引的办理和调度，完成弹性伸缩，然后提高可用性，处理规划问题。咱们的处理计划是在多个索引集群之间做数据流动，基于负载、资源、容量主动搬迁索引，支撑动态跨集群在线搬迁索引，平衡索引集群负载。
功用优化
-
消费投递：在消费投递方面咱们支撑了丰厚的消费投递接口，包含：
- 消费者
- 消费组
- Kafka 协议：经过 Kafka 协议进行规范协议的消费；
- S3 协议：支撑经过 S3 目标存储的协议把日志投递到目标存储。
- 查询剖析：支撑先查询过滤后剖析，减少剖析数据量提高功用。剖析支撑规范的 SQL 92，剖析结果支撑图表可视化。
- 日志告警：经过实时监控日志，基于用户装备的监控规矩组合以及告警触发条件，满意条件就能够经过短信、邮件、飞书等方法发送告警给用户或用户组。
- 可视化仪表盘：TLS 供给多种可视化仪表盘，完成实时监测，且仪表盘能够关联告警。
TLS 实践事例
接下来为大家介绍两个 TLS 的典型事例。
火山引擎内部事务及运维日志收集
TLS 目前支撑了火山引擎全国多个 Region 运维日志的收集剖析。日志类型包含事务的文件日志、容器规范输出。事务别离布置在内网、外网以及混合云，日志都经过 TLS 渠道一致做收集和剖析。
相较于前期各事务模块自己树立日志体系，选用 TLS 获得了如下收益：
- 经济高效：资源运用率由之前的 20% 提高到现在的 80%，大幅下降资源本钱；
- 可用性较高：多级流控加缓存，抗突发才能强，即便在索引体系毛病的时候也不会影响原始数据的流量；
- 轻松运维：TLS 的一致运维提高了运维人员的才能，少量运维人员即可完成整个体系的运维。
- 快速接入：TLS 能够在一小时内完成一个新事务的收集、查询、剖析、消费的快速接入。
某教育职业头部客户日志收集
该客户的体系事务首要收集的日志包含：
- 文件日志
- App 日志
- Kubernetes 集群后端事务的日志
- 用户行为日志
TLS 把这几个渠道的日志一致收集到云端，进行实时查询剖析以及进行告警。客户自建有大数据剖析渠道，TLS 可将日志数据经过消费的方法流转到该渠道进行在线、离线等更高阶的大数据剖析。关于时间长的历史数据，则投递到目标存储进行归档，然后下降整个体系的本钱。
用户的办理员可在 TLS 上一致检查一切渠道的各种日志，整个体系的建设和运维本钱也下降了。TLS 运用规范接口，能够兼容云上自建的剖析渠道，用户在快速上线的一起也能确保体系的高度兼容。
未来展望
未来，TLS 渠道会不断进行更深层次的优化：
- 云产品的一键日志收集
- 搜索引擎的深度优化
- 数据清洗和加工的函数式接口
- 集成更多第三方渠道，火山引擎云产品深度融合
火山引擎 TLS 日志服务将在5月初正式 GA，感兴趣的小伙伴能够在火山引擎开发者社区大众号后台回复要害字【TLS】重视试用。
Q&A：
Q：中心化装备，各个事务的日志收集装备是 OP 担任还是 RD 担任？
A：日志收集的中心化装备是 Web 方法，装备十分简单，不管是 RD 或是 OP 担任都能够。火山引擎上 Web 装备由 OP 来担任，容器主动化收集是用 CRD 的方法，一般是 RD 担任。
Q：收集端 Agent 的运用资源能够约束吗？是否会影响事务的资源运用？
A：CPU 占用量、内存占用量这些是能够装备的，不会影响事务的资源运用。
Q：CRD 和中心化装备不会冲突吗？
A：一般情况下不会冲突。CRD 有特定的命名规矩，只要 Web 装备和 CRD 装备的姓名不冲突就不会报错。假如姓名冲突，装备会失败，改姓名后重试即可。
Q：Node 节点宕机是否会丢日志？
A：不会。LogCollector 有 Checkpoint，Checkpoint 会定时更新。假如节点宕机没有更新 Checkpoint，日志会从上次 Checkpoint 点从头收集，所以是不会丢的。
Q：日志收集的推迟情况怎么？
A：一般在秒级推迟，后端事务忙的时候可能是几秒到十几秒的推迟。
Q：Kafka 协议是怎么暴露的？经过完成 Kafka Server 吗？
A：咱们是在服务端完成的 Kafka 协议。用户以 Kafka 的协议方法接入，鉴权也是以 Kafka 的鉴权协议来做的。用户看到的其实便是一个 Kafka。这样能够对用户做到透明。
