关于日志: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 的前身源自阿里云的神农我的项目，自从 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 ++ 外围代码也正式开源了，自此开发者能够基于该版本构建残缺的云原生可观测数据采集计划。

可观测数据采集 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}

作为容器编排畛域的规范，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 提供了对于 Log、Metric、Trace 的对立存储剖析能力，并且也能够承载流量管道作用，具备弱小的数据加工能力，基于 SLS 能够疾速构建出一套云原生可观测平台。智能告警中枢、智能算法服务近一步加强了该平台的智能化程度。用户能够基于此平台，便捷高效的构建各类 ITOps、DevOps、SecOps、BusinessOps 下层利用。

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

技术共享始终是 iLogtail 秉承的理念，咱们冀望和欢送更多开发者参加共建。咱们心愿跟开发者一起，将 iLogtail 的上下游生态建的更丰盛。为了晋升开发者的体验，咱们也会继续的改善 iLogtail 外围能力跟框架能力，进一步升高开发门槛，丰盛测试体系建设，为开发者提供必要的技术支持。

如何高效治理采集配置始终是可观测采集器的痛点，为此咱们也会在不久未来开源服务端全局管控计划及 iLogtail 监控计划，也欢送开发者参加共建，一起打造对立的管控生态。

最初，OpenTelemetry 作为可观测畛域的规范，iLogtail 也将踊跃拥抱。K8s 原生体验也是咱们谋求的方向，咱们也有打算推出 iLogtail Operator。

原文链接

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

关于日志:iLogtail-开源之路

可观测性探讨

生存中的可观测

时机与挑战

可观测性的数据根底

开源计划探讨

iLogtail 倒退历程

iLogtail 外围劣势

外围劣势 — 轻量、高效、稳固、牢靠

轻量

高效采集

日志程序采集

采集可靠性

日志解决阻塞

采集配置更新 / 过程降级

外围劣势 — 性能及隔离性

无锁化设计及工夫片调度

多租户隔离

极其场景解决

外围劣势 — 插件化扩大能力

外围劣势 — K8s 采集能力

部署模式

采集原理

企业版与社区版

差别比拟

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

开源社区瞻望