COPY 基於Flume的美團日誌收集系統架構和設計
對比項 | Flume-NG | Scribe |
使用語言 | Java | c/c++ |
容錯性 | Agent和Collector間,Collector和Store間都有容錯性,且提供三種級別的可靠性保證; | Agent和Collector間, Collector和Store之間有容錯性; |
負載均衡 | Agent和Collector間,Collector和Store間有LoadBalance和Failover兩種模式 | 無 |
可擴充套件性 | 好 | 好 |
Agent豐富程度 | 提供豐富的Agent,包括avro/thrift socket, text, tail等 | 主要是thrift埠 |
Store豐富程度 | 可以直接寫hdfs, text, console, tcp;寫hdfs時支援對text和sequence的壓縮; | 提供buffer, network, file(hdfs, text)等 |
程式碼結構 | 系統框架好,模組分明,易於開發 | 程式碼簡單 |
a. 整個系統分為三層:Agent層,Collector層和Store層。其中Agent層每個機器部署一個程序,負責對單機的日誌收集工作;Collector層部署在中心伺服器上,負責接收Agent層傳送的日誌,並且將日誌根據路由規則寫到相應的Store層中;Store層負責提供永久或者臨時的日誌儲存服務,或者將日誌流導向其它伺服器。 b. Agent到Collector使用LoadBalance策略,將所有的日誌均衡地發到所有的Collector上,達到負載均衡的目標,同時並處理單個Collector失效的問題。 c. Collector層的目標主要有三個:SinkHdfs, SinkKafka和SinkBypass。分別提供離線的資料到Hdfs,和提供實時的日誌流到Kafka和Bypass。其中SinkHdfs又根據日誌量的大小分為SinkHdfs_b,SinkHdfs_m和SinkHdfs_s三個Sink,以提高寫入到Hdfs的效能,具體見後面介紹。 d. 對於Store來說,Hdfs負責永久地儲存所有日誌;Kafka儲存最新的7天日誌,並給Storm系統提供實時日誌流;Bypass負責給其它伺服器和應用提供實時日誌流。 下圖是美團的日誌收集系統的模組分解圖,詳解Agent, Collector和Bypass中的Source, Channel和Sink的關係。
a. 模組命名規則:所有的Source以src開頭,所有的Channel以ch開頭,所有的Sink以sink開頭; b. Channel統一使用美團開發的DualChannel,具體原因後面詳述;對於過濾掉的日誌使用NullChannel,具體原因後面詳述; c. 模組之間內部通訊統一使用Avro介面; 4 架構設計考慮 下面將從可用性,可靠性,可擴充套件性和相容性等方面,對上述的架構做細緻的解析。 4.1 可用性(availablity) 對日誌收集系統來說,可用性(availablity)指固定週期內系統無故障執行總時間。要想提高系統的可用性,就需要消除系統的單點,提高系統的冗餘度。下面來看看美團的日誌收集系統在可用性方面的考慮。 4.1.1 Agent死掉 Agent死掉分為兩種情況:機器宕機或者Agent程序死掉。 對於機器宕機的情況來說,由於產生日誌的程序也同樣會死掉,所以不會再產生新的日誌,不存在不提供服務的情況。 對於Agent程序死掉的情況來說,確實會降低系統的可用性。對此,我們有下面三種方式來提高系統的可用性。首先,所有的Agent在supervise的方式下啟動,如果程序死掉會被系統立即重啟,以提供服務。其次,對所有的Agent進行存活監控,發現Agent死掉立即報警。最後,對於非常重要的日誌,建議應用直接將日誌寫磁碟,Agent使用spooldir的方式獲得最新的日誌。 4.1.2 Collector死掉 由於中心伺服器提供的是對等的且無差別的服務,且Agent訪問Collector做了LoadBalance和重試機制。所以當某個Collector無法提供服務時,Agent的重試策略會將資料傳送到其它可用的Collector上面。所以整個服務不受影響。 4.1.3 Hdfs正常停機 我們在Collector的HdfsSink中提供了開關選項,可以控制Collector停止寫Hdfs,並且將所有的events快取到FileChannel的功能。 4.1.4 Hdfs異常停機或不可訪問 假如Hdfs異常停機或不可訪問,此時Collector無法寫Hdfs。由於我們使用DualChannel,Collector可以將所收到的events快取到FileChannel,儲存在磁碟上,繼續提供服務。當Hdfs恢復服務以後,再將FileChannel中快取的events再發送到Hdfs上。這種機制類似於Scribe,可以提供較好的容錯性。 4.1.5 Collector變慢或者Agent/Collector網路變慢 如果Collector處理速度變慢(比如機器load過高)或者Agent/Collector之間的網路變慢,可能導致Agent傳送到Collector的速度變慢。同樣的,對於此種情況,我們在Agent端使用DualChannel,Agent可以將收到的events快取到FileChannel,儲存在磁碟上,繼續提供服務。當Collector恢復服務以後,再將FileChannel中快取的events再發送給Collector。 4.1.6 Hdfs變慢 當Hadoop上的任務較多且有大量的讀寫操作時,Hdfs的讀寫資料往往變的很慢。由於每天,每週都有高峰使用期,所以這種情況非常普遍。 對於Hdfs變慢的問題,我們同樣使用DualChannel來解決。當Hdfs寫入較快時,所有的events只經過MemChannel傳遞資料,減少磁碟IO,獲得較高效能。當Hdfs寫入較慢時,所有的events只經過FileChannel傳遞資料,有一個較大的資料快取空間。 4.2 可靠性(reliability) 對日誌收集系統來說,可靠性(reliability)是指Flume在資料流的傳輸過程中,保證events的可靠傳遞。 對Flume來說,所有的events都被儲存在Agent的Channel中,然後被髮送到資料流中的下一個Agent或者最終的儲存服務中。那麼一個Agent的Channel中的events什麼時候被刪除呢?當且僅當它們被儲存到下一個Agent的Channel中或者被儲存到最終的儲存服務中。這就是Flume提供資料流中點到點的可靠性保證的最基本的單跳訊息傳遞語義。 那麼Flume是如何做到上述最基本的訊息傳遞語義呢? 首先,Agent間的事務交換。Flume使用事務的辦法來保證event的可靠傳遞。Source和Sink分別被封裝在事務中,這些事務由儲存event的儲存提供或者由Channel提供。這就保證了event在資料流的點對點傳輸中是可靠的。在多級資料流中,如下圖,上一級的Sink和下一級的Source都被包含在事務中,保證資料可靠地從一個Channel到另一個Channel轉移。
其次,資料流中 Channel的永續性。Flume中MemoryChannel是可能丟失資料的(當Agent死掉時),而FileChannel是永續性的,提供類似mysql的日誌機制,保證資料不丟失。 4.3 可擴充套件性(scalability) 對日誌收集系統來說,可擴充套件性(scalability)是指系統能夠線性擴充套件。當日志量增大時,系統能夠以簡單的增加機器來達到線性擴容的目的。 對於基於Flume的日誌收集系統來說,需要在設計的每一層,都可以做到線性擴充套件地提供服務。下面將對每一層的可擴充套件性做相應的說明。 4.3.1 Agent層 對於Agent這一層來說,每個機器部署一個Agent,可以水平擴充套件,不受限制。一個方面,Agent收集日誌的能力受限於機器的效能,正常情況下一個Agent可以為單機提供足夠服務。另一方面,如果機器比較多,可能受限於後端Collector提供的服務,但Agent到Collector是有Load Balance機制,使得Collector可以線性擴充套件提高能力。 4.3.2 Collector層 對於Collector這一層,Agent到Collector是有Load Balance機制,並且Collector提供無差別服務,所以可以線性擴充套件。其效能主要受限於Store層提供的能力。 4.3.3 Store層 對於Store這一層來說,Hdfs和Kafka都是分散式系統,可以做到線性擴充套件。Bypass屬於臨時的應用,只對應於某一類日誌,效能不是瓶頸。 4.4 Channel的選擇 Flume1.4.0中,其官方提供常用的MemoryChannel和FileChannel供大家選擇。其優劣如下:
- MemoryChannel: 所有的events被儲存在記憶體中。優點是高吞吐。缺點是容量有限並且Agent死掉時會丟失記憶體中的資料。
-
FileChannel: 所有的events被儲存在檔案中。優點是容量較大且死掉時資料可恢復。缺點是速度較慢。
-
DualChannel:基於 MemoryChannel和 FileChannel開發。當堆積在Channel中的events數小於閾值時,所有的events被儲存在MemoryChannel中,Sink從MemoryChannel中讀取資料; 當堆積在Channel中的events數大於閾值時, 所有的events被自動存放在FileChannel中,Sink從FileChannel中讀取資料。這樣當系統正常執行時,我們可以使用MemoryChannel的高吞吐特性;當系統有異常時,我們可以利用FileChannel的大快取的特性。
下面是Flume Collector的FileChannel中擁堵的events資料量截圖:
5.2 flume寫hfds狀態的監控 Flume寫入Hdfs會先生成tmp檔案,對於特別重要的日誌,我們會每15分鐘左右檢查一下各個Collector是否都產生了tmp檔案,對於沒有正常產生tmp檔案的Collector和日誌我們需要檢查是否有異常。這樣可以及時發現Flume和日誌的異常. 5.3 日誌大小異常監控 對於重要的日誌,我們會每個小時都監控日誌大小周同比是否有較大波動,並給予提醒,這個報警有效的發現了異常的日誌,且多次發現了應用方日誌傳送的異常,及時給予了對方反饋,幫助他們及早修復自身系統的異常。 通過上述的講解,我們可以看到,基於Flume的美團日誌收集系統已經是具備高可用性,高可靠性,可擴充套件等特性的分散式服務。 在《基於Flume的美團日誌收集系統(一)架構和設計》中,我們詳述了基於Flume的美團日誌收集系統的架構設計,以及為什麼做這樣的設計。在本節中,我們將會講述在實際部署和使用過程中遇到的問題,對Flume的功能改進和對系統做的優化。 1 Flume的問題總結 在Flume的使用過程中,遇到的主要問題如下: a. Channel“水土不服”:使用固定大小的MemoryChannel在日誌高峰時常報佇列大小不夠的異常;使用FileChannel又導致IO繁忙的問題; b. HdfsSink的效能問題:使用HdfsSink向Hdfs寫日誌,在高峰時間速度較慢; c. 系統的管理問題:配置升級,模組重啟等; 2 Flume的功能改進和優化點 從上面的問題中可以看到,有一些需求是原生Flume無法滿足的,因此,基於開源的Flume我們增加了許多功能,修改了一些Bug,並且進行一些調優。下面將對一些主要的方面做一些說明。 2.1 增加Zabbix monitor服務 一方面,Flume本身提供了http, ganglia的監控服務,而我們目前主要使用zabbix做監控。因此,我們為Flume添加了zabbix監控模組,和sa的監控服務無縫融合。 另一方面,淨化Flume的metrics。只將我們需要的metrics傳送給zabbix,避免 zabbix server造成壓力。目前我們最為關心的是Flume能否及時把應用端傳送過來的日誌寫到Hdfs上, 對應關注的metrics為:
- Source : 接收的event數和處理的event數
- Channel : Channel中擁堵的event數
-
Sink : 已經處理的event數
event大小(Byte) | sink.batch-size | hdfs.batchSize | 壓縮格式 | 總資料大小(G) | 耗時(s) | 平均events/s | 壓縮後大小(G) |
544 | 300 | 10000 | bz2 | 9.1 | 2448 | 6833 | 1.36 |
544 | 300 | 10000 | lzo | 9.1 | 612 | 27333 | 3.49 |
-
/**
-
* Rename bucketPath file from .tmp to permanent location.
-
*/
-
private void renameBucket() throws IOException, InterruptedException {
-
if(bucketPath.equals(targetPath)) {
-
return;
-
}
-
final Path srcPath = new Path(bucketPath);
-
final Path dstPath = new Path(targetPath);
-
callWithTimeout(new CallRunner<Object>() {
-
@Override
-
public Object call() throws Exception {
-
if(fileSystem.exists(srcPath)) { // could block
-
LOG.info("Renaming " + srcPath + " to " + dstPath);
-
fileSystem.rename(srcPath, dstPath); // could block
-
//index the dstPath lzo file
-
if (codeC != null && ".lzo".equals(codeC.getDefaultExtension()) ) {
-
LzoIndexer lzoIndexer = new LzoIndexer(new Configuration());
-
lzoIndexer.index(dstPath);
-
}
-
}
-
return null;
-
}
-
});
- }
2.3 增加HdfsSink的開關 我們在HdfsSink和DualChannel中增加開關,當開關開啟的情況下,HdfsSink不再往Hdfs上寫資料,並且資料只寫向DualChannel中的FileChannel。以此策略來防止Hdfs的正常停機維護。 2.4 增加DualChannel Flume本身提供了MemoryChannel和FileChannel。MemoryChannel處理速度快,但快取大小有限,且沒有持久化;FileChannel則剛好相反。我們希望利用兩者的優勢,在Sink處理速度夠快,Channel沒有快取過多日誌的時候,就使用MemoryChannel,當Sink處理速度跟不上,又需要Channel能夠快取下應用端傳送過來的日誌時,就使用FileChannel,由此我們開發了DualChannel,能夠智慧的在兩個Channel之間切換。 其具體的邏輯如下:
-
/***
-
* putToMemChannel indicate put event to memChannel or fileChannel
-
* takeFromMemChannel indicate take event from memChannel or fileChannel
-
* */
-
private AtomicBoolean putToMemChannel = new AtomicBoolean(true);
-
private AtomicBoolean takeFromMemChannel = new AtomicBoolean(true);
-
void doPut(Event event) {
-
if (switchon && putToMemChannel.get()) {
-
//往memChannel中寫資料
-
memTransaction.put(event);
-
if ( memChannel.isFull() || fileChannel.getQueueSize() > 100) {
-
putToMemChannel.set(false);
-
}
-
} else {
-
//往fileChannel中寫資料
-
fileTransaction.put(event);
-
}
-
}
-
Event doTake() {
-
Event event = null;
-
if ( takeFromMemChannel.get() ) {
-
//從memChannel中取資料
-
event = memTransaction.take();
-
if (event == null) {
-
takeFromMemChannel.set(false);
-
}
-
} else {
-
//從fileChannel中取資料
-
event = fileTransaction.take();
-
if (event == null) {
-
takeFromMemChannel.set(true);
-
putToMemChannel.set(true);
-
}
-
}
-
return event;
- }
2.5 增加NullChannel Flume提供了NullSink,可以把不需要的日誌通過NullSink直接丟棄,不進行儲存。然而,Source需要先將events存放到Channel中,NullSink再將events取出扔掉。為了提升效能,我們把這一步移到了Channel裡面做,所以開發了NullChannel。 2.6 增加KafkaSink 為支援向Storm提供實時資料流,我們增加了KafkaSink用來向Kafka寫實時資料流。其基本的邏輯如下:
相關推薦
COPY 基於Flume的美團日誌收集系統架構和設計
美團的日誌收集系統負責美團的所有業務日誌的收集,並分別給Hadoop平臺提供離線資料和Storm平臺提供實時資料流。美團的日誌收集系統基於Flume設計和搭建而成。 《基於Flume的美團日誌收集系統》將分兩部分給讀者呈現美團日誌收集系統的架構設計和實戰經驗。 第一部
基於Flume的美團日誌收集系統(二)改進和優化
問題導讀: 1.Flume的存在些什麼問題? 2.基於開源的Flume美團增加了哪些功能? 3.Flume系統如何調優? 在《基於Flume的美團日誌收集系統(一)架構和設計》中,我們詳述了基於Flume的美團日誌收集系統的架構設計,以及為什麼做這樣的設計。在本節
基於Flume的美團日誌收集系統(一)架構和設計
美團的日誌收集系統負責美團的所有業務日誌的收集,並分別給Hadoop平臺提供離線資料和Storm平臺提供實時資料流。美團的日誌收集系統基於Flume設計和搭建而成。 《基於Flume的美團日誌收集系統》將分兩部分給讀者呈現美團日誌收集系統的架構設計和實戰經驗。 第一部
10044---基於Flume的美團日誌收集系統(一)架構和設計
原文 問題導讀: 1.Flume-NG與Scribe對比,Flume-NG的優勢在什麼地方?2.架構設計考慮需要考慮什麼問題?3.Agent宕機該如何解決?4.Collector宕機是否會有影響?5.Flume-NG可靠性(reliability)方面做了哪些措施?
基於flume+kafka+storm日誌收集系統搭建
基於flume+kafka+storm日誌收集系統搭建 1. 環境 192.168.0.2 hadoop1 192.168.0.3 hadoop2 192.168.0.4 hadoop3 已經
Flume日誌收集系統架構詳解--轉
with 指定 mwl 裏程碑 工程 生命 數據接收 dba -i 2017-09-06 朱潔 大數據和雲計算技術 任何一個生產系統在運行過程中都會產生大量的日誌,日誌往往隱藏了很多有價值的信息。在沒有分析方法之前,這些日誌存儲一段時間後就會被清理。隨著技術的發展和
日誌收集系統架構
各元件介紹 Log Agent 日誌收集客戶端,用來收集伺服器上的日誌 Kafka 高吞吐量的分散式佇列 linkin開發 apache頂級開源專案 非同步處理,把非關鍵流程非同步化,提高系統的響應時間和健壯性 應用解耦,
基於flume的日誌收集系統配置
大資料系統中通常需要採集的日誌有: 系統訪問日誌 使用者點選日誌 其他業務日誌(比如推薦系統的點選日誌) 在收集日誌的時候,一般分為三層結構:採集層、彙總層和儲存層,而不是直接從採集端將資料傳送到儲存端,這樣的好處有: 如果儲存端如Hadoop叢集、Kafka等需要停
日誌收集系統Flume及其應用
註意 內存緩存 外部 ner 流動 場景 啟動 net conf Apache Flume概述 Flume 是 Cloudera 提供的一個高可用的,高可靠的,分布式的海量日誌采集、聚合和傳輸的系統。Flume 支持定制各類數據發送方,用於收集各類型數據;同時,Flu
Flume可分布式日誌收集系統
agen debug 程序 負責 and 序列化 得到 集群 ava Flume 1. 前言 flume是由cloudera軟件公司產出的可分布式日誌收集系統,後與2009年被捐贈了apache軟件基金會,為hadoop相關組件之一。尤其近幾年隨著flume的不斷被完善
Flume(日誌收集系統)簡介
一、Flume簡介 flume是一個分散式、可靠、高可用的海量日誌採集、聚合和傳輸的系統。支援在日誌系統中定製各類資料傳送方,用於收集資料 ; 同時,Flume提供對資料進行簡單處理,並寫到各種資料接受方(比如文字、HDFS、Hbase等)的能力 。 flume的
大資料學習筆記之flume----日誌收集系統
一、flume基本概念 Flume是Cloudera提供的一個高可用的,高可靠的,分散式的海量日誌採集、聚合和傳輸的系統; Flume支援在日誌系統中定製各類資料傳送方,用於收集資料; Flume提供對資料進行簡單處理,並寫到各種資料接受方(可定製)的能力。 總結:f
nginx+flume+hdfs搭建實時日誌收集系統
1、配置nginx.conf,新增以下配置 http { #配置日誌格式 log_format lf '$remote_addr^A$msec^A$http_host^A$reques
分散式日誌收集系統:Flume
Flume知識點: Event 是一行一行的資料 1.flume是分散式的日誌收集系統,把收集來的資料傳送到目的地去。 2.flume裡面有個核心概念,叫做agent。agent是一個java程序,執行在日誌收集節點。 3.agent裡面包
基於ELK的日誌收集系統的心得
elasticsearch+logstash+kinana搭建的日誌收集系統 elasticsearch是基於倒排序查詢的查詢引擎,什麼叫倒排序?比如mysql建立的索引是正排序,對於規範化資料(比如表格,元資料)而言基本使用正排序索引,倒排序一般用於文字之類的查詢,典型
分散式日誌收集系統 —— Flume
一、Flume簡介 Apache Flume 是一個分散式,高可用的資料收集系統。它可以從不同的資料來源收集資料,經過聚合後傳送到儲存系統中,通常用於日誌資料的收集。Flume 分為 NG 和 OG (1.0 之前) 兩個版本,NG 在 OG 的基礎上進行了完全的重構,是目前使用最為廣泛的版本。下面的介紹均以
Linux 之rsyslog+LogAnalyzer 日誌收集系統
windows 服務器 應用程序 數據庫 規劃圖 一、LogAnalyzer介紹 LogAnalyzer工具提供了一個易於使用,功能強大的前端,用於搜索,查看和分析網絡活動數據,包括系統日誌,事件日誌和其他許多日誌源。由於它只是將數據展示到我們用戶的面前,所以數據本身需要由另一個程序收集
es redis logstash 日誌收集系統排錯
bsp pos keys allow light 通過命令 bash 系統排錯 man 用logstash收集日誌並發送到redis,然後通過logstash取redis數據寫入到es集群,最近kibana顯示日誌總是中斷,日誌收集不過來,客戶端重啟發現報錯: Faile
Go實現海量日誌收集系統(二)
fig encode 文件配置 sar 架構 cli 代碼執行 CP lob 一篇文章主要是關於整體架構以及用到的軟件的一些介紹,這一篇文章是對各個軟件的使用介紹,當然這裏主要是關於架構中我們agent的實現用到的內容 關於zookeeper+kafka 我們需要先把兩
Linux搭建ELK日誌收集系統:FIlebeat+Redis+Logstash+Elasticse
uri 對數 exp 取數 網速 docker useradd 通過 演示 Centos7部署ELK日誌收集系統 一、ELK概述: ELK是一組開源軟件的簡稱,其包括Elasticsearch、Logstash 和 Kibana。ELK最近幾年發展迅速,已經成為目前最流行的