資料加工調度原理及加工規則引擎工作原理 - Simple Log Service

Log Service提供的資料加工功能，通過編排內建的兩百多個函數，使用協同消費組對日誌資料進行消費，實現對日誌資料的加工處理。本文檔主要介紹進行資料加工時日誌資料的調度原理，以及加工規則引擎的工作原理。

調度原理

Log Service的資料加工功能使用協同消費組對源日誌庫的日誌資料進行流式消費，將每一條日誌通過加工規則處理後再輸出。

調度機制
對每一個加工規則，加工服務的調度器會啟動一個或多個運行執行個體，每個運行執行個體扮演一個消費者的角色去消費1個或者多個源Logstore的Shard，調度器會根據運行執行個體對記憶體與CPU的消耗情況決定並行的運行執行個體數，最多啟動與源Logstore的Shard數量相同的運行執行個體。
運行執行個體
根據使用者配置從分配的Shard中讀取源日誌資料，經過加工規則處理後再輸出到目標Logstore。加工規則支援通過外部資源對日誌資料進行富化。運行執行個體支援通過消費組機制儲存Shard的消費位置，確保意外停止後可以從斷點處繼續消費。
任務停止
- 當使用者沒有配置任務的終點時間時，運行執行個體預設不會退出，則加工任務不會停止。
- 當使用者配置了任務的終點時間時，運行執行個體處理到配置的終點時間所接收的日誌後會自動結束，加工任務停止。
- 當任務因為某些原因被停止，再次啟動時，預設會從上次儲存的消費位置繼續消費。

使用SLS DSL提供的內建函數編寫加工規則，每個函數可以看做一個加工步驟，規則引擎按步驟順序執行函數。例如下面4個函數定義了4個主要步驟。

e_set("log_type", "access_log")
e_drop_fields("__action")
e_if(e_search("ret: pass"), e_set("result", "pass"))
e_if(e_search("ret: unknown"), DROP)

對應的邏輯圖：

基本邏輯
規則中定義的每個事件函數會順序執行，每一個函數會對每個事件處理和修改，返回一個處理後的事件。
例如e_set("log_type", "access_log")會為每個事件添加一個值為access_log的欄位log_type，下一個函數接收到的事件就是添加欄位log_type後的最新事件。
條件判斷
步驟可以設定條件，不滿足條件的事件會跳過本次操作。
例如e_if(e_search("ret: pass"), e_set("result", "pass"))，會首先檢查欄位ret是否包含pass，不滿足條件不會做任何操作；如果滿足條件，則會設定欄位result的值為pass。
停止處理
步驟返回0個事件，表示刪除事件。
例如e_if(e_search("ret: unknown"), DROP)，丟棄欄位ret的值是unknown的事件，這條事件被丟棄後，後續的操作將不再進行，自動重新開始下一條事件。

規則引擎也支援複製、輸出與分裂事件，例如下面4個函數定義了4個主要步驟。

e_coutput("archive_Logstore") )
e_split("log_type")
e_if(e_search("log_type: alert"), e_output("alert_Logstore") )
e_set("result", "pass")

假設現在處理的一條源日誌如下：

log_type: access,alert
content: admin login to database.

對應的邏輯如圖：規則引擎原理邏輯圖

輸出事件
預設輸出事件可以視為一種特殊的停止處理，例如第3步中對欄位log_type的值為alert的事件調用e_output("alert_Logstore")函數，提前輸出事件到指定目標並刪除該事件，其後續的操作也不會再進行。
複製輸出事件
函數e_coutput會複製當前的事件進行輸出，輸出後原事件會繼續進行後續處理。例如第1步中，會將所有接收到的日誌輸出到archive_Logstore目標中。
分裂並行
在第2步中，假如log_type欄位的值是access和alert，e_split("log_type")表示根據欄位log_type的值分裂成兩條事件，分裂後的兩條事件除欄位值分別為access和alert以外，其餘完全一樣。
分裂後的每條事件都會分別繼續進行後續的步驟。