原文鏈接：記Flume-NG一些注意事項(xiàng)

這里只考慮flume本身的一些東西，對(duì)于JVM、HDFS、HBase等得暫不涉及。。。。

一、關(guān)于Source：

1、spool-source：適合靜態(tài)文件，即文件本身不是動(dòng)態(tài)變化的；

2、avro source可以適當(dāng)提高線程數(shù)量來(lái)提高此source性能；

3、ThriftSource在使用時(shí)有個(gè)問(wèn)題需要注意，使用批量操作時(shí)出現(xiàn)異常并不會(huì)打印異常內(nèi)容而是"Thrift source %s could not append events to the?channel."，這是因?yàn)樵创a中在出現(xiàn)異常時(shí)，它并未捕獲異常而是獲取組件名稱(chēng)，這是源碼中的一個(gè)bug，也可以說(shuō)明thrift很少有人 用，否則這個(gè)問(wèn)題也不會(huì)存在在很多版本中；

4、如果一個(gè)source對(duì)應(yīng)多個(gè)channel，默認(rèn)就是每個(gè)channel是同樣的一份數(shù)據(jù)，會(huì)把這批數(shù)據(jù)復(fù)制N份發(fā)送到N個(gè)channel中，所以如果某個(gè)channel滿了會(huì)影響整體的速度的哦；

5、ExecSource官方文檔已經(jīng)說(shuō)明是異步的，可能會(huì)丟數(shù)據(jù)哦，盡量使用tail -F，注意是大寫(xiě)的；

二、關(guān)于Channel：

1、采集節(jié)點(diǎn)建議使用新的復(fù)合類(lèi)型的SpillableMemoryChannel，匯總節(jié)點(diǎn)建議采用memory channel，具體還要看實(shí)際的數(shù)據(jù)量，一般每分鐘數(shù)據(jù)量超過(guò)120MB大小的flume agent都建議用memory channel(自己測(cè)的file channel處理速率大概是2M/s，不同機(jī)器、不同環(huán)境可能不同，這里只提供參考)，因?yàn)橐坏┐薬gent的channel出現(xiàn)溢出情況，將會(huì)導(dǎo)致大 多數(shù)時(shí)間處于file channel(SpillableMemoryChannel本身是file channel的一個(gè)子類(lèi)，而且復(fù)合channel會(huì)保證一定的event的順序的使得讀完內(nèi)存中的數(shù)據(jù)后，再需要把溢出的拿走，可能這時(shí)內(nèi)存已滿又會(huì)溢 出。。。)，性能大大降低，匯總一旦成為這樣后果可想而知；

2、調(diào)整memory 占用物理內(nèi)存空間，需要兩個(gè)參數(shù)byteCapacityBufferPercentage(默認(rèn)是20)和byteCapacity(默認(rèn)是JVM最大 可用內(nèi)存的0.8)來(lái)控制，計(jì)算公式是：byteCapacity = (int)((context.getLong("byteCapacity", defaultByteCapacity).longValue() * (1 - byteCapacityBufferPercentage * .01 )) /byteCapacitySlotSize)，很明顯可以調(diào)節(jié)這兩個(gè)參數(shù)來(lái)控制，至于byteCapacitySlotSize默認(rèn)是100，將物理內(nèi) 存轉(zhuǎn)換成槽(slot)數(shù)，這樣易于管理，但是可能會(huì)浪費(fèi)空間，至少我是這樣想的。。。；

3、還有一個(gè)有用的參數(shù)"keep-alive"這個(gè)參數(shù)用來(lái)控制channel滿時(shí)影響source的發(fā)送，channel空時(shí)影響sink 的消費(fèi)，就是等待時(shí)間，默認(rèn)是3s，超過(guò)這個(gè)時(shí)間就甩異常，一般不需配置，但是有些情況很有用，比如你得場(chǎng)景是每分鐘開(kāi)頭集中發(fā)一次數(shù)據(jù)，這時(shí)每分鐘的開(kāi) 頭量可能比較大，后面會(huì)越來(lái)越小，這時(shí)你可以調(diào)大這個(gè)參數(shù)，不至于出現(xiàn)channel滿了得情況；

三、關(guān)于Sink：

1、avro sink的batch-size可以設(shè)置大一點(diǎn)，默認(rèn)是100，增大會(huì)減少RPC次數(shù)，提高性能；

2、內(nèi)置hdfs sink的解析時(shí)間戳來(lái)設(shè)置目錄或者文件前綴非常損耗性能，因?yàn)槭腔谡齽t來(lái)匹配的，可以通過(guò)修改源碼來(lái)替換解析時(shí)間功能來(lái)極大提升性能，稍后我會(huì)寫(xiě)一篇文章來(lái)專(zhuān)門(mén)說(shuō)明這個(gè)問(wèn)題；

3、RollingFileSink文件名不能自定義，而且不能定時(shí)滾動(dòng)文件，只能按時(shí)間間隔滾動(dòng)，可以自己定義sink，來(lái)做定時(shí)寫(xiě)文件；

4、hdfs sink的文件名中的時(shí)間戳部分不能省去，可增加前綴、后綴以及正在寫(xiě)的文件的前后綴等信息；"hdfs.idleTimeout"這個(gè)參數(shù)很有意義，指 的是正在寫(xiě)的hdfs文件多長(zhǎng)時(shí)間不更新就關(guān)閉文件，建議都配置上，比如你設(shè)置了解析時(shí)間戳存不同的目錄、文件名，而且rollInterval=0、 rollCount=0、rollSize=1000000，如果這個(gè)時(shí)間內(nèi)的數(shù)據(jù)量達(dá)不到rollSize的要求而且后續(xù)的寫(xiě)入新的文件中了，就是一直 打開(kāi)，類(lèi)似情景不注意的話可能很多；"hdfs.callTimeout"這個(gè)參數(shù)指的是每個(gè)hdfs操作(讀、寫(xiě)、打開(kāi)、關(guān)閉等)規(guī)定的最長(zhǎng)操作時(shí)間， 每個(gè)操作都會(huì)放入"hdfs.threadsPoolSize"指定的線程池中得一個(gè)線程來(lái)操作；

5、關(guān)于HBase sink(非異步hbase sink：AsyncHBaseSink)，rowkey不能自定義，而且一個(gè)serializer只能寫(xiě)一列，一個(gè)serializer按正則匹配多個(gè) 列，性能可能存在問(wèn)題，建議自己根據(jù)需求寫(xiě)一個(gè)hbase sink；

6、avro sink可以配置failover和loadbalance，所用的組件和sinkgroup中的是一樣的，而且也可以在此配置壓縮選項(xiàng)，需要在avro source中配置解壓縮；

四、關(guān)于SinkGroup：

1、不管是loadbalance或者是failover的多個(gè)sink需要共用一個(gè)channel；

2、loadbalance的多個(gè)sink如果都是直接輸出到同一種設(shè)備，比如都是hdfs，性能并不會(huì)有明顯增加，因?yàn)閟inkgroup是 單線程的它的process方法會(huì)輪流調(diào)用每個(gè)sink去channel中take數(shù)據(jù)，并確保處理正確，使得是順序操作的，但是如果是發(fā)送到下一級(jí)的 flume agent就不一樣了，take操作是順序的，但是下一級(jí)agent的寫(xiě)入操作是并行的，所以肯定是快的；

3、其實(shí)用loadbalance在一定意義上可以起到failover的作用，生產(chǎn)環(huán)境量大建議loadbalance；

五、關(guān)于監(jiān)控monitor：

1、監(jiān)控我這邊做得還是比較少的，但是目前已知的有以下幾種吧：cloudera manager（前提是你得安裝CDH版本）、ganglia(這個(gè)天生就是支持的)、http(其實(shí)就是將統(tǒng)計(jì)信息jmx信息，封裝成json串，使用 jetty展示在瀏覽器中而已)、再一個(gè)就是自己實(shí)現(xiàn)收集監(jiān)控信息，自己做(可以收集http的信息或者自己實(shí)現(xiàn)相應(yīng)的接口實(shí)現(xiàn)自己的邏輯，具體可以參考 我以前的博客)；

2、簡(jiǎn)單說(shuō)一下cloudera manager這種監(jiān)控，最近在使用，確實(shí)很強(qiáng)大，可以查看實(shí)時(shí)的channel進(jìn)出數(shù)據(jù)速率、channel實(shí)時(shí)容量、sink的出速率、source 的入速率等等，圖形化的東西確實(shí)很豐富很直觀，可以提供很多flume agent整體運(yùn)行情況的信息和潛在的一些信息；

六、關(guān)于flume啟動(dòng)：

1、flume組件啟動(dòng)順序：channels——>sinks——>sources，關(guān)閉順序：sources——>sinks——>channels；

2、自動(dòng)加載配置文件功能，會(huì)先關(guān)閉所有組件，再重啟所有組件；

3、關(guān)于AbstractConfigurationProvider中的Map<Class<? extends Channel>, Map<String, Channel>> channelCache這個(gè)對(duì)象，始終存儲(chǔ)著agent中得所有channel對(duì)象，因?yàn)樵趧?dòng)態(tài)加載時(shí)，channel中可能還有未消費(fèi)完的數(shù)據(jù)，但是需要對(duì)channel重新配置，所以用以來(lái)緩存channel對(duì)象的所有數(shù)據(jù)及配置信息；

4、通過(guò)在啟動(dòng)命令中添加 "no-reload-conf"參數(shù)為true來(lái)取消自動(dòng)加載配置文件功能；

七、關(guān)于interceptor：

請(qǐng)看我的關(guān)于這個(gè)組件的博客，傳送門(mén)；

八、關(guān)于自定義組件：sink、source、channel：

1、channel不建議自定義哦，這個(gè)要求比較高，其他倆都是框架式的開(kāi)發(fā)，往指定的方法填充自己配置、啟動(dòng)、關(guān)閉、業(yè)務(wù)邏輯即可，以后有機(jī)會(huì)單獨(dú)寫(xiě)一篇文章來(lái)介紹；

2、關(guān)于自定義組件請(qǐng)相信github，上面好多好多好多，可以直接用的自定義組件....；

九、關(guān)于Flume-NG集群網(wǎng)絡(luò)拓?fù)浞桨?#xff1a;

1、在每臺(tái)采集節(jié)點(diǎn)上部署一個(gè)flume agent，然后做一到多個(gè)匯總flume agent(loadbalance)，采集只負(fù)責(zé)收集數(shù)據(jù)發(fā)往匯總，匯總可以寫(xiě)HDFS、HBase、spark、本地文件、kafka等等，這樣一般 修改會(huì)只在匯總，agent少，維護(hù)工作少；

2、采集節(jié)點(diǎn)沒(méi)有部署flume agent，可能發(fā)往mongo、redis等，這時(shí)你需要自定義source或者使用sdk來(lái)將其中的數(shù)據(jù)取出并發(fā)往flume agent，這樣agent就又可以充當(dāng)“采集節(jié)點(diǎn)”或者匯總節(jié)點(diǎn)了，但是這樣在前面相當(dāng)于加了一層控制，就又多了一層風(fēng)險(xiǎn)；

3、由于能力有限，其它未知，上面兩種，第一種好些，這里看看美團(tuán)的架構(gòu)———— 傳送門(mén) ；

東西比較簡(jiǎn)單，容易消化。

其他參考鏈接：

Flume研究心得

基于Flume的美團(tuán)日志收集系統(tǒng)(一)架構(gòu)和設(shè)計(jì)

基于Flume的美團(tuán)日志收集系統(tǒng)(二)改進(jìn)和優(yōu)化

總結(jié)

以上是生活随笔為你收集整理的Flume-NG一些注意事项（转）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。