作者：張浩翔（篤敏）
概述
隨着可觀測數據採集需求的不斷推陳出新，多樣化的數據輸入輸出選項、個性化的數據處理能力組合、以及高性能的數據處理吞吐能力已經成爲頂流可觀測數據採集器的必備條件。然而，由於歷史原因，現有的 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 爲例）
| 場景 | CPU（核） | 內存（MB） | 處理速率（MB/s） |
|---|---|---|---|
| 單行日誌採集 | 1.06 | 33 | 400 |
| 多行日誌採集 | 1.04 | 33 | 150 |
兼容性說明
（一）採集配置
商業版
- 新版流水線採集配置是完全向前兼容舊版採集配置的，因此：
<!---->
- 在您升級 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=a2c4g.11186623.0.0.2a755c0dN5uxv4
[2] 處理插件
https://help.aliyun.com/zh/sls/user-guide/overview-22?spm=a2c4g.11186623.0.0.2f2d1279yGXSce
[3] iLogtail 流水線配置結構
[4] OpenAPI 文檔
[5] iLogtail 2.0 版本採集配置不兼容變更說明