本發(fā)明涉及日志管理服務技術領域，尤其涉及一種日志服務器及其管理方法。

背景技術：

在通信和計算機信息處理相關產品中，系統(tǒng)運行過程中記錄的日志對于用戶系統(tǒng)故障、及早發(fā)現(xiàn)警告和跟蹤關鍵操作有著重要作用。現(xiàn)有技術中基于activeMQ實現(xiàn)的日志管理系統(tǒng)是基于JMS(Java Message Service)實現(xiàn)的。通過Log4j控制日志信息輸送的目的地、每一條日志的輸出格式等對日志的生成過程進行控制，進一步的將服務器的日志信息寫入隊列。日志管理系統(tǒng)可能對應管理多個應用服務器產生的日志消息，例如：Web服務器有兩臺，每臺服務器上分別有4個tomcat，通過Log4j輸出到tomcat下。當輸出至tomcat的日志過大(超過2g)時就會影響到tomcat的正常運行，也不利于開發(fā)人員查看日志，分析問題。傳統(tǒng)的消息系統(tǒng)具有下述缺陷：

1.日志文件在被消費以后立即被刪除，需要頻繁的對磁盤進行操作，增加了磁盤的IO開銷；

2.無法將消息持久化到磁盤；

3.集中式的日志處理系統(tǒng)，不易于向外擴展；

4.不支持多訂閱者，當消費失敗時無法自動平衡消費者；

5.JMS系統(tǒng)所需的消息頭較大，再加上維護各種索引結構的開銷，導致ActiveMQ的每條消息有144個字節(jié)。導致ActiveMQ一個最忙的線程大部分時間都在存取B-Tree以維護消息元數(shù)據(jù)和狀態(tài)。

6.當客戶端多個端口同時訪問一個端口時會有并發(fā)的沖突產生。

授權公告號CN 102158349 B，授權公告日2016年3月30日的發(fā)明專利公開了一種日志管理裝置及方法。該裝置包括日志記錄模塊，用于將日志原文，根據(jù)轉換規(guī)則轉換為日志記錄，調用日志管理模塊；根據(jù)日志管理模塊湖區(qū)的日志記錄寫入地址，將日志記錄寫入存儲介質；日志管理模塊，用于根據(jù)存儲介質保存的日志全局信息以及日志記錄的地址范圍，獲取日志記錄寫入地址，返回給日志記錄模塊。同時還公開了一種日志管理的方法，采用該發(fā)明所述的裝置及方法，能夠提高存儲介質保存日志的容量，以及讀寫日志的處理速度，且避免重要日志丟失。但是，其無法實現(xiàn)分布式的處理系統(tǒng)，擴展性不高。

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

為解決現(xiàn)有技術存在的上述問題，本發(fā)明公開了一種日志服務器及其管理方法。

本發(fā)明采取如下技術方案：

一種日志服務器，包括消息訂閱發(fā)布模塊和轉換系統(tǒng)，所述消息訂閱發(fā)布模塊接收、存儲、管理來自應用服務器的第一日志文件，所述轉換系統(tǒng)將存儲在所述消息訂閱發(fā)布模塊中的第一日志文件轉換為第二日志文件；所述消息訂閱發(fā)布模塊包括與所述應用服務器一一對應的會話隊列；所述會話隊列包括與其對應的應用服務器的第一日志文件一一對應的會話區(qū)。

作為優(yōu)選，所述會話區(qū)包括用于存儲所述第一日志文件的第一存儲單元以及用于存儲所述第一存儲單元的索引文件的第二存儲單元，所述第一日志文件順序存儲在所述第一存儲單元中，所述索引文件用于索引存儲在所述第一存儲單元中的第一日志文件數(shù)據(jù)。

作為優(yōu)選，所述轉換系統(tǒng)包括多個數(shù)據(jù)轉換單元，所述日志數(shù)據(jù)轉換單元從所述消息訂閱發(fā)布模塊獲取的二進制的所述第一日志文件轉換為文本形式的第二日志文件并輸出至目標目錄。

作為優(yōu)選，所述轉換系統(tǒng)定期轉換存儲在所述會話隊列中的第一日志文件。

作為優(yōu)選，所述轉換系統(tǒng)包括與所述會話隊列一一對應的轉換單元，所述轉換單元定期將與其對應的會話隊列中的第一日志文件轉換為第二日志文件，并輸出至目標目錄。

作為優(yōu)選，存儲在所述會話隊列中的第一日志文件，在超過預設的存儲期限以后被刪除。

作為優(yōu)選，所述轉換系統(tǒng)包括日志刪除單元，所述日志刪除單元定期判斷存儲在所述會話隊列中的第一日志文件是否已超過預設的存儲期限，并且將超過存儲期限的第一日志文件從所述會話隊列中刪除。

本發(fā)明還提供了一種日志服務器的管理方法，其特征在于包括步驟：

步驟S1：消息訂閱發(fā)布模塊接收來自應用服務器的第一日志文件，并將其存儲至與對應的會話隊列的會話區(qū)中；

步驟S2：轉換系統(tǒng)定期轉換存儲在所述會話隊列中的第一日志文件為對應的第二日志文件；

步驟S3：轉換系統(tǒng)定期判斷存儲在所述會話隊列中的第一日志文件是否已超過預設的存儲期限，并將超過預設的存儲期限的第一日志文件從所述會話隊列中刪除。

作為優(yōu)選，步驟S1中，所述消息訂閱發(fā)布模塊將所述第一日志文件順序存儲至所述會話區(qū)的第一存儲單元中，并更新所述第一存儲單元的索引文件；步驟S2中，所述轉換系統(tǒng)根據(jù)所述索引文件索引需要處理的第一日志文件。

作為優(yōu)選，步驟S2中，所述轉換系統(tǒng)通過與所述會話隊列一一對應的轉換單元分別將與其對應的會話隊列中的第一日志文件轉換成第二日志文件。

本發(fā)明提供的日志服務器及其管理方法與傳統(tǒng)的消息系統(tǒng)相比：它被設計為一個分布式系統(tǒng)，易于向外擴展；它同時為發(fā)布和訂閱提供高吞吐量；它支持多訂閱者，當失敗時能自動平衡消費者；它將消息持久化到磁盤，因此可用于批量消費，例如ETL，以及實時應用程序。

附圖說明

附圖1本發(fā)明實施例的日志服務器的應用系統(tǒng)圖。

附圖2本發(fā)明實施例的應用服務器和消息訂閱發(fā)布模塊之間的通訊示意圖。

附圖3本發(fā)明實施例的消息訂閱發(fā)布模塊和轉換系統(tǒng)之間的通訊示意圖。

具體實施方式

以下具體實施例僅僅是對本發(fā)明的解釋，其并不是對本發(fā)明的限制，本領域技術人員在閱讀完本說明書后可以根據(jù)需要對本實施例做出沒有創(chuàng)造性貢獻的修改，但只要在本發(fā)明的權利要求范圍內都受到專利法的保護。雖然附圖中顯示了本公開的示例性實施例，然而當然可以理解，可以以各種形式實現(xiàn)本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開并且能夠將本公開的范圍完整的傳達給本領域的技術人員。

實施例一

本發(fā)明目的是能實時的將web服務器產生的日志實時的傳送到日志服務器中，并按服務器tomcat端口和日期，文件的不同進行分類存儲，便于開發(fā)人員進行查看日志。

圖1為本實施例的一種日志服務器的系統(tǒng)架構圖，其包括kafka消息訂閱發(fā)布模塊和轉換系統(tǒng)。消息訂閱發(fā)布模塊接收、存儲、管理來自應用服務器的第一日志文件。轉換系統(tǒng)作為kafka的消費群組(consumer croup)，用于將存儲在消息訂閱發(fā)布模塊中的第一日志文件轉換為第二日志文件。

作為producer的應用服務器和kafka消息訂閱發(fā)布模塊之間的通訊關系如圖2。Web服務器A上有tomcat1(T1)，這里我們簡稱A-T1；Web服務器A上有tomcat2(T2)，這里我們簡稱A-T2；Web服務器A上有tomcat3(T3)，這里我們簡稱A-T3；Web服務器A上有tomcat4(T4)，這里我們簡稱A-T4；B上有tomcat1(T1)，這里我們簡稱B-T1；Web服務器B上有tomcat2(T2)，這里我們簡稱B-T2；Web服務器B上有tomcat3(T3)，這里我們簡稱B-T3；Web服務器B上有tomcat4(T4)，這里我們簡稱B-T4。

Kafka消息訂閱發(fā)布模塊具有分別與Web服務器A和Web服務器B上的tomcat一一對應的會話隊列topicAT1、topicAT2、topicAT3、topicAT4、topicBT1、topicBT2、topicBT3、topicBT4。會話隊列topicAT1與應用服務器A-T1對應，其進一步包括與應用服務器A-T1的catalina.log文件對應的會話區(qū)(partition1)、與應用服務器A-T1的feixun.log文件對應的會話區(qū)(partition2)、與應用服務器A-T1的feixun-hessian.log文件對應的會話區(qū)(partition3)；應用服務器A-T1里的catalina.log文件輸出到日志服務器topic0里的partition1，應用服務器A-T1里的feixun.log文件輸出到日志服務器里的partition2,A-T1里的feixun-hessian.log文件輸出到日志服務器里的partition3；

會話隊列topicAT2與應用服務器A-T2對應，其進一步包括與應用服務器A-T2的catalina.log文件對應的會話區(qū)(partition1)、與應用服務器A-T2的feixun.log文件對應的會話區(qū)(partition2)、與應用服務器A-T2的feixun-hessian.log文件對應的會話區(qū)(partition3)；應用服務器A-T2里的catalina.log文件輸出到日志服務器topic0里的partition1，應用服務器A-T2里的feixun.log文件輸出到日志服務器里的partition2,A-T2里的feixun-hessian.log文件輸出到日志服務器里的partition3；依此類推。

Kafka消息訂閱發(fā)布模塊的topic在邏輯上可以被認為是一個queue，每條消費(即第一日志文件數(shù)據(jù))都必須指定它的topic。為了使得Kafka的吞吐率可以線性提高，物理上把Topic分成一個或多個會話區(qū)(partition)，每個partition在物理上對應一個文件夾，該文件夾下存儲與這個Partition對應的日志文件和索引文件。第一日志文件順序存儲在第一存儲單元中，每個第一日志文件都是一個log entrie序列，每個log entrie包含一個4字節(jié)整型數(shù)值(值為N+5)，1個字節(jié)的"magic value"，4個字節(jié)的CRC校驗碼，其后跟N個字節(jié)的消息體。每條第一日志數(shù)據(jù)的消息都有一個當前partition下唯一的64字節(jié)的offset，它指明了這條消息的起始位置。磁盤上存儲的消息格式如下：

message length：4bytes(value:1+4+n)

"magic"value：1byte

crc：4bytes

payload：n bytes

這個log entries并非由一個文件構成，而是分成多個segment，每個segment以該segment第一條消息的offset命名并以“.kafka”為后綴。另外會有一個索引文件，它標明了每個segment下包含的log entry的offset范圍。索引文件用于索引存儲在第一存儲單元中的第一日志文件數(shù)據(jù)。

若創(chuàng)建topic1和topic2兩個topic，且分別有13個和19個分區(qū)，則整個集群上會相應會生成共32個文件夾。

Kafka消息訂閱發(fā)布模塊與轉換系統(tǒng)之間的關系如圖3：

由于topic中的第一日志文件是二進制的，需要經(jīng)過轉換系統(tǒng)經(jīng)過轉換消費變成可讀的文本形式的第二日志文件，并輸出至相應的目標目錄中。

Kafka是基于socket編程的，非阻塞的nio方法接收socket的連接，采用了Reactor的模式，所以不會出現(xiàn)客戶端多個端口同時訪問kafka一個端口并發(fā)的問題產生。因為Kafka中會話隊列(topic)可以隨著生產端(producer，即安裝在Web服務器上的應用服務器Tomcat)變化而變化，但是會話區(qū)(partition)的數(shù)目是通過kafka配置文件配置的，本實施例中tomcat數(shù)量可以是變化的，日志文件數(shù)目是不變的，為了方便以后的維護，topic根據(jù)tomcat來定，partition根據(jù)日志文件來定，具體制定以下方案：

首先，日志服務器端在linux下安裝kafka消息訂閱發(fā)布模塊，并修改kafka配置文件，設置端口號(本實施例中可設為9092)，設置partition數(shù)量(即分區(qū)數(shù)，本實施例中可設為3)，設置日志保存在消息訂閱發(fā)布模塊的時間(本實施例中可設為1天)。本實施例中的兩臺web服務器上8個tomcat應用服務器生產的日志全部輸出到日志服務器的消息訂閱發(fā)布模塊上，8個tomcat產生8個topic，topic的命名是按照topic–當前IP的后兩位格式命名。topic下分成3個partition，每個partition分別對應catalina文件，feixun.log文件，feixun-hessian.log文件(后期需要加文件，再添加)。比如2016-7-27，服務器A的tomcat1(IP是172.16.5.28，端口號：8082)產生對應topic為topic-5288082；2016-7-27，服務器A的tomcat2(IP是172.16.5.28，端口號：8083)產生對應topic為topic-5288083，依次類推，一天內產生8個topic，每個topic對應一個tomcat，topic里3個分區(qū)分別存儲有對應該tomcat下的第一日志文件。

topic產生后，第一日志文件已經(jīng)傳送到消息訂閱發(fā)布模塊上，這時需要實時的去轉換消費存儲在消息訂閱系統(tǒng)的會話隊列中的第一日志文件。在日志服務器上每天00點00分00秒跑一個定時任務，檢查保存的第一日志文件是否超過7天，超過7天刪除7天之前的第一日志文件。可以直接main方法實現(xiàn)，為了不影響實時性，定時任務里創(chuàng)建一個線程池，啟動8個消費線程去轉換8個topic，每個消費線程分別轉換topic里3個partition。將轉換完的文件輸出到目標目錄(本實施例中為/opt/mycar/logs)中，如圖3。

本實施例的日志管理器的管理方法，包括步驟：

步驟S1：消息訂閱發(fā)布模塊接收來自應用服務器的第一日志文件，并將其存儲至與對應的會話隊列的會話區(qū)中；消息訂閱發(fā)布模塊將第一日志文件順序存儲至會話區(qū)的第一存儲單元中，并更新第一存儲單元的索引文件；

步驟S2：轉換系統(tǒng)定期轉換存儲在會話隊列中的第一日志文件為對應的第二日志文件；轉換系統(tǒng)根據(jù)索引文件索引需要處理的第一日志文件。并且轉換系統(tǒng)通過與會話隊列一一對應的轉換單元分別將與其對應的會話隊列中的第一日志文件轉換成第二日志文件。

步驟S3：轉換系統(tǒng)定期判斷存儲在會話隊列中的第一日志文件是否已超過預設的存儲期限，并將超過預設的存儲期限的第一日志文件從會話隊列中刪除。

本日志管理系統(tǒng)的安裝應用方法為：

1)生產端(produer)

生產端也就是在web服務器端，需要在log4j配置文件里，配置kafka消息訂閱發(fā)布模塊相關信息。一方面log4j.properties需要加入kafka消息訂閱發(fā)布模塊；另一方面，由于kafka消息訂閱發(fā)布模塊在log4j上功能不完善，需要根據(jù)具體項目具體改kafka訂閱發(fā)布系統(tǒng)的kafka-log4j-appender-0.10.0.0.jar包以滿足項目的需求，比如本項目中topic需要按照文件和日期產生，將每臺tomcat輸出的第一日志文件到對應的partition上等。

具體改動包括：

1.log4j中增加partition配置，kafka-log4j-appender-0.10.0.0.jar包中KafkaLog4jAppender.java增加partition字段和set,get方法

2.KafkaLog4jAppender.java中修改setTopic方法，讀取當前機器Ip和tomcat的端口號，使topic按照topic–當前IP的后兩位格式發(fā)送。

3.KafkaLog4jAppender.java中修改append方法，當前tomcat向指定topic，partition中生產日志。

4.KafkaLog4jAppender.java中修改subAppend方法，將拋異常的日志也生產到broker上。

2)日志服務器端

配置文件config/server.properties在日志服務器上，需要根據(jù)項目做相應修改：

3)消費端

Topic產生后，文件已經(jīng)傳送到日志服務器上，這時需要實時的去轉換日志服務器上的文件。在日志服務器上每天00點00分00秒跑一個定時任務，檢查保存的存儲在會話區(qū)中的第一日志文件是否超過7天，超過7天刪除7天之前的第一日志文件。可以直接main方法實現(xiàn)，定時任務里創(chuàng)建一個線程池，為了不影響實時性，在線程池里啟動8個消費線程去轉換消費8個topic，每個消費線程分別轉換topic里3個patition中的第一日志文件。將轉換完的文件輸出到目標目錄(/opt/mycar/logs)中。