共计 5377 个字符，预计需要花费 14 分钟才能阅读完成。
简介：11 月 23 日，阿里正式开源可观测数据采集器 iLogtail。作为阿里外部可观测数据采集的基础设施，iLogtail 承载了阿里巴巴团体、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail 运行在服务器、容器、K8s、嵌入式等多种环境，反对采集数百种可观测数据，目前曾经有千万级的装置量，每天采集数十 PB 的可观测数据，广泛应用于线上监控、问题剖析 / 定位、经营剖析、平安剖析等多种场景。
作者 | 元乙
起源 | 阿里技术公众号
11 月 23 日，阿里正式开源可观测数据采集器 iLogtail。作为阿里外部可观测数据采集的基础设施，iLogtail 承载了阿里巴巴团体、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail 运行在服务器、容器、K8s、嵌入式等多种环境，反对采集数百种可观测数据，目前曾经有千万级的装置量，每天采集数十 PB 的可观测数据，广泛应用于线上监控、问题剖析 / 定位、经营剖析、平安剖析等多种场景。
一 iLogtail 与可观测性
可观测性并不是一个全新的概念，而是从 IT 零碎中的监控、问题排查、稳定性建设、经营剖析、BI、平安剖析等逐步演变而来，可观测性相比传统监控，最外围的演进是尽可能多的收集各类可观测数据，来实现目标的白盒化。而 iLogtail 的外围定位就是可观测数据的采集器，可能尽可能多的采集各类可观测性数据，助力可观测平台打造各种下层的利用场景。
二 阿里可观测数据采集的挑战
对于可观测数据的采集，有很多开源的 Agent，例如 Logstash、Filebeats、Fluentd、Collectd、Telegraf 等。这些 Agent 的性能十分丰盛，应用这些 Agent 的组合再进行肯定的扩大，根本能够满足外部各类数据的采集需要。但因为一些性能、稳定性、管控能力等关键性的挑战无奈满足，最终咱们还是抉择自研：
1、资源耗费：目前阿里外部有数百万的主机（物理机 / 虚拟机 / 容器），每天会产生几十 PB 的可观测数据，每 1M 的内存缩小、每 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 的最根本谋求，咱们也心愿可能通过开源社区，吸引更多优良的开发者，一起共建 iLogtail，继续晋升这款可观测数据采集器的性能和稳定性。
原文链接
本文为阿里云原创内容，未经容许不得转载。
