前言:
阿裡雲日志服務(SLS)的
資料加工功能是一個可托管、高可用、可擴充的資料加工服務,廣泛适用于資料的規整、富化、分發、彙總、重建索引等場景。使用自建的DSL編排文法,讓使用者可以通過短短幾行代碼實作資料清洗和再投遞的功能。這篇文章我們主要來介紹下資料加工下的投遞功能。
本文要點:
1.e_output/e_coutput文法詳解。
2.不使用e_output/e_couput函數的最簡單投遞配置。
3.使用e_output/e_couput 函數進行多源分發實踐。
4.如何将一個logstore中不同資料通過多源分發投遞到不同logstore。
資料加工e_output 文法詳解
首先我們可以根據官方文檔來了解其參數作用
e_output。參數圖示如下:

1.參數差別。
當我們使用e_output 函數的時候,需要在裡面填入name, project, logstore 等參數,其中name參數對應的是右邊儲存資料加工時候需要填入的存儲目标的名稱。那麼這時候有的小夥伴可能會有點蒙,既然在存儲目标裡面已經填入了project, logstore 的名稱,為什麼在e_output裡面還有這兩個參數,如果在e_output 裡面填入的project,logstore參數和存儲目标裡面填入的 project,logstore 參數不一緻,那麼我的資料又會被發送到哪裡? 那麼我們從下面這個表格裡去詳細解釋他們之間的差別:
用法 | 文法示例 | 說明 |
---|---|---|
隻填寫name參數 | e_output(name="target") | 會發送資料到目标"target"中配置的logstore 中去。 |
同時填寫name,project,logstore 參數 | e_output(name="target",project="test_project",logstore="test_logstore") | 資料會發送到"test_logstore"當中去,使用的ak 為目标"target"下配置的AK 資訊。 |
不填寫name 參數,隻填project/logstore參數 | e_output(project="test_project",logstore="test_logstre") | 資料會發送到"test_logstore"當中去。使用的 AK 資訊為目前登入賬号的AK 資訊。 |
2.如何配置預設目标。
要注意的是當我們使用e_output這個函數時候,需要在目标中配置一個預設目标,經過加工DSL層層處理,能夠達到最後(沒有在中間被丢棄)的行,預設的行為會寫到第一個存儲目标(不論目标的名稱是什麼)。
3.如何設定進階參數。
有些時候我們需要從加工的資料中動态的去擷取分發目标,例如e_output(logstore=v("name")), 這個文法會動态的去取值進來,那麼假如此時目标logstore 不存在,我們的資料加工任務就會在此停住,進行不斷的重試,直到目标logstore 被建立出來為止。那麼如何才能不讓我們的加工任務繼續進行加工呢? 這時可以通過配置進階參數來跳過不存在的目标Logstore: config.sls_output.failure_strategy: {“drop_when_not_exists”:”true”}
Note: 需要注意的是,當我們配置這個參數的時候,如果出現目标logstore 不存在的情況,這時候會将資料丢棄,是以請大家謹慎使用該參數。

4.e_output和e_coutput的差別
當資料加工文法執行到e_output語句的時候不會在執行後續的文法,而e_coutput 是可以繼續執行後續的語句的。
案例實踐
1.不使用e_output文法的 最基本簡單分發
最基本的資料分發,我們不需要使用e_output 文法去進行動态的分發,隻需要配置最基礎的分發目标,加工後的資料就會被投遞到目标logstore 當中去。我們來做一個最簡單的分發,将日志設定一個新字段後投遞到另外兩個目标logstore。
日志樣例:
__time__ : 1591754815
__source__: 127.0.0.1
product: aliyun
product_2: ecs
加工文法:
e_set("new","new_name")
配置資料加工投遞目标

小結: 以上我們就配置成功了最簡單的資料加工任務,這裡我們沒有使用e_output/e_coutput文法一樣可以達到多目标投遞效果。
2. 案例實踐: 通過解析user-agent請求頭并使用e_output函數進行多源分發
現有某公司對一款遊戲進行了廣告投放,現在關于該遊戲的所有API請求資訊都存儲在一個logstore當中,公司希望通過解析useragent請求頭,将來自不同裝置的請求進行歸檔分發存儲(ios/android/windows), 并且對method方法進行資料分析。
需求分析
首先針對上述需求,需要使用ua_parse_os 函數首先對資料中的useragent 進行解析拿到該裝置的os資訊,後根據所得資訊調用 e_output 函數進行動态分發。
原始資料樣例
以下logstore 資料中,我們将會對 user_agent 字段的值進行解析,并對解析後的資訊進行清洗和轉發。
__source__:127.0.0.1
__tag__:__receive_time__: 1589541467
ip:31.110.75.122
request_method: GET
user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
資料加工文法與邏輯
# 使用ua_parse_os函數,解析user_agent字段,使用dct_get函數,拿到請求頭中的os資訊,并把值賦予新字段os。
e_set("os", dct_get(ua_parse_os(v("user_agent")),"family"))
# 根據os 字段的值,結合e_if 文法進行分發,根據解析出來不同值分發到不同logstore。
e_if(e_search("os==Windows"),e_output(name="target1"))
e_if(e_search("os=iOS"),e_output(name="target2"))
e_if(e_search("os==Android"),e_output(name="target3"))
儲存資料加工任務:

通過上圖我們可以看到資料經過清洗後分别發送到了配置的預設目标targe0 和其他三個用來分别存儲windows請求,ios請求,Android請求的三個(target1,target2,target3)三個目标當中。我們先看發送到目标target2,用來存儲IOS資料的logstore 中使用者get/post兩種請求占比:
這裡我們在控制台輸入sql 語句:
* | SELECT Request_method, COUNT(*) as number GROUP BY Request_method
生成如下的儀表盤:

可以看出使用者在IOS 端發送GET/POST請求的比例基本是7:3。
同樣的分析語句,我們來看目标target3,用來存儲Android資料的logstore中的GET/POST請求占比:

通過儀表盤可以看出,通過Android用戶端進行的GET/POST請求基本上是6:4 ,證明在使用Android系統的使用者中,該廣告轉化率較高。
3.使用e_split和e_output将logstore中不同字段分發到不同logstore中
背景:
在使用資料加工多源分發的任務中,有的使用者希望通過多源分發函數,将不同的字段輸出到不同的目标logstore 當中去。這裡我們用
e_split函數結合
函數來實作該需求。
需求圖示:

日志樣例:
__time__ : 1591754815
__source__: 127.0.0.1
product: aliyun
product_2: ecs
DSL編排文法:
e_set("tag", "t1, t2")
e_split("tag")
e_if(e_search("tag==t1"),e_compose(e_keep_fields("__time__", "__source__","product", regex=False),e_output(name="t1")))
e_keep_fields("__time__","__source__","product_2", regex=False)
e_output(name="t2")
文法解析:
1.我們首先設定了一個新字段 tag , 并且給予其 "t1,t2"的值,
2.接下來我們使用e_split()函數将資料按照 t1,t2 分裂成兩份資料。
3.然後通過e_if 和 e_search 組合文法,針對t1, t2 兩份資料做不同的加工和分發。
加工結果:

寫在最後
關于多源分發函數的使用,隻是資料加工諸多函數中其中一個,目前資料加工提供的加工函數類型有100+,能夠覆寫絕大多數資料加工的場景,其他的函數的使用還需要使用者移步
阿裡雲日志服務資料加工函總覽。資料加工目前經曆了大量場景的錘煉,我們對使用者提出的需求也在不斷改進中,期望将來持續為使用者提供更貼心的服務,更暢快的使用感受。