基于flume的美團日志收集系統(tǒng)(編輯修改稿)
2025-07-15 15:52 本頁面
【文章內(nèi)容簡介】 進入到存儲系統(tǒng)。所以目前的權(quán)限控制就是category過濾。如果權(quán)限控制放在Agent端，優(yōu)勢是可以較好地控制垃圾數(shù)據(jù)在系統(tǒng)中流轉(zhuǎn)。但劣勢是配置修改麻煩，每增加一個日志就需要重啟或者重載Agent的配置。如果權(quán)限控制放在Collector端，優(yōu)勢是方便進行配置的修改和加載。劣勢是部分沒有注冊的數(shù)據(jù)可能在Agent/Collector之間傳輸?？紤]到Agent/Collector之間的日志傳輸并非系統(tǒng)瓶頸，且目前日志收集屬內(nèi)部系統(tǒng)，安全問題屬于次要問題，所以選擇采用Collector端控制。 提供實時流美團的部分業(yè)務(wù)，如實時推薦，反爬蟲服務(wù)等服務(wù)，需要處理實時的數(shù)據(jù)流。因此我們希望Flume能夠?qū)С鲆环輰崟r流給Kafka/Storm系統(tǒng)。一個非常重要的要求是實時數(shù)據(jù)流不應(yīng)該受到其它Sink的速度影響，保證實時數(shù)據(jù)流的速度。這一點，我們是通過Collector中設(shè)置不同的Channel進行隔離，并且DualChannel的大容量保證了日志的處理不受Sink的影響。5 系統(tǒng)監(jiān)控對于一個大型復(fù)雜系統(tǒng)來說，監(jiān)控是必不可少的部分。設(shè)計合理的監(jiān)控，可以對異常情況及時發(fā)現(xiàn)，只要有一部手機，就可以知道系統(tǒng)是否正常運作。對于美團的日志收集系統(tǒng)，我們建立了多維度的監(jiān)控，防止未知的異常發(fā)生。 發(fā)送速度，擁堵情況，寫Hdfs速度通過發(fā)送給zabbix的數(shù)據(jù)，我們可以繪制出發(fā)送數(shù)量、擁堵情況和寫Hdfs速度的圖表，對于超預(yù)期的擁堵，我們會報警出來查找原因。下面是Flume Collector HdfsSink寫數(shù)據(jù)到Hdfs的速度截圖：下面是Flume Collector的FileChannel中擁堵的events數(shù)據(jù)量截圖： flume寫hfds狀態(tài)的監(jiān)控Flume寫入Hdfs會先生成tmp文件，對于特別重要的日志，我們會每15分鐘左右檢查一下各個Collector是否都產(chǎn)生了tmp文件，對于沒有正常產(chǎn)生tmp文件的Collector和日志我們需要檢查是否有異常。這樣可以及時發(fā)現(xiàn)Flume和日志的異常. 日志大小異常監(jiān)控對于重要的日志，我們會每個小時都監(jiān)控日志大小周同比是否有較大波動，并給予提醒，這個報警有效的發(fā)現(xiàn)了異常的日志，且多次發(fā)現(xiàn)了應(yīng)用方日志發(fā)送的異常，及時給予了對方反饋，幫助他們及早修復(fù)自身系統(tǒng)的異常。通過上述的講解，我們可以看到，基于Flume的美團日志收集系統(tǒng)已經(jīng)是具備高可用性，高可靠性，可擴展等特性的分布式服務(wù)?；贔lume的美團日志收集系統(tǒng)(二)改進和優(yōu)化問題導(dǎo)讀：？？？在《基于Flume的美團日志收集系統(tǒng)(一)架構(gòu)和設(shè)計》中，我們詳述了基于Flume的美團日志收集系統(tǒng)的架構(gòu)設(shè)計，以及為什么做這樣的設(shè)計。在本節(jié)中，我們將會講述在實際部署和使用過程中遇到的問題，對Flume的功能改進和對系統(tǒng)做的優(yōu)化。1 Flume的問題總結(jié)在Flume的使用過程中，遇到的主要問題如下：a. Channel“水土不服”：使用固定大小的MemoryChannel在日志高峰時常報隊列大小不夠的異常；使用FileChannel又導(dǎo)致IO繁忙的問題；b. HdfsSink的性能問題：使用HdfsSink向Hdfs寫日志，在高峰時間速度較慢；c. 系統(tǒng)的管理問題：配置升級，模塊重啟等；2 Flume的功能改進和優(yōu)化點從上面的問題中可以看到，有一些需求是原生Flume無法滿足的，因此，基于開源的Flume我們增加了許多功能，修改了一些Bug，并且進行一些調(diào)優(yōu)。下面將對一些主要的方面做一些說明。 增加Zabbix monitor服務(wù)一方面，F(xiàn)lume本身提供了, ganglia的監(jiān)控服務(wù)，而我們目前主要使用zabbix做監(jiān)控。因此，我們?yōu)镕lume添加了zabbix監(jiān)控模塊，和sa的監(jiān)控服務(wù)無縫融合。另一方面，凈化Flume的metrics。只將我們需要的metrics發(fā)送給zabbix，避免 zabbix server造成壓力。目前我們最為關(guān)心的是Flume能否及時把應(yīng)用端發(fā)送過來的日志寫到Hdfs上， 對應(yīng)關(guān)注的metrics為： Source : 接收的event數(shù)和處理的event數(shù) Channel : Channel中擁堵的event數(shù) Sink : 已經(jīng)處理的event數(shù) 為HdfsSink增加自動創(chuàng)建index功能首先，我們的HdfsSink寫到hadoop的文件采用lzo壓縮存儲。 HdfsSink可以讀取hadoop配置文件中提供的編碼類列表，然后通過配置的方式獲取使用何種壓縮編碼，我們目前使用lzo壓縮數(shù)據(jù)。采用lzo壓縮而非bz2壓縮，是基于以下測試數(shù)據(jù)：event大小(Byte)壓縮格式總數(shù)據(jù)大小(G)耗時(s)平均events/s壓縮后大小(G)54430010000bz22448683354430010000lzo61227333其次，我們的HdfsSink增加了創(chuàng)建lzo文件后自動創(chuàng)建index功能。Hadoop提供了對lzo創(chuàng)建索引，使得壓縮文件是可切分的，這樣Hadoop Job可以并行處理數(shù)據(jù)文件。HdfsSink本身lzo壓縮，但寫完lzo文件并不會建索引，我們在close文件之后添加了建索引功能。 /** * Rename bucketPath file from .tmp to permanent location. */ private void renameBucket() throws IOException, InterruptedException { if((targetPath)) { return。 } final Path srcPath = new Path(bucketPath)。 final Path dstPath = new Path(targetPath)。 callWithTimeout(new Cal
職業(yè)教育相關(guān)推薦
鄂ICP備17016276號-1