更完整的系统支持

更通用的数据模型

// 基础 Event 模型type PipelineEvent interface {  GetName() string  SetName(string)  GetTags() Tags  GetType() EventType  GetTimestamp() uint64  GetObservedTimestamp() uint64  SetObservedTimestamp(uint64)}
// 用于对数据进行分组聚合的 Event Grouptype GroupInfo struct {  Metadata Metadata  Tags     Tags}type PipelineGroupEvents struct {  Group  *GroupInfo  Events []PipelineEvent}

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

• Profiling 模型[20]：讨论中，待入库。

更强大的容器采集

Kubernetes 元数据关联

短生命周期容器采集增强

更便捷的管控能力

• 以 Agent 组的形式对采集 Agent 进行统一管理。

• 远程批量配置采集 Agent 的采集配置。

• 监控采集 Agent 的运行状态，汇总告警信息。

整体概览

• 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 的第一印象，好的印象有助于拉近开发者的距离。为此，重新设计了 结构清晰的 Pipeline 配置文件，输出了极简的快速开始[26]和 getting-started 案例[27]。

• 编译构建是开发者参与 iLogtail 开发的第一步。为了解决众多编译依赖（特别是 C++ 语言部分）的问题，发布了多架构镜像[28]，用户可以基于统一的镜像，实现 Linux X86-64、ARM64 系统的快速开发；提供了基于 VSCode 的远程开发案例《一招解决开发环境问题 —— 远程容器开发指南》，便于开发者快速入手；并且应社区的强烈建议，优化了 Go Mod 管理机制[29]，大大降低新引入依赖库的复杂度；Go版本升级到1.18 [30]方便开发者利用更多高版本的新特性。

• iLogtail 数据流是基于 SLS-PB 或者 V2 扩展后的内部通用结构实现的，因此在开发第三方 Flusher 时往往面临着格式转换的问题。为了加快开发插件流程，iLogtail 提供了通用协议转换模块，开发者只需要指定目标协议的名称和编码方式即可获得编码后的字节流，完整开发指南[31]。

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

eBPF 支持

• Kernel Space：通过内核态 Hook 模块，进行数据的抓取与预处理。

• User Space：根据网络协议进行细粒度的协议分析、数据聚合等操作，以及一些资源控制管理的工作。

OpenTelemetry 全面兼容

• service_otlp[39]：支持 OTLP Log、Metric、Trace 的 HTTP/gPRC 请求。

• service_http_server[40]：扩展了 OTLP Log、Metric、Trace HTTP 接收能力。

• flusher_otlp_log[41]：将采集到的日志发送到支持 OTLP 的后端系统。

更多插件建设

• 更丰富的接入能力：metric_input_netping、service_mssql[42]（采集Sql Server查询数据）、service_pgsql[43]（采集PostgreSQL 查询数据）。

• 更灵活的处理能力：Grok Processor[44]、CSV Processor[45]、Desensitize Processor（数据脱敏）[46]、条件字段处理插件[47]（根据日志字段取值动态进行字段扩展或删除）。

• 更完整的第三方 Flusher 支持：HTTP Flusher[]48（以 HTTP 发送可观测数据，支持多种 custom_single[49]、influxdb、raw [50]等多种协议）、新版 Kafka Flusher[51]、Pulsar Flusher、Clickhouse Flusher（PR[52] 中）。

• 更强大的数据聚合能力：aggregator_content_value_group[53]（按照指定的Key对采集到的数据进行分组聚合）、aggregator_metadata_group[54]（按照指定的 Metadata Key 进行重新聚合）。

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

1. iLogtail 经过在阿里生态和阿里云上的大规模使用，性能和稳定性有足够的保障。

2. 我们的经验更多在 Metrics & Trace 数据使用上，iLogtail 对 Log 完善的支持可以和我们的场景进行互补 。

3. 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 有：

1. 与业务容器解耦分离

2. 单节点仅一个采集器

3. 容器自动发现等特性

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

——同城必应

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

1. 以 Agent 组的形式对采集 Agent 进行统一管理

2. 远程批量配置采集 Agent 的采集配置

3. 监控采集 Agent 的运行状态，汇总告警信息

——Bilibili

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

——石墨文档

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

• 其他方面：加强 iLogtail 自身可观测建设，扩展第三方系统的对接，持续降低监控及问题排查门槛；通过推进标准管控协议的建设，打造统一管控方案；与更多开源软件（例如，KubeVela、OpenKruise等）的横向合作，并输出实用案例。

留言有奖活动

说出2022年你与iLogtail社区的故事或者新的一年的建议，点赞量第一名将获得定制杯子一个，活动截止日期：2023年2月24日。快在下方参与留言吧～