2022 注定是不平凡的一年，在这一年中我们亲历了北京冬奥会、冬残奥会成功举办，冰雪健儿驰骋赛场，取得了骄人成绩；见证了神舟十三号、十四号、十五号接力腾飞，中国空间站全面建成，“太空之家”遨游苍穹；目睹了潘帕斯雄鹰时隔36年再度登顶世界之巅，球王梅西君临波斯湾。同时在这一年，iLogtail 也迈出了发展历程中关键的一步，于6月正式完整开源。

iLogtail 作为一款阿里云日志服务（SLS）团队自研的可观测数据采集器，拥有的轻量级、高性能、自动化配置等诸多生产级别特性，可以部署于物理机、虚拟机、Kubernetes 等多种环境中，用于采集文件、容器输出、指标等各类可观测数据。iLogtail 的核心定位是帮助开发者构建统一的数据采集层，助力可观测平台打造各种上层的应用场景；此外，对于一些寻求轻量计算的场景，也可以使用 iLogtail 承担一些数据聚合、数据过滤、数据路由等功能。

开源之路 -- 路漫漫其修远兮，吾将上下而求索

当今云原生时代是个快速发展变迁的时代，闭源自建的软件永远无法紧跟时代潮流，我们坚信开源才是 iLogtail 最优的发展策略，也是释放其最大价值的方法。通过开源，iLogtail 插上了腾飞的翅膀，仿佛获得了新的动力之源。目前已有来自字节跳动、同程旅行、石墨文档、小红书、哔哩哔哩、阿里巴巴等知名企业的多位同学参与社区共建，相信通过大家共同的努力，iLogtail 将会被打造成业界最顶级的可观测数据采集器。

iLogtail 的前身源自阿里云的神农项目，自从2013年正式孵化以来，10年的发展历程中，iLogtail 始终在不断演进，到目前为止总体经历了四个阶段：飞天 5K 阶段、阿里集团阶段、云原生阶段、开源共建阶段。

2021年11月 iLogtail 迈出了开源的第一步，在 Github 上低调开源了 Golang 插件部分的代码。2022年6月，iLogtail 正式向外界开源全部C++核心代码，发布了 1.1.0 版本，内核能力上首次对齐企业版，同时发布了《iLogtail用户手册》，社区版正式进入大规模生产可用阶段，社区的发展速度也犹如装上了加速引擎。开源社区自此变得活跃起来，吸引了众多开发者的关注和参与。

2022年11月7日，在完整开源不到半年的时间，iLogtail 在 GitHub 上的关注人数就突破 1000 大关。越来越多的人知道并开始使用 iLogtail，社区活跃度也持续增强，截止到 2023.2.7 数据，Github 活跃度数据：

社区运营 -- 有朋自远方来，不亦乐乎

取得的成绩

在过去一年中，通过与各方朋友共同的努力，iLogtail 逐渐得到了越来越多的认可。相对年初，iLogtail 在OpenLeaderboard 开源项目中国排名中活跃度上升147位，影响力上升117位，并最终荣获了“阿里巴巴2022新锐开源项目”的称号。

活跃的社区

应社区发展的需要，建立了 iLogtail 社区钉钉群、微信群（详见文末二维码），群内志同道合的小伙伴共计近500人。在 GitHub 上，制定了 iLogtail 贡献指南、代码开发指南、测试指南（UT 和 E2E），并发布了一系列的 good first issue，以便期望参与社区建设的小伙伴快速入手；建立了 iLogtail 社区论坛，收集意见并沉淀解决的常见问题，所有iLogtail社区的活动的预告也都可以在群公告或论坛置顶帖看到；为了构建更广泛的社区合作机制，发布社区 RoadMap。

在过去的一年中，社区同学贡献了很多优秀提案，并落地实现。iLogtail 社区已经逐步形成了浓厚的沟通交流氛围。

为了鼓励更多用户和开发者参与社区的建设和宣传，专门设立了贡献者奖励机制，发布了社区徽章（开发者徽章、布道师徽章、答题王徽章），定义了社区角色及发展路径。截止发稿时，已有24人获得 Junior Developer 成就，9人获得 Senior Developer 成就，4人获得 Junior Junior Ambassador 成就，3人获得 Senior Ambassador 成就，11人获得 Junior Moderator 成就，1 人获得 Senior Moderator 成就。

为了更好地与社区和开发者沟通，iLogtail 社区例行在线上召开开发者例会（已组织了6次），用于跟开发者同步开发进展信息，商讨项目下一步计划；Meetup 活动（已组织3次），用于向社区介绍整个项目在这一周期的项目进展并进行功能演示，也会邀请一些合作伙伴来分享 iLogtail 应用案例。

积极的贡献者

iLogtail 社区的快速发展离不开贡献者们的努力，目前 iLogtail 项目的贡献者已增加至30人。在 iLogtail 社区高速发展的过程中，涌现了一批活跃的高质量的贡献者，在帮助 iLogtail 生态完善的同时也建立起了自己的行业信誉。

核心贡献者（排名不分先后）如下：

刘浩杨（liuhaoyang，字节跳动工程师，iLogtail 社区的 Committer）：贡献了数据模型、OpenTelemetry Log Flusher等。
郭刚平（snakorse，字节跳动工程师）：贡献了私有仓库插件编译构建方案、HTTP Flusher。
朱舜佳（shunjiazhu ，字节跳动工程师）：贡献了 OTLP Input。
俞倩雯（urnotsally，字节跳动工程师）：贡献了 ByteArray 数据结构和 HTTP 数据透传功能。
孙宇（shalousun，来自同程旅行）：贡献了 Kafka v2 Flusher、Pulsar Flusher。
魏文晗（XLPE，国内某大型通信与信息服务类公司）：贡献了第三方性能测试。
舒震宇（szy441687879，小红书工程师）：多次分享使用经验，提出多项大数量场景下 GC 优化建议。
杜旻翔（kl7sn，石墨文档工程师）：贡献了 ClickHouse Flusher。
彭友顺（askuy，石墨文档工程师）：贡献了 ClickHouse Flusher。
杨泽华（Takuka0311，在校学生）：贡献 Grok Processor、Desensitize Processor、ConfigServer 实现。
周弘懿（pj1987111，阿里云 EMR 团队）：贡献了 Fields_with_conditions Processor 及多篇案例分享。
余韬（yyuuttaaoo，阿里云工程师）
徐可甲（messixukejia，阿里云工程师）
张浩翔（henryzhx8，阿里云工程师）
刘嘉鹏（EvanLjp，阿里云工程师）
林润骑（linrunqi08，阿里云工程师）

功能演进 -- 积跬步以至千里

核心能力建设

更完整的系统支持

对于不同的企业来说，生产环境是复杂多变的，因此，作为一款通用的采集器需要首先需要有完备的操作系统和架构的支持。目前社区版的系统支持能力已经基本对齐企业版，对于暂不支持的也提供了基础的依赖，期望有需求的开发者参与共建。

系统与架构	企业版	社区版
Linux X86-64	支持	支持
Linux ARM64	支持	支持，相关 PR
Windows	支持	Windows 编译 Issue，归档了编译依赖及构建方法，期待社区共建。
K8s Docker Linux版	支持	支持
K8s Containerd Linux版	支持	支持
K8s Docker Windows 版	支持	支持，但缺少部署模版。

目前，已有同学也将 iLogtail 成功部署到树莓派上，具体可参见《树莓派上玩转iLogtail：构建/采集/分析NAS日志》。

更通用的数据模型

iLogtail 最初定位为 SLS 的采集器，因此内部数据流是以 SLS-PB 为结构的，对于开源社区流行的 OTLP 等协议兼容性不是太好；此外，也是缺乏原生的 Metrics 、Traces 数据模型，这两种类型的数据处理都需要以 SLS-PB 结构做数据中转，而这往往会造成性能额外开销及兼容性问题。

字节跳动同学发起了全新数据模型的提案，经 iLogtail 社区讨论后接收。新的数据模型中 Pipeline 中流动的每一条数据定义为 PipelineEvent，为 iLogtail 向通用 OneAgent 发展打下了坚实的基础。

// 基础 Event 模型

type PipelineEvent interface {

GetName() string

SetName(string)

GetTags() Tags

GetType() EventType

GetTimestamp() uint64

GetObservedTimestamp() uint64

SetObservedTimestamp(uint64)

}

// 用于对数据进行分组聚合的 Event Group

type GroupInfo struct {

Metadata Metadata

Tags Tags

}

type PipelineGroupEvents struct {

Group *GroupInfo

Events []PipelineEvent

}

Metric、Trace、Log、Profiling 等都是派生自 PipelineEvent 的具体事件。目前各数据模型的支持情况：

Metric 模型：支持 MetricSingleValue 和 MetricMultiValue 两种实现，兼容开源主流的 Metric 单值(eg. Prometheus)和多值(eg. Influxdb)模型；同时，扩展了非数值类型的实现 MetricTypedValues。更多详见《Metrics 数据模型改进设计》、PR。
Trace 模型：包含追踪上下文的数据，详见 PR。
Log 模型：定义中。
ByteArray 模型：字节流模型，详见 PR。
Profiling 模型：讨论中，待入库。

新的数据模型打通了 iLogtail 的任督二脉，大大提升了 iLogtail 通用处理能力。新的数据模型将被定义为 iLogtail 的核心处理模型，后续新的插件都将支持新的数据模型，存量的插件也会逐渐适配支持。

更强大的容器采集

Kubernetes 元数据关联

K8s 元数据（例如，Namespace、Pod、Container、Labels等）对于应用日志分析往往起着至关重要的作用。K8s Pod 的元信息存在于 CRI 定义下的 Sandbox Container 内，因此，iLogtail 基于标准 CRI API 与 Pod 的底层定义进行交互，实现获取 K8s 下各类元数据信息，从而无侵入的实现日志采集时的 K8s 元信息关联及过滤筛选能力。

更多详见《阿里云SLS 容器采集全面兼容Kubernetes》

短生命周期容器采集增强

从 Sysdig 2023 容器安全报告可以看出，72% 的容器存活时间不到五分钟，23% 的容器（例如，K8s 的 Job 任务）生命周期甚至只有十秒左右！这些短生命周期的容器，对业务团队进行应用系统分析、基础架构团队进行故障排查、安全团队进行安全取证，都造成了巨大的困难。

iLogtail 针对 Job 类容器增删频率高、生命周期短、突发并发大等特点，从容器发现速度、句柄锁定机制、秒退容器数据完整性等方面进行了针对性的优化与方案探究，给出了可靠性稳定的采集方案。

更多详见《分布式短任务的数据采集原理与实践》

更便捷的管控能力

对于可观测采集器，采集配置变更是常有的事。从 1.1.1 版本起，iLogtail 社区版增加了配置热加载能力，即使不重启iLogtail的情况下，也能够动态识别到配置的变更，大大降低了管控复杂度。同时，也提供了针对主机、K8s的配置热加载案例，供社区同学交流。此外，为了满足 K8s 用户的部署需求，发布了 k8s_templates，覆盖从采集源到典型处理，再到输出的整个过程，便于开发者开箱即用、快速上手。

K8s 作为开源容器编排平台，在应用部署领域提供了便利的手段，iLogtail 采集配置管理可以通过 Cofigmap 实现全局的管理。但是主机场景下，需要逐个实例进行配置管理，或者需要借助第三方完成。此外，不管是主机还是 K8s 场景，都缺少对 Agent 版本信息、运行状态的统一管理。鉴于行业上缺乏一套统一有效的管控标准的现状，iLogtail 社区联合哔哩哔哩共同制定了采集 Agent 管控协议，并基于该协议实现了 ConfigServer 服务，可以管控任意符合该协议的 Agent。

ConfigServer 作为一款可观测 Agent 的管控服务，支持以下功能：

以 Agent 组的形式对采集 Agent 进行统一管理。
远程批量配置采集 Agent 的采集配置。
监控采集 Agent 的运行状态，汇总告警信息。

同时，对于存储适配层进行了抽象，便于开发者对接符合自己环境需求的持久化存储。

采集生态建设

iLogtail 作为一款通用的可观测数据采集器，核心目的就是从各种可观测数据源进行数据采集，并将采集到的数据经过一些列处理后，发送到对应的存储系统。目前 iLogtail 数据源类型覆盖 Logs、Metrics、Traces，数据源除了主机或 K8s 文件的采集外，还包括了主流标准协议的采集，例如 Opentelemetry、HTTP、Mysql Binlog、Prometheus、Skywalking、Syslog 等；iLogtail 也通过eBPF支持，实现了无侵入的网路数据采集能力。数据输出生态也从 SLS 逐步扩展到 Kafka、gPRC、Opentelemetry、Pulsar、ClickHouse 等，未来通过开源社区共建也会支持ElasticSearch等更多类型的协议。

整体概览

插件建设概览提供了目前支持插件的全景视图，可以看出社区贡献的比例在逐步提高，社区贡献者已成为 iLogtail 生态建设不可或缺的核心力量。

据不完全统计，比较受开发者青睐的插件有：

Input：service_docker_stdout、file_log、service_http_server、service_docker_event、service_skywalking_agent_v3
Processor：processor_add_fields、processor_rename、processor_json、processor_regex、processor_strptime
Flusher：flusher_kafka、flusher_kafka_v2、flusher_sls、flusher_stdout、flusher_http

开发友好度提升

开发者永远是 iLogtail 社区最宝贵的财产，开发者的数量和质量决定了社区的发展。为了让开发者更低门槛的入手 iLogtail，做出了如下努力：

快速的使用案例是开发者接触 iLogtail 的第一印象，好的印象有助于拉近开发者的距离。为此，重新设计了结构清晰的 Pipeline 配置文件，输出了极简的快速开始和 getting-started 案例。
编译构建是开发者参与 iLogtail 开发的第一步。为了解决众多编译依赖（特别是 C++ 语言部分）的问题，发布了多架构镜像，用户可以基于统一的镜像，实现 Linux X86-64、ARM64 系统的快速开发；提供了基于 VSCode 的远程开发案例，便于开发者快速入手；并且应社区的强烈建议，优化了 Go Mod 管理机制，大大降低新引入依赖库的复杂度；Go版本升级到1.18 方便开发者利用更多高版本的新特性。
iLogtail 数据流是基于 SLS-PB 或者 V2 扩展后的内部通用结构实现的，因此在开发第三方 Flusher 时往往面临着格式转换的问题。为了加快开发插件流程，iLogtail 提供了通用协议转换模块，开发者只需要指定目标协议的名称和编码方式即可获得编码后的字节流。相关PR add support for protocol conversion，完整开发指南。

支持的协议类型	协议名称	支持的编码方式
标准协议	sls协议	json、protobuf
自定义协议	单条协议	json
标准协议	Influxdb协议	custom
字节流协议	raw协议	custom

为了保证代码质量，iLogtail 基于 docker-compose 提供了一个完整的 E2E 测试引擎，便于开发者快速开展各类插件的集成测试。在大部分情况下，开发者只需要编写一个 Yaml 配置文件来定义测试行为，即可轻松完成测试。如果测试流程涉及外部环境依赖，只需额外提供该环境的镜像（或构建镜像所需文件），从而省却了人工配置测试环境（包括网络等）的麻烦。

更多详见：《iLogtail社区版使用入门》、《iLogtail社区版开发者指南》。

eBPF 支持

随着微服务、云原生、DevOps 等技术的推进，推动着服务部署环境动态性的不断提升，带来了弹性、资源利用率、解耦等诸多优势，但也带来了如上文所述的异构语言、多种协议等诸多问题，这对传统观测性带来了极大的挑战。而 eBPF 基于内核态观测手段，可以灵活、无侵入、高性能的解决上述复杂环境带来的多语言与多协议观测等挑战。iLogtail 与 Coolbpf 合作，研发了无侵入 eBPF 采集方案，相关 PR。目前已支持 L4/L7 网络流量采集，HTTP、Redis、MySQL、PgSQL、DNS等协议解析，未来也将支持 Dubbo、gRPC、Profling等更多场景。

iLogtail 无侵入监控采集分为两部分：

Kernel Space：通过内核态 Hook 模块，进行数据的抓取与预处理。
User Space：根据网络协议进行细粒度的协议分析、数据聚合等操作，以及一些资源控制管理的工作。

更多详见《阿里SLS无侵入监控采集方案发布》

OpenTelemetry 全面兼容

OpenTelemetry 旨在提供可观测领域标准化方案，OTLP 作为数据传输模型被众多系统支持。iLogtail 也积极拥抱 OTLP，目前已提供：

service_otlp：支持 OTLP Log、Metric、Trace 的 HTTP/gPRC 请求。
service_http_server：扩展了 OTLP Log、Metric、Trace HTTP 接收能力。
flusher_otlp_log：将采集到的日志发送到支持 OTLP 的后端系统。

第三方性能/可靠性测试

日志采集是整个日志基础设施中最基础最关键的组件之一，影响着企业内部数据的完整性以及实时性。采集器作为数据链路的前置环节，其可靠性、扩展性、灵活性以及资源（CPU 和内存）消耗等，往往是最被关注的核心技术点。来自国内某大型通信与信息服务类公司的运维同学，从中立的第三方视角，针对五个主流的开源日志采集器做的详细的测评：ilogtail（社区版 v1.1.1）、filebeat（v8.4.2）、vector（v0.24.1）、fluent-bit（v1.9.9）、rsyslog（v8）。

首先，从进程正常退出、进程异常终止、日志轮转、配置在线升级等四个常见可靠性场景出发，进行了采集数据一致性测试。结果显示，iLogtail 除了在异常退出场景下少量重复外，其他场景数据完全一致。

其次，在多种场景下（多行/单行日志、采集速率变化、正则的使用）进行了完备的性能测试对比。从性能测试结果看，ilogtail 在采集速率上优势明显。在某些极端速率场景下，iLogtail是唯一一个采集速度可以个日志生成速度接近的采集器，且资源占用率和采集速率基本维持一个线性关系。

更多详见：《性能与可靠的超强碰撞：第三方测评开源日志采集器》

交流分享 -- 肯与邻翁相对饮，隔篱呼取尽余杯

通过 iLogtail 社区搭建了一个技术交流的平台，秉承着开放交流的态度，通过线上 iLogtail 例会、线下技术大会多路出击，与开发者近距离交流可观测采集相关技术、解决方案及实践案例。

成功案例 -- 三人行必有我师

根据社区用户群和公开资料统计，目前使用 iLogtail 社区版的公司包括阿里巴巴、字节跳动、小红书、同程旅行、同城必应、Bilibili等知名企业。这些企业的应用实践，为广大企业构建可观测性数据实时采集和大数据平台提供了宝贵的经验。

在字节内部，我们建设了可以处理数十PB级别海量数据的可观测性基础设施，随着越来越多的数据接入和内外一体背景下 ToB 场景的需求，我们想要使用 OneAgent 来覆盖 Metrics、Trace、Log 、Event 等可观测性数据。通过对比 iLogtail、Vector、Opentelemetry Collector、Fluentbit 等开源的数据采集器，基于下面的几点考虑我们最终选择了和阿里的同学一起建设 iLogtail。

iLogtail 经过在阿里生态和阿里云上的大规模使用，性能和稳定性有足够的保障
我们的经验更多在 Metrics & Trace 数据使用上，iLogtail 对 Log 完善的支持可以和我们的场景进行互补
iLogtail 使用 Apache 2.0 开源协议对商业使用比较友好，同时我们也可以和阿里的同学密切合作来共同建设 iLogtail 的开源生态

目前我们已经在 APM 产品上使用了 iLogtail 的日志采集功能，并且在私有云中有实际的落地应用，接下来我们已经在尝试增强 iLogtail 的 Metrics 采集能力用于百万级的云基础设施和公有云产品的监控数据接入场景。

——字节跳动

目前小红书正在使用 iLogtail 替换 ELK 体系日打造新一代日志系统，iLogtail 在新系统中同时承担了采集(Filebeat)和管道(Logstash)的功能，在业务日志场景下使用将其级联的方式去除了 Kafka 的中间环节，提高系统效率；在 APM、风控等日志场景下使用其作为统一的数据采集处理层，消费 Kafka 做后续处理。

——小红书

在同程旅行数据中心大数据云原生的开发建设场景中，我们必须把 HDFS、Flink、Spark、Kudu 等大数据组件和机器学习平台的服务日志进行实时收集，为大数据基础设施建立起完整的可观测闭环。随着大数据集群业务规模的不断扩大，过去采用 Filebeat 作为可观测性日志采集的方案出现了 CPU 占用高、日志采集延迟等一系列问题。通过调研和测试对比一些其它开源日志采集组件后，我们决定采用高性能的 iLogtail 替代 Filebeat。由于iLogtail 优异的性能和社区丰富的日志处理插件，过去日志采集中 CPU 占用高和采集延迟的问题得到有效的解决，也减轻了 Flink 日志清洗层任务的工作和压力、降低了日志处理对资源的消耗。

——同程旅行

同城必应的业务分别部署在阿里云容器集群和 AWS 的 EC2，由于用户涉及国内和海外，故未使用厂商提供的日志聚合功能，而是自建 ES 的方式来做日志聚合。 Kubernetes 社区推荐的日志采集方案为 Deamonset 方式部署采集器，但只针对于标准输出的采集，由于我们的业务日志均为写日志方式，故之前采用的日志采集方案为 Sidecar 模式部署 Filebeat。但该方案存在以下问题：1. 资源占用高，单集群中会存在多个日志采集容器；2. 业务侵入性高，业务容器可能会因为日志采集器容器 crash 而无法就绪，无法正常接收业务流量；3. 配置复杂，每次新增 Pod 都需要再部署一次日志采集器。而 Deamonset 方式部署的 iLogtail 有：

与业务容器解耦分离
单节点仅一个采集器
容器自动发现等特性

其很好的解决了我们之前 Sidecar 部署方式存在的问题，可在满足我们业务需求的前提下，降低集群资源成本。

——同城必应

业界主流的开源采集 Agent，例如 FileBeat、Fluentd 都是提供了本地部署模式，如果需要全局管控只能借助第三方的工具例如 supervisor 进行管理。目前 Bilibili 内部使用多种采集端，而行业上缺乏一套统一有效的管控手段，基于这个现状，Bilibili 与 iLogtail 开源社区一起联合制定了采集 Agent 管控协议。iLogtail 社区也基于该协议提供了 ConfigServer 服务，可以管控任意符合该协议的 Agent。ConfigServer 作为一款可观测 Agent 的管控服务，支持以下功能：

以 Agent 组的形式对采集 Agent 进行统一管理
远程批量配置采集 Agent 的采集配置
监控采集 Agent 的运行状态，汇总告警信息

——Bilibili

目前石墨文档正基于 ClickHouse 和自研的 ClickVisual 构建全新的日志系统，使用 Fluent Bit 配合 Kafka 进行日志采集传输，未来计划使用 iLogtail 替换 Fluent Bit。目前已在部分业务场景下使用 iLogtail 结合 ClickHouse 缓冲表的方式完成日志采集存储，该流程缩减了中间环节，iLogtail 在过程中出色的承担了日志采集和传输管道的角色，依托于活跃的社区环境与丰富的插件组件，在整个开发实施过程中高效的解决了很多问题，并最终有效的提升了系统效率。

——石墨文档

2023展望 -- 海阔凭鱼跃，天高任鸟飞

2022年，iLogtail 迈出了开源的关键一步，不管是数据模型演进，还是生态集成都有了很大的飞跃。在这里，首先需要感谢下众多开发者的积极参与，特别需要感谢字节跳动同学的做出的卓越贡献，提出了很多极具建设性的提案并实施落地。iLogtail 2022 开源的故事分享的差不多了，但是 iLogtail 过去一年还不仅于此，我们不久将继续分享关于 iLogtail 企业版，尤其是是借助 SLS 可观测平台能力的一些工作，敬请期待本文姊妹篇《iLogtail 企业版 2022年度技术总结》。

新的一年，iLogtail 社区将围绕以下领域同开发者一起共建，将 iLogtail 打造成更加高效、稳定、可扩展性强的通用采集器。更多技术规划，社区将通过 Roadmap 定期发布。

极致的采集性能、超强可靠性、跨系统支持一直是 iLogtail 追求的目标，社区将持续加大核心竞争力投入。通过改进 C++/Golang 交互，让开源用户享受到更多 C++的加速能力，通过资源控制等手段持续增强极端场景下的可靠性与稳定性。
可观测采集 OneAgent 越来越成为趋势，iLogtail 社区将继续与字节跳动等同学一起通过数据模型的升级来完善 Log、Metric、Trace、Profiling、Security的核心处理能力，通过扩展 Pipeline 语义增强各个场景的处理能力，通过对 C++ 代码优化提升模块化扩展能力。
持续降低开发门槛，助力开发者快速参与项目开发。借助 eBPF、第三方协议对接等技术手段，增强时序、安全、Profiling等垂直场景等采集能力，打造业界领先的数据生态。
其他方面：加强 iLogtail 自身可观测建设，扩展第三方系统的对接，持续降低监控及问题排查门槛；通过推进标准管控协议的建设，打造统一管控方案；与更多开源软件（例如，KubeVela、OpenKruise等）的横向合作，并输出实用案例。

技术共享一直是 iLogtail 秉承的理念，如果以上内容让您感觉到兴奋，非常欢迎加入 iLogtail 社区参与共建。“集百家之所长，融百家之所思”，希望跟开发者一起能够将 iLogtail 的核心能力打造的更完善，上下游生态构建的更丰富。相信通过大家共同的努力，iLogtail 将会被打造成业界最顶级的可观测数据采集器。

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社区2022年度开源报告