iLogtail 2.0 来了!
缘起
Cloud Native
随着可观测数据采集需求的不断推陈出新,多样化的数据输入输出选项、个性化的数据处理能力组合、以及高性能的数据处理吞吐能力已经成为顶流可观测数据采集器的必备条件。然而,由于历史原因,现有的 iLogtail 架构和采集配置结构已经无法继续满足上述需求,逐渐成为制约 iLogtail 继续向前快速演进的瓶颈:
▶︎ iLogtail 设计之初完全面向文件日志采集至日志服务的场景:
▶︎ Golang 插件系统的引入极大地扩展了 iLogtail 的输入输出通道,且一定程度提升了 iLogtail 的处理能力。然而,囿于 C++ 部分的实现,输入输出与处理模块间的组合能力仍然严重受限:
基于上述原因,在 iLogtail 诞生 10 周年之际,日志服务启动对 iLogtail 的升级改造,寄希望于让 iLogtail 的易用性更佳,性能更优,可扩展性更强,从而更好地服务广大用户。
新特性
Cloud Native
输入插件:用于从指定输入源获取数据(各插件具体功能详见输入插件[1]) 处理插件:用于对日志进行解析和处理(各插件具体功能详见处理插件[2]),可进一步分为原生处理插件和扩展处理插件
原生处理插件:性能较优,适用于大部分业务场景,推荐优先使用 扩展处理插件:功能覆盖更广,但性能劣于原生处理插件,建议仅在原生处理插件无法完成全部处理需求时使用
输出插件:用于将处理后的数据发送至指定的存储
我们可以用一个 JSON 对象来表示一个流水线配置:
示例:采集 /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
CreateLogtailPipelineConfig UpdateCreateLogtailPipelineConfig GetLogtailPipelineConfig DeleteLogtailPipelineConfig ListLogtailPipelineConfig
有关这些接口的详细信息,请参见 OpenAPI 文档[4]。
全新控制台界面
示例:最大目录监控深度与日志路径中的**密切相关,旧版界面中,二者分隔较远,容易遗忘;在新版界面中,二者在一起,便于理解。 旧版控制台: 新版控制台:
所有参数均为有效参数:在旧版控制台中,启用插件处理后,部分控制台参数会失效,从而引起不必要的误解。新版控制台所有参数均为有效参数。
全新 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
原生处理插件可任意组合: 原有原生处理插件间的依赖限制不复存在,您可以随意组合原生处理插件以满足您的处理需求。 原生处理插件和扩展处理插件可同时使用: 对于复杂日志解析场景,如果仅用原生处理插件无法满足处理需求,您可进一步添加扩展处理插件进行处理。
示例:假如您的文本日志为如下内容:
{"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 语法
整体结构:
指令式语句,支持结构化数据和非结构化数据统一处理
管道符(|)引导的探索式语法,复杂逻辑编排简便
<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
KeepingSourceWhenParseFail:解析失败时,是否保留原始字段。若不配置,默认不保留。 KeepingSourceWhenParseSucceed:解析成功时,是否保留原始字段。若不配置,默认不保留。 RenameSourceKey:当原始字段被保留时,用于存储原始字段的字段名。若不配置,默认不改名。
示例:假设需要在日志字段内容解析失败时在日志中保留该字段,并重命名为 raw,则可配置如下参数:
KeepingSourceWhenParseFail:true
RenameSourceKey:raw
示例:假设日志中存在字段 time,其值为 2024-01-23T14:00:00.745074,时区为东 8 区,现在需要解析该时间至纳秒精度并将 __time__ 置为该值。
采集结果如下:
所有采集配置都有完整指标,可以在 Project/Logstore 等维度上进行不同采集配置的统计与比较 所有插件都有自己的指标,可以构建完整流水线的拓扑图,每个插件的状态可以进行清楚的观测 C++ 原生插件提供更加详细的指标,可以用来监控与优化插件的配置参数
兼容性说明
Cloud Native
商业版
新版流水线采集配置是完全向前兼容旧版采集配置的,因此:
在您升级 iLogtail 至 2.0 版本的过程中,日志服务会在下发配置时自动将您的旧版配置转换为新版流水线配置,您无需执行任何额外操作。您可以通过 GetLogtailPipelineConfig 接口直接获取旧版配置对应的新版流水线配置
旧版采集配置并不完全向后兼容新配流水线配置
如果流水线配置描述的采集处理能力可用旧版配置表达,则该流水线配置依然可以被 iLogtail 0.x 和 1.x 版本使用,日志服务会在向 iLogtail 下发配置时自动将新版流水线配置转换为旧版配置 反之,该流水线配置会被 iLogtail 0.x 和 1.x 版本忽略
开源版
1. 使用扩展处理插件时的 Tag 存储位置
对于通过旧版控制台界面和旧版 API 创建的采集配置,在您升级 iLogtail 2.0 后,tag 的存储位置仍然与 1.x 版本一致; 对于通过新版控制台界面和新版 API 创建的采集配置,在您升级 iLogtail 2.0 后,tag 的存储位置将默认归位。
3. 飞天格式日志微秒时间戳时区调整
4. 日志解析控制
该参数的存在是为了兼容旧版配置,当您升级 iLogtail 2.0 版本后,建议您及时删去该参数以减少不必要的重复日志上传。
总结
Cloud Native
[1] 输入插件
[2] 处理插件
[3] iLogtail 流水线配置结构
https://next.api.aliyun.com/struct/Sls/2020-12-30/LogtailPipelineConfig?spm=api-workbench.api_explorer.0.0.65e61a47jWtoir
[4] OpenAPI 文档
[5] iLogtail 2.0 版本采集配置不兼容变更说明