作者：vivo 互聯網存盤技術團隊- Qiu Sidi
在企業大資料體系建設程序中，資料采集是其中的首要環節，然而，當前行業內的相關開源資料采集組件，并無法滿足企業大規模資料采集的需求與有效的資料采集治理，所以大部分企業都采用自研開發采集組件的方式，本文通過在vivo的日志采集服務的設計實踐經驗，為大家提供日志采集Agent在設計開發程序中的關鍵設計思路，
一、概述
在企業大資料體系的建設程序中，資料的處理一般包含4個步驟：采集、存盤、計算和使用，其中，資料采集，是建設程序中的首要的環節，也是至關重要的環節，如果沒有采集就沒有資料，更談不上后續的資料處理與使用，所以，我們看到的企業中的運營報表、決策報表、日志監控、審計日志等的資料來源都是基于資料采集，一般的，我們對資料采集的定義是，把各種分散的源頭上的資料（可以包括企業產品的埋點的日志、服務器日志、資料庫、IOT設備日志等）統一匯聚到大資料存盤組件的程序（如下圖所示），其中，日志檔案型別的采集場景，是各種資料采集型別中最常見的一種，接下來，將圍繞該場景提出我們的設計實踐方案，
通常，日志采集服務可以分為幾個部分（業界常見的架構如下圖所示）：日志采集Agent組件（常見的開源采集Agent組件有Flume、Logstash、Scribe等）、采集傳輸與存盤組件（如kafka、HDFS）、采集管理平臺，Bees采集服務是vivo自研的日志采集服務，本文章是通過在Bees采集服務中的關鍵組件bees-agent的開發實踐后，總結出一個通用的日志采集Agent設計中的核心技術點和一些關鍵思考點，希望對大家有用，
二、特性&能力
- 具備基本的日志檔案的實時與離線采集能力
- 基于日志檔案，無侵入式采集日志
- 具備自定義的過濾超大日志的能力
- 具備自定義的過濾采集、匹配采集、格式化的能力
- 具備自定義的限速采集的能力
- 具備秒級別的實時采集時效性
- 具備斷點續傳能力，升級和停止不丟資料
- 具備可視化的、中心化的采集任務管理平臺
- 豐富的監控指標與告警（包括采集流量、時效性、完整性等）
- 低系統資源開銷（包括磁盤、記憶體、CPU及網路等）
三、設計原則
- 簡單優雅
- 健壯穩定
四、關鍵設計
目前業界流行的日志采集Agent組件，開源的有Flume、Logstash、Scribe、FileBeats、Fluentd等，自研的有阿里的Logtail，它們都有不錯的性能與穩定性，如果想要快速上手，可以不妨使用它們，但是一般大企業會有個性化的采集需求，比如采集任務大規模管理、采集限速、采集過濾等，還有采集任務平臺化、任務可視化的需求，為了滿足上面這些需求我們自研了一個日志采集Agent，
在做一切的設計和開發之前，我們設定了采集Agent最基本的設計原則，即簡單優雅、健壯穩定，
日志檔案采集的一般流程會包括：檔案的發現與監聽、檔案讀取，日志內容的格式化、過濾、聚合與發送，當我們開始著手開始設計這樣一個日志采集Agent時，會遇到不少關鍵的難點問題，比如：日志檔案在哪里？如何發現日志檔案新增？如何監聽日志內容追加？如何識別一個檔案？宕機重啟怎么辦？如何斷點續傳？等等問題，接下來，我們針對日志采集Agent設計程序中遇到的關鍵問題，為大家一一解答，（注：下文出現的檔案路徑與檔案名都為演示樣例非真實路徑）
4.1 日志檔案發現與監聽
Agent要如何知道采集哪些日志檔案呢？
最簡單的設計，就是在Agent的本地組態檔中，把需要采集的日志檔案路徑都一一羅列進去，比如 /home/sample/logs/access1.log、/home/sample/logs/access2.log、/home/sample/logs/access3.log 等，這樣Agent通過讀取組態檔得到對應的日志檔案串列，這樣就能遍歷檔案串列讀取日志資訊，但是實際情況是，日志檔案是動態生成的，像一般tomcat的業務日志，每個小時都會滾動生成一個新的的日志檔案，日志名字通常會帶上時間戳，命名類似 /data/sample/logs/access.2021110820.log，所以采用直接配置固定的檔案串列方式是行不通的，
所以，我們想到可以使用一個檔案夾路徑和日志檔案名使用正則運算式或者通配符來表示（為了方便，下文統一使用通配符來表示），機器上的日志一般固定存在某一個目錄下，比如 /data/sample/logs/ 下，檔案名由于某種規則是滾動產生的（比如時間戳），類似 access.2021110820.log、access.2021110821.log、access.2021110822.log，我們可以簡單粗暴使用 access.*.log 的通配方法來匹配這一類的日志，當然實際情況可以根據你需要的匹配粒度去選擇你的正則運算式，有了這個通配符方法，我們的Agent就能的匹配滾動產生的一批日志檔案了，
如何持續發現和監聽到新產生的日志檔案呢？
由于新的日志檔案會由其他應用程式（比如Nginx、Tomcat等）持續的按小時動態產生的，Agent如何使用通配符快速去發現這個新產生的檔案呢？
最容易想到的，是使用輪詢的設計方案，即是通過一個定時任務來檢查對應目錄下的日志檔案是否有增加，但是這種簡單的方案有個問題，就是如果輪詢間隔時間太長，比如間隔設定為10s、5s，那么日志采集的時效性滿足不了我們的需求；如果輪詢間隔時間太短，比如500ms，大量的無效的輪詢檢查又會消耗許多CPU資源，幸好，Linux內核給我們提供一種高效的檔案事件監聽機制：Linux Inotify機制，該機制可監聽任意檔案的操作，比如檔案創建、檔案洗掉和檔案內容變更，內核會給應用層一個對應的事件通知，Inotify這種的事件機制比輪詢機制高效的多，也不存在CPU空跑浪費系統資源的情況，在java中，使用java.nio.file.WatchService，可以參考如下核心代碼：
/**
* 訂閱檔案或目錄的變更事件
*/
public synchronized BeesWatchKey watchDir(File dir, WatchEvent.Kind<?>... watchEvents) throws IOException {
if (!dir.exists() && dir.isFile()) {
throw new IllegalArgumentException("watchDir requires an exist directory, param: " + dir);
}
Path path = dir.toPath().toAbsolutePath();
BeesWatchKey beesWatchKey = registeredDirs.get(path);
if (beesWatchKey == null) {
beesWatchKey = new BeesWatchKey(subscriber, dir, this, watchEvents);
registeredDirs.put(path, beesWatchKey);
logger.info("successfully watch dir: {}", dir);
}
return beesWatchKey;
}
public synchronized BeesWatchKey watchDir(File dir) throws IOException {
WatchEvent.Kind<?>[] events = {
StandardWatchEventKinds.ENTRY_CREATE,
StandardWatchEventKinds.ENTRY_DELETE,
StandardWatchEventKinds.ENTRY_MODIFY
};
return watchDir(dir, events);
}
綜合以上思考，日志檔案的發現和日志內容變更的監聽，我們使用的是"inotify機制為主+輪詢機制兜底"、"通配符"的設計方案，如下圖所示：
4.2 日志檔案的唯一標識
要設計日志檔案的唯一標識，如果直接使用日志檔案的名稱是行不通的，日志檔案名可能被頻繁重復使用，比如，一些應用程式使用的日志框架在輸出日志時，對于當前應用正在輸出的日志命名是不帶任何時間戳資訊的，比如固定是 access.log，只有等到當前小時寫入檔案完畢時，才把檔案重命名為 access.2021110820.log，此時新生產的日志檔案命名也是 access.log，該檔案名對于采集Agent來說是重復的，所以檔案名是無法作為檔案唯一標識，
我們想到使用Linux作業系統上的檔案inode號作為檔案識別符號，Unix/Linux檔案系統使用inode號來識別不同檔案，即使移動檔案或重命名檔案，inode號是保持不變的，創建一個新檔案，會給這個新檔案分配一個新的不重復的inode號，這樣就能與現有磁盤上的其他檔案很好區分，我們使用 ls -i access.log 可以快速查看該檔案的inode號，如下代碼塊所示：
ls -i access.log 62651787 access.log
一般來說，使用系統的inode號作為標識，已經能滿足大多數的情況了，但是為了更嚴謹的考慮，還可以進一步升級方案，因為Linux 的inode號存在復用的情況，這里的"復用"要和"重復"區別一下，在一臺機器上的所有檔案不會同一時刻出現重復的兩個inode號，但是當檔案洗掉后，另一個新檔案創建時，這個檔案的inode號是可能復用之前洗掉檔案的inode號的，代碼邏輯處理不好，很可能造成日志檔案漏采集，這一點是要注意的，為了規避這個問題，我們把檔案的唯一標識設計為" 檔案inode與檔案簽名組合"，這里的檔案簽名使用的是該檔案內容前128位元組的Hash值，代碼參考如下：
public static String signFile(File file) throws IOException {
String filepath = file.getAbsolutePath();
String sign = null;
RandomAccessFile raf = new RandomAccessFile(filepath, "r");
if (raf.length() >= SIGN_SIZE) {
byte[] tbyte = new byte[SIGN_SIZE];
raf.seek(0);
raf.read(tbyte);
sign = Hashing.sha256().hashBytes(tbyte).toString();
}
return sign;
}
關于inode再補充點小知識，Linux inode是會滿的，inode的資訊存盤本身也會消耗一些硬碟空間，因為inode號只是inode內容中的一小部分，inode內容主要是包含檔案的元資料資訊：如檔案的位元組數、檔案資料block的位置、檔案的讀寫執行權限、檔案的時間戳等，可以用stat命令，查看某個檔案完整的inode資訊（stat access.log），因為這樣的設計，作業系統是將硬碟分成兩個區域的：一個是資料區，存放檔案資料；另一個是inode區，存放inode所包含的資訊，每個inode節點的大小，一般是128位元組或256位元組，查看每個硬碟磁區的inode總數和已經使用的數量，可以使用df -i命令，由于每個檔案都必須有一個inode，如果一個日志機器上，日志檔案小而且數量太多，是有可能發生作業系統inode用完了即是inode區磁盤滿了，但是我們使用的資料區硬碟還未存滿的情況，這時，就無法在硬碟上創建新檔案，所以在日志列印規范上是要避免產生大量的小日志檔案的，
4.3 日志內容的讀取
發現并且能有效監聽日志檔案后，我們應該如何去讀取這個日志檔案中實時追加的日志內容呢？日志內容的讀取，我們期望從日志檔案中把每一行的日志內容逐行讀取出來，每一行以\n或者\r為分隔符，很顯然，我們不能直接簡單采用InputStreamReader去讀取，因為Reader只能按照字符從頭到尾讀取整個日志檔案，不適合讀取實時追加日志內容的情況；最合適的選擇應該是使用RandomAccessFile，RandomAccessFile它為代碼開發者提供了一個可供設定的指標，通過指標開發者可以訪問檔案的隨機位置，參考下圖：
通過這種方式，當某一時刻出現執行緒讀取到檔案末尾時，只需要記錄當前的位置，執行緒就進入等待狀態，直到有新的日志內容寫入后，執行緒又重新啟動，啟動后可以接著上次的尾部往下讀取，代碼參考如下，另外，在行程掛或者宕機恢復后，也會用到RandomAccessFile來從指定點位開始讀取，不需要從整個檔案頭部重新讀取，關于斷點續傳的能力后文會提到，
RandomAccessFile raf = new RandomAccessFile(file, "r");
byte[] buffer;
private void readFile() {
if ((raf.length() - raf.getFilePointer()) < BUFFER_SIZE) {
buffer = new byte[(int) (raf.length() - raf.getFilePointer())];
} else {
buffer = new byte[BUFFER_SIZE];
}
raf.read(buffer, 0, buffer.length);
}
4.4 實作斷點續傳
機器宕機、Java行程OOM重啟、Agent升級重啟等這些是常有的事，那么如何在這些情況下保障采集資料的正確呢？這個問題主要考慮的是采集Agent斷點續傳的能力，一般的，我們在采集程序中需要記錄當前的采集點位（采集點位，即RandomAccessFile中最后的指標指向的位置，一個整型數值），當Agent把對應緩沖區的資料成功發送到kafka后，此時可以先把最新點位的數值更新到記憶體，并且通過一個定時任務（默認是3s）持久化記憶體中的采集點位數值到本地的磁盤的點位檔案中，這樣，當出現行程停止，重新啟動時，加載本次磁盤檔案中的采集點位，并使用RandomAccessFile移動到對應的點位，實作了從上一次停止的點位繼續往下采集的能力，Agent可以恢復到原有的狀態，從而實作了斷點續傳，有效規避重復采集或者漏采集的風險，
Agent針對的每一個采集任務會有一個對應的點位檔案，一個Agent如果有多個采集任務，將會對應多個點位檔案，一個點位檔案存盤的內容格式為JSON陣列（如下圖所示），其中file表示任務所采集的檔案的名字，inode即檔案的inode，pos即position的縮小，表示點位的數值；
[
{
"file": "/home/sample/logs/bees-agent.log",
"inode": 2235528,
"pos": 621,
"sign": "cb8730c1d4a71adc4e5b48931db528e30a5b5c1e99a900ee13e1fe5f935664f1"
}
]
4.5 實時資料發送
前面主要介紹了，日志檔案的實時的發現、實時的日志內容變更監聽、日志內容的讀取等設計方案，接下來介紹Agent的資料發送，
最簡單的模型是，Agent通過Kafka Client把資料直接發送到Kafka分布式訊息中間件，這也是一種簡潔可行的方案，實際上在Bees的采集鏈路架構中，在Agent與Kafka的資料鏈路中我們增加了一個"組件bees-bus“（如下圖所示），
bees-bus組件主要起到匯聚資料的作用，類似于Flume在采集鏈路中聚合的角色，Agent基于Netty開源框架實作NettyRpcClient與Bus之間通訊實作資料發送，網路傳輸部分展開講內容較多，非本文章重點就此帶過（具體可參考Flume NettyAvroRpcClient實作），
這里稍微補充下，我們引入bees-bus的目的主要有以下幾個：
- 收斂來自于Agent過多的網路連接數，避免所有Agent直連Kafka broker對其造成較大的壓力；
- 資料匯聚到Bus后，Bus具備流量多路輸出的能力，可以實作跨機房Kafka資料容災；
- 在遇到流量陡增的情況下， 會導致topic磁區所在broker機器磁盤IO繁忙進而導致資料反壓到客戶端， 由于kafka副本遷移比較耗時所以出現問題后恢復較慢，Bus可以起到一層緩沖層的作用，
4.6 離線采集能力
除了上面常見的實時日志采集的場景外（一般是日志采集到kafka這類訊息中間件），Bees采集還有一個離線日志采集的場景，所謂離線日志采集，一般是指把日志檔案是采集到HDFS下（參考下圖），
這些日志資料是用于下游的Hive離線數倉建設、離線報表分析使用，該場景資料時效性沒有那么強，一般是按天為單位使用資料（我們常說的T+1資料），所以日志資料采集無需像實時日志采集一樣，實時的一行一行的采集，離線采集一般可以按照固定時間一個批次采集，我們默認是每隔一小時定時采集上個小時產生的一個完整的小時日志檔案，比如在21點的05分，采集Agent則開始采集上個小時產生的日志檔案（access.2021110820.log），該檔案保存了20點內產生的完整的（20:00~20:59）日志內容，
實作離線的采集能力，我們的Agent通過集成HDFS Client的基本能力來實作，HDFS Client中使用 FSDataOutputStream 可以快速的完成一個檔案PUT到HDFS的目錄下，
尤其要關注的一點是，離線采集需要特別的增加了一個限流采集的能力，由于離線采集的特點是，在整點左右的時刻，所有的機器上的Agent會幾乎同時全量開啟采集，如果日志量大、采集速度過快，可能會造成該時刻公司網路帶寬被快速占用飆升，超出全網帶寬上限，進一步會影響其他業務的正常服務，引發故障；還有一個需要關注的就是離線采集整點時刻對機器磁盤資源的需求是很大，通過限流采集，可以有效削平對磁盤資源的整點峰值，避免影響其他服務，
4.7 日志檔案清理策略
業務日志源源不斷的產生落到機器的磁盤上，單個小時的日志檔案大小，小的可能是幾十MB，大的可以是幾十GB，磁盤很有可能在幾小時內被占滿，導致新的日志無法寫入造成日志丟失，另一方面可能導致更致命的問題，linux 作業系統報 “No space left on device 例外"，引發其他行程的各種故障；所以機器上的日志檔案需要有一個清理的策略，
我們采用的策略是，所有的機器都默認啟動了一個shell的日志清理腳本，定期檢查固定目錄下的日志檔案，規定日志檔案的生命周期為6小時，一旦發現日志檔案是6小時以前的檔案，則會對其進行洗掉（執行 rm 命令），
因為日志檔案的洗掉，不是由日志采集Agent自身發起和執行的，那么可能出現”采集速度跟不上洗掉速度（采集落后6小時）“的情況，比如日志檔案還在采集，但是洗掉腳本已經檢測到該檔案生命周期已達6小時準備對其進行洗掉；這種情況，我們只需要做好一點，保證采集Agent對該日志檔案的讀取句柄是正常打開的，這樣的話，即使日志清理行程對該檔案執行了rm操作（執行rm后只是將該檔案從檔案系統的目錄結構上解除鏈接 unlink，實際檔案還未從磁盤徹底洗掉），采集Agent持續打開的句柄，依然能正常采集完此檔案；這種"采集速度跟不上洗掉速度"是不能長時間存在，也有磁盤滿的風險，需要通過告警識別出來，根本上來說，需要通過負載均衡或者降低日志量的方法，來減少單機器日志長時間采集不過來的情況，
4.8 系統資源消耗與控制
Agent采集行程是隨著業務行程一起部署在一個機器上的，共同使用業務機器的資源（CPU、記憶體、磁盤、網路），所以在設計時，要考慮控制好Agent采集行程對機器資源的消耗，同時要做好對Agent行程對機器資源消耗的監控，一方面保障業務有穩定的資源可以正常運行；另外可以保障Agent自身行程正常運作，通常我們可以采用以下方案：
1. 針對CPU的消耗控制，
我們可以較方便采用Linux系統層面的CPU隔離的方案來控制，比如TaskSet；通過TaskSet命令，我們可以在采集行程啟動時，設定采集行程系結在某個限定的CPU核心上面（行程綁核，即設定行程與CPU親和性，設定以后Linux調度器就會讓這個行程/執行緒只在所系結的核上面去運行）；這樣的設定之后，可以保障采集行程與業務行程在CPU的使用上面互相不影響，
2. 針對記憶體的消耗控制，
由于采集Agent采用java語言開發基于JVM運行，所以我們可以通過JVM的堆引數配置即可控制；bees-agent一般默認配置512MB，理論上最低值可以是64MB，可以根據實際機器資源情況和采集日志檔案大小來配置；事實上，Agent的記憶體占用相對穩定，記憶體消耗方面的風險較小，
3.針對磁盤的消耗控制，
由于采集Agent是一個IO密集型行程，所以磁盤IO的負載是我們需要重點保障好的；在系統層面沒有成熟的磁盤IO的隔離方案，所以只能在應用層來實作，我們需要清楚行程所在磁盤的基準性能情況，然后在這個基礎上，通過Agent自身的限速采集能力，設定采集行程的峰值的采集速率（比如：3MB/s、5MB/s）；除此之外，還需要做好磁盤IO負載的基礎監控與告警、采集Agent采集速率大小的監控與告警，通過這些監控告警與值班分析進一步保障磁盤IO資源，
4.針對網路的消耗控制，
這里說的網路，重點要關注是跨機房帶寬上限，避免同一時刻，大批量的Agent日志采集導致跨機房的帶寬到達了上限，引發業務故障，所以，針對網路帶寬的使用也需要有監控與告警，相關監控資料上報到平臺匯總計算，平臺通過智能計算后給Agent下發一個合理的采集速率，
4.9 自身日志監控
為了更好的監控線上所有的Agent的情況，能夠方便地查看這些Agent行程自身的log4j日志是很有必要的，為了達成這一目的，我們把Agent自身產生的日志采集設計成一個普通的日志采集任務，就是說，采集Agent行程自身，自己采集自己產生的日志，于是就可以把所有Agent的日志通過Agent采集匯聚到下游Kafka，再到Elasticsearch存盤引擎，最后通過Kibana或其他的日志可視化平臺可以查看，
4.10 平臺化管理
目前的生產環境Agent實體數量已經好幾萬，采集任務數量有上萬個，為了對這些分散的、資料量多的Agent進行有效的集中的運維和管理，我們設計了一個可視化的平臺，管理平臺具備以下Agent控制能力：Agent 的現網版本查看，Agent存活心跳管理，Agent采集任務下發、啟動、停止管理，Agent采集限速管理等；需要注意的是，Agent與平臺的通訊方式，我們設計采用簡單的HTTP通訊方式，即Agent以定時心跳的方式（默認5分鐘）向平臺發起HTTP請求，HTTP請求體中會包含Agent自身資訊，比如idc、ip、hostname、當前采集任務資訊等，而HTTP回傳體的內容里會包含平臺向Agent下發的任務資訊，比如哪個任務啟動、哪個任務停止、任務的具體引數變更等，
五、與開源能力對比
bees-agent與flume-agent對比
- 記憶體需求大大降低，bees-agent 采用無 Channel 設計，大大節省記憶體開銷，每個 Agent 啟動 ，JVM 堆疊最低理論值可以設定為64MB；
- 實時性更好，bees-agent 采用Linux inotify事件機制，相比 Flume Agent 輪詢機制，采集資料的時效性可以在1s以內；
- 日志檔案的唯一標識，bees-agent 使用inode+檔案簽名，更準確，不會出現日志檔案誤采重采；
- 用戶資源隔離，bees-agent 不同 Topic 的日志采集任務，采用不同的執行緒隔離采集，互相無影響；
- 真正的優雅退出，bees-agent 在正常采集程序中，隨時使用平臺的"停止命令"讓 Agent 優雅退出，不會出現無法退出的尷尬情況，也能保證日志無任何丟失；
- 更豐富的指標資料，bees-agent 包括采集速率、采集總進度，還有 機器資訊、JVM 堆情況、類數量、JVM GC次數等；
- 更豐富的定制化能力，bees-agent 具備關鍵字匹配采集能力、日志格式化能力、平臺化管理的能力等；
六、總結
前文介紹了vivo日志采集Agent在設計程序中的一些核心技術點：包括日志檔案的發現與監聽、日志檔案的唯一識別符號設計、日志檔案的實時采集與離線采集的架構設計、日志檔案的清理策略、采集行程對系統資源的消耗控制、平臺化管理的思路等，這些關鍵的設計思路覆寫了自研采集agent大部分的核心功能，同時也覆寫了其中的難點痛點，能讓后續的開發環節更加暢通，當然，還有一些高階的采集能力未涵蓋本文介紹在內，比如"如何做好日志采集資料的完整性對賬"，"資料庫型別的場景的采集設計"等，大家可以繼續探索解決方案，
從2019年起，vivo大資料業務的日志采集場景就是由Bees資料采集服務支撐，bees-agent在生產環境持續服務，至今已有3年多的穩定運行的記錄，有數萬個bees-agent實體正在運行，同時在線支撐數萬個日志檔案的采集，每天采集PB級別的日志量，實踐證明，bees-agent的穩定行、健壯性、豐富的功能、性能與合理的資源情況，都符合最開始設計的預期，本文的設計思路的也一再被證實行之有效，
分享 vivo 互聯網技術干貨與沙龍活動，推薦最新行業動態與熱門會議，轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/538670.html
標籤：大數據