摘要： 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條，任一一條滿足則觸發發送：
3. 日誌聚合時間超過3秒
4. 日誌聚合條數超過4096條
5. 日誌聚合總大小超過1MB

日誌發送

1. 日誌發送前會進行壓縮，目前Logtail採用的是LZ4壓縮演算法。
2. 日誌發送受限於max_bytes_per_sec 和 send_request_concurrency 限制，Logtail會保證發送速率以及並發不超過配置值，具體參數請參考啟動參數配置。
3. 若數據發送失敗，則根據錯誤信息選擇重試還是丟棄數據：
4. 401錯誤，說明沒有許可權採集數據，直接丟棄。
5. 404錯誤，說明project或logstore不存在，直接丟棄。
6. 403錯誤，Quota超限，等待3秒後重試。
7. 500錯誤，等待3秒後重試。
8. 網路超時，等待3秒後重試。

插件採集原理

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

插件數據採集

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

數據處理

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

日誌聚合

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

日誌發送

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

資源限制

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

數據採集可靠性

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

Logtail內部採用了很多機制提升日誌採集可靠性，但並不能保證日誌絕對不會丟失。以下情況可能造成日誌丟失：

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

作者：元乙

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！