排查資料加工錯誤思路 - Simple Log Service

資料加工任務啟動後，加工結果根據路由規則發送到對應的Logstore。如果加工任務失敗，目標Logstore沒有日誌產生或者加工延遲過大等異常，可以根據本文檔步驟進行排查處理。

錯誤分析

當發生錯誤時，分析錯誤在資料加工任務的哪個環節產生，能協助使用者更高效地定位錯誤位置。

根據加工原理，資料加工任務的主要四個環節如下圖所示。加工環節

以上每個環節都可能產生錯誤，其原因、影響和排查方式各不相同。

啟動加工引擎。
- 該環節產生錯誤主要是由於在啟動加工引擎過程中，檢測到使用者編寫的LOG DSL規則存在錯誤，導致加工引擎內部的安全檢查不通過。
- 在該階段產生錯誤時，加工任務會停止。使用者需要修改LOG DSL規則並重新啟動加工任務。如果重試成功，加工任務會繼續正常工作，不會產生日誌的丟失或冗餘。
該環節的錯誤排查方法請參見加工引擎啟動錯誤。
讀取源Logstore資料。
- 該環節產生錯誤可能是由於源Logstore資訊配置錯誤、網路錯誤、源Logstore資訊發生變化等，導致對源Logstore的訪問異常。
- 該階段產生錯誤時，加工任務會一直重試，直到重試成功或被手動停止。如果重試成功，加工任務會繼續正常工作，不會產生日誌的丟失。
- 如果是已經讀取部分資料後才報錯，則加工服務會儲存斷點並一直重試，重試成功後從斷點處繼續讀取，不會有資料的丟失與重複。如果重試過程中停止，不會有資料丟失與重複。
該環節的錯誤排查方法請參見源Logstore讀取錯誤。
加工日誌事件。
- 該環節產生錯誤主要是由於在資料加工過程中，部分或全部日誌事件不適配加工規則引發的錯誤。
- 該階段產生錯誤時，不適配加工規則的日誌事件會引發報錯，錯誤分成WARNING和ERROR層級（通過加工日誌的logging.levelname體現）。
  - 對於ERROR層級的錯誤，該日誌事件會丟棄，加工後的輸出結果中將不包含這些日誌事件。
  - 對於WARNING層級的錯誤（例如某些事件與正則規則不匹配），會跳過當前DSL的這一步，進行下一步。
該環節的錯誤排查方法請參見加工規則錯誤。
輸出到目標Logstore。
- 該環節產生錯誤可能是由於目標Logstore資訊配置錯誤、網路錯誤、目標Logstore資訊發生變化等，導致對目標Logstore的訪問異常。
- 該階段產生錯誤時，加工任務會一直重試，直到重試成功或被手動停止。如果重試成功，加工任務會繼續正常工作，不會產生日誌的丟失。
- 如果是已經輸出部分資料後才報錯，例如配置了兩個目標，一個目標成功，另外一個目標失敗。會儲存斷點並一直重試，重試成功後不會有資料的丟失與冗餘。但如果這時停止加工任務再重新啟動時，會從斷點繼續加工，不會有資料的丟失，但可能會有資料的冗餘。

通用錯誤排查

確認目標Logstore是否有資料寫入。
檢查目標Logstore最近是否有資料寫入，正確的方法是通過查看目標Logstore的消費預覽資料。
說明
通過Logstore的查詢的方式可能不準確，因為：
- 資料加工是基於日誌接收時間進行加工，可能正在加工歷史日誌，當前查詢的時間範圍與日誌的寫入時間並不一定一致。
- Log Service在寫入歷史日誌時的索引可以查詢，但通常會有幾分鐘的延遲。資料加工如果正在寫入歷史日誌，那麼查詢介面立刻查詢可能查詢不到。
查看加工任務狀態。
- 查看當前任務的進度，是否已經啟動，請參見查看任務狀態。對於時間區間固定的任務，加工到結束位置之後會自動結束。
- 查看對應任務的消費組，檢查其狀態是否開啟並有所更新。
- 參見錯誤記錄檔查看方式查看是否有異常發生，然後根據錯誤分析進一步找到原因並解決。
查看源Logstore是否有資料產生。
通過查看加工任務，確認在當前加工任務的時間範圍內，源Logstore是否存在日誌。
- 如果時間配置沒有設定結束時間，檢查源Logstore是否有新日誌產生，如果沒有新日誌產生，且特定時間範圍內沒有日誌而且沒有歷史日誌存在，加工任務無法進行。
- 如果選擇的是歷史時間，確認歷史特定時間範圍內源Logstore是否有日誌。
單擊加工任務的修改加工規則，選擇對應的時間範圍來查看是否有原始日誌。
查看加工規則是否異常。
檢查加工規則代碼中是否存在異常。例如：
- 修改了日誌的時間，導致在目前時間範圍內查詢不到。
- 加工規則在特定條件下丟棄了日誌。
  例如如下代碼，會丟棄所有欄位name不存在或者為空白的日誌，而前置邏輯是構建欄位name，如果前置邏輯存在問題，導致欄位name沒有正確構建的話，所有日誌都不會產出。
```
# ....前置邏輯.
#  .... 構建欄位name...

e_keep(e_search('name: "?"'))
```
- 如果存在從第三方拉取資料做富化的邏輯，需要確認是否因為第三方的資料過大，導致資料加工任務正在處於初始化狀態，遲遲未能開始消費資料。例如：
```
e_dict_map(res_rds_mysql(..database="userinfo", table="user"), "username", ["city", "school", "age"])
```
單擊加工任務的修改加工規則，選擇對應的時間範圍，並單擊預覽資料來查看結果。
如果能夠重現，可以通過注釋掉特定語句重試預覽進行調試。
確認Shard數量是否符合預期。
如果發現加工速度過慢，可以考慮是否源Logstore與目標Logstore的規劃不符合效能預期，建議調整源Logstore或目標Logstore的Shard數量。

錯誤記錄檔查看方式

錯誤記錄檔可以通過如下方式查看。

通過日誌庫internal-etl-log查看。
加工任務產生的日誌會儲存在日誌庫internal-etl-log中，該Logstore在執行資料加工任務後由系統自動產生。
- internal-etl-log屬於專屬Logstore，不收取任何費用，不支援修改其配置，也不支援寫入其他資料。
- internal-etl-log中每個日誌事件的__topic__欄位顯示了加工任務的狀態，可通過該欄位判斷對應的加工任務是否產生了錯誤。
- 具體的錯誤資訊通過每個日誌事件的message和reason欄位查看，如下圖所示。
通過儀錶盤查看。
單擊目標加工任務，在資料加工概覽頁面的執行狀態地區查看儀錶盤。
具體的錯誤資訊在異常詳情的reason列，如下圖所示。
控制台查看。
預覽階段的錯誤記錄檔會直接顯示在控制台。預覽階段只是類比加工規則的操作，以及預覽預期的加工結果，並不會真的對源Logstore和目標Logstore進行修改，因此預覽階段遇到的各類錯誤都不會對源日誌事件產生影響。

預覽限制

預覽階段的資料加工相較於真實的加工任務，會存在限制。

不能發現源Logstore密鑰許可權問題。
預覽階段不會建立消費組進行消費，因此不會對消費組許可權進行檢查。
不能發現加工規則中輸出目標的名稱錯誤。
預覽階段不會對寫入目標做真正的寫入操作，因此不會檢查配置項中是否配置了相關的輸出目標。
不能發現輸出目標的配置錯誤。
- 此處配置錯誤包含輸出目標的Project、Logstore、密鑰許可權等資訊配置錯誤。
- 預覽階段不會對寫入目標做真正的寫入操作，因此不會檢查輸出目標的配置資訊是否正確。
不能完整覆蓋所有資料。
- 預覽階段預設只從源Logstore中拉取1000條資料進行加工，不會覆蓋所有資料。
- 如果拉取的1000條資料經過加工後沒有加工結果產生，則會持續拉取資料五分鐘，直到有加工結果產生為止。