在上家公司工作時，設(shè)計的日志收集與實時分析架構(gòu)，還是比較簡單的:

創(chuàng)新互聯(lián)建站企業(yè)建站,十年網(wǎng)站建設(shè)經(jīng)驗，專注于網(wǎng)站建設(shè)技術(shù)，精于網(wǎng)頁設(shè)計，有多年建站和網(wǎng)站代運(yùn)營經(jīng)驗，設(shè)計師為客戶打造網(wǎng)絡(luò)企業(yè)風(fēng)格，提供周到的建站售前咨詢和貼心的售后服務(wù)。對于網(wǎng)站設(shè)計制作、成都網(wǎng)站制作中不同領(lǐng)域進(jìn)行深入了解和探索，創(chuàng)新互聯(lián)在網(wǎng)站建設(shè)中充分了解客戶行業(yè)的需求，以靈動的思維在網(wǎng)頁中充分展現(xiàn)，通過對客戶行業(yè)精準(zhǔn)市場調(diào)研，為客戶提供的解決方案。

flume-ng + rocketmq + storm + redis + 前端展示

消息隊列部分，我們剛開始采用的是kafka，但 kafka在支持回溯消費和重復(fù)消費方面比較弱，同時在數(shù)據(jù)安全方面也相對弱一些，后來我們改為阿里的rocketmq。

考慮到我們的數(shù)據(jù)量也不是很大，已經(jīng)能夠足夠支撐，但在rocketmq這層，有時會因為網(wǎng)絡(luò)異常問題，會產(chǎn)生消息堆積，導(dǎo)致消息隊列被沖爆，穩(wěn)定性還不是非常高，后來咨詢了其他部門的同事，他們的做法是，在消息隊列這一層次，額外增加了一層MongoDB，消息隊列這層僅保留消息的索引信息，消息的實體信息保存在mongodb中，可以很好地回避此問題，后來由于各種原因就沒有再去嘗試此方法......

其他一些常用方案：

logstash + elasticsearch + kibana

fluentd + influxdb + grafana

flume-ng + kafka + storm

kafka + spark streaming + redis

網(wǎng)頁標(biāo)題：日志實時分析架構(gòu)
轉(zhuǎn)載來于：http://www.chinadenli.net/article46/ishgeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、網(wǎng)站維護(hù)、做網(wǎng)站、網(wǎng)站排名、響應(yīng)式網(wǎng)站、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)