fx|阿里千万实例可观测采集器 - iLogtail 正式开源 Java|C++|编程

文章图片

文章图片

文章图片

文章图片

文章图片

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多个不同部门的人要去使用这些数据。除了这些之外，还会有其他很多企业级的特性需要支持，例如：