关于阿里云:你好iLogtail-20

作者：张浩翔（笃敏）

概述

随着可观测数据采集需要的一直新陈代谢，多样化的数据输入输出选项、个性化的数据处理能力组合、以及高性能的数据处理吞吐能力曾经成为顶流可观测数据采集器的必备条件。然而，因为历史起因，现有的 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 系列相比，有以下能力降级：

• 原生解决插件可任意组合：

  原有原生解决插件间的依赖限度不复存在，您能够随便组合原生解决插件以满足您的解决需要。

• 原生解决插件和扩大解决插件可同时应用：

  对于简单日志解析场景，如果仅用原生解决插件无奈满足解决需要，您可进一步增加扩大解决插件进行解决。

🔔 留神： 扩大解决插件只能呈现在所有的原生解决插件之后，不能呈现在任何原生解决插件之前。

示例：如果您的文本日志为如下内容：

{“time”: “2024-01-22T14:00:00.745074”, “level”: “warning”, “module”: “box”, “detail”: “127.0.0.1 GET 200”}

您须要将 time、level 和 module 字段解析进去，同时还须要将 detail 字段做进一步正则解析，拆分出 ip、method 和 status 字段，最初抛弃 drop 字段，则您能够按程序应用“Json 解析原生解决插件”、“正则解析原生解决插件”和“抛弃字段扩大解决插件”实现相干需要：

【商业版】

【开源版】

{
  "configName": "test-config"
  "inputs": [...],
  "processors": [
    {
      "Type": "processor_parse_json_native",
      "SourceKey": "content"
    },
    {
      "Type": "processor_parse_regex_native",
      "SourceKey": "detail",
      "Regex": "(\S)+\s(\S)+\s(.*)",
      "Keys": [
        "ip",
        "method",
        "status"
      ]
    }
    {
      "Type": "processor_drop",
      "DropKeys": ["module"]
    }
  ],
  "flushers": [...]
}

采集后果如下：

（三）新增 SPL 解决模式

除了应用解决插件组合来解决日志，iLogtail 2.0 还新增了 SPL（SLS Processing Language）解决模式，即应用日志服务提供的用于对立查问、端上解决、数据加工等的语法，来实现端上的数据处理。应用 SPL 解决模式的劣势在于：

• 领有丰盛的工具和函数：反对多级管道操作，内置功能丰富的算子和函数
• 上手难度低：低代码，简略易学
• 【商业版】对立语法：一个语言玩转日志采集、查问、加工和生产

SPL 语法

整体构造：

• 指令式语句，反对结构化数据和非结构化数据对立解决
• 管道符（|）疏导的摸索式语法，简单逻辑编排简便

<data-source> 
| <spl-cmd> -option=<option> -option ... <expression>, ... as <output>, ...
| <spl-cmd> ...
| <spl-cmd> ...

结构化数据 SQL 计算指令：

• where 通过 SQL 表达式计算结果产生新字段
• extend 依据 SQL 表达式计算结果过滤数据条目

*
| extend latency=cast(latency as BIGINT)
| where status='200' AND latency>100

非结构化数据提取指令：

• parse-regexp 提取指定字段中的正则表达式分组匹配信息
• parse-json 提取指定字段中的第一层 JSON 信息
• parse-csv 提取指定字段中的 CSV 格局信息

*
| project-csv -delim='^_^' content as time, body
| project-regexp body, '(\S+)\s+(\w+)' as msg, user

（四）日志解析管制更加精密

对于原生解析类插件，iLogtail 2.0 提供了更精密的解析管制，包含如下参数：

• KeepingSourceWhenParseFail：解析失败时，是否保留原始字段。若不配置，默认不保留。
• KeepingSourceWhenParseSucceed：解析胜利时，是否保留原始字段。若不配置，默认不保留。
• RenameSourceKey：当原始字段被保留时，用于存储原始字段的字段名。若不配置，默认不改名。

示例：假如须要在日志字段内容解析失败时在日志中保留该字段，并重命名为 raw，则可配置如下参数：

• KeepingSourceWhenParseFail：true
• RenameSourceKey：raw

（五）【商业版】日志工夫解析反对纳秒级精度

在 iLogtail 1.x 版本中，如果您须要提取日志工夫字段到纳秒精度，日志服务只能在您的日志中额定增加“纳秒工夫戳”字段。在 iLogtail 2.0 版本中，纳秒信息将间接附加至日志采集工夫（__time__）而无需额定增加字段，不仅缩小了不必要的日志存储空间，也为您在 SLS 控制台依据纳秒工夫精度对日志进行排序提供方便。

如果须要在 iLogtail 2.0 中提取日志工夫字段到纳秒精度，您须要首先配置工夫解析原生解决插件，并在“源工夫格局（SourceFormat）”的开端增加“.%f”，而后在全局参数中减少 ”EnableTimestampNanosecond”: true。

示例：假如日志中存在字段 time，其值为 2024-01-23T14:00:00.745074，时区为东 8 区，当初须要解析该工夫至纳秒精度并将 time 置为该值。

采集后果如下：

🔔 留神： iLogtail 2.0 不再反对 1.x 版本中提取纳秒工夫戳的形式，如果您在 1.x 版本中曾经应用了提取纳秒工夫戳性能，在降级 iLogtail 2.0 后，须要依照上述示例手动开启新版纳秒精度提取性能，详细信息参见文末兼容性阐明。

（六）【商业版】状态观测更加清晰

相比于 iLogtail 1.x 裸露的简略指标，iLogtail 2.0 极大地欠缺了本身可观测性的建设：

• 所有采集配置都有残缺指标，能够在 Project/Logstore 等维度上进行不同采集配置的统计与比拟
• 所有插件都有本人的指标，能够构建残缺流水线的拓扑图，每个插件的状态能够进行分明的观测
• C++ 原生插件提供更加具体的指标，能够用来监控与优化插件的配置参数

（七）运行更快更平安

iLogtail 2.0 反对 C++ 17 语法，C++ 编译器降级至 gcc 9，同时更新了 C++ 依赖库的版本，使得 iLogtail 的运行更快更平安。

表：iLogtail 2.0 单线程解决日志的性能（以单条日志长度 1KB 为例）

兼容性阐明

（一）采集配置

商业版

• 新版流水线采集配置是齐全向前兼容旧版采集配置的，因而：

<!—->

• 在您降级 iLogtail 至 2.0 版本的过程中，日志服务会在下发配置时主动将您的旧版配置转换为新版流水线配置，您无需执行任何额定操作。您能够通过 GetLogtailPipelineConfig 接口间接获取旧版配置对应的新版流水线配置

<!—->

• 旧版采集配置并不齐全向后兼容新配流水线配置

<!—->

• 如果流水线配置形容的采集解决能力可用旧版配置表白，则该流水线配置仍然能够被 iLogtail 0.x 和 1.x 版本应用，日志服务会在向 iLogtail 下发配置时主动将新版流水线配置转换为旧版配置
• 反之，该流水线配置会被 iLogtail 0.x 和 1.x 版本疏忽

开源版

新版采集配置与旧版采集配置存在大量不兼容状况，详见 iLogtail 2.0 版本采集配置不兼容变更阐明 [ 5]。

（二）iLogtail 客户端

1. 应用扩大解决插件时的 Tag 存储地位

当您应用扩大插件解决日志时，iLogtail 1.x 版本因为实现起因会将局部 tag 寄存在日志的一般字段中，从而为您后续在 SLS 控制台应用查问、搜寻和生产等性能时带来诸多不便。为了解决这一问题，iLogtail 2.0 将默认将所有 tag 归位，如果您仍心愿放弃 1.x 版本行为，您能够在配置的全局参数中减少 ”UsingOldContentTag”: true。

• 对于通过旧版控制台界面和旧版 API 创立的采集配置，在您降级 iLogtail 2.0 后，tag 的存储地位依然与 1.x 版本统一；
• 对于通过新版控制台界面和新版 API 创立的采集配置，在您降级 iLogtail 2.0 后，tag 的存储地位将默认归位。

2. 高精度日志工夫提取

2.0 版本不再反对 1.x 版本的 PreciseTimestampKey 和 PreciseTimestampUnit 参数，当您降级 iLogtail 2.0 版本后，原有纳秒工夫戳提取性能将生效，如果您仍需解析纳秒精度工夫戳，您须要参照日志工夫解析反对纳秒精度板块对配置进行手动更新。

3. 飞天格局日志微秒工夫戳时区调整

2.0 版本的飞天解析原生解决插件将不再反对 1.x 版本的 AdjustingMicroTimezone 参数，默认微秒工夫戳也会依据配置的时区进行正确的时区调整。

4. 日志解析管制

对于原生解析类插件，除了日志解析管制更加精密板块中提到的 3 个参数，还存在 CopyingRawLog 参数，该参数仅在 KeepingSourceWhenParseFail 和 KeepingSourceWhenParseSucceed 都为 true 时无效，它将在日志解析失败时，在日志中额定减少 raw_log 字段，字段内容为解析失败的内容。

该参数的存在是为了兼容旧版配置，当您降级 iLogtail 2.0 版本后，建议您及时删去该参数以缩小不必要的反复日志上传。

总结

为用户提供更舒服便捷的用户体验始终是日志服务的主旨。相比于 iLogtail 1.x 时代，iLogtail 2.0 的变动是比拟显著的，但这些转变只是 iLogtail 迈向古代可观测数据采集器的序曲。咱们强烈建议您在条件容许的状况下尝试 iLogtail 2.0，兴许您在转换之初会有些许的不适应，但咱们置信，您很快会被 iLogtail 2.0 更弱小的性能和更杰出的性能所吸引。

相干链接：

[1] 输出插件

https://help.aliyun.com/zh/sls/user-guide/overview-19?spm=a2c…

[2] 解决插件

https://help.aliyun.com/zh/sls/user-guide/overview-22?spm=a2c…

[3] iLogtail 流水线配置构造

https://next.api.aliyun.com/struct/Sls/2020-12-30/LogtailPipe…

[4] OpenAPI 文档

https://next.api.aliyun.com/document/Sls/2020-12-30/CreateLog…

[5] iLogtail 2.0 版本采集配置不兼容变更阐明

https://github.com/alibaba/ilogtail/discussions/1294