本發(fā)明實施例涉及互聯(lián)網(wǎng)的技術(shù)領(lǐng)域，尤其涉及一種日志管理系統(tǒng)、方法及裝置。

背景技術(shù)：

過去十年來，隨著分布式系統(tǒng)的發(fā)展，日志數(shù)據(jù)管理起來更加復(fù)雜。如今，系統(tǒng)中可以容納數(shù)以千計的服務(wù)器實例或者微服務(wù)容器，而所有這些實例或容器又會生成自己的日志數(shù)據(jù)。隨著以云為基礎(chǔ)的系統(tǒng)快速出現(xiàn)并占據(jù)主導(dǎo)地位，由機器所生成的日志數(shù)據(jù)呈爆炸性增長。

目前傳統(tǒng)的收集日志方法，在后端生成日志后，通過scp命令上傳、下載或通過rsync命令定時同步等方式收集匯總，然后通過機器腳本分析、或者人工觀察統(tǒng)計、或者圖形繪制等方式來分析，這種方法的實時性較差。而日志管理隨之成為現(xiàn)代化IT運營中的重要任務(wù)，為包括調(diào)試、生產(chǎn)監(jiān)控、性能監(jiān)控、支持援助與故障查找之類的許多用例提供輔助支撐。處理這些日志需要特定的日志管理解決方案，一般而言，日志管理解決方案需要解決以下特征：

(1)低耦合：構(gòu)建應(yīng)用系統(tǒng)和分析系統(tǒng)的橋梁，并將它們之間的關(guān)聯(lián)解耦；

(2)高吞吐：支持高吞吐、低延遲、近實時數(shù)據(jù)持久化操作和大量小文件的存儲；

(3)具有高可擴展性：即：當系統(tǒng)操作量增加時，可以通過增加節(jié)點進行水平擴展；

(4)具有高可用：當節(jié)點出現(xiàn)故障時，日志能夠被傳送到其他節(jié)點上而不會丟失。

技術(shù)實現(xiàn)要素：

本發(fā)明實施例的目的在于提出一種日志管理系統(tǒng)、方法及裝置，旨在解決如何快速、準確地收集用戶行為日志，并快速、準確地獲取與關(guān)注用戶行為相關(guān)的信息。

為達此目的，本發(fā)明實施例采用以下技術(shù)方案：

第一方面，一種日志管理系統(tǒng)，所述系統(tǒng)包括：Kafka、Flume和Jstorm；

所述K afka，用于根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；

所述Flume，用于從所述Topic中讀取日志數(shù)據(jù)，讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作；

所述Jstorm，用于從所述Topic中讀取日志數(shù)據(jù)，讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作。

第二方面，一種日志管理方法，所述方法包括：

Kafka根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；

Flume和Jstorm從所述Topic中讀取日志數(shù)據(jù)；

所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作；

優(yōu)選地，所述根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，包括：

根據(jù)不同的業(yè)務(wù)定義日志格式，并在所述Kafka中定義不同的Topic，所述Topic用于收發(fā)日志；

根據(jù)業(yè)務(wù)需要定義所述Hbase表，所述Hbase表用于避免造成熱點寫\讀。

優(yōu)選地，所述Flume讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作，包括：

從所述Flume中讀取所述日志數(shù)據(jù)并傳輸?shù)紿base表中，未做ETL的數(shù)據(jù)需數(shù)據(jù)持久化操作到HDFS中。

優(yōu)選地，所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作，包括：

所述JStorm從所述KafkaCluster中獲取所述日志數(shù)據(jù)并通過預(yù)設(shè)算法計算后將復(fù)雜業(yè)務(wù)邏輯數(shù)據(jù)持久化操作到RDBMS中；

從所述Jstorm中分析的日志數(shù)據(jù)持久化操作到所述RDBMS中后，由Sqoop組件進行所述HDFS的數(shù)據(jù)持久化操作。

優(yōu)選地，所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作之后，包括：

采用MapReduce進行分析提取數(shù)據(jù)持久化操作后的數(shù)據(jù)；

若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量小于預(yù)設(shè)第一數(shù)據(jù)量閾值，則采用Sqoop重新提交到RDBMS中；

若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量大于預(yù)設(shè)第二數(shù)據(jù)閾值，則采用Solr、ES全文數(shù)據(jù)庫做查詢支撐。

第三方面，一種日志管理裝置，所述裝置包括：

定義模塊，用于根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表；

發(fā)送模塊，用于根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；

讀取模塊，用于從所述Topic中讀取日志數(shù)據(jù)；

第一處理模塊，用于讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作；

優(yōu)選地，所述定義模塊，具體用于：根據(jù)不同的業(yè)務(wù)定義日志格式，并在所述Kafka中定義不同的Topic，所述Topic用于收發(fā)日志；

根據(jù)業(yè)務(wù)需要定義所述Hbase表，所述Hbase表用于避免造成熱點寫\讀。

優(yōu)選地，所述第一處理模塊，具體用于：

從Flume中讀取所述日志數(shù)據(jù)并傳輸?shù)紿base表中，未做ETL的數(shù)據(jù)需數(shù)據(jù)持久化操作到HDFS中；

所述第一處理模塊，還具體用于：

從所述KafkaCluster中獲取所述日志數(shù)據(jù)并通過預(yù)設(shè)算法計算后將復(fù)雜業(yè)務(wù)邏輯數(shù)據(jù)持久化操作到RDBMS中；從Jstorm中分析的日志數(shù)據(jù)持久化操作到所述RDBMS中后，由Sqoop組件進行所述HDFS的數(shù)據(jù)持久化操作。

優(yōu)選地，所述裝置還包括：

第二處理模塊，用于在所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作之后，采用MapReduce進行分析提取數(shù)據(jù)持久化操作后的數(shù)據(jù)；若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量小于預(yù)設(shè)第一數(shù)據(jù)量閾值，則采用Sqoop重新提交到RDBMS中；若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量大于預(yù)設(shè)第二數(shù)據(jù)閾值，則采用Solr、ES全文數(shù)據(jù)庫做查詢支撐。

本發(fā)明實施例提供一種日志管理方法、裝置及系統(tǒng)，Kafka根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；Flume和Jstorm從所述Topic中讀取日志數(shù)據(jù)；所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作。本發(fā)明采用了Kafka這一高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)與Flume海量日志采集、聚合和傳輸?shù)南到y(tǒng)；當系統(tǒng)操作量增加時，可以通過增加節(jié)點進行水平擴展；采用的所有組件都采用了Master/Slave模式保證了當有個別節(jié)點宕機的情況下不會影響業(yè)務(wù)的正常運行，并且Flume與Kafka都有Wal機制，保證日志不會丟失。

附圖說明

圖1是本發(fā)明實施例提供的一種日志管理系統(tǒng)的結(jié)構(gòu)示意圖；

圖2是本發(fā)明實施例提供的另一種日志管理系統(tǒng)的結(jié)構(gòu)示意圖；

圖3是本發(fā)明實施例提供的一種日志管理方法的流程示意圖；

圖4是本發(fā)明實施例提供的另一種日志管理方法的流程示意圖；

圖5是本發(fā)明實施例提供的一種日志管理裝置的功能模塊示意圖。

具體實施方式

下面結(jié)合附圖和實施例對本發(fā)明實施例作進一步的詳細說明?？梢岳斫獾氖?，此處所描述的具體實施例僅僅用于解釋本發(fā)明實施例，而非對本發(fā)明實施例的限定。另外還需要說明的是，為了便于描述，附圖中僅示出了與本發(fā)明實施例相關(guān)的部分而非全部結(jié)構(gòu)。

參考圖1，圖1是本發(fā)明實施例提供的一種日志管理系統(tǒng)的結(jié)構(gòu)示意圖。

如圖1所示，所述日志管理系統(tǒng)包括：Kafka、Flume和Jstorm；

Kafka，用于根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster(Apache Kafka Cluster)的Topic中；

Flume，用于從所述Topic中讀取日志數(shù)據(jù)，讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作；

Jstorm，用于從所述Topic中讀取日志數(shù)據(jù)，讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作。

本發(fā)明實施例提供一種日志管理系統(tǒng)，所述Kafka，用于根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；所述Flume，用于從所述Topic中讀取日志數(shù)據(jù)，讀取所述日志數(shù)據(jù)并進行Hadoop分布式文件系統(tǒng)(Hadoop Distributed file system，HDFS)的數(shù)據(jù)持久化操作；所述Jstorm，用于從所述Topic中讀取日志數(shù)據(jù)，讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作。本發(fā)明采用了Kafka這一高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)與Flume海量日志采集、聚合和傳輸?shù)南到y(tǒng)；當系統(tǒng)操作量增加時，可以通過增加節(jié)點進行水平擴展；采用的所有組件都采用了Master/Slave模式保證了當有個別節(jié)點宕機的情況下不會影響業(yè)務(wù)的正常運行，并且Flume與Kafka都有預(yù)寫日志(Write-Ahead Logging，WAL)機制，保證日志不會丟失。

參考圖2，圖2是本發(fā)明實施例提供的另一種日志管理系統(tǒng)的結(jié)構(gòu)示意圖。

如圖2所示，所述日志管理系統(tǒng)包括：Kafka、Flume、Jstorm、HBASE、關(guān)系數(shù)據(jù)庫管理系統(tǒng)(Relational Database Management System，RDBMS)、Sqoop、HDFS以及Zookeeper；

低耦合：該解決方案采用組件化的設(shè)計思想,由于采用的組件都為Apache、Cloudera等國際上知名開源機構(gòu)。在業(yè)務(wù)系統(tǒng)與分析系統(tǒng)的整合上起到了解耦的作用。

高吞吐：因本發(fā)明采用了Kafka這一高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)與Flume海量日志采集、聚合和傳輸?shù)南到y(tǒng)。這兩大系統(tǒng)都為現(xiàn)今業(yè)界公認的高吞吐系統(tǒng)，這樣保證了不管是業(yè)務(wù)系統(tǒng)日志還是RPC服務(wù)日志在吞吐量上沒有了后顧之憂。

具有高可擴展性：即當系統(tǒng)操作量增加時，可以通過增加節(jié)點進行水平擴展：不管是如何優(yōu)秀的解決方案都有在設(shè)計之初考慮不足的地方，本發(fā)明為了保證系統(tǒng)的高擴展性，不管是業(yè)務(wù)方面還是性能方面的，都將與之考慮進來，在設(shè)計之初，考慮使用Flume與JStorm的原因不僅僅是為了高吞吐一點才采用這兩種日志分析系統(tǒng)，如果系統(tǒng)吞吐量達到瓶頸時，那么僅僅需要擴展Flume與JStorm節(jié)點即可，如果當后期因業(yè)務(wù)的新增或改變，也可以通過增加不同的agent或者Topology來實現(xiàn)業(yè)務(wù)上的擴展性。而考慮到業(yè)務(wù)上存在復(fù)雜關(guān)系，本發(fā)明采用了Sql與Nosql兩種存儲方式來滿足不同的查詢業(yè)務(wù)。

具有高可用：本發(fā)明采用的所有組件都采用了Master/Slave模式保證了當有個別節(jié)點宕機的情況下不會影響業(yè)務(wù)的正常運行，并且Flume與Kafka都有Wal機制，保證日志不會丟失。

參考圖3，圖3是本發(fā)明實施例提供的一種日志管理方法的流程示意圖。

如圖3所示，所述日志管理方法包括：

步驟301，Kafka根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；

具體的，依照本方案進行相關(guān)的組件安裝

(Zookeeper-Hadoop-Hbase-Kafka-JStorm-Oracle、Mysql、-Sqoop)按照上述順序安裝。

優(yōu)選地，所述根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，包括：

根據(jù)不同的業(yè)務(wù)定義日志格式，并在所述Kafka中定義不同的Topic，所述Topic用于收發(fā)日志；

根據(jù)業(yè)務(wù)需要定義所述Hbase表，所述Hbase表用于避免造成熱點寫\讀。

步驟302，F(xiàn)lume和Jstorm從所述Topic中讀取日志數(shù)據(jù)；

步驟303，所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作。

優(yōu)選地，所述Flume讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作，包括：

從所述Flume中讀取所述日志數(shù)據(jù)并傳輸?shù)紿base表中，未做ETL的數(shù)據(jù)需數(shù)據(jù)持久化操作到HDFS中。

優(yōu)選地，所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作，包括：

所述JStorm從所述KafkaCluster中獲取所述日志數(shù)據(jù)并通過預(yù)設(shè)算法計算后將復(fù)雜業(yè)務(wù)邏輯數(shù)據(jù)持久化操作到RDBMS中；

從所述Jstorm中分析的日志數(shù)據(jù)持久化操作到所述RDBMS中后，由Sqoop組件進行所述HDFS的數(shù)據(jù)持久化操作。

本發(fā)明實施例提供一種日志管理方法，Kafka根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；Flume和Jstorm從所述Topic中讀取日志數(shù)據(jù)；所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作。本發(fā)明采用了Kafka這一高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)與Flume海量日志采集、聚合和傳輸?shù)南到y(tǒng)；當系統(tǒng)操作量增加時，可以通過增加節(jié)點進行水平擴展；采用的所有組件都采用了Master/Slave模式保證了當有個別節(jié)點宕機的情況下不會影響業(yè)務(wù)的正常運行，并且Flume與Kafka都有Wal機制，保證日志不會丟失。

參考圖4，圖4是本發(fā)明實施例提供的另一種日志管理方法的流程示意圖。

如圖4所示，所述日志管理方法包括：

步驟401，Kafka根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；

步驟402，F(xiàn)lume和Jstorm從所述Topic中讀取日志數(shù)據(jù)；

步驟403，所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作；

步驟404，采用MapReduce(映射/歸納)進行分析提取數(shù)據(jù)持久化操作后的數(shù)據(jù)；若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量小于預(yù)設(shè)第一數(shù)據(jù)量閾值，則采用Sqoop重新提交到RDBMS中；若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量大于預(yù)設(shè)第二數(shù)據(jù)閾值，則采用Solr、ES全文數(shù)據(jù)庫做查詢支撐。

參考圖5，圖5是本發(fā)明實施例提供的一種日志管理裝置的功能模塊示意圖。

如圖5所示，所述裝置包括：

定義模塊501，用于根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表；

發(fā)送模塊502，用于根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；

讀取模塊503，用于從所述Topic中讀取日志數(shù)據(jù)；

第一處理模塊504，用于讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作；

優(yōu)選地，所述定義模塊501，具體用于：根據(jù)不同的業(yè)務(wù)定義日志格式，并在所述Kafka中定義不同的Topic，所述Topic用于收發(fā)日志；

根據(jù)業(yè)務(wù)需要定義所述Hbase表，所述Hbase表用于避免造成熱點寫\讀。

優(yōu)選地，所述第一處理模塊504，具體用于：

從Flume中讀取所述日志數(shù)據(jù)并傳輸?shù)紿base表中，未做抽取-轉(zhuǎn)換-加載(Extract-Transform-Load，ETL)的數(shù)據(jù)需數(shù)據(jù)持久化操作到HDFS中；

所述第一處理模塊504，還具體用于：

從所述KafkaCluster中獲取所述日志數(shù)據(jù)并通過預(yù)設(shè)算法計算后將復(fù)雜業(yè)務(wù)邏輯數(shù)據(jù)持久化操作到RDBMS中；從Jstorm中分析的日志數(shù)據(jù)持久化操作到所述RDBMS中后，由Sqoop組件進行所述HDFS的數(shù)據(jù)持久化操作。

優(yōu)選地，所述裝置還包括：

第二處理模塊，用于在所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作之后，采用MapReduce進行分析提取數(shù)據(jù)持久化操作后的數(shù)據(jù)；若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量小于預(yù)設(shè)第一數(shù)據(jù)量閾值，則采用Sqoop重新提交到RDBMS中；若所述數(shù)據(jù)持久化操作后的數(shù)據(jù)量大于預(yù)設(shè)第二數(shù)據(jù)閾值，則采用Solr、ES(Elasticsearch)全文數(shù)據(jù)庫做查詢支撐。

本發(fā)明實施例提供一種日志管理裝置，Kafka根據(jù)不同的業(yè)務(wù)定義日志格式和Hbase表，并根據(jù)所述日志格式將日志數(shù)據(jù)發(fā)送到KafkaCluster的Topic中；Flume和Jstorm從所述Topic中讀取日志數(shù)據(jù)；所述Flume和所述Jstorm讀取所述日志數(shù)據(jù)并進行HDFS的數(shù)據(jù)持久化操作。本發(fā)明采用了Kafka這一高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)與Flume海量日志采集、聚合和傳輸?shù)南到y(tǒng)；當系統(tǒng)操作量增加時，可以通過增加節(jié)點進行水平擴展；采用的所有組件都采用了Master/Slave模式保證了當有個別節(jié)點宕機的情況下不會影響業(yè)務(wù)的正常運行，并且Flume與Kafka都有Wal機制，保證日志不會丟失。

以上結(jié)合具體實施例描述了本發(fā)明實施例的技術(shù)原理。這些描述只是為了解釋本發(fā)明實施例的原理，而不能以任何方式解釋為對本發(fā)明實施例保護范圍的限制。基于此處的解釋，本領(lǐng)域的技術(shù)人員不需要付出創(chuàng)造性的勞動即可聯(lián)想到本發(fā)明實施例的其它具體實施方式，這些方式都將落入本發(fā)明實施例的保護范圍之內(nèi)。