背景介紹

公司業(yè)務(wù)系統(tǒng)做優(yōu)化改造，同時(shí)為了能夠?qū)崿F(xiàn)全鏈路監(jiān)控，需收集所有業(yè)務(wù)系統(tǒng)之間的調(diào)用日志。

數(shù)據(jù)情況:每天20億+

機(jī)器成本:3臺(tái)kafka集群，2臺(tái)logstash采集機(jī)器

技術(shù):JAVA,MQ,MLSQL,Logstash

下圖為最終結(jié)果圖

實(shí)戰(zhàn)：如何實(shí)時(shí)采集上億級(jí)別數(shù)據(jù)？

采集流程

流程分解

流程一：MLSQL 消費(fèi)MQ

原始日志產(chǎn)生側(cè)通過protobuf進(jìn)行序列化推送至mq,然后通過MLSQL進(jìn)行反序列化并進(jìn)行簡(jiǎn)單的etl處理后，再推送至MQ

流程二：通過Logstash進(jìn)行消費(fèi)MQ

通過logstash消費(fèi)經(jīng)過MLSQL處理后的數(shù)據(jù)，并在這里通過ruby進(jìn)行再次的加工處理，最后寫入es和hdfs

注意：這里一部分流程推送到es是業(yè)務(wù)側(cè)使用，而另一部分寫入hdfs是提供給數(shù)倉(cāng)使用

流程三: 數(shù)倉(cāng)建模

這里通過數(shù)倉(cāng)建模，將最后的指標(biāo)結(jié)果推送至es提供給業(yè)務(wù)側(cè)使用

注意：本篇主要是借鑒這個(gè)需求講解Logstash在實(shí)際場(chǎng)景中的使用以及優(yōu)化，其他兩個(gè)部分流程不做詳細(xì)講解

為什么這樣設(shè)計(jì)？

原因一：

首先這個(gè)需求屬于日志采集的范疇，但Logstash本身不支持反序列化功能，需要自定義開發(fā)ruby插件來支持，但這樣一來開發(fā)成本較高，且不好維護(hù)，所以使用了MLSQL結(jié)合UDF的方式進(jìn)行流式處理

原因二：

大家在對(duì)最后的輸出流程可能會(huì)有疑惑，為什么不直接通過MLSQL來寫入到hdfs和es呢，這里有兩點(diǎn)：

1.MLSQL寫入hdfs會(huì)產(chǎn)生大量的小文件，需要單獨(dú)開發(fā)合并文件的功能

2.最后寫入es的數(shù)據(jù)是需要數(shù)倉(cāng)結(jié)合其他業(yè)務(wù)數(shù)據(jù)進(jìn)行建模的，而MLSQL在這點(diǎn)做的不太好，所以這里走的是離線處理的方式

說到這里，具體的場(chǎng)景需要結(jié)合公司的實(shí)際情況來進(jìn)行決策的，有些同學(xué)或許會(huì)想為什么不用flume進(jìn)行日志采集呢？那這里就不做過多的解釋了，白菜蘿卜各有所愛，適合自己的才是最好的！廢話不多說，接下來進(jìn)入正題，結(jié)合該需求場(chǎng)景，如何使用較少的成本完成大數(shù)據(jù)量的采集呢？以及如何優(yōu)化呢？

Logstash開發(fā)流程

1.確定日志格式

首先呢，一個(gè)日志文件里肯定是不止一種日志格式，也有可能是標(biāo)準(zhǔn)化的格式，這里需要跟日志產(chǎn)生側(cè)進(jìn)行確認(rèn)格式

2.調(diào)試grok

確定好日志格式后，編寫grok語(yǔ)法，然后進(jìn)行調(diào)試，本人是通過kibana6自帶的grok debug進(jìn)行調(diào)試。結(jié)合該需求背景，最后經(jīng)過logstash采集的時(shí)候，其實(shí)已經(jīng)通過MLSQL進(jìn)行了處理，最后Logstash消費(fèi)的是格式就是一個(gè)json字符串，所以不需要grok語(yǔ)法，但是這里還是簡(jiǎn)單舉個(gè)例子來說明一下