采集系统上云( 阿里正式开源可观测数据采集器iLogtail改造基本不可行)

　　采集系统上云(

阿里正式开源可观测数据采集器iLogtail改造基本不可行)

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

　　一个 iLogtail 和可观察性

　　可观察性并不是一个新概念，而是从IT系统中的监控、故障排除、稳定性构建、运行分析、BI、安全分析等逐步演化而来。与传统监控相比，可观察性是核心进化是采集尽可能多的可观察数据以达到白盒的目的。iLogtail的核心定位是可观察数据的采集器，可以采集尽可能多的采集各类可观察数据，帮助可观察平台打造各种上层应用场景。

　　2. 阿里巴巴可观察数据采集的挑战

　　对于可观察数据采集，有很多开源代理，比如Logstash、Filebeats、Fluentd、Collectd、Telegraf等，这些代理的功能非常丰富，这些代理和一些扩展的组合基本可以满足各种内部数据采集的要求。但由于性能、稳定性、控制等关键挑战不尽人意，我们最终选择进行自研：

　　1、资源消耗：目前阿里有上百万台主机（物理机/虚拟机/容器），每天产生几十PB的可观察数据，降低每1M的内存和每1M/s的性能。改善对于我们的资源节约来说是巨大的，节约的成本可能是几百万甚至几千万。目前很多开源代理的设计更注重功能而不是性能，改造现有的开源代理基本不可行。例如：

　　开源Agents单核处理性能一般在2-10M/s左右，我们希望有性能可以达到100M/s。采集目标增加，数据量增加，采集延迟，服务器异常。在这种情况下，开源代理内存将呈现爆发式增长，我们希望即使在各种环境下，内存也能处于较低的水位。开源代理的资源消耗无法控制。只能通过cgroups强制限制。效果就是一直OOM重启，数据一直上不来采集。并且我们希望在指定了 CPU、内存、流量等资源限制后，Agent 可以一直在这个限制内正常工作。

　　2、稳定性：稳定性是一个永恒的话题，数据的稳定性采集，除了保证数据本身的准确性采集，还要保证采集的Agent @采集 不能影响业务应用，否则影响将是灾难性的。至于稳定性建设，除了Agent本身的基本稳定性外，还有很多目前开源Agents还没有提供的特性：

　　Agent自恢复：Agent在遇到关键事件后可以自动恢复，提供进程自身、父子进程、守护进程等多个维度的自恢复能力。全球多维监控：可以从全球视角监控不同版本。不同采集配置、不同压力、不同区域/网络等属性的Agent的稳定性问题。问题隔离：作为Agent，无论问题如何出现，都需要尽可能地隔离问题。比如有多个采集配置，一个配置有问题，不能影响其他配置；代理本身有问题，不能影响机器上应用进程的稳定性。回滚能力：

　　3、Controllable：可观察数据的应用范围很广。几乎所有的业务、运维、BI、安全等部门都会用到它，各种数据都会在一台机器上生成。同一台机器产生的数据也会被多个部门的人使用。例如，在 2018 年，我们计算出平均而言，一个虚拟机上有 100 多种不同类型的数据。采集，设计了10多个不同部门的人想要使用这些数据。除了这些，还有很多其他的企业级功能需要支持，比如：

　　远程管理配置：在*敏*感*词*场景下，手动登录机器修改配置基本上是不可能的。因此，需要一套配置图形化管理、远程存储、自动投递机制，并且必须能够区分不同的应用和差异。地区、不同归属方等信息。同时，由于涉及到远程配置的动态加载和卸载，Agent也需要能够保证在配置Reload过程中数据不丢失或者不重现。采集配置优先级：当一台机器上运行多个采集配置时，如果遇到资源不足的情况，需要区分每个不同的配置优先级，并且资源优先给高优先级的配置，同时要保证低优先级的配置不被“饿死”。降级和恢复能力：在阿里，大促和秒杀是家常便饭。在这个高峰期，很多不重要的应用可能会被降级，相应的应用数据也需要降级。降级后，早高峰过后，需要有足够的Burst能力快速追赶。完整数据采集完整性：监控、数据分析等场景需要数据的准确性。数据准确的前提是可以采集及时到服务器，但是如何判断每台机器，每个文件采集的数据已经到达了对应的时间点，

　　基于以上背景和挑战，我们从 2013 年开始逐步优化和改进 iLogtail 以解决性能、稳定性、可控性等问题，并经历了多次 double十一、double十二、 的测试春晚红包等物品。目前iLogtail支持Logs、Traces、Metrics等多种数据的统一采集。核心功能如下：

　　支持多种Logs, Traces, Metrics数据采集，特别是容器和Kubernetes环境，数据非常友好采集 资源消耗极低，单核采集容量100M/s，对比对类似Observable数据采集的Agent性能提高5-20倍，稳定性高。它用于阿里巴巴和数以万计的阿里云客户的生产。部署量接近1000万。每天采集几十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现阶段的主要特点是：

<p>功能：实时日志，监控采集，日志捕获延迟毫秒级性能：单核处理能力10M/s，5000集群平均资源占用0.5% CPU核心可靠性：自动监控新文件，新建文件夹，支持文件轮换，处理网络中断管理：远程Web管理，自动配置文件分发运维：加入群yum源，运行状态监控，异常自动上报规模：3W+部署规模，千