阿里雲日誌服務SLS 數據加工之多源分發詳解

前言:

阿里雲日誌服務(SLS)的數據加工功能是一個可託管、高可用、可擴展的數據加工服務，廣泛適用於數據的規整、富化、分發、彙總、重建索引等場景。使用自建的DSL編排語法，讓用戶可以通過短短几行代碼實現數據清洗和再投遞的功能。這篇文章我們主要來介紹下數據加工下的投遞功能。

undefined

本文要點:

1.e_output/e_coutput語法詳解。
2.不使用e_output/e_couput函數的最簡單投遞配置。
3.使用e_output/e_couput 函數進行多源分發實踐。
4.如何將一個logstore中不同數據通過多源分發投遞到不同logstore。

數據加工e_output 語法詳解

首先我們可以根據官方文檔來了解其參數作用 e_output。參數圖示如下:
undefined

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層層處理，能夠達到最後（沒有在中間被丟棄）的行，默認的行為會寫到第一個存儲目標（不論目標的名稱是什麼）。
undefined

3.如何設置高級參數。

有些時候我們需要從加工的數據中動態的去獲取分發目標，例如e_output(logstore=v("name")), 這個語法會動態的去取值進來，那麼假如此時目標logstore 不存在，我們的數據加工任務就會在此停住，進行不斷的重試，直到目標logstore 被創建出來為止。那麼如何才能不讓我們的加工任務繼續進行加工呢？這時可以通過配置高級參數來跳過不存在的目標Logstore: config.sls_output.failure_strategy: {“drop_when_not_exists”:”true”}
Note: 需要注意的是，當我們配置這個參數的時候，如果出現目標logstore 不存在的情況，這時候會將數據丟棄，所以請大家謹慎使用該參數。
undefined

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")

配置數據加工投遞目標
undefined

小結: 以上我們就配置成功了最簡單的數據加工任務，這裡我們沒有使用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"))

保存數據加工任務：
undefined

通過上圖我們可以看到數據經過清洗後分別發送到了配置的默認目標targe0 和其他三個用來分別存儲windows請求，ios請求，Android請求的三個(target1,target2,target3)三個目標當中。我們先看發送到目標target2,用來存儲IOS數據的logstore 中用戶get/post兩種請求佔比:
這裡我們在控制檯輸入sql 語句：
* | SELECT Request_method, COUNT(*) as number GROUP BY Request_method
生成如下的儀表盤:
undefined

可以看出用戶在IOS 端發送GET/POST請求的比例基本是7:3。

同樣的分析語句，我們來看目標target3，用來存儲Android數據的logstore中的GET/POST請求佔比:
undefined
通過儀表盤可以看出，通過Android客戶端進行的GET/POST請求基本上是6:4 ，證明在使用Android系統的用戶中，該廣告轉化率較高。

3.使用e_split和e_output將logstore中不同字段分發到不同logstore中

背景：
在使用數據加工多源分發的任務中，有的用戶希望通過多源分發函數，將不同的字段輸出到不同的目標logstore 當中去。這裡我們用e_split函數結合 e_output函數來實現該需求。

需求圖示:
undefined

日誌樣例：

__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 兩份數據做不同的加工和分發。

加工結果：