日志數(shù)據(jù)采集
提到數(shù)據(jù)分析，大部分人首先想到的都是Hadoop秽晚，流計(jì)算，API等數(shù)據(jù)加工的方式筒愚。如果從整個(gè)過程來看赴蝇，數(shù)據(jù)分析其實(shí)包含了4個(gè)過程：采集，存儲(chǔ)巢掺，計(jì)算和理解四個(gè)步驟句伶。
采集：從各種產(chǎn)生數(shù)據(jù)的源頭，將數(shù)據(jù)集中到存儲(chǔ)系統(tǒng)陆淀。包括硬盤上的歷史數(shù)據(jù)考余，用戶網(wǎng)頁(yè)的點(diǎn)擊，傳感器等等
存儲(chǔ)：以各種適合計(jì)算的模式集中式存儲(chǔ)數(shù)據(jù)轧苫，其中既包含大規(guī)模的存儲(chǔ)系統(tǒng)（例如數(shù)倉(cāng)）楚堤，也有例如臨時(shí)的存儲(chǔ)（例如Kafka類消息中間件）
計(jì)算：形態(tài)多種多樣，但大部分計(jì)算完成后會(huì)將結(jié)果再放入存儲(chǔ)
理解：利用機(jī)器學(xué)習(xí)浸剩、可視化钾军、通知等手段將結(jié)果呈現(xiàn)出來
數(shù)據(jù)采集是一門很大的范疇，從實(shí)時(shí)性上和規(guī)模上分绢要，一般可以分為3類：
實(shí)時(shí)采集：例如日志吏恭，database change log等
定時(shí)任務(wù)：例如每隔5分鐘從FTP或數(shù)據(jù)源去批量導(dǎo)出數(shù)據(jù)
線下導(dǎo)數(shù)據(jù)：例如郵寄硬盤，AWS Snowmobile 卡車等 從數(shù)據(jù)的價(jià)值以及體量上而言重罪，實(shí)時(shí)數(shù)據(jù)采集毫無疑問最重要的樱哼，而其中最大的部分就是日志實(shí)時(shí)采集。
日志采集Agent做了哪些工作剿配？
日志采集Agent看起來很簡(jiǎn)單：安裝在操作系統(tǒng)中搅幅，將實(shí)時(shí)產(chǎn)生的日志（文本）數(shù)據(jù)采集到類似消息中間件（類似Kafka）服務(wù)中。很多人可能覺得這是一個(gè)tail 命令就能干的呼胚，哪有這么復(fù)雜茄唐？
如果我們把其中細(xì)節(jié)展開就會(huì)發(fā)現(xiàn)一大堆工作，除了需要解決分布式日志匯聚的問題，還需要處理各種日志格式沪编、不同采集目錄呼盆、不同運(yùn)行環(huán)境、多租戶資源隔離蚁廓、資源限制访圃、配置管理、系統(tǒng)監(jiān)控相嵌、容錯(cuò)腿时、升級(jí)等等問題，而日志采集Agent就是為了解決這些問題應(yīng)運(yùn)而生的產(chǎn)物饭宾。
試想如果不用Agent批糟，就拿最簡(jiǎn)單的收集nginx訪問日志來講，需要寫一個(gè)腳本定期檢測(cè)access.log有無更新捏雌，把更新的日志發(fā)送到服務(wù)端跃赚，除此之外還需要將原始訪問日志解析成key/value字段、處理日志輪轉(zhuǎn)性湿、處理本地/服務(wù)端網(wǎng)絡(luò)異常纬傲、處理訪問流量burst時(shí)的削峰填谷、處理腳本異常等等肤频，當(dāng)一個(gè)接一個(gè)的問題解決完之后叹括，回過頭原來你又造了一遍輪子。
阿里云日志服務(wù)的logtail就是一款進(jìn)行日志實(shí)時(shí)采集的Agent宵荒，當(dāng)前幾十萬臺(tái)部署logtail的設(shè)備運(yùn)行在各種不同環(huán)境上（集團(tuán)汁雷、螞蟻、阿里云报咳，還有用戶部署在公網(wǎng)侠讯、IOT設(shè)備），每天采集數(shù)PB的數(shù)據(jù)暑刃，支撐上千種應(yīng)用的日志采集厢漩。從剛開始幾個(gè)應(yīng)用、幾千臺(tái)岩臣、每天幾T數(shù)據(jù)的規(guī)模發(fā)展到今天溜嗜，我們踩過很多坑，也從中學(xué)到很多架谎，積累了很多寶貴的經(jīng)驗(yàn)炸宵。
本期主要和大家一起分享logtail設(shè)計(jì)中對(duì)于輪詢和事件模式共存情況下如何解決日志采集保序、高效谷扣、可靠的問題土全。
為什么要輪詢+事件
什么是輪詢什么是事件
對(duì)于日志采集，大家很容易想到通過定期檢測(cè)日志文件有無更新來進(jìn)行日志采集，這種我們一般稱之為輪詢(polling)的方式裹匙。輪詢是一種主動(dòng)探測(cè)的收集方式野哭，相對(duì)也存在被動(dòng)監(jiān)聽的方式，我們一般稱之為事件模式幻件。事件模式依賴于操作系統(tǒng)的事件通知，在linux下2.6.13內(nèi)核版本引入inotify蛔溃， 而windows在xp中引入FindFirstChangeNotification绰沥，兩者都支持以被動(dòng)監(jiān)聽的方式獲取日志文件的修改事件。
輪詢vs事件
下面來看看輪詢和事件之間的區(qū)別贺待，對(duì)比如下：
輪詢事件
實(shí)現(xiàn)復(fù)雜度低高
跨平臺(tái)不依賴操作系統(tǒng)不同操作系統(tǒng)單獨(dú)實(shí)現(xiàn)
采集延遲高低
資源消耗高低
系統(tǒng)限制基本無限制依賴內(nèi)核/驅(qū)動(dòng)
資源限制基本無限制依賴系統(tǒng)
大規(guī)模場(chǎng)景支持較差支持
輪詢相對(duì)事件的實(shí)現(xiàn)復(fù)雜度要低很多徽曲、原始支持跨平臺(tái)而且對(duì)于系統(tǒng)限制性不高；但輪詢的采集延遲（默認(rèn)加上輪詢間隔一半的采集延遲）以及資源消耗較高麸塞，而且在文件規(guī)模較大（十萬級(jí)/百萬級(jí)）時(shí)輪詢一次的時(shí)間較長(zhǎng)秃臣，采集延遲非常高。
傳統(tǒng)Agent怎么做
一般Agent（例如logstash哪工、fluentd奥此、filebeats、nxlog等）都采用基于輪詢的方式雁比，相對(duì)事件實(shí)現(xiàn)較為簡(jiǎn)單稚虎，而且對(duì)于大部分輕量級(jí)場(chǎng)景基本適用。但這種方式就會(huì)暴露以上對(duì)比中出現(xiàn)的采集延遲偎捎、資源消耗以及大規(guī)模環(huán)境支持的問題蠢终，部分對(duì)于這些條件要求較高的應(yīng)用只能望而卻步。
logtail的方案是什么
為了同時(shí)兼顧采集效率以及支持各類特殊采集場(chǎng)景茴她，logtail使用了輪詢與事件并存的混合方式（目前只支持linux寻拂，windows下方案正在集成中）。一方面借力inotify的低延遲與低性能消耗丈牢，另一方面使用輪詢兼容不支持事件的運(yùn)行環(huán)境祭钉。然而混合方案相比純粹輪詢/事件的方案都要復(fù)雜，這里主要存在3個(gè)問題：
1. 如何解決高效采集的問題
2. 如何解決日志順序保證問題
3. 如何保證可靠性問題
下面圍繞這些問題對(duì)我們的方案進(jìn)行展開
logtail輪詢+inotify事件實(shí)現(xiàn)方式
輪詢+inotify事件混合方案簡(jiǎn)介
logtail內(nèi)部以事件的方式觸發(fā)日志讀取行為赡麦，輪詢和inotify作為較為獨(dú)立的兩個(gè)模塊朴皆，對(duì)于同一文件/模塊會(huì)分別產(chǎn)生獨(dú)立的Create/Modify/Delete事件，事件分別存儲(chǔ)于Polling Event Queue和Inotify Event Queue中泛粹。
輪詢模塊由DirFilePolling和ModifyPolling兩個(gè)線程組成遂铡，DirFilePolling負(fù)責(zé)根據(jù)用戶配置定期遍歷文件夾，將符合日志采集配置的文件加入到modify cache中晶姊；ModifyPolling負(fù)責(zé)定期掃描modify cache中文件狀態(tài)扒接，對(duì)比上一次狀態(tài)（Dev、Inode、Modify Time钾怔、Size）碱呼，若發(fā)現(xiàn)更新則生成modify event。
Inotify屬于事件監(jiān)聽方式宗侦，因此不存在獨(dú)立線程愚臀，該模塊根據(jù)用戶配置監(jiān)聽對(duì)應(yīng)的目錄以及子目錄，當(dāng)監(jiān)聽目錄存在變化矾利，內(nèi)核會(huì)將事件push到相應(yīng)的file descriptor中姑裂。
最終由Event Handler線程負(fù)責(zé)將兩個(gè)事件隊(duì)列合并(merge)到內(nèi)部的Event Queue中，并處理相應(yīng)的Create/Modify/Delete事件男旗，進(jìn)行實(shí)際的日志讀取舶斧。
高效性如何保證
相信讀者在看到混合兩個(gè)字時(shí)一定想到一個(gè)非常明顯的問題：logtail采用了兩種方案，那是不是開銷就是2倍安旎省茴厉？答案當(dāng)然不是，logtail在混合方案中采取了以下幾個(gè)措施來保證兩種方案混合的情況下如何采兩家之長(zhǎng)并盡可能去兩家之短：
1. 事件合并(merge)：為減少輪詢產(chǎn)生的事件和inotify產(chǎn)生的事件多次觸發(fā)事件處理行為什荣，logtail在事件處理之前將重復(fù)的輪詢/inotify事件進(jìn)行合并矾缓，減少無效的事件處理行為；
2. 輪詢自動(dòng)降級(jí)：如果在系統(tǒng)支持且資源足夠的場(chǎng)景下稻爬，inotify無論從延遲和性能消耗都要優(yōu)于輪詢而账，因此當(dāng)某個(gè)目錄inotify可以正常工作時(shí)，則該目錄的輪詢進(jìn)行自動(dòng)降級(jí)因篇，輪詢間隔大幅降低到對(duì)CPU基本無影響的程度泞辐；
3. 輪詢與inotify cache共享：日志采集中的很大一部分開銷來源于日志文件匹配，在集團(tuán)內(nèi)外經(jīng)常會(huì)出現(xiàn)一臺(tái)機(jī)器上logtail配置了上百種不同的配置的情況竞滓，對(duì)于一個(gè)文件需要對(duì)上百個(gè)配置進(jìn)行逐一判斷是否匹配咐吼。logtail內(nèi)部對(duì)于匹配結(jié)果維護(hù)了一個(gè)cache，而且cache對(duì)于輪詢和inotify共享商佑，盡可能減少這部分較大的開銷锯茄。
日志收集順序保證
日志收集順序難點(diǎn)分析
日志順序性保證是日志采集需要提供的基本功能，也是較難實(shí)現(xiàn)的一種功能茶没，尤其在以下幾種場(chǎng)景并存的情況下：
1. 日志輪轉(zhuǎn)(rotate)：日志輪轉(zhuǎn)是指當(dāng)日志滿足一定條件（日志跨天肌幽、超過一定條數(shù)、超過一定大凶グ搿）進(jìn)行重命名/壓縮/刪除后重新創(chuàng)建并寫入的情況喂急，例如Ngnix訪問日志可設(shè)置以20M位單位進(jìn)行輪轉(zhuǎn)，當(dāng)日志超過20M時(shí)笛求，將access.log重命名為access.log.1廊移，之前的access.log.1重命名為access.log.2糕簿，以此類推。agent需要保證日志輪轉(zhuǎn)時(shí)收集順序與日志產(chǎn)生順序相同狡孔；
2. 不同配置方式：優(yōu)秀的日志采集agent并不應(yīng)該強(qiáng)制限制用戶的配置方式懂诗，尤其在指定日志采集文件名時(shí)，有的用戶習(xí)慣配置成*.log苗膝，有的用戶習(xí)慣配置成*.log*殃恒，而無論哪種配置agent都應(yīng)該能夠兼容，不會(huì)出現(xiàn)*.log在日志輪轉(zhuǎn)情況下少收集或*.log*在日志輪轉(zhuǎn)情況下多收集的情況辱揭；
3. 輪詢與inotify并存問題：若系統(tǒng)不支持inotify芋类，則只有輪詢產(chǎn)生的事件，而若inotify正常工作界阁，那么同一文件的修改會(huì)產(chǎn)生兩次事件，而且由于inotify延遲較低胖喳，所以事件很可能會(huì)先于輪詢的事件被處理泡躯。我們需要保證延遲到來的事件不會(huì)影響日志exactly once的讀取丽焊；
基于輪轉(zhuǎn)隊(duì)列與文件簽名的日志采集方法
基本概念
在logtail中较剃，我們?cè)O(shè)計(jì)了一套用于在日志輪轉(zhuǎn)、不同用戶配置技健、輪詢與inotify并存写穴、日志解析阻塞情況下依然可以保證日志采集順序的機(jī)制。本文將重點(diǎn)該機(jī)制的實(shí)現(xiàn)方法雌贱，在展開之前首先介紹logtail中用到的幾個(gè)基本概念：
文件的dev和inode標(biāo)識(shí)
dev這里指的是設(shè)備編號(hào)啊送、inode是該文件在file system中的唯一標(biāo)識(shí)，通過dev+inode的組合可唯一標(biāo)識(shí)一個(gè)文件（這里需要排除硬連接）欣孤。文件的move操作雖然可以改變文件名馋没，但并不涉及文件的刪除創(chuàng)建，dev+inode并不會(huì)變化降传，因此通過dev+inode可以非常方便的判斷一個(gè)文件是否發(fā)生了輪轉(zhuǎn)篷朵。
inode引用計(jì)數(shù)
每個(gè)文件都對(duì)應(yīng)著一個(gè)inode，inode指向文件的meta信息婆排，其中有一個(gè)字段是reference count声旺，默認(rèn)文件創(chuàng)建時(shí)引用計(jì)數(shù)為1，引用計(jì)數(shù)為0時(shí)文件被文件系統(tǒng)回收段只。以下情況會(huì)改變文件的引用計(jì)數(shù)：若文件open腮猖，則引用計(jì)數(shù)加1，文件close后減1赞枕；硬連接創(chuàng)建引用計(jì)數(shù)加1缚够；文件/硬鏈接刪除幔妨，引用計(jì)數(shù)減1。因此谍椅，雖然文件被刪除误堡，但只要有應(yīng)用保持該文件的open狀態(tài)，則該文件并不會(huì)被文件系統(tǒng)回收雏吭，應(yīng)用還可以對(duì)該文件進(jìn)行讀取锁施。
文件簽名(signature)
dev+inode只能保證同一時(shí)刻該文件的唯一性，但并不代表整個(gè)life cycle中的唯一性杖们。在文件從文件系統(tǒng)中刪除時(shí)悉抵，對(duì)應(yīng)的inode也會(huì)被回收，內(nèi)核file system實(shí)現(xiàn)中存在分配唯一inode的機(jī)制摘完，為了提高inode分配性能姥饰，回收的inode會(huì)保留在文件系統(tǒng)的cache中，下一次創(chuàng)建文件時(shí)孝治，若存在inode cache則直接將該inode賦給新文件列粪。因此純粹通過dev+inode判斷輪轉(zhuǎn)并不可行（例如日志文件到達(dá)一定size被刪除后，重新創(chuàng)建繼續(xù)寫谈飒，只要期間沒有其他文件創(chuàng)建岂座，則dev+inode都沒變），logtail中使用日志文件的前1024字節(jié)的hash作為該文件的簽名(signature)杭措，只有當(dāng)dev+inode+signature一致的情況下才會(huì)認(rèn)為該文件是輪轉(zhuǎn)的文件费什。
在logtail的設(shè)計(jì)中利用了以上幾個(gè)概念的功能，下面介紹一下日志收集順序保證的幾個(gè)數(shù)據(jù)結(jié)構(gòu)：
LogFileReader
LogFileReader存儲(chǔ)了日志文件讀取的元數(shù)據(jù)手素，包括sorcePath鸳址、signature、devInode泉懦、deleteFlag氯质、filePtr、readOffset祠斧、lastUpdateTime闻察、readerQueue(LogFileReaderQueue)。其中sorcePath是reader文件路徑琢锋，辕漂，signature是文件的簽名，devInode是改文件的dev+inode組合吴超，deleteFlag用于標(biāo)識(shí)該文件是否被刪除钉嘹，filePtr是文件指針，readOffset代表當(dāng)前日志解析進(jìn)度鲸阻，lastUpdateTime記錄最后一次進(jìn)行讀取的時(shí)間跋涣，readerQueue標(biāo)識(shí)該reader所在的讀取隊(duì)列（參見下面介紹）缨睡。
LogFileReaderQueue
LogFileReaderQueue中存儲(chǔ)sourcePath相同且未采集完畢的reader列表，reader按照日志文件創(chuàng)建順序進(jìn)行排列陈辱。
NamedLogFileReaderQueueMap
以sourcePath為key/LogFileReaderQueue為value的map奖年，用于存儲(chǔ)當(dāng)前正在讀取的所有ReaderQueue
DevInodeLogFileReaderMap
以devInode為key/LogFileReader為value的map，用于存儲(chǔ)當(dāng)前正在讀取的所有Reader
RotatorLogFileReaderMap
以devInode為key/LogFileReader為value的map沛贪，用于存儲(chǔ)處于輪轉(zhuǎn)狀態(tài)且已經(jīng)讀取完畢的Reader
事件處理流程
logtail基于以上的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)了日志數(shù)據(jù)順序讀取陋守，具體處理流程如下：
CreateEvent處理方式
對(duì)于日志的Create Event，首先從當(dāng)前的devInodeReaderMap中查找是否存在該dev+inode的Reader（因?yàn)樵谳喸兒虸notify共存的情況下利赋，可能會(huì)出現(xiàn)在處理Create Event時(shí)Reader已經(jīng)被創(chuàng)建的情況）水评，若不存在則創(chuàng)建Reader。
Reader通過dev+inode和sourcePath創(chuàng)建媚送，創(chuàng)建Reader后需加入到devInodeReaderMap以及其sourcePath對(duì)應(yīng)的ReaderQueue尾部
DeleteEvent處理方式
對(duì)于日志文件的Delete Event中燥，若該Reader所在隊(duì)列長(zhǎng)度大于1（當(dāng)前解析進(jìn)度落后，文件雖被刪除但日志未采集完成）塘偎，則忽略此Delete事件疗涉；若Reader所在隊(duì)列長(zhǎng)度為1，設(shè)置該Reader的deleteFlag式塌，若一定時(shí)間內(nèi)該Reader沒有處理過Modify事件且日志解析完畢則刪除該Reader
ModifyEvent處理方式
首先根據(jù)dev+inode查找devInodeReaderMap，找到該Reader所在的ReaderQueue友浸，獲取ReaderQueue的隊(duì)列首部的Reader進(jìn)行日志讀取操作峰尝；
日志讀取時(shí)首先檢查signature是否改變，若改變則認(rèn)為日志被truncate寫收恢，從文件頭開始讀任溲А；若signature未改變伦意，則從readOffset處開始讀取并更新readOffset
若該日志文件讀取完畢(readOffset==fileSize)且ReaderQueue的size > 1火窒，則從ReaderQueue中移除該Reader并加入到rotatorReadrMap中（日志已經(jīng)發(fā)生了輪轉(zhuǎn)，且輪轉(zhuǎn)后的文件已經(jīng)讀取完畢驮肉，所以可以從ReaderQueue中移除）熏矿，此時(shí)繼續(xù)把Modify Event push到Event隊(duì)列中，觸發(fā)隊(duì)列后續(xù)文件的讀取离钝，進(jìn)入下一循環(huán)票编；若日志文件讀取完畢且ReaderQueue的size==1（size為1說明該文件并沒有輪轉(zhuǎn)，極有可能后續(xù)還有寫入卵渴，所以不能從ReaderQueue中移除）慧域，則完成次輪Modify Event處理，進(jìn)入下一循環(huán)
若日志文件沒有讀取完成浪读，則把Modify Event push到Event隊(duì)列中昔榴，進(jìn)入下一循環(huán)（避免所有時(shí)間都被同一文件占用辛藻，保證日志文件讀取公平性）
RotatorLogFileReaderMap主要用于解決輪詢事件延遲問題：當(dāng)inotify事件處理完成、日志讀取完畢互订、ReaderQueue size > 1同時(shí)發(fā)生吱肌，若直接刪除該Reader，則輪詢的事件到達(dá)時(shí)屁奏，將會(huì)查找不到Reader并創(chuàng)建一個(gè)新的Reader重新進(jìn)行日志讀取岩榆。因此我們?cè)赗eader讀取完畢時(shí)將其放入到RotatorLogFileReaderMap保存，若事件查找不到Reader時(shí)會(huì)檢測(cè)RotatorLogFileReaderMap坟瓢，若存在則跳過此次事件處理勇边，避免多重事件造成日志重復(fù)采集的情況。
日志采集可靠性保證
考慮到性能折联、資源粒褒、性價(jià)比等問題，logtail在設(shè)計(jì)之初并不保證exact once或者at least once诚镰，但這并不代表logtail不可靠奕坟，有很多用戶基于logtail采集的access日志用來計(jì)費(fèi)。下面主要介紹可靠性中較難解決的三個(gè)場(chǎng)景：
1. 日志解析阻塞：由于各種原因（網(wǎng)絡(luò)阻塞清笨、日志burst寫入月杉、流量控制、CPU/磁盤負(fù)載）等問題可能造成日志解析進(jìn)度落后于日志產(chǎn)生速度抠艾，而在此時(shí)若發(fā)生日志輪轉(zhuǎn)苛萎，logtail需在有限資源占用情況下盡可能保證輪轉(zhuǎn)后的日志文件不丟失
2. 采集配置更新/進(jìn)程升級(jí)：配置更新或進(jìn)行升級(jí)時(shí)需要中斷采集并重新初始化采集上下文，logtail需要保證在配置更新/進(jìn)程升級(jí)時(shí)即使日志發(fā)生輪轉(zhuǎn)也不會(huì)丟失日志
3. 進(jìn)程crash检号、宕機(jī)等異常情況：在進(jìn)程crash或宕機(jī)時(shí)腌歉，logtail需盡可能保證日志重復(fù)采集數(shù)盡可能的少丟失日志
日志采集阻塞處理
正常情況下，日志采集進(jìn)度和日志產(chǎn)生進(jìn)度一致齐苛，此時(shí)ReaderQueue中只有一個(gè)Reader處于采集狀態(tài)翘盖。如上圖所示，正在被采集的access.log由于磁盤上存在凹蜂、應(yīng)用和logtail正在打開馍驯，所以引用計(jì)數(shù)為3，其他輪轉(zhuǎn)的日志文件引用計(jì)數(shù)為1玛痊。
而當(dāng)應(yīng)用日志burst寫入泥彤、網(wǎng)絡(luò)暫時(shí)性阻塞、服務(wù)端Quota不足卿啡、CPU/磁盤負(fù)載較高等情況發(fā)生吟吝，日志采集進(jìn)度可能落后于日志產(chǎn)生進(jìn)度，此時(shí)我們希望logtail能夠在一定的資源限制下盡可能保留住這些日志颈娜，等待網(wǎng)絡(luò)恢復(fù)或系統(tǒng)負(fù)載下降時(shí)將這些日志采集到服務(wù)器剑逃，并且保證日志采集順序不會(huì)因?yàn)椴杉枞靵y浙宜。
如上圖所示，logtail內(nèi)部通過保持輪轉(zhuǎn)日志file descriptor的打開狀態(tài)來防止日志采集阻塞時(shí)未采集完成的日志文件被file system回收（在ReaderQueue中的file descriptor一直保持打開狀態(tài)蛹磺，保證文件引用計(jì)數(shù)至少為1）粟瞬。通過ReaderQueue的順序讀取保證日志采集順序與日志產(chǎn)生順序一致。
當(dāng)ReaderQueue的size大于1時(shí)說明日志解析出現(xiàn)阻塞萤捆，此時(shí)logtail會(huì)將該ReaderQueue中所有Reader的file descriptor保持打開狀態(tài)裙品，這樣即使在日志文件輪轉(zhuǎn)后被刪除或被壓縮（本質(zhì)還是被刪除）時(shí)logtail依然能夠采集到該日志。
當(dāng)日志輪轉(zhuǎn)時(shí)（dev+inode變化俗或，文件名未變）市怎，logtail會(huì)根據(jù)新的dev+inode創(chuàng)建Reader，并加入其文件名對(duì)應(yīng)的ReaderQueue尾部辛慰，ReaderQueue保持順序讀取区匠，以此保證日志文件解析順序。
若日志采集進(jìn)度一直低于日志產(chǎn)生進(jìn)度帅腌，則很有可能出現(xiàn)ReaderQueue會(huì)無限增長(zhǎng)的情況驰弄，因此logtail內(nèi)部對(duì)于ReaderQueue設(shè)置了上限，當(dāng)size超過上限時(shí)禁止后續(xù)Reader的創(chuàng)建
配置更新/升級(jí)過程處理
logtail配置采用中心化的管理方式速客，用戶只需在管理頁(yè)面配置戚篙，保存后會(huì)自動(dòng)將配置更新到遠(yuǎn)程的logtail節(jié)點(diǎn)。此外logtail具備自動(dòng)升級(jí)的功能溺职，當(dāng)推出新版本時(shí)岔擂，logtail會(huì)自動(dòng)從服務(wù)器下載最新版本并升級(jí)到該版本。
為保證配置更新/升級(jí)過程中日志數(shù)據(jù)不丟失辅愿，在logtail升級(jí)過程中智亮，會(huì)將當(dāng)前所有Reader的狀態(tài)保存到內(nèi)存/本地的checkpoint文件中忆某；當(dāng)新配置應(yīng)用/新版本啟動(dòng)后点待，會(huì)加載上一次保存的checkpoint，并通過checkpoint恢復(fù)Reader的狀態(tài)弃舒。
然而在老版本checkpoint保存完畢到新版本Reader創(chuàng)建完成的時(shí)間段內(nèi)癞埠，很有可能出現(xiàn)日志輪轉(zhuǎn)的情況，因此新版本在加載checkpoint時(shí)聋呢，會(huì)檢查對(duì)應(yīng)checkpoint的文件名苗踪、dev+inode有無變化
若文件名與dev+inode未變且signature未變，則直接根據(jù)該checkpoint創(chuàng)建Reader
若文件名與dev+inode變化則從當(dāng)前目錄查找對(duì)應(yīng)的dev+inode削锰，若查找到則對(duì)比signature是否變化通铲；若signature未變則認(rèn)為是文件輪轉(zhuǎn)，根據(jù)新文件名創(chuàng)建Reader器贩；若signature變化則認(rèn)為是該文件被刪除后重新創(chuàng)建颅夺，忽略該checkpoint朋截。
進(jìn)程crash、宕機(jī)等異常情況處理
進(jìn)程異常crash：logtail運(yùn)行時(shí)會(huì)產(chǎn)生兩個(gè)進(jìn)程吧黄，分別是守護(hù)進(jìn)程和工作進(jìn)程部服，當(dāng)工作進(jìn)程異常crash時(shí)（概率極低）守護(hù)進(jìn)程會(huì)立即重新拉起工作進(jìn)程
進(jìn)程重新啟動(dòng)時(shí)狀態(tài)恢復(fù)：logtail除配置更新/進(jìn)程升級(jí)會(huì)保存checkpoint外，還會(huì)定期將采集進(jìn)度dump到本地拗慨，進(jìn)程重新啟動(dòng)的過程與版本升級(jí)的過程相似：除了恢復(fù)正常日志文件狀態(tài)外廓八，還會(huì)查找輪轉(zhuǎn)后的日志，盡可能降低日志丟失風(fēng)險(xiǎn)
