11月23日，阿里巴巴正式开源可观察数据采集器iLogtail。iLogtail作为阿里巴巴内部可观察数据采集的基础设施，承载了阿里巴巴集团和蚂蚁集团的日志、监控、trace、事件等各类可观察数据的采集。iLogtail运行于服务器、容器、K8s、嵌入式等多种环境，支持上百种可观察数据的采集。目前，它拥有数千万的安装量，每天收集数十PB的可观察数据。它在网上被广泛使用。监控、问题分析/定位、运营分析、安全分析等场景。一、iLogtail与ObservabilityObservability并不是一个全新的概念，而是从IT系统监控、故障排查、稳定性建设、运营分析、BI、安全分析等逐渐演化而来的。Observability与传统监控相比，核心演进是收集尽可能多的可观察数据以达到白拳的目标。iLogtail的核心定位是可观察数据收集器，可以收集尽可能多的可观察数据，帮助可观察平台打造各种上层应用场景。2、阿里的可观察数据采集的挑战对于可观察数据的采集，有很多开源的agent，比如Logstash、Filebeats、Fluentd、Collectd、Telegraf等，这些Agent的功能非常丰富，结合这些Agent可以进行一定程度的扩展，基本可以满足各种内部数据的采集需求。但由于性能、稳定性、控制能力等一些关键挑战无法满足，我们最终选择了自己研究：1.资源消耗：目前有数百万台主机（物理机/虚拟机）/容器）在阿里巴巴。将生成数十PB的可观察数据。每减少1M的内存，每提高1M/s的性能，对于我们的资源节约来说都是巨大的，由此带来的成本节约可能是数百万甚至上千万。目前很多开源代理的设计更注重功能而不是性能，基本不可能基于现有的开源代理进行改造。例如：开源Agent一般单核处理性能在2-10M/s左右，我们希望能有能达到100M/s的性能。内存会呈现爆发式增长，我们希望即使在各种环境下，内存也能保持在一个较低的水平。无法控制开源代理的资源消耗。只能被cgroup限制。最后的效果是连续OOM，连续重启后就无法采集到数据。而我们希望在指定了CPU、内存、流量等资源限制后，Agent能够一直在这个限制内正常工作。2、稳定：稳定是一个永恒的话题。数据采集??的稳定性，除了要保证数据本身的准确性之外，还要保证采集到的Agent不能影响业务应用，否则影响将是灾难性的。在稳定性建设方面，除了Agent本身的基本稳定性外，还有很多目前开源Agent所不具备的特性：自恢复能力，如进程自身、父子进程、daemon进程的全局多维度监控：可以监控不同版本、不同采集配置、不同压力、不同的Agent的稳定性全局视角下的regions/networks等属性问题隔离：作为Agent，无论问题是如何发生的，都需要尽可能的隔离问题。比如一个Agent上有多个采集配置，一个配置问题不能影响其他配置；如果Agent本身有问题，也不会影响本机应用进程的稳定性。回滚能力：版本更新和发布是无法回避的问题。如何在出现问题时快速回滚，并保证问题和回滚期间的数据采集至少一次甚至恰好一次。3.可控：可观察的数据可用于广泛的应用。几乎所有的业务、运维、BI、安全等部门都会用到，一台机器也会产生各种数据。同一台机器产生的数据，也会有多个部门的人要用。比如在2018年，根据我们的统计，平均一台虚拟机上需要收集的数据超过100种，而这些数据被设计为来自10多个不同部门的人使用。.除了这些，还会有很多其他的企业级特性需要支持，比如：远程管理配置：在大规模场景下，基本上不可能手动登录机器修改配置，所以需要一套配置的图形化管理，远程存储和自动分发的机制，以及区分不同应用、不同Region、不同归属方的能力。同时，由于涉及到远程配置的动态加载和卸载，因此Agent还需要能够保证配置重载时数据不丢失或重载。采集配置优先级：当一台机器上运行多个采集配置时，如果资源不足，需要区分每个不同的配置优先级。资源优先分配给高优先级的配置，同时也要保证低优先级的配置不被“饿死”。在这个高峰期，很多不重要的应用可能会被降级，相应应用的数据也需要降级。降级后，凌晨高峰过后，需要有足够的突发能力，才能快速赶上数据采集的完整性：监控数据分析、数据分析等场景，对数据的准确性要求很高。数据准确的前提是能够及时采集到服务器。但是如何保证每台机器、每一个文件的数据在计算前都已经在对应的时间点采集到，需要一套非常复杂的计算机制基于以上背景和挑战，我们一直在逐步优化和完善iLogtail2013年开始解决性能、稳定性、可控性等问题。2、春晚红包等物品测试。目前iLogtail支持Logs、Traces、Metrics等各类数据的统一采集。核心特性如下：支持多种Logs、Traces、Metrics的数据采集，对容器和Kubernetes环境特别友好。数据采集??的资源消耗极低。单核采集能力100M/s，比同类可观测数据采集Agent性能提升5-20倍，稳定性高。已经在阿里巴巴和数万阿里云客户的生产中使用和验证。十PB可观测数据支持插件扩展，可随意扩展数据采集、处理、聚合、发送模块。支持配置远程管理，支持图形化、SDK、K8sOperator形式的配置管理，轻松管理百万级机器。数据采集??支持自主监控、流量控制、资源控制、主动告警、采集统计等多种高级管控特性。3、iLogtail的发展历史秉承了阿里巴巴人简单的特点，iLogtail的命名也很简单。我们一开始期待的是能够有一个工具统一taillog，所以叫Logtail。之所以加上“i”，主要是因为当时使用了inotify技术，可以将日志采集的延迟控制在毫秒级，所以最后才叫iLogtail。自2013年开始研发以来，iLogtail的整个发展历程大致可以分为三个阶段，即飞天5K阶段、阿里集团阶段、云原生阶段。1、飞天5K舞台是中国云计算领域的里程碑。2013年8月15日，阿里巴巴集团正式运营服务器规模达5000台（5K）的“飞天”集群，成为中国第一家拥有大规模通用计算自主研发平台的公司，也是第一家进入该平台的公司。全球提供5K云计算服务能力。飞天5K项目从2009年开始，从最初的30台逐步发展到5000台，不断解决系统的规模、稳定性、运维、容灾等核心问题。而iLogtail就是在这个阶段诞生的，一开始是为了解决5000台机器的监控、问题分析、定位（今天这个词叫“可观察性”）。从30台到5000台的飞跃，对于可观测问题的挑战有很多，包括单机瓶颈、问题复杂度、排查方便性、管理复杂度等。5K之前5K(2013)监控指标单机飞神农采集系统状态。只能支持1000个单位以内的索引聚合。数据在本地生成，由iLogtail收集到SLS服务器，包括：Indicatordata：Metrics（神农指标）Logdata：Logs（飞天日志，系统日志等）Linkdata：Traces（飞天Trace）SLS根据日志处理日志针对需求提供三种处理方式：实时指标计算和展示（分布式神农版）索引数据提供实时查询（Logs、Traces）数据导入ODPS（现称MaxCompute）进行离线分析日志查询日志在机器grep中，或者使用pssh工具批量grep。速度慢，可能会清除日志，影响机器性能，存在误操作/安全隐患。对于链接检查，所有机器上grep只能用一个JobID。离线分析使用脚本rsync将各台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。在5K阶段，iLogtail本质上解决了从单机、小规模集群到大规模运维监控的挑战。iLogtail现阶段的主要特点是：功能：实时日志、监控采集、日志抓取延迟毫秒级性能：单核处理能力10M/s，5000个集群平均资源占用0.5%CPU核心可靠性：自动监控新文件和新文件夹，支持文件轮转，处理网络中断管理：远程web管理，配置文件自动下发运维：加入yum源组，监控运行状态，自动上报异常规模：3W+部署规模，上千个采集配置项，每天10TB数据量当时阿里巴巴集团和蚂蚁集团还缺乏统一可靠的日志采集系统，所以我们开始推广iLogtail作为集团和蚂蚁集团的日志采集基础设施。从5K这样一个相对独立的项目到整个集团的应用，不是简单复制的问题，而是我们要面对的是更多的部署，更高的要求，更多的部门：百万级运维问题：这个当时阿里、蚂蚁的物理机和虚拟机都超过百万台。我们希望只用三分之一的人力来运营和管理百万规模的Logtail。稳定性更高：iLogtail一开始采集的数据主要用于Troubleshooting，集团广泛的应用场景对日志的可靠性要求越来越高，比如计费和计量数据，交易数据，也需要满足压力测试双十一、双十二等超大数据流量。多部门多团队：从服务5000个团队到近千个团队，不同的团队会使用不同的iLogtail，一个iLogtail也会被多个不同的团队使用。租户隔离对iLogtail来说是一个新的挑战。经过与阿里集团、蚂蚁同学几年的合作打磨，iLogtail在多租户和稳定性方面有了长足的进步。iLogtail现阶段的主要特点是：功能：支持更多的日志格式，如正则、定界符、JSON等，支持多种日志编码方式，支持数据过滤、脱敏等高级处理性能：在极简模式下,单核100M/s,regular,delimiter,JSON等方式20M/s+可靠性：采集可靠性支持Polling，轮换队列顺序保证，日志清理保护，CheckPoint增强；进程可靠性增加Critical自恢复，Crash自动上报，多级守护日志保序解决原理（详见《iLogtail技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》）Multi-tenant：支持全进程多租户隔离，多级高和低水位队列，采集优先级，配置级/进程级流控，临时降级机制多租户隔离全流程（详见《iLogtail技术分享(二)：多租户隔离技术+双十一实战效果》）和守护，异常主动通知，提供多种问题自查工具随着全面云化，iLogtail的产品SLS（日志服务）在阿里云正式商用，iLogtail开始全面拥抱云原生。从阿里内部的商业化，到对外对外提供服务的各行各业，iLogtail挑战的重点不是性能和可靠性，而是如何适配云原生（容器化、K8s、适配云环境)，如何兼容开源协议，如何处理碎片化的需求。这个阶段是iLogtail发展最快的时期，经历了很多重要的变化：统一版本：iLogtail初始版本是基于GCC4.1.2编译的，代码也依赖于飞天基地。完整版进行了重构，基于一套代码，全面支持Windows/Linux、X86/Arm、server/embedded等多种环境的编译发布。容器化和K8s：除了支持容器和K8s环境的日志和监控采集之外，配置管理也进行了升级。支持通过Operator进行扩容。只需要配置一个AliyunLogConfig的K8s自定义资源，就可以实现日志的收集和监控。iLogtailKubernetes日志采集原理（详见《Kubernetes日志采集原理剖析》）插件扩展：iLogtail增加了插件系统，可以自由扩展Input、Processor、Aggregator、Flusher插件，实现各种自定义功能。iLogtail插件系统整体流程（详见《iLogtail插件系统简介》）数万个内外部客户，百万+采集配置项，每日采集数十PB数据四、开源背景及预期封闭的自建软件永远跟不上时代的潮流，尤其是在云原生时代的今天，我们坚信开源是iLogtail的最佳发展策略，也是释放其最大价值的方式。iLogtail作为可观测领域最基础的软件，是开源的，我们希望与开源社区共同建设，持续优化，力争成为世界一流的可观测数据采集器。对于iLogail未来的发展，我们预计：iLogtail在性能和资源占用方面较其他开源采集软件有一定优势。100TB内存和每年1亿个CPU核心小时数。我们也希望这款采集软件能够为更多的企业提高资源效率，实现可观测数据采集的“共同富裕”。目前iLogtail只在阿里巴巴和云上的小部分企业（虽然有几万家企业，但这个数字面对全球几千万的企业还是很小的），还有场景比较少。我们希望有更多不同行业、不同特点的公司可以使用iLogtail，并对数据来源??、处理、输出目标提出更多要求，丰富iLogtail支持的上下游生态。性能和稳定性是iLogtail最基本的追求。我们也希望通过开源社区吸引更多优秀的开发者共同打造iLogtail，不断提升这款可观察数据采集器的性能和稳定性。链接总结：1）阿里官方开源可观察数据采集器iLogtail：https://github.com/alibaba/ilogtail2）《iLogtail技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》：https://zhuanlan.zhihu.com/p/293036003）《iLogtail技术分享(二)：多租户隔离技术+双十一实战效果》:https://www.sohu.com/a/205324880_4659594)?:https://developer.aliyun.com/article/8063695)《iLogtail插件系统简介》:https://github.com/alibaba/ilogtail/blob/main/docs/en/concept%26designs/Overview.md
