iLogtail 开源之路

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

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

复制代码

核心优势 -- 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。
原文链接
本文为阿里云原创内容，未经答应不得转载。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。