Logtail從入門到精通（六）：工做原理簡介

摘要： Logtail數據採集原理介紹，包括文件採集原理以及插件採集原理。

文件採集原理

Logtail文件採集的流程包括：文件監聽、文件讀取、日誌處理、日誌過濾、日誌聚合和數據發送6個環節。下面將分別進行介紹：

 

• 注意：本節只介紹正常運行模式中Logtail的文件採集原理，該模式下不支持採集歷史文件，若有采集歷史文件需求，請參考採集歷史文件。

文件監聽

1. 當Logtail獲取到採集配置後，根據配置的日誌路徑、文件名、最大監控目錄深度遞歸掃描目錄下符合文件名規則的日誌目錄和文件。
2. 爲保證日誌採集時效性以及穩定性，Logtail會對採集目錄註冊事件監聽（Linux下Inotify、Windows下使用ReadDirectoryChangesW）以及按期輪詢。
3. 當第一次應用配置時，對於目錄下存量的日誌文件不會進行採集，直到文件在配置應用後產生修改事件纔會採集。
4. 當監聽到文件修改後，會進入文件讀取環節。

文件讀取

1. 每次Logtail讀取會從該文件上一次讀取的偏移處開始。
2. 若該文件首次讀取，會檢查該文件大小，若文件小於1MB，則從文件頭開始讀取，不然從文件尾1MB處開始讀取。
3. 每次讀取最多512KB數據，所以一條日誌最大支持512KB。

日誌處理

1. 對於讀取的數據塊，會根據行首配置進行分行，切分紅多條日誌。
2. 對於每條日誌內容執行對應的解析，例如正則、分隔符、JSON等。
3. 若未配置時間字段，則日誌時間爲當前解析時間；若配置了時間提取字段，則從解析的日誌字段中提取時間，若時間距離當前時間超過12小時，則丟棄該日誌並上傳錯誤信息。
4. 若該日誌能夠被正確解析，則進入日誌過濾環節。
5. 若該日誌解析失敗且開啓 高級配置中的丟棄解析失敗日誌，則直接丟棄該日誌，並上報解析失敗的報錯信息
6. 若該日誌解析失敗，但未開啓 高級配置中的丟棄解析失敗日誌，則將解析失敗的原始日誌上傳，其中Key爲__raw_log__、Value爲日誌內容

日誌過濾

1. 若用戶未設置 高級配置 中的 過濾器配置，則跳過日誌過濾環節。
2. 若用戶已經設置過濾器配置，則會對每條日誌中的全部字段進行遍歷並驗證。
3. 只有過濾器中配置的全部字段都在該日誌出現，且全部對應的字段所有符合過濾器配置時，日誌纔會被採集，不然丟棄該日誌。

日誌聚合

1. 爲下降網絡請求次數，當日志處理、過濾完畢後，會在Logtail內部緩存一段時間再進行發送。

2. 緩存規則有3條，任一一條知足則觸發發送：

   1. 日誌聚合時間超過3秒
   2. 日誌聚合條數超過4096條
   3. 日誌聚合總大小超過1MB

日誌發送

1. 日誌發送前會進行壓縮，目前Logtail採用的是LZ4壓縮算法。
2. 日誌發送受限於max_bytes_per_sec 和 send_request_concurrency 限制，Logtail會保證發送速率以及併發不超過配置值，具體參數請參考啓動參數配置。

3. 若數據發送失敗，則根據錯誤信息選擇重試仍是丟棄數據：

   1. 401錯誤，說明沒有權限採集數據，直接丟棄。
   2. 404錯誤，說明project或logstore不存在，直接丟棄。
   3. 403錯誤，Quota超限，等待3秒後重試。
   4. 500錯誤，等待3秒後重試。
   5. 網絡超時，等待3秒後重試。

插件採集原理

Logtail的插件採集流程主要包括如下環節：插件數據採集、數據處理、日誌聚合和日誌發送。

插件數據採集

插件數據採集的原理在每一個插件的文檔中都有介紹，具體請參見各個插件的幫助文檔。

數據處理

插件數據處理邏輯請參考插件-數據處理。

日誌聚合

插件的日誌聚合邏輯和文件採集的日誌聚合邏輯一致。

日誌發送

插件的日誌發送邏輯和文件採集的日誌發送邏輯一致。

資源限制

Logtail會根據配置文件中的資源限制進行工做，若資源佔用長時間（5分鐘）超過限定值，則Logtail會進行強制重啓。重啓後可能會產生必定的數據重複。

數據採集可靠性

Logtail在採集數據時，會按期將採集的點位（CheckPoint）信息保存到本地，若遇到宕機、Crash等異常時，Logtail再次啓動會從上一次記錄的位置處開始採集數據，儘量保證數據不丟失。

Logtail內部採用了不少機制提高日誌採集可靠性，但並不能保證日誌絕對不會丟失。如下狀況可能形成日誌丟失：

1. Logtail未運行且日誌輪轉屢次。
2. 日誌輪轉速度極快，例如1秒輪轉1次。
3. 日誌採集速度長期沒法達到日誌產生速度。

做者：元乙​

原文連接