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

作為一個(gè)日志采集的Agent簡(jiǎn)單來(lái)看其實(shí)就是一個(gè)將數(shù)據(jù)從源端投遞到目的端的程序，通常目的端是一個(gè)具備數(shù)據(jù)訂閱功能的集中存儲(chǔ)，這么做的目的其實(shí)是為了將日志分析和日志存儲(chǔ)解耦，同一份日志可能會(huì)有不同的消費(fèi)者感興趣，獲取到日志后所處理的方式也會(huì)有所不同，通過(guò)將數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)分析進(jìn)行解耦后，不同的消費(fèi)者可以訂閱自己感興趣的日志，選擇對(duì)應(yīng)的分析工具進(jìn)行分析。像這樣的具備數(shù)據(jù)訂閱功能的集中存儲(chǔ)業(yè)界比較流行的是Kafka，對(duì)應(yīng)到阿里巴巴內(nèi)部就是DataHub還有阿里云的LogHub。而數(shù)據(jù)源端大致可以分為三類(lèi)，一類(lèi)就是普通的文本文件，另外一類(lèi)則是通過(guò)網(wǎng)絡(luò)接收到的日志數(shù)據(jù)，最后一類(lèi)則是通過(guò)共享內(nèi)存的方式，本文只會(huì)談及第一類(lèi)。一個(gè)日志采集Agent最為核心的功能大致就是這個(gè)樣子了。在這個(gè)基礎(chǔ)上進(jìn)一步又可以引入日志過(guò)濾、日志格式化、路由等功能，看起來(lái)就好像是一個(gè)生產(chǎn)車(chē)間。從日志投遞的方式來(lái)看，日志采集又可以分為推模式和拉模式，本文主要分析的是推模式的日志采集。

推模式是指日志采集Agent主動(dòng)從源端取得數(shù)據(jù)后發(fā)送給目的端，而拉模式指的是目的端主動(dòng)向日志采集Agent獲取源端的數(shù)據(jù)業(yè)界現(xiàn)狀

目前業(yè)界比較流行的日志采集主要有Fluentd、Logstash、Flume、scribe等，阿里巴巴內(nèi)部則是LogAgent、阿里云則是LogTail，這些產(chǎn)品中Fluentd占據(jù)了絕對(duì)的優(yōu)勢(shì)并成功入駐CNCF陣營(yíng)，它提出的統(tǒng)一日志層(Unified Logging Layer)大大的減少了整個(gè)日志采集和分析的復(fù)雜度。Fluentd認(rèn)為大多數(shù)現(xiàn)存的日志格式其結(jié)構(gòu)化都很弱，這得益于人類(lèi)出色的解析日志數(shù)據(jù)的能力，因?yàn)槿罩緮?shù)據(jù)其最初是面向人類(lèi)的，人類(lèi)是其主要的日志數(shù)據(jù)消費(fèi)者。為此Fluentd希望通過(guò)統(tǒng)一日志存儲(chǔ)格式來(lái)降低整個(gè)日志采集接入的復(fù)雜度，假想下輸入的日志數(shù)據(jù)比如有M種格式，日志采集Agent后端接入了N種存儲(chǔ)，那么每一種存儲(chǔ)系統(tǒng)需要實(shí)現(xiàn)M種日志格式解析的功能，總的復(fù)雜度就是M*N，如果日志采集Agent統(tǒng)一了日志格式那么總的復(fù)雜度就變成了M + N。這就是Fluentd的核心思想，另外它的插件機(jī)制也是一個(gè)值得稱(chēng)贊的地方。Logstash和Fluentd類(lèi)似是屬于ELK技術(shù)棧，在業(yè)界也被廣泛使用，關(guān)于兩者的對(duì)比可以參考這篇文章Fluentd vs. Logstash: A Comparison of Log Collectors

從頭開(kāi)始寫(xiě)一個(gè)日志采集Agent

作為一個(gè)日志采集Agent在大多數(shù)人眼中可能就是一個(gè)數(shù)據(jù)“搬運(yùn)工”，還會(huì)經(jīng)常抱怨這個(gè)“搬運(yùn)工”用了太多的機(jī)器資源，簡(jiǎn)單來(lái)看就是一個(gè)tail -f命令，再貼切不過(guò)了，對(duì)應(yīng)到Fluentd里面就是in_tail插件。筆者作為一個(gè)親身實(shí)踐過(guò)日志采集Agent的開(kāi)發(fā)者，希望通過(guò)本篇文章來(lái)給大家普及下日志采集Agent開(kāi)發(fā)過(guò)程中的一些技術(shù)挑戰(zhàn)。為了讓整篇文章脈絡(luò)是連續(xù)的，筆者試圖通過(guò)“從頭開(kāi)始寫(xiě)一個(gè)日志采集Agent”的主題來(lái)講述在整個(gè)開(kāi)發(fā)過(guò)程中遇到的問(wèn)題。

如何發(fā)現(xiàn)一個(gè)文件？

當(dāng)我們開(kāi)始寫(xiě)日志采集Agent的時(shí)候遇到的第一個(gè)問(wèn)題就是怎么發(fā)現(xiàn)文件，最簡(jiǎn)單的方式就是用戶(hù)直接把要采集的文件羅列出來(lái)放在配置文件中，然后日志采集Agent會(huì)讀取配置文件找到要采集的文件列表，最后打開(kāi)這些文件進(jìn)行采集，這恐怕是最為簡(jiǎn)單的了。但是大多數(shù)情況日志是動(dòng)態(tài)產(chǎn)生的，會(huì)在日志采集的過(guò)程中動(dòng)態(tài)的創(chuàng)建出來(lái), 提前羅列到配置文件中就太麻煩了。正常情況下用戶(hù)只需要配置一個(gè)日志采集的目錄和文件名字匹配的規(guī)則就可以了，比如Nginx的日志是放在/var/www/log目錄下，日志文件的名字是access.log、access.log-2018-01-10…類(lèi)似于這樣的形式，為了描述這類(lèi)文件可以通過(guò)通配符或者正則的表示來(lái)匹配這類(lèi)文件例如:access.log(-[0-9]{4}-[0-9]{2}-[0-9]{2})?有了這樣的描述規(guī)則后日志采集Agent就可以知道哪些文件是需要采集的，哪些文件是不用采集的。接下來(lái)會(huì)遇到另外一個(gè)問(wèn)題就是如何發(fā)現(xiàn)新創(chuàng)建的日志文件?，定時(shí)去輪詢(xún)下目錄或許是個(gè)不錯(cuò)的方法，但是輪詢(xún)的周期太長(zhǎng)會(huì)導(dǎo)致不夠?qū)崟r(shí)，太短又會(huì)耗CPU，你也不希望你的采集Agent被人吐槽占用太多CPU吧。Linux內(nèi)核給我們提供了高效的Inotify的機(jī)制，由內(nèi)核來(lái)監(jiān)測(cè)一個(gè)目錄下文件的變化，然后通過(guò)事件的方式通知用戶(hù)。但是別高興的太早，Inotify并沒(méi)有我們想的那么好，它存在一些問(wèn)題，首先并不是所有的文件系統(tǒng)都支持Inotify，此外它不支持遞歸的目錄監(jiān)測(cè)，比如我們對(duì)A目錄進(jìn)行監(jiān)測(cè)，但是如果在A目錄下面創(chuàng)建了B目錄，然后立刻創(chuàng)建C文件，那么我們只能得到B目錄創(chuàng)建的事件，C文件創(chuàng)建的事件就會(huì)丟失，最終會(huì)導(dǎo)致這個(gè)文件沒(méi)有被發(fā)現(xiàn)和采集。對(duì)于已經(jīng)存在的文件Inotify也無(wú)能為力，Inotify只能實(shí)時(shí)的發(fā)現(xiàn)新創(chuàng)建的文件。Inotify manpage中描述了更多關(guān)于Inotify的一些使用上的限制以及bug。如果你要保證不漏采那么最佳的方案還是Inotify+輪詢(xún)的組合方式。通過(guò)較大的輪詢(xún)周期來(lái)檢測(cè)漏掉的文件和歷史文件，通過(guò)Inotify來(lái)保證新創(chuàng)建的文件在絕大數(shù)情況下可以實(shí)時(shí)發(fā)現(xiàn)，即使在不支持Inotify的場(chǎng)景下，單獨(dú)靠輪詢(xún)也能正常工作。到此為止我們的日志采集Agent可以發(fā)現(xiàn)文件了，那么接下來(lái)就需要打開(kāi)這個(gè)文件，然后進(jìn)行采集了。但是天有不測(cè)風(fēng)云，在我們采集的過(guò)程中機(jī)器Crash掉了，我們?cè)撊绾伪ＷC已經(jīng)采集的數(shù)據(jù)不要再采集了，能夠繼續(xù)上次沒(méi)有采集到的地方繼續(xù)呢?

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

點(diǎn)位文件高可用

點(diǎn)位文件? 對(duì)就是通過(guò)點(diǎn)位文件來(lái)記錄文件名和對(duì)應(yīng)的采集位置。那如何保證這個(gè)點(diǎn)位文件可以可靠的寫(xiě)入呢? 因?yàn)榭赡茉谖募?xiě)入的那一刻機(jī)器Crash了導(dǎo)致點(diǎn)位數(shù)據(jù)丟掉或者數(shù)據(jù)錯(cuò)亂了。要解決這個(gè)問(wèn)題就需要保證文件寫(xiě)入要么成功，要么失敗，絕對(duì)不能出現(xiàn)寫(xiě)了一半的情況。Linux內(nèi)核給我們提供了原子的rename。一個(gè)文件可以原子的rename成另外一個(gè)文件，利用這個(gè)特性可以保證點(diǎn)位文件的高可用。假設(shè)我們已經(jīng)存在一份點(diǎn)位文件叫做offset，每一秒我們?nèi)ジ逻@個(gè)點(diǎn)位文件，將采集的位置實(shí)時(shí)的記錄在里面，整個(gè)更新的過(guò)程如下：

將點(diǎn)位數(shù)據(jù)寫(xiě)入到磁盤(pán)的offset.bak文件中

fdatasync確保數(shù)據(jù)寫(xiě)入到磁盤(pán)

通過(guò)rename系統(tǒng)調(diào)用將offset.bak更名為offset

通過(guò)這個(gè)手段可以保證在任何時(shí)刻點(diǎn)位文件都是正常的，因?yàn)槊看螌?xiě)入都會(huì)先確保寫(xiě)入到臨時(shí)文件是成功的，然后原子的進(jìn)行替換。這樣就保證了offset文件總是可用的。在極端場(chǎng)景下會(huì)導(dǎo)致1秒內(nèi)的點(diǎn)位沒(méi)有及時(shí)更新，日志采集Agent啟動(dòng)后會(huì)再次采集這1秒內(nèi)的數(shù)據(jù)進(jìn)行重發(fā)，這基本上滿(mǎn)足需求了。

但是點(diǎn)位文件中記錄了文件名和對(duì)應(yīng)的采集位置這會(huì)帶來(lái)另外一個(gè)問(wèn)題，如果在進(jìn)程Crash的過(guò)程中，文件被重命名了該怎么辦? 那啟動(dòng)后豈不是找不到對(duì)應(yīng)的采集位置了。在日志的這個(gè)場(chǎng)景下文件名其實(shí)非常不可靠，文件的重命名、刪除、軟鏈等都會(huì)導(dǎo)致相同的文件名在不同時(shí)刻其實(shí)指向的是不同的文件，而且將整個(gè)文件路徑在內(nèi)存中保存其實(shí)是非常耗費(fèi)內(nèi)存的。Linux內(nèi)核提供了inode可以作為文件的標(biāo)識(shí)信息，而且保證同一時(shí)刻Inode是不會(huì)重復(fù)的，這樣就可以解決上面的問(wèn)題，在點(diǎn)位文件中記錄文件的inode和采集的位置即可。日志采集Agent啟動(dòng)后通過(guò)文件發(fā)現(xiàn)找到要采集的文件，通過(guò)獲取Inode然后從點(diǎn)位文件中查找對(duì)應(yīng)的采集位置，最后接著后面繼續(xù)采集即可。那么即使文件重命名了但是它的Inode不會(huì)變化，所以還是可以從點(diǎn)位文件中找到對(duì)應(yīng)的采集位置。但是Inode有沒(méi)有限制呢? 當(dāng)然有，天下沒(méi)有免費(fèi)的午餐，不同的文件系統(tǒng)Inode會(huì)重復(fù)，一個(gè)機(jī)器可以安裝多個(gè)文件系統(tǒng)，所以我們還需要通過(guò)dev(設(shè)備號(hào))來(lái)進(jìn)一步區(qū)分，所以點(diǎn)位文件中需要記錄的就是dev、inode、offset三元組。到此為止我們的采集Agent可以正常的采集日志了，即使Crash了再次啟動(dòng)后仍然可以繼續(xù)進(jìn)行采集。但是突然有一天我們發(fā)現(xiàn)有兩個(gè)文件居然是同一個(gè)Inode，Linux內(nèi)核不是保證同一時(shí)刻不會(huì)重復(fù)的嗎?難道是內(nèi)核的bug?注意我用的是“同一時(shí)刻”，內(nèi)核只能保證在同一時(shí)刻不會(huì)重復(fù)，這到底是什么意思呢? 這便是日志采集Agent中會(huì)遇到的一個(gè)比較大的技術(shù)挑戰(zhàn)，如何準(zhǔn)確的標(biāo)識(shí)一個(gè)文件。

如何識(shí)別一個(gè)文件？

如何標(biāo)識(shí)一個(gè)文件算是日志采集Agent中一個(gè)比較有挑戰(zhàn)的技術(shù)問(wèn)題了，我們先是通過(guò)文件名來(lái)識(shí)別，后來(lái)發(fā)現(xiàn)文件名并不可靠，而且還耗費(fèi)資源，后來(lái)我們換成了dev+Inode，但是發(fā)現(xiàn)Inode只能保證同一時(shí)刻Inode不重復(fù)，那這句話到底是什么意思呢? 想象一下在T1時(shí)刻有一個(gè)文件Inode是1我們發(fā)現(xiàn)了并開(kāi)始采集，一段時(shí)間后這個(gè)文件被刪除了，Linux內(nèi)核就會(huì)將這個(gè)Inode釋放掉，新創(chuàng)建一個(gè)文件后Linux內(nèi)核會(huì)將剛釋放的Inode又分配給這個(gè)新文件。那么這個(gè)新文件被發(fā)現(xiàn)后會(huì)從點(diǎn)位文件中查詢(xún)上次采集到哪了，結(jié)果就會(huì)找到之前的那個(gè)文件記錄的點(diǎn)位了，導(dǎo)致新文件是從一個(gè)錯(cuò)誤的位置進(jìn)行采集。如果能給每一個(gè)文件打上一個(gè)唯一標(biāo)識(shí)或許就可以解決這個(gè)問(wèn)題，幸好Linux內(nèi)核給文件系統(tǒng)提供了擴(kuò)展屬性xattr，我們可以給每一個(gè)文件生成唯一標(biāo)識(shí)記錄在點(diǎn)位文件中，如果文件被刪除了，然后創(chuàng)建一個(gè)新的文件即使Inode相同，但是文件標(biāo)識(shí)不一樣，日志采集Agent就可以識(shí)別出來(lái)這是兩個(gè)文件了。但是問(wèn)題來(lái)了，并不是所有的文件系統(tǒng)都支持xattr擴(kuò)展屬性。所以擴(kuò)展屬性只是解了部分問(wèn)題。或許我們可以通過(guò)文件的內(nèi)容來(lái)解決這個(gè)問(wèn)題，可以讀取文件的前N個(gè)字節(jié)作為文件標(biāo)識(shí)。這也不失為一種解決方案，但是這個(gè)N到底取多大呢? 越大相同的概率越小，造成無(wú)法識(shí)別的概率就越小。要真正做到100%識(shí)別出來(lái)的通用解決方案還有待調(diào)研，姑且認(rèn)為這里解了80%的問(wèn)題吧。接下來(lái)就可以安心的進(jìn)行日志采集了，日志采集其實(shí)就是讀文件了，讀文件的過(guò)程需要注意的就是盡可能的順序讀，充份利用Linux系統(tǒng)緩存，必要的時(shí)候可以用posix_fadvise在采集完日志文件后清除頁(yè)緩存，主動(dòng)釋放系統(tǒng)資源。那么什么時(shí)候才算采集完一個(gè)文件呢? 采集到末尾返回EOF的時(shí)候就算采集完了。可是一會(huì)日志文件又會(huì)有新內(nèi)容產(chǎn)生，如何才知道有新數(shù)據(jù)了，然后繼續(xù)采集呢?

如何知道文件內(nèi)容更新了？

Inotify可以解決這個(gè)問(wèn)題、通過(guò)Inotify監(jiān)控一個(gè)文件，那么只要這個(gè)文件有新增數(shù)據(jù)就會(huì)觸發(fā)事件，得到事件后就可以繼續(xù)采集了。但是這個(gè)方案存在一個(gè)問(wèn)題就是在大量文件寫(xiě)入的場(chǎng)景會(huì)導(dǎo)致事件隊(duì)列溢出，比如用戶(hù)連續(xù)寫(xiě)入日志N次就會(huì)產(chǎn)生N個(gè)事件，其實(shí)對(duì)于日志采集Agent只要知道內(nèi)容就更新就可以了，至于更新幾次這個(gè)反而不重要， 因?yàn)槊看尾杉鋵?shí)都是持續(xù)讀文件，直到EOF，只要用戶(hù)是連續(xù)寫(xiě)日志，那么就會(huì)一直采集下去。另外Intofy能監(jiān)控的文件數(shù)量也是有上限的。所以這里最簡(jiǎn)單通用的方案就是輪詢(xún)?nèi)ゲ樵?xún)要采集文件的stat信息，發(fā)現(xiàn)文件內(nèi)容有更新就采集，采集完成后再觸發(fā)下一次的輪詢(xún)，既簡(jiǎn)單又通用。通過(guò)這些手段日志采集Agent終于可以不中斷的持續(xù)采集日志了，既然是日志總會(huì)有被刪除的一刻，如果在我們采集的過(guò)程中被刪除了會(huì)如何? 大可放心，Linux中的文件是有引用計(jì)數(shù)的，已經(jīng)打開(kāi)的文件即使被刪除也只是引用計(jì)數(shù)減1，只要有進(jìn)程引用就可以繼續(xù)讀內(nèi)容的，所以日志采集Agent可以安心的繼續(xù)把日志讀完，然后釋放文件的fd，讓系統(tǒng)真正的刪除文件。但是如何知道采集完了呢? 廢話，上面不是說(shuō)了采集到文件末尾就是采集完了啊，可是如果此刻還有另外一個(gè)進(jìn)程也打開(kāi)了這個(gè)文件，在你采集完所有內(nèi)容后又追加了一段內(nèi)容進(jìn)去，而你此時(shí)已經(jīng)釋放了fd了，在文件系統(tǒng)上這個(gè)文件已經(jīng)不在了，再也沒(méi)辦法通過(guò)文件發(fā)現(xiàn)找到這個(gè)文件，打開(kāi)并讀取數(shù)據(jù)了，這該怎么辦?

如何安全地釋放文件句柄？

Fluentd的處理方式就是將這部分的責(zé)任推給用戶(hù)，讓用戶(hù)配置一個(gè)時(shí)間，文件刪除后如果在指定的時(shí)間范圍內(nèi)沒(méi)有數(shù)據(jù)新增就釋放fd，其實(shí)這就是間接的甩鍋行為了。這個(gè)時(shí)間配置的太小會(huì)造成丟數(shù)據(jù)的概率增大，這個(gè)時(shí)間配置的太大會(huì)導(dǎo)致fd和磁盤(pán)空間一直被占用造成短時(shí)間自由浪費(fèi)的假象。這個(gè)問(wèn)題的本質(zhì)上其實(shí)就是我們不知道還有誰(shuí)在引用這個(gè)文件，如果還有人在引用這個(gè)文件就可能會(huì)寫(xiě)入數(shù)據(jù)，此時(shí)即使你釋放了fd資源仍然是占用的，還不如不釋放，如果沒(méi)有任何人在引用這個(gè)文件了，那其實(shí)就可以立刻釋放fd了。如何知道誰(shuí)在引用這個(gè)文件呢? 想必大家都用過(guò)lsof -f列出系統(tǒng)中進(jìn)程打開(kāi)的文件列表，這個(gè)工具通過(guò)掃描每一個(gè)進(jìn)程的/proc/PID/fd/目錄下的所有文件描述符，通過(guò)readlink就可以查看這個(gè)描述符對(duì)應(yīng)的文件路徑，例如下面這個(gè)例子:

22686這個(gè)進(jìn)程就打開(kāi)了一個(gè)文件，fd是4，對(duì)應(yīng)的文件路徑是/home/tianqian-zyf/.post.lua.swp。通過(guò)這個(gè)方法可以查詢(xún)到文件的引用計(jì)數(shù)，如果引用計(jì)數(shù)是1，也就是只有當(dāng)前進(jìn)程引用，那么基本上可以做到安全的釋放fd，不會(huì)造成數(shù)據(jù)丟失，但是帶來(lái)的問(wèn)題就是開(kāi)銷(xiāo)有點(diǎn)大，需要遍歷所有的進(jìn)程查看它們的打開(kāi)文件表逐一的比較，復(fù)雜度是O(n)，如果能做到O(1)這個(gè)問(wèn)題才算完美解決。通過(guò)搜索相關(guān)的資料我發(fā)現(xiàn)這個(gè)在用戶(hù)態(tài)來(lái)做幾乎是沒(méi)有辦法做到的，Linux內(nèi)核沒(méi)有暴露相關(guān)的API。只能通過(guò)Kernel的方式來(lái)解決，比如添加一個(gè)API通過(guò)fd來(lái)獲取文件的引用計(jì)數(shù)。這在內(nèi)核中還是比較容易做到的，每一個(gè)進(jìn)程都保存了打開(kāi)的文件，在內(nèi)核中就是struct file結(jié)構(gòu)，通過(guò)這個(gè)結(jié)構(gòu)就可以找到這個(gè)文件對(duì)應(yīng)的struct inode對(duì)象，這個(gè)對(duì)象內(nèi)部就維護(hù)了引用計(jì)數(shù)值。期待后續(xù)Linux內(nèi)核能夠提供相關(guān)的API來(lái)完美解決這個(gè)問(wèn)題吧。

到此為此，一個(gè)基于文件的采集Agen涉及到的核心技術(shù)點(diǎn)都已經(jīng)介紹完畢了，這其中涉及到很多文件系統(tǒng)、Linux相關(guān)的知識(shí)，只有掌握好這些知識(shí)才能更好的駕馭日志采集。想要編寫(xiě)一個(gè)可靠的日志采集Agent確保數(shù)據(jù)不丟失，這其中的復(fù)雜度和挑戰(zhàn)不容忽視。希望通過(guò)本文能讓讀者對(duì)日志采集有一個(gè)較為全面的認(rèn)知。