利用采集器 采集的平台(阿里正式开源可观测数据采集器iLogtail（/alibaba/ilogtail）)

　　利用采集器 采集的平台(阿里正式开源可观测数据采集器iLogtail（/alibaba/ilogtail）)

　　11月23日，阿里巴巴正式开放了可观察数据采集器iLogtail（/alibaba/ilogtail）。作为阿里巴巴内部可观察数据采集的基础设施，iLogtail承载了阿里巴巴集团的采集工作和蚂蚁的日志、监控、跟踪、事件等可观察数据。iLogtail运行在服务器、容器、K8s、嵌入式等各种环境中，支持采集上百个可观察数据。目前有千万级安装量，每天都有采集几十PB的数据可用。观测数据广泛应用于在线监控、问题分析/定位、运营分析、安全分析等各种场景。

　　iLogtail 和可观察性

　　

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

　　

　　阿里可观测数据的挑战采集

　　

　　对于可观察数据采集，有很多开源代理，例如Logstash、Filebeats、Fluentd、Collectd、Telegraf等，这些代理的功能非常丰富，这些代理的组合可以用于一定的用途扩展，基本可以满足各种内部数据的采集需求。但是，由于性能、稳定性、管控能力等一些关键挑战无法解决，我们最终选择了自己发展：

　　资源消耗：目前阿里巴巴有几百万台主机（物理机/虚拟机/容器），每天产生几十PB的可观察数据。每减少 1M 内存，每 1M/s 性能提升对我们的资源来说都是非常重要的。节省的费用是巨大的，由此带来的成本节省可能达到数百万甚至数千万。目前很多开源代理的设计更注重功能而不是性能，在现有开源代理的基础上进行改造基本上是不可能的。比如：开源代理一般单核处理性能在2-10M/s左右，我们希望能有100M/s的性能。采集目标增加，数据量增加，采集延迟，服务端异常等情况，开源代理的内存将呈现爆发式增长，我们希望即使在各种环境下，内存也能处于低水位。开源代理的资源消耗无法控制，只能通过cgroup来限制。最后的效果就是一直OOM，一直重启，数据一直采集上不来。并且我们希望在指定了 CPU、内存、流量等资源限制后，Agent 始终可以在这个限制内正常工作。稳定性：稳定性是一个永恒的话题，数据采集的稳定性，除了保证数据本身采集的准确性之外，还要保证采集的Agent @> 不能影响业务应用，否则影响将是灾难性的。在稳定性建设方面，除了代理本身的基本稳定性，还有很多开源代理还没有提供的特性： . ，如对进程本身、父子进程、守护进程的全局多维度监控：可以监控不同版本、不同采集配置、不同压力、不同区域/网络等的Agent的稳定性从全局角度看属性。隔离：作为Agent，无论问题如何发生，都需要尽可能地隔离问题，比如一个Agent上有多个采集 有很多开源代理还没有提供的特性： 代理自恢复：代理遇到关键事件后可以自动恢复，并提供多维度的自恢复能力。，如对进程本身、父子进程、守护进程的全局多维度监控：可以监控不同版本、不同采集配置、不同压力、不同区域/网络等的Agent的稳定性从全局角度看属性。隔离：作为Agent，无论问题如何发生，都需要尽可能地隔离问题，比如一个Agent上有多个采集 有很多开源代理还没有提供的特性： 代理自恢复：代理遇到关键事件后可以自动恢复，并提供多维度的自恢复能力。，如对进程本身、父子进程、守护进程的全局多维度监控：可以监控不同版本、不同采集配置、不同压力、不同区域/网络等的Agent的稳定性从全局角度看属性。隔离：作为Agent，无论问题如何发生，都需要尽可能地隔离问题，比如一个Agent上有多个采集 并提供多维度的自愈能力。，如对进程本身、父子进程、守护进程的全局多维度监控：可以监控不同版本、不同采集配置、不同压力、不同区域/网络等的Agent的稳定性从全局角度看属性。隔离：作为Agent，无论问题如何发生，都需要尽可能地隔离问题，比如一个Agent上有多个采集 并提供多维度的自愈能力。，如对进程本身、父子进程、守护进程的全局多维度监控：可以监控不同版本、不同采集配置、不同压力、不同区域/网络等的Agent的稳定性从全局角度看属性。隔离：作为Agent，无论问题如何发生，都需要尽可能地隔离问题，比如一个Agent上有多个采集 从全球的角度来看，不同的地区/网络和其他属性。隔离：作为Agent，无论问题如何发生，都需要尽可能地隔离问题，比如一个Agent上有多个采集 从全球的角度来看，不同的地区/网络和其他属性。隔离：作为Agent，无论问题如何发生，都需要尽可能地隔离问题，比如一个Agent上有多个采集

　　可控：可观察数据的应用范围很广，几乎所有的业务、运维、BI、安全等部门都会用到，在一台机器上会产生多种数据，同一台机器产生的数据也会被使用。会有多个部门的人来使用。比如2018年，根据我们的统计，平均一个虚拟机上有100多个不同类型的数据需要采集，并且设计了来自10多个不同部门的人来使用它. 这些数据。除了这些，还有很多其他的企业级功能需要支持，比如：远程管理配置：在*敏*感*词*场景下，手动登录机器修改配置基本上是不可能的，所以一套图形化的管理配置，远程存储和自动分发的机制，以及区分不同应用、不同Region、不同属性等信息的能力。同时，由于远程配置的动态加载和卸载，Agent还需要能够保证配置过程中数据不丢失或不重复Reload 采集配置优先级：当有多个< @采集机器上运行的配置，如果遇到资源不足，需要区分不同的配置优先级，资源会优先分配给高优先级的配置，同时保证低优先级的配置不会"饿死”降级和恢复能力：在阿里，大促销和高峰是家常便饭。在这个高峰期，可能会有很多不重要的应用降级，相应应用的数据也需要降级。降级后，凌晨高峰过后，需要有足够的Burst能力快速追逐数据的完整性采集：监控、数据分析等场景都需要数据的准确性。数据准确的前提是能够及时传递到服务器采集，但是如何确定每台机器，每个文件采集的数据到达对应的时间点，这就需要很复杂的计算机制 降级后，凌晨高峰过后，需要有足够的Burst能力快速追逐数据的完整性采集：监控、数据分析等场景都需要数据的准确性。数据准确的前提是能够及时传递到服务器采集，但是如何确定每台机器，每个文件采集的数据到达对应的时间点，这就需要很复杂的计算机制 降级后，凌晨高峰过后，需要有足够的Burst能力快速追逐数据的完整性采集：监控、数据分析等场景都需要数据的准确性。数据准确的前提是能够及时传递到服务器采集，但是如何确定每台机器，每个文件采集的数据到达对应的时间点，这就需要很复杂的计算机制

　　

　　基于上述背景和挑战，我们从 2013 年开始对 iLogtail 进行逐步优化和改进，以解决性能、稳定性、可控性等问题。春晚红包等项目的考验。目前iLogtail支持Logs、Traces、Metrics等各类数据的统一采集。核心功能如下：

　　iLogtail发展历程

　　秉承阿里人朴实的特点，iLogtail的命名也非常简单。我们一开始的预期是有一个统一记录尾日志的工具，所以叫Logtail。之所以加上“i”，主要是因为当时使用了inotify的技术。，可以控制日志采集的延迟毫秒，所以最后叫iLogtail。从2013年开始研发以来，iLogtail的整个开发过程大致可以分为三个阶段，分别是飞天5K阶段、阿里巴巴集团阶段和云原生阶段。

　　

　　飞天5K舞台

　　作为中国云计算领域的里程碑，2013年8月15日，阿里巴巴集团正式运营5000台（5K）服务器规模的“飞天”集群，成为国内第一家自主研发*敏*感*词*通用计算平台。全球首家提供5K云计算服务能力的公司。

　　飞天5K项目从2009年开始，逐步从30台发展到5000台，不断解决系统的规模、稳定性、运维、容灾等核心问题。而iLogtail就是在这个阶段诞生的。最开始是为了解决5000台机器的监控、问题分析、定位（今天这个词叫“可观察性”）。在从 30 到 5000 的跃迁中，可观察到的问题有很多挑战，包括单机瓶颈、问题复杂性、故障排除的难易程度和管理复杂性。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　5K之前

　　5K (2013)

　　监测指标

　　系统状态通过单机飞天神农聚合。只能支持1000个单位以内的指标聚合。

　　数据在本地生成，由iLogtail采集到SLS服务器，包括： Metrics数据：Metrics（神农Metrics） 日志数据：Logs（飞天日志、系统日志等） 链接数据：Traces（飞天Trace） 基于日志的SLS处理需求 提供三种处理方式： 实时索引计算和展示（神农分布式版本） 索引数据提供实时查询（Logs、Traces） 数据导入ODPS（现称MaxCompute）进行离线分析

　　日志查询

　　登录机器进行grep，或者使用pssh工具批量grep。速度慢，可能会清理日志，影响机器性能，存在误操作/安全隐患。

　　链接检查

　　在所有机器上只能使用一个 JobID 进行 grep。

　　离线分析

　　使用脚本rsync将每台机器上的日志导入离线系统进行计算。性能差，运维管理复杂。

　　在 5K 阶段，iLogtail 从本质上解决了从单机、小规模集群到*敏*感*词*运维监控的挑战。这个阶段iLogtail的主要特点是：

　　阿里小组赛

　　iLogtail在阿里云飞天5K项目中的应用解决了日志统一采集和监控的问题。当时阿里巴巴集团、蚂蚁等还缺乏一个系统的一、可靠日志采集系统，所以我们开始推广iLogtail作为集团，蚂蚁的日志采集基础设施。从5K等相对独立的项目，到全集团的应用，都不是简单的复制，而是要面对更多的部署、更高的要求和更多的部门：

　　百万级运维问题：此时阿里巴巴和蚂蚁都有超过百万的物理机和虚拟机。我们希望只有 1/3 的人力可以操作和管理一个稳定性更高的百万级 Logtail：iLogtail 一开始，采集 的数据主要用于排查问题。本集团广泛的应用场景对计费计量数据、交易数据等日志可靠性的要求越来越高。超大数据流量十二级压测。多部门多团队：从服务5K团队到近1000个团队，不同的团队会使用不同的iLogtail，一个iLogtail也会被多个不同的团队使用，这对iLogtail在租户隔离方面提出了新的挑战。

　　经过几年与阿里巴巴集团和蚂蚁同学的合作，iLogtail在多租户和稳定性方面取得了长足的进步。现阶段iLogtail的主要特点有：

　　

　　日志顺序保存采集方案原理（详见《iLogtail技术分享（一)：轮询+Inotify组合下的日志顺序保存采集方案》）

　　

　　多租户隔离整体流程（详情请参考《iLogtail技术分享（二)：多租户隔离技术+双十一实战》）

　　云原生阶段

　　随着阿里所有IT基础设施的全面云化，以及iLogtail产品SLS（日志服务）在阿里云上的正式商用，iLogtail已经开始全面拥抱云原生。从阿里巴巴内部商业化和对外各行各业提供服务来看，iLogtail挑战的重点不是性能和可靠性，而是如何适应云原生（容器化、K8s、适应云环境），如何做到兼容开源协议，如何处理碎片化需求。这个阶段是 iLogtail 增长最快的时期，经历了很多重要的变化：

　　

　　iLogtail Kubernetes log采集原理（详见《Kubernetes log采集原理解析》）

　　

　　iLogtail插件系统的整体流程（详细请参考《iLogtail插件系统介绍》）

　　开源背景和期望

　　封闭自建的软件永远跟不上时代的潮流，尤其是在云原生时代，我们坚信开源是iLogtail最好的发展战略，也是释放其最大价值的途径。iLogtail作为可观察领域最基础的软件，已经开源，我们希望与开源社区一起共建，不断优化，努力成为世界一流的可观察数据采集器。对于iLogail未来的发展，我们期待：

　　与其他开源采集软件相比，iLogtail在性能和资源使用上具有一定的优势。与开源软件相比，在千万级部署和每天几十PB数据的规模下，内存和年存储容量减少了100TB。1亿个CPU核心小时。我们也希望这个采集软件能够为更多的企业提升资源效率，实现可观测数据的“共同繁荣”采集。目前iLogtail仅在阿里巴巴和少数云上企业使用，场景相对较少。我们希望更多不同行业、不同特点的公司能够使用iLogtail，并为其提供更多的数据源。，处理和输出目标，丰富 iLogtail 支持的上下游生态系统。性能和稳定性是 iLogtail 最基本的追求。我们也希望通过开源社区吸引更多优秀的开发者共同打造iLogtail，不断提升这个可观察数据采集器的性能和稳定性。iLogtail相关信息列表

　　iLogtail由C++部分和Golang插件部分组成。目前，功能最丰富、扩展性最强的Golang插件部分已经开源。C++部分的开源整理工作正在进行中，我们将在接下来的几个月与大家见面。

　　进一步参考

　　为你推荐

　　阿里云日志服务：数据处理备忘单的使用

　　阿里云日志服务：基于日志服务的数据预处理与交付

　　阿里云日志服务：Grafana插件深度解析