iLogtail 开源之路

Posted 2023-01-11 阿里云云栖号

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插件接口为例，只需要实现以下接口，即可快速提供一个处理插件。

// Processor also can be a filter
type Processor interface 
    // Init called for init some system resources, like socket, mutex...
    Init(Context) error
    // Description returns a one-sentence description on the Input
    Description() string
    // Apply the filter to the given metric
    ProcessLogs(logArray []*protocol.Log) []*protocol.Log

核心优势 -- 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。

原文链接

本文为阿里云原创内容，未经允许不得转载。