阿里云 iLogtail 开源之路丨深度长文_阿里云 sls redis日志

2022 年 6 月底，阿里云 iLogtail 代码完整开源，正式发布了完整功能的 iLogtail 社区版。

iLogtail 作为阿里云 SLS 官方标配的采集器，多年以来一直稳定服务阿里集团、蚂蚁集团以及众多公有云上的企业客户，目前已经有千万级的安装量，每天采集数十 PB 的可观测数据，广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。

此次完整开源，iLogtail 社区版首次在内核能力上与企业版完全对齐，开发者可以构建出与企业版性能相当的 iLogtail 云原生可观测性数据采集器。

iLogtail 的核心定位是可观测数据的采集器，帮助开发者构建统一的数据采集层，助力可观测平台打造各种上层的应用场景。iLogtail 一贯秉承开放共建的原则，欢迎任何形式的社区讨论交流及公建。

可观测性探讨

生活中的可观测

可观测性指的是从系统的外部输出推断及衡量系统的内部状态。在我们生活当中也会遇到很多可观测的例子。汽车仪表盘就是一个很典型的可观测例子，在驾驶汽车过程中，特别需要高度重视就是行驶安全问题。而汽车仪表盘降低了识别汽车内部状态的门槛，即使非汽车工程专业人员也能通过仪表盘快速识别汽车的内部状态。

另外，我们平常的看病也可以看作是人体可观测的例子。在古代，医疗水平比较落后，整体来说人体是一个黑盒，只能通过表面的望闻问切来诊断病因，然而这种方式过度的依赖医生的经验、缺乏有力的数据支撑。而到了近代，随着心电图、X 光等医疗设备的发展，人体的内部机制变得越来越透明，大幅提升了医疗水平，给人们的身体健康带来了福音。通过上述的例子我们可以看到，可观测性不仅要能定性地反馈系统内部状态，最重要是要定量地论证系统内部状态，需要有足够的数据依据，也就是我们提到的可观测数据的质量和准确性。

机遇与挑战

回到我们软件行业，经过几十年的飞速发展，整个开发模式、系统架构、部署模式、基础设施等也都经过了几次颠覆性的变革，这些变革带来了更快的开发和部署效率，但随之而来的整个系统也更加复杂，开发所依赖的人和部门也更多、部署模式和运行环境也更加动态和不确定，这对可观测数据采集提出了更高的要求。

首先需要适应开发模式快速迭代的需求，需要能够与 DevOps 流程等进行高度的集成，通过轻量级、自动化集成的方式实现开发、测试、运维的一体化；

其次，需要适应部署架构分布式、容器化的需求，提升即时、准确发现业务服务动态的能力；

最后，云原生的发展也带来了更多的上下游依赖，因此也需要适应数据来源、数据类型越来越多的需求。

可观测性的数据基础

Logs、Traces、Metrics 作为可观测性数据的三大支柱，基本可以满足各类监控、告警、分析、问题排查等需求。这里大致分析下这三类数据的特点、转化方式以及适用场景：

• Logs：作为软件运行状态的载体，通过日志可以详细解释系统运行状态及还原业务处理的过程。常见日志类型包括运行日志、访问日志、交易日志、内核日志、满日志、错误日志等。
• Metrics：是指对系统中某一类信息的统计聚合，相对比较离散。一般有 name、labels、time、values 组成，Metrics 数据量一般很小，相对成本更低，查询的速度比较快。
• Traces：是最标准的调用日志，除了定义了调用的父子关系外（一般通过 TraceID、SpanID、ParentSpanID），一般还会定义操作的服务、方法、属性、状态、耗时等详细信息。

三者间的转换关系：Logs 在调用链场景结构化后其实可以转变为 Trace，在进行聚合、降采样操作后会变成 Metrics。

开源方案探讨

目前行业上主流的可观测开源方案，大概可以分为 5 个部分。

采集端：承载可观测数据采集及一部分前置的数据处理功能。随着云原生的发展，采集端也需要适应时代潮流，提供对 K8s 采集的友好支持。常见的采集端有 Filebeat、FluentD/Fluent-bIt，以及我们开源的 iLogtail。

消息队列：采集 Agent 往往不会直接将采集到的数据发送到存储系统，而是写入消息队列，起到削峰填谷的作用，避免流量洪峰导致存储系统宕机。常见消息队列为 Kafka、RabbitMQ 等。

计算：用于消费消息队列中的数据，经过处理、聚合后输出到存储系统。比较常见的为 Flink、Logstash 等。

存储分析引擎：提供采集数据持久化存储能力，并提供查询分析能力。常见的存储分析引擎为 Elasticsearch、ClickHouse 及 Loki。

可视化：借助 Kibana 和 Grafana 提供采集数据的可视化能力。

另外，日志服务 SLS 作为一款云原生观测与分析平台，为 Log、Metric、Trace 等数据提供大规模、低成本、实时的平台化服务。SLS 一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能，用户可以基于 SLS 快速构建一套完整的可观测平台。iLogtail 企业版作为 SLS 官方标配的采集器，承载了业务数据采集的职责，而 iLogtail 社区版正是从企业版发展而来的，功能及性能自然也继承了企业版的绝大部分能力。

iLogtail 发展历程

iLogtail 的前身源自阿里云的神农项目，自从 2013 年正式孵化以来，iLogtail 始终在不断演进。

诞生初期，面对阿里云自身和早期客户运维和可观测性需求，iLogtail 主要解决的是从单机、小规模集群到大规模的运维监控挑战，此时的 iLogtail 已经具备了基本的文件发现和轮转处理能力，可以实现日志、监控实时采集，抓取毫秒级延迟，单核处理能力约为 10M/s。通过 Web 前端可支持中心化配置文件自动下发，支持3W+ 部署规模，上千采集配置项，实现日10TB 数据的高效采集。

2015 年，阿里巴巴开始推进集团和蚂蚁金服业务上云，面对近千个团队、数百万终端、以及双 11、双 12 等超大流量数据采集的挑战，iLogtail 在功能、性能、稳定性和多租户支持方面都需要进行巨大的改进。

至 2017 年前后，iLogtail 已经具备了正则、分隔符、JSON 等多个格式日志的解析能力，支持多种日志编码方式，支持数据过滤、脱敏等高级处理能力，单核处理能力极简模式下提升到 100M/s，正则、分隔符、JSON 等方式 20M/s+。采集可靠性方面，增加文件发现 Polling 方式兜底、轮转队列顺序保证、日志清理丢失保护、CheckPoint 增强；进程可靠性方面，增加异常自动恢复、Crash 自动上报、守护进程等。通过全流程多租户隔离、多级高低水位队列、配置级/进程级流量控制、临时降级等机制，支持百万+部署规模，千级别租户，10 万+采集配置项，实现日 PB 级数据的稳定采集。

随着阿里推进核心业务全面上云，以及 iLogtail 所属日志服务（SLS）正式在阿里云上商业化，iLogtail 开始全面拥抱云原生。面对多元的云上环境、迅速发展的开源生态和大量涌入的行业客户需求，iLogtail 的发展的重心转移到解决如何适应云原生、如何兼容开源协议和如何去处理碎片化需求等问题上。

2018 年 iLogtail 正式支持docker 容器采集。

2019 年支持containerd 容器采集。

2020 年全面升级Metric 采集。

2021 年增加Trace 支持。通过全面支持容器化、K8S Operator 管控和可扩展插件系统，iLogtail支持千万部署规模，数万内外部客户，百万+采集配置项，实现日数十 PB 数据的稳定采集。

2021 年 11 月 iLogtail 迈出了开源的第一步，将Golang 插件代码开源。自开源以来，吸引了数百名开发者的关注，并且也有不少开发者贡献了 processor 跟 flusher 插件。

2022 年 6 月C++ 核心代码也正式开源了，自此开发者可以基于该版本构建完整的云原生可观测数据采集方案。

iLogtail 核心优势

核心优势 – 轻量、高效、稳定、可靠

轻量

可观测数据采集 Agent 作为一个基础设施，往往需要每台机器都有部署，比如目前阿里内部有数百万的装机量，每天会产生几十 PB 的可观测数据。因此不管是内存还是 CPU 的一点点节省，都能带来比较大的成本收益。特别是，K8s Sidecar 模式对于内存的要求更加苛刻，因为 iLogtail 与业务容器共同部署，iLogtail 部署量会随业务规模扩大而增长。

从设计初期，我们就比较重视 iLogtail 的资源占用问题，选择了主体部分 C++、插件部分 Golang 实现，并且通过一些技术细节（详见下文）的优化，使得内存还是 CPU 相对于同类 Agent 都有较大的优势。

高效采集

对于日志采集，比较常见的手段是轮询机制，这是一种主动探测的收集方式，通过定期检测日志文件有无更新来触发日志采集；相应的也存在一种被动监听的事件模式，依赖于操作系统的事件通知（对操作系统有一定的要求），常见的事件通知机制是 Linux 2.6.13 内核版本引入的 inotify 机制。轮询相对事件通知的实现复杂度要低很多、天然支持跨平台而且对于系统限制性不高；但轮询的采集延迟以及资源消耗较高，而且在文件规模较大时轮询一次的时间较长，比较容易发生采集延迟。

为了同时兼顾采集效率以及跨平台的支持，iLogtail 采用了轮询（polling）与事件（inotify）并存的模式进行日志采集，既借助了 inotify 的低延迟与低性能消耗的特点，也通过轮询的方式兼顾了运行环境的全面性。

iLogtail 内部以事件的方式触发日志读取行为。其中，polling 和 inotify 作为两个独立模块，分别将各自产生的 Create/Modify/Delete 事件，存入 Polling Event Queue 和 Inotify Event Queue 中。

• 轮询模块由 DirFilePolling 和 ModifyPolling 两个线程组成，DirFilePolling 负责根据用户配置定期遍历文件夹，将符合日志采集配置的文件加入到 modify cache 中；ModifyPolling 负责定期扫描 modify cache 中文件状态，对比上一次状态（Dev、Inode、Modify Time、Size），若发现更新则生成 modify event。
• inotify 属于事件监听方式，根据用户配置监听对应的目录以及子目录，当监听目录存在变化，内核会产生相应的通知事件。

由 Event Handler 线程负责将两个事件队列合并到内部的 Event Queue 中，并处理相应的 Create/Modify/Delete 事件，进而进行实际的日志采集。

此外，我们也通过一些技术手段，保证了 polling、inotify 两种机制的高效配合，整体近一步提升了 iLogtail 运行效率。

事件合并：为避免轮询事件和 inotify 事件多次触发事件处理行为，iLogtail 在事件处理之前将重复的轮询/inotify 事件进行合并，减少无效的事件处理行为；

轮询自动降级：如果在系统支持且资源足够的场景下，inotify 无论从延迟和性能消耗都要优于轮询，因此当某个目录 inotify 可以正常工作时，则该目录的轮询进行自动降级，轮询间隔大幅降低到对 CPU 基本无影响的程度。

日志顺序采集

日志顺序性采集是日志采集需要提供的基本功能，也是一个采集的难点，需要考虑如下场景：

适应不同的日志轮转(rotate)机制：日志轮转是指当日志满足一定条件（时间或文件大小）时，需要进行重命名、压缩等操作，之后创建新的日志文件继续写入。另外，不同使用日志库轮转文件的格式不尽相同，有的时间结尾，有的数字结尾等。

适应不同的采集路径配置方式：优秀的日志采集 agent 并不应该强制限制用户的配置方式，尤其在指定日志采集文件名时，需要适应不同用户的配置习惯。不管是精准路径匹配，还是模糊匹配，例如 *.log 或 .log，都不能出现日志轮转时多收集或者少收集的情况。

为了实现日志文件的顺序采集，首先需要定义好文件的唯一标识。我们知道在文件系统中，可以通过 dev+inode 的组合唯一标识一个文件。文件的 move 操作虽然可以改变文件名，但并不涉及文件的删除创建，dev+inode 并不会变化，因此通过 dev+inode 可以非常方便的判断一个文件是否发生了轮转。但是 dev+inode 只能保证同一时刻文件的唯一性，当涉及文件快速删除创建的时候，前后两个文件的 dev+inode 很可能是相同的。

因此纯粹通过 dev+inode 判断轮转并不可行，iLogtail 引入了文件签名（signature）的概念，使用日志文件的前 1024 字节的 hash 作为文件的 signature，只有当 dev+inode+signature 一致的情况下才会认为该文件是轮转的文件。此外，iLogtail 内部也引入了文件轮转队列，保证了文件的顺序采集。

采集可靠性

iLogtail 作为一个可观测数据基础采集组件，除了资源、性能外，可靠性也是一项关键指标。对于一些异常场景，iLogtail 也有充分的设计考虑，保证了在网络异常、流量突增、进程重启等场景下依然能够完成正常的采集任务。

日志处理阻塞

问题描述：iLogtail 需要大量部署在不同的业务机器上，运行环境是复杂多变的，应用日志 burst 写入、网络暂时性阻塞、服务端 Quota 不足、CPU/磁盘负载较高等情况在所难免，当这些情况发生时，很容易造成日志采集进度落后于日志产生进度，此时，iLogtail 需要在合理的资源限制下尽可能保留住这些日志，等待网络恢复或系统负载下降时将这些日志采集到服务器，并且保证日志采集顺序不会因为采集阻塞而混乱。

解决思路：

iLogtail 内部通过保持轮转日志 file descriptor 的打开状态来防止日志采集阻塞时未采集完成的日志文件被 file system 回收（在文件轮转队列中的 file descriptor 一直保持打开状态，保证文件引用计数至少为 1）。同时，通过文件轮转队列的顺序读取保证日志采集顺序与日志产生顺序一致。

若日志采集进度长时间持续落后于日志产生进度，完全的不回收机制，则很有可能出现文件轮转队列会无限增长的情况，进而导致磁盘被写爆，因此 iLogtail 内部对于文件轮转队列设置了上限，当 size 超过上限时禁止后续 Reader 的创建，只有这种持续的极端情况出现时，才会出现丢日志采集的情况。当然，在问题被放大之前，iLogtail 也会通过报警的方式，通知用户及时介入修复问题。

采集配置更新/进程升级

问题描述：配置更新或进行升级时需要中断采集并重新初始化采集上下文，iLogtail 需要保证在配置更新/进程升级时，即使日志发生轮转也不会丢失日志。

解决思路：
为保证配置更新/升级过程中日志数据不丢失，在 iLogtail 在配置重新加载前或进程主动退出前，会将当前所有采集的状态保存到本地的 checkpoint 文件中；当新配置应用/进程启动后，会加载上一次保存的 checkpoint，并通过 checkpoint 恢复之前的采集状态。

然而在老版本 checkpoint 保存完毕到新版本采集 Reader 创建完成的时间段内，很有可能出现日志轮转的情况，因此新版本在加载 checkpoint 时，会检查对应 checkpoint 的文件名、dev+inode 有无变化。

• 若文件名与 dev+inode 未变且 signature 未变，则直接根据该 checkpoint 创建 Reader 即可。
• 若文件名与 dev+inode 变化则从当前目录查找对应的 dev+inode，若查找到则对比 signature 是否变化。若 signature 未变则认为是文件轮转，根据新文件名创建 Reader；若 signature 变化则认为是该文件被删除后重新创建，忽略该 checkpoint。

进程 crash、宕机等异常情况

问题描述：在进程 crash 或宕机时，iLogtail 需要提供容错机制，不丢数据，尽可能的少重复采集。

解决思路：
进程 crash 或宕机没有退出前记录 checkpoint 的时机，因此 iLogtail 还会定期将采集进度 dump 到本地：除了恢复正常日志文件状态外，还会查找轮转后的日志，尽可能降低日志丢失风险。

核心优势 – 性能及隔离性

无锁化设计及时间片调度

业界主流的 Agent 对于每个配置会分配独立的线程/go runtime 来进行数据读取，而 iLogtail 数据的读取只配置了一个线程，主要原因是：

数据读取的瓶颈并不在于计算而是磁盘，单线程足以完成所有配置的事件处理以及数据读取。

单线程的另一个优势是可以使事件处理和数据读取在无锁环境下运行，相对多线程处理性价比较高。

iLogtail 数据读取线程可完成每秒 200MB 以上的数据读取（SSD 速率可以更高）。

但单线程的情况下会存在多个配置间资源分配不均的问题，如果使用简单的 FCFS（First Come First Serve）方式，一旦一个写入速度极高的文件占据了处理单元，它就一直运行下去，直到该文件被处理完成并主动释放资源，此方式很有可能造成其他采集的文件被饿死。

因此我们采用了基于时间片的采集调度方案，使各个配置间尽可能公平的调度，防止采集文件饿死的现象发生。iLogtail 将 Polling 以及 Inotify 事件合并到无锁的事件队列中，每个文件的修改事件会触发日志读取。每次读取从上次记录的偏移位置开始，并尝试在固定的时间片内将文读取到 EOF 处。如果时间片内读取完毕，则表示事件处理完成，删除事件；否则，将事件重新 Push 到队列尾部，等待下一次调用。

通过以上设计，保证了 iLogtail 可以高性能的进行数据采集。对比数据可以详见：

https://developer.aliyun.com/article/850614

多租户隔离

基于时间片的采集调度保证了各个配置的日志在数据读取时得到公平的调度，满足了多租户隔离中基本的公平性，但对于隔离性并未起到帮助作用。例如当部分采集配置因处理复杂或网络异常等原因阻塞时，阻塞配置依然会进行处理，最终会导致队列到达上限而阻塞数据读取线程，影响其他正常配置。为此我们设计了一套多级高低水位反馈队列用以在不同采集配置间实现读取、解析、发送各个步骤的有效的协调，为了更好的实现不同配置间隔离性，所以 iLogtail 会为每个配置创建一组队列。

多级：iLogtail 从采集到输出总体要经过读取->解析->发送三个步骤，iLogtail 在相邻步骤间分别设置一个队列。

高低水位：每个队列设置高低两个水位，高水位时停止非紧急数据写入，只有恢复到低水位时才允许再次写入。

反馈：在准备读取当前队列数据时会同步检查下一级队列状态，下一级队列高水位则跳过读取；当前队列从高水位消费到低水位时，异步通知关联的前一级队列。

极端场景处理

对于一些阻塞场景的可靠性也需要考虑，主要包括事件处理、数据读取逻辑以及数据发送控制三个方面：

事件处理与数据读取无关，即使读取关联的队列满也照常处理，这里的处理主要是更新文件 meta、将轮转文件放入轮转队列，可保证在配置阻塞的情况下，即使文件轮转也不会丢失数据。

当配置关联的解析队列满时，如果将事件重新放回队列尾，则会造成较多的无效调度，使 CPU 空转。因此 iLogtail 在遇到解析队列满时，将该事件放到一个专门的 blocked 队列中，当解析队列异步反馈时重新将 blocked 队列中的数据放回事件队列。

Sender 中每个配置的队列关联一个 SenderInfo，SenderInfo 中记录该配置当前网络是否正常、Quota 是否正常以及最大允许的发送速率。每次 Sender 会根据 SenderInfo 中的状从队列中取数据，这里包括：网络失败重试、Quota 超限重试、状态更新、流控等逻辑。

核心优势 – 插件化扩展能力

iLogtail 进程由两部分组成，一是 C++ 编写的主体二进制进程，提供了管控、文件采集、C++ 加速处理的功能；二是 Golang 编写的插件部分，通过插件系统实现了处理能力的扩展以及更丰富的上下游生态支持。

上下游生态：通过插件系统的扩展，目前 iLogtail 已经支持了众多数据源的接入，数据源类型覆盖 Log、Metric、Trace，数据源除了文件的采集，还包括了标准协议的支持，例如 HTTP、Mysql Binlog、Prometheus、Skywalking、syslog 等。数据输出生态也从 SLS 逐步扩展到 Kafka、gPRC 等，未来也会支持 ClickHouse、ElasticSearch 等。

处理能力扩展：iLogtail 采用 PipeLine 的设计，通过 Input 插件采集到数据，会经过采集配置中设定的 Processor 处理，之后经过 Aggregator 插件打包，最终通过 Flusher 发送到日志存储系统。数据处理环境包含数据切分、字段提取、过滤、数据增强等环节，所有插件可以自由组合。此外，针对于正则、Json、分隔符等特定格式，iLogtail 还提供了 C++ 加速能力。

快速迭代：开发者也可以根据自己的需求，定制开发相应的插件。因为每个插件相互独立，所以开发者只需要按照接口规范开发即可，入手门槛较低。以 Processor 插件接口为例，只需要实现以下接口，即可快速提供一个处理插件。

核心优势 – K8s 采集能力

作为容器编排领域的标准，Kubernetes（K8s）应用的场景越来越广泛，iLogtail 在 K8s 下也提供了完备的采集能力。

部署模式

在 Kubernetes 场景下，iLogtail 主要常用的有 3 种工作模式：

DaemonSet 方式：

• 模式：在 K8s 的每个 node 上部署一个 iLogtail，由该 iLogtail 采集节点上所有容器的日志到日志系统。
• 优点：运维简单、资源占用少、支持采集容器的标准输出和文本文件、配置方式灵活。
• 缺点：iLogtail 需要采集节点上所有容器的日志，各个容器之间的隔离性较弱，且对于业务超级多的集群可能存在一定的性能瓶颈。

Sidecar 方式：

• 模式：一个 POD 中伴随业务容器运行一个 iLogtail 容器，用于采集该 POD 中业务容器产生的日志。
• 优点：Sidecar 方式为每个需要采集日志的容器创建一个 Sidecar 容器，多租户隔离性好、性能好。
• 缺点：资源占用较多。

Deployment 方式：

• 模式：当业务容器用 PVC 挂载日志目录或者需要全局连接 API Server 获取 K8s 元数据等场景，可以选择在集群中部署一个单副本的 iLogtail Deployment 进行数据采集。

采集原理

自 K8s 问世以来，docker 运行时一直是主流，但是随着 K8s 将 dockershim 移除，K8s 官方推荐优先选择 containerd 或 CRI-O 作为容器运行时。docker 份额目前虽然还是主流但是已经在呈逐年下降的趋势，contailerd、cri-o 地位逐年都在快速上升。因此，从 K8s 支持全面性上，iLogtail 需要支持主流的运行时，目前已经支持 Docker 和 Containerd 两种容器引擎的数据采集。K8s 提供了强大的运维部署、弹性伸缩、故障恢复能力，极大地便利了分布式系统的开发和管理，然而这也带来了可观测数据采集难度的增大。特别是一些短 Job 场景，比如一些机器学习的训练任务，生命周期只有几分钟甚至几秒，如何快速准确地发现所需要采集的容器至关重要。

容器自动发现与释放

• iLogtail 通过访问位于宿主机上容器运行时（Docker Engine/ContainerD）的 sock 获取容器信息。
• 通过监听 Docker Event 及增量获取机制，及时感知容器新增与释放。

容器上下文信息获取

• 容器层级信息：容器名、ID、挂载点、环境变量、Label
• K8s 层级信息：Pod、命名空间、Labels。

容器过滤及隔离性：基于容器上下文信息，提供采集容器过滤能力，可以将不同采集配置应用到不同的采集容器上，既可以保证采集的隔离性，也可以减少不必要的资源浪费。

元信息关联：基于容器上下文信息和容器环境变量，提供在日志中富化 K8s 元信息的能力。

采集路径发现

• 标准输出：iLogtail 可以根据容器元信息自动识别不同运行时的标准输出格式和日志路径，不需要额外手动配置。
• 容器内文件：对于 overlay、overlay2 的存储驱动，iLogtail 可以根据日志类型及容器运行时自动拼接出采集路径，简单高效。

此外，对于 CICD 自动化部署和运维程度要求较高的用户，iLogtail 还提供了 K8s 原生支持，支持通过 CRD 的方式进行采集配置管理。目前该功能仅企业版可用，后续会逐步开源。该方案中，iLogtail K8s 新增了一个CustomResourceDefinition 扩展，名为 AliyunLogConfig。同时开发了 alibaba-log-controller 用于监听 AliyunLogConfig 事件并自动创建 iLogtail 的采集配置，进而完成日志采集工作。

企业版与社区版

差异比较

iLogtail 开源后，目前会有两个版本分支。

• 企业版：可以从阿里云 SLS 官方下载到。主要服务于 SLS。
• 社区版：从 GitHub 仓库，release 页下载。

iLogtail 开源，秉承技术共享与开发者共建的原则，所以核心功能是完全开源的，因此可以认为在核心采集能力上（包括采集处理功能、性能、可靠性等）与企业版是完全对标的。企业版相对于社区版的优势主要在于阿里云基础能力的集成上。

作为阿里云 SLS 官方标配采集器，与 SLS 无缝集成

• SLS 平台为 iLogtail 提供了强大的管控能力，及丰富的 API 支持。
• SLS 提供了对于 Log、Metric、Trace 的统一存储分析能力，使用 iLogtail 企业版将数据采集到 SLS，可以更好的构建各类上层应用。借助 SLS 可以实现日志上下文预览、Exactly Once 等高级特性。
• 借助 SLS 平台，可以实现第三方 Agent 的管控能力。例如，未来 SLS 也会跟 DeepFlow 进行深度集成。
• SLS 作为可观测平台，既可以承载可观测数据存储分析的功能，也可以承载流量管道的作用，可以简化架构部署。
• CloudLens For SLS 为 iLogtail 采集状态、数据流量监控提供了便捷的手段。
• 支持的操作系统、系统架构更加丰富，企业版支持 Windows 系统跟 ARM 架构。

阿里云服务加持

• 自动化安装部署能力更高，借助阿里云的运维服务，可以实现 iLogtail 批量自动安装。
• 与阿里云 ECS、ACK、ASK、EMR 等高度集成，可以一键安装部署，采集数据可以快速接入，内置分析。

企业版服务上的保证

• SLS 官方提供企业应用场景下最全最及时的文档/最佳实践支持
• 及时的专家服务（工单、群支持）与需求承接。
• 大规模/复杂场景专业化支持：比如 K8s 短 job，单节点大流量日志、大规模采集配置等。

基于 SLS 的云原生可观测平台

SLS 提供了对于 Log、Metric、Trace 的统一存储分析能力，并且也可以承载流量管道作用，具备强大的数据加工能力，基于 SLS 可以快速构建出一套云原生可观测平台。智能告警中枢、智能算法服务近一步增强了该平台的智能化水平。用户可以基于此平台，便捷高效的构建各类 ITOps、DevOps、SecOps、BusinessOps 上层应用。

iLogtail 企业版作为 SLS 官方标配官方标配采集器，在 SLS 数据接入领域充当着排头兵的指责，承载了大量的接入流量。

开源社区展望

技术共享一直是 iLogtail 秉承的理念，我们期望和欢迎更多开发者参与共建。我们希望跟开发者一起，将 iLogtail 的上下游生态建设得更加繁荣。为了提升开发者的体验，我们也会持续改善 iLogtail 的核心能力和框架能力，进一步降低开发门槛，丰富测试体系建设，为开发者提供必要的技术支持。

如何高效管理采集配置一直是可观测采集器的痛点，为此我们也会在不久的将来开源服务端全局管控方案及 iLogtail 监控方案，也欢迎开发者参与共建，一起打造统一的管控生态。

最后，OpenTelemetry 作为可观测领域的标准，iLogtail 也将积极拥抱。K8s 原生体验也是我们追求的方向，我们也有计划推出 iLogtail Operator。

关于 iLogtail

iLogtail 作为阿里云 SLS 提供的可观测数据采集器，可以运行在服务器、容器、K8s、嵌入式等多种环境，支持采集数百种可观测数据（日志、监控、Trace、事件等），已经有千万级的安装量。目前，iLogtail 已正式开源，欢迎使用及参与共建。

· GitHub:
https://github.com/alibaba/ilogtail

· 社区版文档：
https://ilogtail.gitbook.io/ilogtail-docs/about/readme

· 企业版官网：
https://help.aliyun.com/document_detail/65018.html

阿里云 iLogtail 开源之路丨深度长文