Flume日志收集方案設(shè)計(jì)和測(cè)試

1 背景

隨著微服務(wù)拆封和部署節(jié)點(diǎn)的增長，各服務(wù)日志非常分散，發(fā)現(xiàn)業(yè)務(wù)問題時(shí)，排查人員需要依次登錄不同節(jié)點(diǎn)服務(wù)器逐一排查日志，現(xiàn)有方式存在查詢定位問題耗時(shí)長，日志滾動(dòng)日志丟失，服務(wù)器登錄安全等問題，收集的業(yè)務(wù)服務(wù)日志量級(jí)非常巨大，截止現(xiàn)在每天約10TG日志量為此，我們引入日志平臺(tái)，將分散的服務(wù)日志統(tǒng)一收集存儲(chǔ)并提供平臺(tái)進(jìn)行查詢，并做好方案性能測(cè)試與調(diào)優(yōu)方案調(diào)研。

2 目標(biāo)

完成對(duì)服務(wù)日志統(tǒng)一收集。
日志實(shí)時(shí)性不超過2小時(shí)。
單Agent節(jié)點(diǎn)QPS吞吐量>5000。

3 方案設(shè)計(jì)

3.1 架構(gòu)設(shè)計(jì)

image.png

3.1.1 Agent

采集日志節(jié)點(diǎn)，部署在應(yīng)用服務(wù)器。

3.1.1.1 Source

選擇Taildir Source。

image.png

Windows系統(tǒng)不支持，對(duì)于部署在Windows服務(wù)程序（網(wǎng)上有魔改的tail source，不建議使用），需要使用Spooling Directory Source，并且保證監(jiān)控目錄不會(huì)出現(xiàn)正在寫的文件。可通過日志配置或?qū)懩_本將日志文件MV到指定目錄。

3.1.1.2 Channel

選擇File Source。

Agent部署在業(yè)務(wù)服務(wù)服務(wù)器，從日志消息不丟失，盡可能不影響業(yè)務(wù)服務(wù)運(yùn)行情況下決定使用File Source，F(xiàn)lume 1.7版本已存在與美團(tuán)Dao Channel相似功能，資源限制條件下使用Memory Channel，超過資源限制使用File channel，但是官方建議此功能是實(shí)驗(yàn)性功能，當(dāng)前版本不推薦在生產(chǎn)環(huán)境使用。

image.png

3.1.1.3 Sink

3.1.2 Collector Node

收集節(jié)點(diǎn)，單獨(dú)服務(wù)器，可擴(kuò)展。

3.1.2.1 Source

3.1.2.2 Channel

選擇File Source。考慮與Agent Channel相同原因。

3.1.2.3 Sink

3.2 穩(wěn)定性擴(kuò)展方案

通過Load balancing Sink Processor，對(duì)Agent的 Kafka Sink進(jìn)行負(fù)載均衡（負(fù)載策略round_robin）穩(wěn)定性擴(kuò)展，由于flume在單線程中輪詢，故此方案性能提升不明顯，僅提高file channel與Kfka Sink之間可靠性。

image.png

3.3 備用方案

之前sink kafka，kafka集群可能是瓶頸，此方案作為備選方案。

多個(gè)Agent順序連接：將多個(gè)Agent順序連接起來，將最初的數(shù)據(jù)源經(jīng)過收集，存儲(chǔ)到最終的存儲(chǔ)系統(tǒng)中。一般情況下，應(yīng)該控制這種順序連接的Agent的數(shù)量，因?yàn)閿?shù)據(jù)流經(jīng)的路徑變長了，如果不考慮Failover的話，出現(xiàn)故障將影響整個(gè)Flow上的Agent收集服務(wù)。

image.png

4 性能測(cè)試

4.1 服務(wù)器列表

4.1.1 flume agent

10.66.221.98 4core 8G

4.1.2 zk+kafka

10.66.221.108 4core 4G

10.66.221.109 4core 4G

10.66.221.110 4core 4G

4.2 用例信息

選擇生產(chǎn)環(huán)境10.66.8.31服務(wù)器CP日志用于測(cè)試（早上6點(diǎn)40左右高峰期日志）。


文件名：Aquila_DATA_201805220640_010368_043.log

日志來源服務(wù)器IP：10.66.8.31

服務(wù)器配置：4core + 4G

文件大小：~100M

總條數(shù)：162034 條   總時(shí)長： 37.5 秒

單條平均大小：100*1024*1024 / 162034 = ~647 byte

單個(gè)cp帶寬： 100M / 37.5 = ~2.67M/s

單個(gè)cp每小時(shí)文件大小：~9.6G

單個(gè)cp每天文件大小：~230G

qps：162034 / 37.5 = ~4321 條

qpm：qps * 60 = ~259260條

qph：qpm * 60 = ~15555600條

以目前30個(gè)cp節(jié)點(diǎn)估算：

30qph= qph * 30 =~466668000條 (30個(gè)cp節(jié)點(diǎn))

30個(gè)cp節(jié)點(diǎn)文件大小每小時(shí)=30qph *單條平均大小/ (1024 *1024*1024) = ~280G

4.2.1 flume測(cè)試配置

JVM 參數(shù)

JAVA_OPTS="-Xms1024m -Xmx1024m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-UseGCOverheadLimit -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=20000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

4.3 測(cè)試方案

主要針對(duì)flumeBatchSize參數(shù)調(diào)優(yōu)。Flume啟動(dòng)最小

每組測(cè)試3次，取平均值。


sink kafka：

flumeBatchSize = 1000       flumeBatchSize = 10000

25s                                                    20s

flume: 1G JVM內(nèi)存

總文件大小：~1G

總條數(shù)：1637590 

總時(shí)長：254 s

JVM MEM：~300M

TPS：1637590 / 254 = ~6447

4.4 測(cè)試結(jié)論

Flume Agent：Flume 1.7
Collector Node：CDH Flume 1.6

4.4.1 Flume Aget測(cè)試

文件名：Aquila_DATA_201805220640_010368_043.log</pre>
文件大小：~100M</pre>
總條數(shù)：162034條 </pre>

4.4.1.1 Source -> Channel

通過觀察和統(tǒng)計(jì)metrics，發(fā)現(xiàn)接收162034 條消息約3秒，F(xiàn)ileChannel并沒有成為瓶頸。Channel -> Sink才是瓶頸關(guān)鍵。

4.4.1.2 Channel -> Sink

以下進(jìn)行多組測(cè)試，取平均值。

file_roll sink：5s
avro sink：20s ChannelFillPercentage值范圍：(0,1)</pre>
kafka sink：100s （配置已做優(yōu)化，研發(fā)環(huán)境kafka集群配置低，具體線上觀察調(diào)節(jié)kakfa JVM內(nèi)存等條件）

image.png

4.4.1.3 Flume JVM

文件大小：~100M</pre>
總條數(shù)：162034 條</pre>
CPU：< 4%</pre>
MEM:<300M</pre>

image.png

將測(cè)試文件并發(fā)增大10倍。</pre>
文件大小：~100M * 10</pre>
總條數(shù)：162034條 * 10</pre>
CPU：< 10%</pre>
MEM:<400M</pre>

image.png

故目前生產(chǎn)環(huán)境Flume JVM分配1G遠(yuǎn)遠(yuǎn)滿足。

image.png

4.4.2 Flume Collector Node 測(cè)試

在CDH創(chuàng)建一個(gè)Flume集群部署一個(gè)Agent 成為Collector Node。

4.4.2.1 Source -> Channel

kafka topic 分區(qū)=5

通過觀察和統(tǒng)計(jì)metrics， channel 和sink 都能及時(shí)處理并實(shí)時(shí)落地HDFS，此時(shí)Sink HDFS 稍微成為瓶頸，后續(xù)可通過增加Cllector Node 方式增加并行處理能力。

image.png

此時(shí)Flume Cllector Node 內(nèi)存~1G。

image.png

4.4.2.2 hdfs性能

image.png

4.5 測(cè)試總結(jié)

當(dāng)前flume架構(gòu)配置設(shè)計(jì)方案：

cp生產(chǎn)日志QPS為6447條/s。

6447 大于 4321，滿足需求，更多性能優(yōu)化只能在生產(chǎn)環(huán)境實(shí)際調(diào)優(yōu)。

5 消息格式驗(yàn)證

消息格式驗(yàn)證在Agent進(jìn)行驗(yàn)證，不通過驗(yàn)證的消息直接丟棄，避免不合約定的消息進(jìn)入kafka，減輕kafka集群壓力。

6 監(jiān)控方案（待定）

Flume包含以下幾種監(jiān)控方案, JMX Reporting,Ganglia Reporting不能同時(shí)配置。

Reporting，JSON Reporting，Ganglia Reporting， Custom Reporting。

也可向Zabbix上報(bào)監(jiān)控?cái)?shù)據(jù)。

Cllector Node 在CDH創(chuàng)建，可通過CDH監(jiān)控。

6.1 JMX Reporting

JMX高爆可以在flume-env.sh文件修改JAVA_OPTS環(huán)境變量，可通過jvisualvm監(jiān)控。

6.2 JSON Reporting

Flume可以通過JSON形式報(bào)告metrics，啟用JSON形式，F(xiàn)lume需要配置一個(gè)端口。

6.3 Ganglia Reporting

Flume也可以報(bào)告metrics到Ganglia 3或者是Ganglia 3.1的metanodes。要將metrics報(bào)告到Ganglia，必須在啟動(dòng)的時(shí)候就支持Flume Agent。

6.4 Custom Reporting

自定義的監(jiān)控需要實(shí)現(xiàn)org.apache.flume.instrumentation.MonitorService接口。例如有一個(gè)HTTP的監(jiān)控類叫HttpReporting，我可以通過如下方式啟動(dòng)這個(gè)監(jiān)控。

7 注意事項(xiàng)

當(dāng)前CDH版flume為1.6版本，參數(shù)配置參考CDH Flume配置文檔。https://archive.cloudera.com/cdh5/cdh/5/flume-ng/FlumeUserGuide.html#hdfs-sink

8 附錄

8.1 FLume Agent配置

agent1.sources = r1
agent1.channels = c1
agent1.sinks = k1

agent1.sources.r1.type = TAILDIR
agent1.sources.r1.positionFile = /flume/agent2/taildir_position.json
agent1.sources.r1.filegroups = f1
agent1.sources.r1.filegroups.f1 = /root/testlog1/Aquila_DATA_.*.log
agent1.sources.r1.batchSize = 1000
agent1.sources.r1.backoffSleepIncrement = 5000
agent1.sources.r1.maxBackoffSleep = 5000
agent1.sources.r1.channels = c1

#agent1.sources.r1.type = avro
#agent1.sources.r1.bind = 10.66.221.138
#agent1.sources.r1.port = 44444
#agent1.sources.r1.compression-type = deflate
#agent1.sources.r1.channels = c1

#agent1.sources.r1.type=org.apache.flume.source.kafka.KafkaSource
#agent1.sources.r1.kafka.bootstrap.servers=10.66.221.108:9092,10.66.221.109:9092,10.66.221.110:9092
#agent1.sources.r1.kafka.topics=cp-aquila-data
#agent1.sources.r1.kafka.consumer.group.id=flume_cp-aquila-data

#agent1.sources.r1.batchSize = 10000
#agent1.sources.r1.batchDurationMillis = 2000
#agent1.sources.r1.channels=c1
#agent1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink
#agent1.sinks.k1.kafka.topic = cp-aquila-data
#agent1.sinks.k1.kafka.bootstrap.servers = 10.66.221.108:9092,10.66.221.109:9092,10.66.221.110:9092
#agent1.sinks.k1.kafka.flumeBatchSize = 5000
#agent1.sinks.k1.kafka.producer.acks = 1
#agent1.sinks.k1.kafka.producer.linger.ms = 1
#agent1.sinks.k1.kafka.producer.max.request.size =10485760
#agent1.sinks.k1.channel = c1
#agent1.sinks.k1.type = file_roll

#agent1.sinks.k1.sink.directory = /root/flumefiles
#agent1.sinks.k1.sink.rollInterval = 0
#agent1.sinks.k1.channel = c1
#agent1.sinks.k1.hdfs.path=hdfs://v2-cdh03:8020/warehouse/applog/aquila/%Y%m%d
#agent1.sinks.k1.hdfs.filePrefix=applog_%Y%m%d_
#agent1.sinks.k1.hdfs.inUsePrefix=_
#agent1.sinks.k1.hdfs.rollSize=280000800
#agent1.sinks.k1.hdfs.rollInterval = 0
#agent1.sinks.k1.hdfs.rollCount=0
#agent1.sinks.k1.hdfs.round = true
#agent1.sinks.k1.hdfs.roundValue = 1
#agent1.sinks.k1.hdfs.roundUnit = hour
#agent1.sinks.k1.hdfs.proxyUser=flume
#agent1.sinks.k1.hdfs.fileType=DataStream
#agent1.sinks.k1.hdfs.batchSize=10000
#agent1.sinks.k1.hdfs.callTimeout=60000
#agent1.sinks.k1.channel = c1
agent1.sinks.k1.type = avro
agent1.sinks.k1.hostname = 10.66.221.138
agent1.sinks.k1.port = 44444
agent1.sinks.k1.connect-timeout = 200000
agent1.sinks.k1.compression-type = deflate
agent1.sinks.k1.channel = c1
agent1.channels.c1.type = file
agent1.channels.c1.checkpointDir = /flume/agent2/checkpoint
agent1.channels.c1.dataDirs = /flume/agent2/data
agent1.channels.c1.capacity = 10000000
agent1.channels.c1.transactionCapacity = 5000
#agent1.channels.c1.type=memory
#agent1.channels.c1.capacity =10000000
#agent1.channels.c1.transactionCapacity =5000
#agent1.channels.c1.keep-alive=30
#agent1.channels.c1.byteCapacityBufferPercentage=40
#agent1.channels.c1.byteCapacity=536870912

8.2 Flume metris

  {

  "SOURCE.src-1":{

    "OpenConnectionCount":"0",    //目前與客戶端或sink保持連接的總數(shù)量(目前只有avro source展現(xiàn)該度量)

    "Type":"SOURCE",          

    "AppendBatchAcceptedCount":"1355",  //成功提交到channel的批次的總數(shù)量

    "AppendBatchReceivedCount":"1355",  //接收到事件批次的總數(shù)量

    "EventAcceptedCount":"28286", //成功寫出到channel的事件總數(shù)量，且source返回success給創(chuàng)建事件的sink或RPC客戶端系統(tǒng)

    "AppendReceivedCount":"0",    //每批只有一個(gè)事件的事件總數(shù)量(與RPC調(diào)用中的一個(gè)append調(diào)用相等)

    "StopTime":"0",     //source停止時(shí)自Epoch以來的毫秒值時(shí)間

    "StartTime":"1442566410435",  //source啟動(dòng)時(shí)自Epoch以來的毫秒值時(shí)間

    "EventReceivedCount":"28286", //目前為止source已經(jīng)接收到的事件總數(shù)量

    "AppendAcceptedCount":"0"   //單獨(dú)傳入的事件到Channel且成功返回的事件總數(shù)量

  },

  "CHANNEL.ch-1":{

    "EventPutSuccessCount":"28286", //成功寫入channel且提交的事件總數(shù)量

    "ChannelFillPercentage":"0.0",  //channel滿時(shí)的百分比

    "Type":"CHANNEL",

    "StopTime":"0",     //channel停止時(shí)自Epoch以來的毫秒值時(shí)間

    "EventPutAttemptCount":"28286", //Source嘗試寫入Channe的事件總數(shù)量

    "ChannelSize":"0",      //目前channel中事件的總數(shù)量

    "StartTime":"1442566410326",  //channel啟動(dòng)時(shí)自Epoch以來的毫秒值時(shí)間

    "EventTakeSuccessCount":"28286",  //sink成功讀取的事件的總數(shù)量

    "ChannelCapacity":"1000000", //channel的容量

    "EventTakeAttemptCount":"313734329512" //sink嘗試從channel拉取事件的總數(shù)量。這不意味著每次事件都被返回，因?yàn)閟ink拉取的時(shí)候channel可能沒有任何數(shù)據(jù)

  },

  "SINK.sink-1":{

    "Type":"SINK",

    "ConnectionClosedCount":"0",  //下一階段或存儲(chǔ)系統(tǒng)關(guān)閉的連接數(shù)量(如在HDFS中關(guān)閉一個(gè)文件)

    "EventDrainSuccessCount":"28286", //sink成功寫出到存儲(chǔ)的事件總數(shù)量

    "KafkaEventSendTimer":"482493",   

    "BatchCompleteCount":"0",   //與最大批量尺寸相等的批量的數(shù)量

    "ConnectionFailedCount":"0",  //下一階段或存儲(chǔ)系統(tǒng)由于錯(cuò)誤關(guān)閉的連接數(shù)量（如HDFS上一個(gè)新創(chuàng)建的文件因?yàn)槌瑫r(shí)而關(guān)閉）

    "EventDrainAttemptCount":"0", //sink嘗試寫出到存儲(chǔ)的事件總數(shù)量

    "ConnectionCreatedCount":"0", //下一個(gè)階段或存儲(chǔ)系統(tǒng)創(chuàng)建的連接數(shù)量（如HDFS創(chuàng)建一個(gè)新文件）

    "BatchEmptyCount":"0",    //空的批量的數(shù)量，如果數(shù)量很大表示souce寫數(shù)據(jù)比sink清理數(shù)據(jù)慢速度慢很多

    "StopTime":"0",     

    "RollbackCount":"9",      //

    "StartTime":"1442566411897",

    "BatchUnderflowCount":"0"   //比sink配置使用的最大批量尺寸更小的批量的數(shù)量，如果該值很高也表示sink比souce更快

  }

  }

最后編輯于：2018.07.13 16:06:53

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

人面猴
序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
沈念sama閱讀 229,908評(píng)論 6贊 541
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 99,324評(píng)論 3贊 429
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
開封第一講書人閱讀 178,018評(píng)論 0贊 383
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長。經(jīng)常有香客問我，道長，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 63,675評(píng)論 1贊 317
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當(dāng)我...
茶點(diǎn)故事閱讀 72,417評(píng)論 6贊 412
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著，像睡著了一般。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發(fā)上，一...
開封第一講書人閱讀 55,783評(píng)論 1贊 329
城市分裂傳說
那天，我揣著相機(jī)與錄音，去河邊找鬼。笑死，一個(gè)胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的。我是一名探鬼主播，決...
沈念sama閱讀 43,779評(píng)論 3贊 446
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢(mèng)啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起，我...
開封第一講書人閱讀 42,960評(píng)論 0贊 290
萬榮殺人案實(shí)錄
序言：老撾萬榮一對(duì)情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個(gè)月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
沈念sama閱讀 49,522評(píng)論 1贊 335
?護(hù)林員之死
正文獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點(diǎn)故事閱讀 41,267評(píng)論 3贊 358
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點(diǎn)故事閱讀 43,471評(píng)論 1贊 374
活死人
序言：一個(gè)原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 39,009評(píng)論 5贊 363
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜，卻給世界環(huán)境...
茶點(diǎn)故事閱讀 44,698評(píng)論 3贊 348
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 35,099評(píng)論 0贊 28
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 36,386評(píng)論 1贊 294
情欲美人皮
我被黑心中介騙來泰國打工，沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。一個(gè)月前我還...
沈念sama閱讀 52,204評(píng)論 3贊 398
代替公主和親
正文我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。傳聞我的和親對(duì)象是個(gè)殘疾皇子，可洞房花燭夜當(dāng)晚...
茶點(diǎn)故事閱讀 48,436評(píng)論 2贊 378

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

Flume日志收集方案設(shè)計(jì)和測(cè)試

1 背景

2 目標(biāo)

3 方案設(shè)計(jì)

3.1 架構(gòu)設(shè)計(jì)

3.1.1 Agent

3.1.1.1 Source

3.1.1.2 Channel

3.1.1.3 Sink

3.1.2 Collector Node

3.1.2.1 Source

3.1.2.2 Channel

3.1.2.3 Sink

3.2 穩(wěn)定性擴(kuò)展方案

3.3 備用方案

4 性能測(cè)試

4.1 服務(wù)器列表

4.1.1 flume agent

4.1.2 zk+kafka

4.2 用例信息

4.2.1 flume測(cè)試配置

4.3 測(cè)試方案

4.4 測(cè)試結(jié)論

4.4.1 Flume Aget測(cè)試

4.4.1.1 Source -> Channel

4.4.1.2 Channel -> Sink

4.4.1.3 Flume JVM

4.4.2 Flume Collector Node 測(cè)試

4.4.2.1 Source -> Channel

4.4.2.2 hdfs性能

4.5 測(cè)試總結(jié)

5 消息格式驗(yàn)證

6 監(jiān)控方案（待定）

6.1 JMX Reporting

6.2 JSON Reporting

6.3 Ganglia Reporting

6.4 Custom Reporting

7 注意事項(xiàng)

8 附錄

8.1 FLume Agent配置

8.2 Flume metris

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频