日志采集系統(tǒng)用到的技術有哪些

這篇文章主要介紹“日志采集系統(tǒng)用到的技術有哪些”，在日常操作中，相信很多人在日志采集系統(tǒng)用到的技術有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”日志采集系統(tǒng)用到的技術有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

概述

日志從最初面向人類演變到現(xiàn)在的面向機器發(fā)生了巨大的變化。最初的日志主要的消費者是軟件工程師，他們通過讀取日志來排查問題，如今，大量機器日夜處理日志數(shù)據(jù)以生成可讀性的報告以此來幫助人類做出決策。在這個轉變的過程中，日志采集Agent在其中扮演著重要的角色。

作為一個日志采集的Agent簡單來看其實就是一個將數(shù)據(jù)從源端投遞到目的端的程序，通常目的端是一個具備數(shù)據(jù)訂閱功能的集中存儲，這么做的目的其實是為了將日志分析和日志存儲解耦，同一份日志可能會有不同的消費者感興趣，獲取到日志后所處理的方式也會有所不同，通過將數(shù)據(jù)存儲和數(shù)據(jù)分析進行解耦后，不同的消費者可以訂閱自己感興趣的日志，選擇對應的分析工具進行分析。

像這樣的具備數(shù)據(jù)訂閱功能的集中存儲業(yè)界比較流行的是Kafka，對應到阿里巴巴內部就是DataHub還有阿里云的LogHub。而數(shù)據(jù)源端大致可以分為三類，一類就是普通的文本文件，另外一類則是通過網(wǎng)絡接收到的日志數(shù)據(jù)，最后一類則是通過共享內存的方式，本文只會談及第一類。一個日志采集Agent最為核心的功能大致就是這個樣子了。

在這個基礎上進一步又可以引入日志過濾、日志格式化、路由等功能，看起來就好像是一個生產車間。從日志投遞的方式來看，日志采集又可以分為推模式和拉模式，本文主要分析的是推模式的日志采集。

推模式是指日志采集Agent主動從源端取得數(shù)據(jù)后發(fā)送給目的端，而拉模式指的是目的端主動向日志采集Agent獲取源端的數(shù)據(jù)

業(yè)界現(xiàn)狀

目前業(yè)界比較流行的日志采集主要有Fluentd、Logstash、Flume、scribe等，阿里巴巴內部則是LogAgent、阿里云則是LogTail，這些產品中Fluentd占據(jù)了絕對的優(yōu)勢并成功入駐CNCF陣營，它提出的統(tǒng)一日志層(Unified Logging Layer)大大的減少了整個日志采集和分析的復雜度。

Fluentd認為大多數(shù)現(xiàn)存的日志格式其結構化都很弱，這得益于人類出色的解析日志數(shù)據(jù)的能力，因為日志數(shù)據(jù)其最初是面向人類的，人類是其主要的日志數(shù)據(jù)消費者。

為此Fluentd希望通過統(tǒng)一日志存儲格式來降低整個日志采集接入的復雜度，假想下輸入的日志數(shù)據(jù)比如有M種格式，日志采集Agent后端接入了N種存儲，那么每一種存儲系統(tǒng)需要實現(xiàn)M種日志格式解析的功能，總的復雜度就是M*N，如果日志采集Agent統(tǒng)一了日志格式那么總的復雜度就變成了M + N。這就是Fluentd的核心思想，另外它的插件機制也是一個值得稱贊的地方。

Logstash和Fluentd類似是屬于ELK技術棧，在業(yè)界也被廣泛使用，關于兩者的對比可以參考這篇文章Fluentd vs. Logstash: A Comparison of Log Collectors

從頭開始寫一個日志采集Agent

作為一個日志采集Agent在大多數(shù)人眼中可能就是一個數(shù)據(jù)“搬運工”，還會經常抱怨這個“搬運工”用了太多的機器資源，簡單來看就是一個tail -f命令，再貼切不過了，對應到Fluentd里面就是in_tail插件。

筆者作為一個親身實踐過日志采集Agent的開發(fā)者，希望通過本篇文章來給大家普及下日志采集Agent開發(fā)過程中的一些技術挑戰(zhàn)。為了讓整篇文章脈絡是連續(xù)的，筆者試圖通過“從頭開始寫一個日志采集Agent”的主題來講述在整個開發(fā)過程中遇到的問題。

如何發(fā)現(xiàn)一個文件?

當我們開始寫日志采集Agent的時候遇到的第一個問題就是怎么發(fā)現(xiàn)文件，最簡單的方式就是用戶直接把要采集的文件羅列出來放在配置文件中，然后日志采集Agent會讀取配置文件找到要采集的文件列表，最后打開這些文件進行采集，這恐怕是最為簡單的了。

但是大多數(shù)情況日志是動態(tài)產生的，會在日志采集的過程中動態(tài)的創(chuàng)建出來, 提前羅列到配置文件中就太麻煩了。正常情況下用戶只需要配置一個日志采集的目錄和文件名字匹配的規(guī)則就可以了，比如Nginx的日志是放在/var/www/log目錄下，日志文件的名字是access.log、access.log-2018-01-10.....類似于這樣的形式，為了描述這類文件可以通過通配符或者正則的表示來匹配這類文件例如: access.log(-[0-9]{4}-[0-9]{2}-[0-9]{2})?有了這樣的描述規(guī)則后日志采集Agent就可以知道哪些文件是需要采集的，哪些文件是不用采集的。

接下來會遇到另外一個問題就是如何發(fā)現(xiàn)新創(chuàng)建的日志文件?，定時去輪詢下目錄或許是個不錯的方法，但是輪詢的周期太長會導致不夠實時，太短又會耗CPU，你也不希望你的采集Agent被人吐槽占用太多CPU吧。Linux內核給我們提供了高效的Inotify的機制，由內核來監(jiān)測一個目錄下文件的變化，然后通過事件的方式通知用戶。

但是別高興的太早，Inotify并沒有我們想的那么好，它存在一些問題，首先并不是所有的文件系統(tǒng)都支持Inotify，此外它不支持遞歸的目錄監(jiān)測，比如我們對A目錄進行監(jiān)測，但是如果在A目錄下面創(chuàng)建了B目錄，然后立刻創(chuàng)建C文件，那么我們只能得到B目錄創(chuàng)建的事件，C文件創(chuàng)建的事件就會丟失，最終會導致這個文件沒有被發(fā)現(xiàn)和采集。

對于已經存在的文件Inotify也無能為力，Inotify只能實時的發(fā)現(xiàn)新創(chuàng)建的文件。Inotify manpage中描述了更多關于Inotify的一些使用上的限制以及bug。如果你要保證不漏采那么最佳的方案還是Inotify+輪詢的組合方式。通過較大的輪詢周期來檢測漏掉的文件和歷史文件，通過Inotify來保證新創(chuàng)建的文件在絕大數(shù)情況下可以實時發(fā)現(xiàn)，即使在不支持Inotify的場景下，單獨靠輪詢也能正常工作。

到此為止我們的日志采集Agent可以發(fā)現(xiàn)文件了，那么接下來就需要打開這個文件，然后進行采集了。但是天有不測風云，在我們采集的過程中機器Crash掉了，我們該如何保證已經采集的數(shù)據(jù)不要再采集了，能夠繼續(xù)上次沒有采集到的地方繼續(xù)呢?

基于輪詢的方式其優(yōu)點就是保證不會漏掉文件，除非文件系統(tǒng)發(fā)生了bug，通過增大輪詢的周期可以避免浪費CPU、但是實時性不夠。Inotify雖然很高效，實時性很好但是不能保證100%不丟事件。因此通過結合輪詢和Inotify后可以相互取長補短。

點位文件高可用

點位文件? 對就是通過點位文件來記錄文件名和對應的采集位置。那如何保證這個點位文件可以可靠的寫入呢? 因為可能在文件寫入的那一刻機器Crash了導致點位數(shù)據(jù)丟掉或者數(shù)據(jù)錯亂了。要解決這個問題就需要保證文件寫入要么成功，要么失敗，絕對不能出現(xiàn)寫了一半的情況。Linux內核給我們提供了原子的rename。

一個文件可以原子的rename成另外一個文件，利用這個特性可以保證點位文件的高可用。假設我們已經存在一份點位文件叫做offset，每一秒我們去更新這個點位文件，將采集的位置實時的記錄在里面，整個更新的過程如下：

• 將點位數(shù)據(jù)寫入到磁盤的offset.bak文件中

• fdatasync確保數(shù)據(jù)寫入到磁盤

• 通過rename系統(tǒng)調用將offset.bak更名為offset

通過這個手段可以保證在任何時刻點位文件都是正常的，因為每次寫入都會先確保寫入到臨時文件是成功的，然后原子的進行替換。這樣就保證了offset文件總是可用的。在極端場景下會導致1秒內的點位沒有及時更新，日志采集Agent啟動后會再次采集這1秒內的數(shù)據(jù)進行重發(fā)，這基本上滿足需求了。

但是點位文件中記錄了文件名和對應的采集位置這會帶來另外一個問題，如果在進程Crash的過程中，文件被重命名了該怎么辦? 那啟動后豈不是找不到對應的采集位置了。在日志的這個場景下文件名其實非常不可靠，文件的重命名、刪除、軟鏈等都會導致相同的文件名在不同時刻其實指向的是不同的文件，而且將整個文件路徑在內存中保存其實是非常耗費內存的。

Linux內核提供了inode可以作為文件的標識信息，而且保證同一時刻Inode是不會重復的，這樣就可以解決上面的問題，在點位文件中記錄文件的inode和采集的位置即可。日志采集Agent啟動后通過文件發(fā)現(xiàn)找到要采集的文件，通過獲取Inode然后從點位文件中查找對應的采集位置，最后接著后面繼續(xù)采集即可。那么即使文件重命名了但是它的Inode不會變化，所以還是可以從點位文件中找到對應的采集位置。

但是Inode有沒有限制呢? 當然有，天下沒有免費的午餐，不同的文件系統(tǒng)Inode會重復，一個機器可以安裝多個文件系統(tǒng)，所以我們還需要通過dev(設備號)來進一步區(qū)分，所以點位文件中需要記錄的就是dev、inode、offset三元組。到此為止我們的采集Agent可以正常的采集日志了，即使Crash了再次啟動后仍然可以繼續(xù)進行采集。

但是突然有一天我們發(fā)現(xiàn)有兩個文件居然是同一個Inode，Linux內核不是保證同一時刻不會重復的嗎?難道是內核的bug?注意我用的是“同一時刻”，內核只能保證在同一時刻不會重復，這到底是什么意思呢? 這便是日志采集Agent中會遇到的一個比較大的技術挑戰(zhàn)，如何準確的標識一個文件。

如何識別一個文件?

如何標識一個文件算是日志采集Agent中一個比較有挑戰(zhàn)的技術問題了，我們先是通過文件名來識別，后來發(fā)現(xiàn)文件名并不可靠，而且還耗費資源，后來我們換成了dev+Inode，但是發(fā)現(xiàn)Inode只能保證同一時刻Inode不重復，那這句話到底是什么意思呢?

想象一下在T1時刻有一個文件Inode是1我們發(fā)現(xiàn)了并開始采集，一段時間后這個文件被刪除了，Linux內核就會將這個Inode釋放掉，新創(chuàng)建一個文件后Linux內核會將剛釋放的Inode又分配給這個新文件。那么這個新文件被發(fā)現(xiàn)后會從點位文件中查詢上次采集到哪了，結果就會找到之前的那個文件記錄的點位了，導致新文件是從一個錯誤的位置進行采集。

如果能給每一個文件打上一個唯一標識或許就可以解決這個問題，幸好Linux內核給文件系統(tǒng)提供了擴展屬性xattr，我們可以給每一個文件生成唯一標識記錄在點位文件中，如果文件被刪除了，然后創(chuàng)建一個新的文件即使Inode相同，但是文件標識不一樣，日志采集Agent就可以識別出來這是兩個文件了。

但是問題來了，并不是所有的文件系統(tǒng)都支持xattr擴展屬性。所以擴展屬性只是解了部分問題。或許我們可以通過文件的內容來解決這個問題，可以讀取文件的前N個字節(jié)作為文件標識。這也不失為一種解決方案，但是這個N到底取多大呢?

越大相同的概率越小，造成無法識別的概率就越小。要真正做到100%識別出來的通用解決方案還有待調研，姑且認為這里解了80%的問題吧。接下來就可以安心的進行日志采集了，日志采集其實就是讀文件了，讀文件的過程需要注意的就是盡可能的順序讀，充份利用Linux系統(tǒng)緩存，必要的時候可以用posix_fadvise在采集完日志文件后清除頁緩存，主動釋放系統(tǒng)資源。那么什么時候才算采集完一個文件呢?

采集到末尾返回EOF的時候就算采集完了?？墒且粫罩疚募謺行聝热莓a生，如何才知道有新數(shù)據(jù)了，然后繼續(xù)采集呢?

如何知道文件內容更新了?

Inotify可以解決這個問題、通過Inotify監(jiān)控一個文件，那么只要這個文件有新增數(shù)據(jù)就會觸發(fā)事件，得到事件后就可以繼續(xù)采集了。但是這個方案存在一個問題就是在大量文件寫入的場景會導致事件隊列溢出，比如用戶連續(xù)寫入日志N次就會產生N個事件，其實對于日志采集Agent只要知道內容就更新就可以了，至于更新幾次這個反而不重要， 因為每次采集其實都是持續(xù)讀文件，直到EOF，只要用戶是連續(xù)寫日志，那么就會一直采集下去。

另外Intofy能監(jiān)控的文件數(shù)量也是有上限的。所以這里最簡單通用的方案就是輪詢去查詢要采集文件的stat信息，發(fā)現(xiàn)文件內容有更新就采集，采集完成后再觸發(fā)下一次的輪詢，既簡單又通用。通過這些手段日志采集Agent終于可以不中斷的持續(xù)采集日志了，既然是日志總會有被刪除的一刻，如果在我們采集的過程中被刪除了會如何?

大可放心，Linux中的文件是有引用計數(shù)的，已經打開的文件即使被刪除也只是引用計數(shù)減1，只要有進程引用就可以繼續(xù)讀內容的，所以日志采集Agent可以安心的繼續(xù)把日志讀完，然后釋放文件的fd，讓系統(tǒng)真正的刪除文件。但是如何知道采集完了呢?

廢話，上面不是說了采集到文件末尾就是采集完了啊，可是如果此刻還有另外一個進程也打開了這個文件，在你采集完所有內容后又追加了一段內容進去，而你此時已經釋放了fd了，在文件系統(tǒng)上這個文件已經不在了，再也沒辦法通過文件發(fā)現(xiàn)找到這個文件，打開并讀取數(shù)據(jù)了，這該怎么辦?

如何安全的釋放文件句柄?

Fluentd的處理方式就是將這部分的責任推給用戶，讓用戶配置一個時間，文件刪除后如果在指定的時間范圍內沒有數(shù)據(jù)新增就釋放fd，其實這就是間接的甩鍋行為了。這個時間配置的太小會造成丟數(shù)據(jù)的概率增大，這個時間配置的太大會導致fd和磁盤空間一直被占用造成短時間自由浪費的假象。

這個問題的本質上其實就是我們不知道還有誰在引用這個文件，如果還有人在引用這個文件就可能會寫入數(shù)據(jù)，此時即使你釋放了fd資源仍然是占用的，還不如不釋放，如果沒有任何人在引用這個文件了，那其實就可以立刻釋放fd了。如何知道誰在引用這個文件呢?

想必大家都用過 lsof -f列出系統(tǒng)中進程打開的文件列表，這個工具通過掃描每一個進程的/proc/PID/fd/目錄下的所有文件描述符，通過readlink就可以查看這個描述符對應的文件路徑，例如下面這個例子:

tianqian-zyf@ubuntu:~$ sudo ls -al /proc/22686/fd  total 0  dr-x------ 2 tianqian-zyf tianqian-zyf  0 May 27 12:25 .  dr-xr-xr-x 9 tianqian-zyf tianqian-zyf  0 May 27 12:25 ..  lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 0 -> /dev/pts/19  lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 1 -> /dev/pts/19  lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 2 -> /dev/pts/19  lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 4 -> /home/tianqian-zyf/.post.lua.swp

22686這個進程就打開了一個文件，fd是4，對應的文件路徑是/home/tianqian-zyf/.post.lua.swp。通過這個方法可以查詢到文件的引用計數(shù)，如果引用計數(shù)是1，也就是只有當前進程引用，那么基本上可以做到安全的釋放fd，不會造成數(shù)據(jù)丟失，但是帶來的問題就是開銷有點大，需要遍歷所有的進程查看它們的打開文件表逐一的比較，復雜度是O(n)，如果能做到O(1)這個問題才算完美解決。

通過搜索相關的資料我發(fā)現(xiàn)這個在用戶態(tài)來做幾乎是沒有辦法做到的，Linux內核沒有暴露相關的API。只能通過Kernel的方式來解決，比如添加一個API通過fd來獲取文件的引用計數(shù)。這在內核中還是比較容易做到的，每一個進程都保存了打開的文件，在內核中就是struct file結構，通過這個結構就可以找到這個文件對應的struct inode對象，這個對象內部就維護了引用計數(shù)值。期待后續(xù)Linux內核能夠提供相關的API來完美解決這個問題吧。

到此，關于“日志采集系統(tǒng)用到的技術有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>