阿里千万实例可观测采集器 - iLogtail 正式开源

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，无论怎样出现问题，都需要尽可能的隔离