作者：張浩翔（篤敏）
概述
隨著可觀測資料採集需求的不斷推陳出新，多樣化的資料輸入輸出選項、個性化的資料處理能力組合、以及高效能的資料處理吞吐能力已經成為頂流可觀測資料採集器的必備條件。然而，由於歷史原因，現有的 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=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 版本採集配置不相容變更說明