作者：张浩翔（笃敏）
概述
随着可观测数据采集需求的不断推陈出新，多样化的数据输入输出选项、个性化的数据处理能力组合、以及高性能的数据处理吞吐能力已经成为顶流可观测数据采集器的必备条件。然而，由于历史原因，现有的 iLogtail 架构和采集配置结构已经无法继续满足上述需求，逐渐成为制约 iLogtail 继续向前快速演进的瓶颈：
▶︎ iLogtail 设计之初完全面向文件日志采集至日志服务的场景：
1）简单地将日志分为多种格式，每种格式的日志仅支持一种处理方式（如正则解析、Json 解析等）；
2）功能实现与日志服务相关概念（如 Logstore 等）强绑定；
基于此设计思想，现有的 iLogtail 架构偏向于单体架构，导致模块间耦合严重，可扩展性和普适性较差，难以提供多个处理流程级联的能力。
▶︎ Golang 插件系统的引入极大地扩展了 iLogtail 的输入输出通道，且一定程度提升了 iLogtail 的处理能力。然而，囿于 C++ 部分的实现，输入输出与处理模块间的组合能力仍然严重受限：
1）C++ 部分原生的高性能处理能力仍然仅限于采集日志文件并投递至日志服务的场景使用；
2）C++ 部分的处理能力无法与插件系统的处理能力相结合，二者只能选其一，从而降低了复杂日志处理场景的性能。
▶︎ 与 iLogtail 整体架构类似，现有的 iLogtail 采集配置结构也采用平铺结构，缺乏处理流水线的概念，无法表达处理流程级联的语义。
基于上述原因，在 iLogtail 诞生 10 周年之际，日志服务启动对 iLogtail 的升级改造，寄希望于让 iLogtail 的易用性更佳，性能更优，可扩展性更强，从而更好地服务广大用户。
目前，经过半年多的重构与优化，iLogtail 2.0 已经呼之欲出。接下来，就让我们来抢先了解一下 iLogtail 2.0 的新特性吧！
新特性
（一）【商业版】采集配置全面升级流水线结构
为了解决旧版采集配置平铺结构无法表达复杂采集行为的问题，iLogtail 2.0 全面拥抱新版流水线配置，即每一个配置对应一条处理流水线，包括输入模块、处理模块和输出模块，每个模块由若干个插件组成，各模块的插件功能如下：
- 输入插件： 用于从指定输入源获取数据（各插件具体功能详见输入插件 [ 1] ）
- 处理插件： 用于对日志进行解析和处理（各插件具体功能详见处理插件 [ 2] ），可进一步分为原生处理插件和扩展处理插件
- 原生处理插件：性能较优，适用于大部分业务场景，推荐优先使用
- 扩展处理插件：功能覆盖更广，但性能劣于原生处理插件，建议仅在原生处理插件无法完成全部处理需求时使用
- 输出插件： 用于将处理后的数据发送至指定的存储
我们可以用一个 JSON 对象来表示一个流水线配置：
其中，inputs、processors 和 flushers 即代表输入、处理和输出模块，列表中的每一个元素 {...} 即代表一个插件；global 代表流水线的一些配置。有关流水线配置结构的具体信息，可参见 iLogtail 流水线配置结构 [ 3] 。
示例：采集 /var/log 目录下的 test.log，对日志进行 json 解析后发送到日志服务。以下是实现该采集需求对应的旧版和新版配置，可以看到新版配置十分精炼，执行的操作一目了然。
旧版配置：
{ "configName": "test-config", "inputType": "file", "inputDetail": { "topicFormat": "none", "priority": 0, "logPath": "/var/log", "filePattern": "test.log", "maxDepth": 0, "tailExisted": false, "fileEncoding": "utf8", "logBeginRegex": ".*", "dockerFile": false, "dockerIncludeLabel": {}, "dockerExcludeLabel": {}, "dockerIncludeEnv": {}, "dockerExcludeEnv": {}, "preserve": true, "preserveDepth": 1, "delaySkipBytes": 0, "delayAlarmBytes": 0, "logType": "json_log", "timeKey": "", "timeFormat": "", "adjustTimezone": false, "logTimezone": "", "filterRegex": [], "filterKey": [], "discardNonUtf8": false, "sensitive_keys": [], "mergeType": "topic", "sendRateExpire": 0, "maxSendRate": -1, "localStorage": true }, "outputType": "LogService", "outputDetail": { "logstoreName": "test_logstore" } }新版流水线配置：
{ "configName": "test-config", "inputs": [ { "Type": "file_log", "FilePaths": "/var/log/test.log" } ], "processors": [ { "Type": "processor_parse_json_native" "SourceKey": "content" } ], "flushers": [ { "Type": "flusher_sls", "Logstore": "test_logstore" } ] }如果在执行 json 解析后需要进一步处理，在流水线配置中只需额外增加一个处理插件即可，但是在旧版配置中已经无法表达上述需求。
有关新版流水线配置和旧版配置的兼容性问题，请参见文末兼容性说明板块。
全新 API
为了支持流水线配置，同时区分旧版配置结构，我们提供了全新的用于管理流水线配置的 API 接口，包括：
- CreateLogtailPipelineConfig
- UpdateCreateLogtailPipelineConfig
- GetLogtailPipelineConfig
- DeleteLogtailPipelineConfig
- ListLogtailPipelineConfig
有关这些接口的详细信息，请参见 OpenAPI 文档 [ 4] 。
全新控制台界面
与流水线采集配置结构相对应，前端控制台界面也进行了全新升级，分为了全局配置、输入配置、处理配置和输出配置。
与旧版控制台界面相比，新版控制台具有如下特点：
参数内聚： 某一功能相关的参数集中展示，避免了旧版控制台参数散落各处出现漏配置。
示例：最大目录监控深度与日志路径中的**密切相关，旧版界面中，二者分隔较远，容易遗忘；在新版界面中，二者在一起，便于理解。
旧版控制台：
新版控制台：
所有参数均为有效参数： 在旧版控制台中，启用插件处理后，部分控制台参数会失效，从而引起不必要的误解。新版控制台所有参数均为有效参数。
全新 CRD
同样，与新版采集配置对应，K8s 场景中与采集配置对应的 CRD 资源也全新升级。与旧版 CRD 相比，新版 CRD 具有如下特点：
- 支持新版流水线采集配置
- CRD 类型调整为 Cluster 级别，且将 CRD 名称直接作为采集配置名称，避免同一集群多个不同的 CRD 资源指向同一个采集配置引起冲突
- 对所有操作的结果进行定义，避免出现多次操作旧版 CRD 后出现的行为未定义情况
apiVersion: log.alibabacloud.com/v1alpha1
kind: ClusterAliyunLogConfig
metadata:
name: test-config
spec:
project:
name: test-project
logstore:
name: test-logstore
machineGroup:
name: test-machine_group
config:
inputs:
- Type: input_file
FilePaths:
- /var/log/test.log
processors:
- Type: processor_parse_json_native
SourceKey: content
（二）处理插件组合更加灵活
对于文本日志采集场景，当您的日志较为复杂需要多次解析时，您是否在为只能使用扩展处理插件而困惑？是否为因此带来的性能损失和各种不一致问题而烦恼？
升级 iLogtail 2.0，以上问题都将成为过去！
iLogtail 2.0 的处理流水线支持全新级联模式，和 1.x 系列相比，有以下能力升级：
-
原生处理插件可任意组合：
原有原生处理插件间的依赖限制不复存在，您可以随意组合原生处理插件以满足您的处理需求。
-
原生处理插件和扩展处理插件可同时使用：
对于复杂日志解析场景，如果仅用原生处理插件无法满足处理需求，您可进一步添加扩展处理插件进行处理。
标签：插件,处理,配置,iLogtail,日志,2.0,你好 From： https://www.cnblogs.com/alisystemsoftware/p/18025893