iLogtail——一款延迟仅在毫秒级的千万实例可观测采集器利器来了 | 龙蜥技术

2022 年 2 月 18 日
本文字数：5770 字
阅读完需：约 19 分钟

编者按：iLogtail 的核心定位就是可观测数据采集的基础设施，广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。本文整理自龙蜥SIG技术周会直播，主要介绍 iLogtail 的开源背景、功能、优势以及它的发展历程，视频回顾里还为大家演示如何使用 iLogtail 采集各类可观测数据，直播视频回放已上线至龙蜥社区官网：首页-支持-视频，欢迎观看。

文/张诚，iLogtail SIG 核心成员、阿里云技术专家

iLogtail 是阿里已开源可观测数据采集器，作为阿里内部可观测数据采集的基础设施，iLogtail 承载了阿里巴巴集团、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail 运行在服务器、容器、K8s、嵌入式等多种环境，支持采集数百种可观测数据，目前已经有千万级的安装量，每天采集数十 PB 的可观测数据，广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。

一、iLogtail 与可观测性

可观测性并不是一个全新的概念，而是从 IT 系统中的监控、问题排查、稳定性建设、运营分析、BI、安全分析等逐渐演化而来，可观测性相比传统监控，最核心的演进是尽可能多的收集各类可观测数据，来实现目标的白盒化。而 iLogtail 的核心定位就是可观测数据的采集器，能够尽可能多的采集各类可观测性数据，助力可观测平台打造各种上层的应用场景。

二、阿里可观测数据采集的挑战

对于可观测数据的采集，有很多开源的 Agent，例如 Logstash、Filebeats、Fluentd、Collectd、Telegraf 等。这些 Agent 的功能非常丰富，使用这些 Agent 的组合再进行一定的扩展，基本可以满足内部各类数据的采集需求。但由于一些性能、稳定性、管控能力等关键性的挑战无法满足，最终我们还是选择自研：

1.资源消耗

目前阿里内部有数百万的主机（物理机/虚拟机/容器），每天会产生几十 PB 的可观测数据，每 1 M 的内存减少、每 1M/s 的性能提升对于我们的资源节省都是巨大的，带来的成本节约可能是数百万甚至上千万。目前众多开源 Agent 的设计更多的是偏重功能而非性能，基于现有开源 Agent 改造基本不可行。例如：

开源 Agent 普遍单核处理性能在 2-10M/s 左右，而我们希望有一个能达到 100M/s 的性能
在采集目标增加、数据量增加、采集延迟、服务端异常等情况下，开源 Agent 内存都会呈现爆炸式增长，而我们希望即使在各种环境下，内存也能处在较低的水位
开源 Agent 的资源消耗没办法控制，只能通过 cgroup 强行限制，最终的效果就是不断 OOM，不断重启，数据一直采集不上来。而我们希望在指定一个 CPU、内存、流量等资源限制后，Agent 能一直在这个限制范围内正常工作

2.稳定性

稳定性是永恒的话题，数据采集的稳定性，除了保证数据本身采集的准确性外，还需要保证采集的 Agent 不能影响业务应用，否则带来的影响将是灾难性的。而稳定性建设，除了 Agent 自身的基础稳定性外，还有很多特性目前开源的 Agent 还没有提供：

Agent 自恢复：Agent 遇到 Critical 的事件后能够自动恢复，并且提供多个维度的自恢复能力，例如进程自身、父子进程、守护进程
全局的多维度监控：能够从全局的角度监控各个不同版本、不同采集配置、不同压力、不同地域/网络等属性的 Agent 的稳定性问题
问题隔离：作为 Agent，无论怎样出现问题，都需要尽可能的隔离问题，例如一个 Agent 上有多个采集配置，一个配置出问题，不能影响其他配置；Agent 自身出现问题，不能影响机器上的应用进程的稳定性
回滚能力：版本更新和发布是再所难免的问题，在出现问题的时候如何快速回滚，而且保证出问题和回滚期间的数据采集还是 at least once 甚至是 exactly once

3.可管控

可观测数据的应用范围非常的广，几乎所有的业务、运维、BI、安全等部门都会要用，而一台机器上也会产生各种数据，同一台机器产生的数据上也会有多个部门的人要去使用，例如在 2018 年我们统计，平均一台虚拟机上有 100 多个不同类型的数据需要采集，设计 10 多个不同部门的人要去使用这些数据。除了这些之外，还会有其他很多企业级的特性需要支持，例如：

配置的远程管理：在大规模场景下，手工登录机器修改配置基本没有可行性，因此需要一套配置的图形化管理、远程存储、自动下发的机制，而且还要能够区分不同的应用、不同的 Region、不同的归属方等信息。同时因为涉及到远程配置的动态加卸载，Agent 还需要能够保证配置 Reload 期间数据不丢不重
采集配置优先级：当一台机器上有多个采集配置在运行时，如果遇到资源不足的情况，需要区分每个不同的配置优先级，资源优先供给高优先级的配置，同时还要确保低优先级的配置不被“饿死”
降级与恢复能力：在阿里，大促、秒杀是家常便饭，在这种波峰期间，可能有很多不重要的应用被降级，同样对应应用的数据也需要降级，降级后，在凌晨波峰过后，还需要有足够的 Burst 能力快速追齐数据
数据采集齐全度：监控、数据分析等场景都要求数据准确度，数据准确的前提是都能及时采集到服务端，但如何在计算前确定每台机器、每个文件的数据都采集到了对应的时间点，需要一套非常复杂的机制去计算

基于以上的背景和挑战下，我们从 2013 年开始，不断逐渐优化和改进 iLogtail 来解决性能、稳定性、可管控等问题，并经历了阿里多次双十一、双十二、春晚红包等项目的考验。目前 iLogtail 支持包括 Logs、Traces、Metrics 多种类型数据的统一收集，核心的特点主要如下：

支持多种 Logs、Traces、Metrics 数据采集，尤其对容器、Kubernetes 环境支持非常友好
数据采集资源消耗极低，单核采集能力 100M/s，相比同类可观测数据采集的 Agent 性能好 5-20 倍
高稳定性，在阿里巴巴以及数万阿里云客户生产中使用验证，部署量近千万，每天采集数十 PB 可观测数据
支持插件化扩展，可任意扩充数据采集、处理、聚合、发送模块
支持配置远程管理，支持以图形化、SDK、K8s Operator 等方式进行配置管理，可轻松管理百万台机器的数据采集
支持自监控、流量控制、资源控制、主动告警、采集统计等多种高级管控特性

三、iLogtail 发展历程

秉承着阿里人简单的特点，iLogtail 的命名也非常简单，我们最开始期望的就是能够有一个统一去 Tail 日志的工具，所以就叫做 Logtail，添加上“i”的原因主要当时使用了 inotify 的技术，能够让日志采集的延迟控制在毫秒级，因此最后叫做 iLogtail。从 2013 年开始研发，iLogtail 整个发展历程概括起来大致可以分为三个阶段，分别是飞天 5K 阶段、阿里集团阶段和云原生阶段。

1.飞天 5K 阶段

作为中国云计算领域的里程碑，2013 年 8 月 15 日，阿里巴巴集团正式运营服务器规模达到 5000（5K）的“飞天”集群，成为中国第一个独立研发拥有大规模通用计算平台的公司，也是世界上第一个对外提供 5K 云计算服务能力的公司。

飞天 5K 项目从 2009 年开始，从最开始的 30 台逐渐发展到 5000，不断解决系统核心的问题，比如说规模、稳定性、运维、容灾等等。而 iLogtail 在这一阶段诞生，最开始就是要解决 5000 台机器的监控、问题分析、定位的工作（如今的词语叫做“可观测性”）。从 30 到 5000 的跃升中，对于可观测问题有着诸多的挑战，包括单机瓶颈、问题复杂度、排查便捷性、管理复杂度等。

在 5K 阶段，iLogtail 本质上解决的是从单机、小规模集群到大规模的运维监控挑战，这一阶段 iLogtail 主要的特点有：

功能：实时日志、监控采集，日志抓取延迟毫秒级
性能：单核处理能力 10M/s，5000 台集群平均资源占用 0.5%CPU 核
可靠性：自动监听新文件、新文件夹，支持文件轮转，处理网络中断
管理：远程 Web 管理，配置文件自动下发
运维：加入集团 yum 源，运行状态监控，异常自动上报
规模：3W+ 部署规模，上千采集配置项，日 10TB 数据

2. 阿里集团阶段

iLogtail 在阿里云飞天 5K 项目中的应用解决了日志、监控统一收集的问题，而当时阿里巴巴集团、蚂蚁等还缺少一套统一、可靠的日志采集系统，因此我们开始推动 iLogtail 作为集团、蚂蚁的日志采集基础设施。从 5K 这种相对独立的项目到全集团应用，不是简单复制的问题，而我们要面对的是更多的部署量、更高的要求以及更多的部门：

百万规模运维问题：此时整个阿里、蚂蚁的物理机、虚拟机超过百万台，我们希望只用 1/3 的人力就可以运维管理百万规模的 Logtail。
更高的稳定性：iLogtail 最开始采集的数据主要用于问题排查，集团广泛的应用场景对于日志可靠性要求越来越高，例如计费计量数据、交易数据，而且还需要满足双十一、双十二等超大数据流量的压力考验。
多部门、团队：从服务 5K 团队到近千个团队，会有不同的团队使用不同的 iLogtail，而一个 iLogtail 也会被多个不同的团队使用，在租户隔离上对 iLogtail 是一个新的挑战。

经过几年时间和阿里集团、蚂蚁同学的合作打磨，iLogtail 在多租户、稳定性等方面取得了非常大的进步，这一阶段 iLogtail 主要的特点有：

功能：支持更多的日志格式，例如正则、分隔符、JSON 等，支持多种日志编码方式，支持数据过滤、脱敏等高级处理
性能：极简模式下提升到单核 100M/s，正则、分隔符、JSON 等方式 20M/s+
可靠性：采集可靠性支持 Polling、轮转队列顺序保证、日志清理保护、CheckPoint 增强；进程可靠性增加 Critical 自恢复、Crash 自动上报、多级守护

日志保序采集方案原理（细节可参考《iLogtail 技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》）

多租户：支持全流程多租户隔离、多级高低水位队列、采集优先级、配置级/进程级流量控制、临时降级机制

多租户隔离整体流程（细节可参考《iLogtail 技术分享(二)：多租户隔离技术+双十一实战效果》）

运维：基于集团 StarAgent 自动安装与守护，异常主动通知，提供多种问题自查工具
规模：百万+部署规模，千级别内部租户，10 万+采集配置，日采集 PB 级数据

3.云原生阶段

随着阿里所有 IT 基础设施全面云化，以及 iLogtail 所属产品 SLS（日志服务）正式在阿里云上商业化，iLogtail 开始全面拥抱云原生。从阿里内部商业化并对外部各行各业的公司提供服务，对于 iLogtail 的挑战的重心已经不是性能和可靠性，而是如何适应云原生（容器化、K8s，适应云上环境）、如何兼容开源协议、如何去处理碎片化需求。这一阶段是 iLogtail 发展最快的时期，经历了非常多重要的变革：

统一版本：iLogtail 最开始的版本还是基于 GCC4.1.2 编译，代码还依赖飞天基座，为了能适用更多的环境，iLogtail 进行了全版本的重构，基于一套代码实现 Windows/Linux、X86/Arm、服务器/嵌入式等多种环境的编译发版
全面支持容器化、K8s：除了支持容器、K8s 环境的日志、监控采集外，对于配置管理也进行了升级，支持通过 Operator 的方式进行扩展，只需要配置一个 AliyunLogConfig 的 K8s 自定义资源就可以实现日志、监控的采集

iLogtail Kubernetes 日志采集原理（细节可参考《Kubernetes 日志采集原理剖析》）

插件化扩展：iLogtail 增加插件系统，可自由扩展 Input、Processor、Aggregator、Flusher 插件用以实现各类自定义的功能

iLogtail 插件系统整体流程（细节可参考《iLogtail 插件系统简介》）

规模：千万部署规模，数万内外部客户，百万+采集配置项，日采集数十 PB 数据

四、开源背景与期待

闭源自建的软件永远无法紧跟时代潮流，尤其在当今云原生的时代，我们坚信开源才是 iLogtail 最优的发展策略，也是释放其最大价值的方法。iLogtail 作为可观测领域最基础的软件，我们将之开源，也希望能够和开源社区一起共建，持续优化，争取成为世界一流的可观测数据采集器。对于未来 iLogail 的发展，我们期待：

iLogtail 在性能和资源占用上相比其他开源采集软件具备一定优势，相比开源软件，在千万部署规模、日数十 PB 数据的规模性下为我们减少了 100TB 的内存和每年 1 亿的 CPU 核小时数。我们也希望这款采集软件可以为更多的企业带来资源效率的提升，实现可观测数据采集的“共同富裕”。
目前 iLogtail 还只是在阿里内部以及很小一部分云上企业（虽然有几万家，但是面对全球千万的企业，这个数字还很小），面对的场景相对还较少，我们希望有更多不同行业、不同特色的公司可以使用 iLogtail 并对其提出更多的数据源、处理、输出目标的需求，丰富 iLogtail 支持的上下游生态。
性能、稳定性是 iLogtail 的最基本追求，我们也希望能够通过开源社区，吸引更多优秀的开发者（钉钉扫面下方二维码或搜索钉钉群号：35576244 入群交流），一起共建 iLogtail，持续提升这款可观测数据采集器的性能和稳定性。

敲重点！

本次直播视频回放已上线至龙蜥社区官网（首页-支持-视频），直播 PPT 获取方式：关注龙蜥社区公众号，后台回复【龙蜥课件】或【龙蜥视频回放】即可。