日誌分析（二）jvm agent+kafka+es +kibana 的OLAP日誌分析系統

jvm agent+kafka+es +kibana

    通常web業務的場景都包含了分佈式，web事務的多應用間跳轉，各層次間實現負載均衡等。日誌分析OLAP的技術要求就須要跟蹤誇web應用的多層次、多應用的鏈式請求，針對多應用。若是採用離線收集數據，又須要針對每一個應用啓動對應的日誌收集實例好比 logstash的shipper或者flume 的agent等，頗爲浪費；若是各個應用的日誌格式或者日誌路徑不統1、樣式複雜等，就須要針對性的去配置對應收集端的一些filter和採集路徑。

     針對以上弊端，因此設計上採用各個應用日誌採集採用主動push而非OLAP系統去pull。這樣弊端應該是日誌採集和主題業務的進程綁定，這個須要代碼進行規避對主業務的影響。優勢就是在日誌格式上能夠獲得統1、減小io次數、避免數據聚合或者預預算次數等從而效率更優。熱日誌推送的概念，還須要下降對代碼的侵入性以及日誌埋點的可控。

    綜上，須要針對全部web業務應用作一個字節碼的嵌入，實現指定埋點的日誌收集工做。實現該操做目前有兩種方式：動態編譯 和 動態生成二進制字節碼。動態編譯是指在運行期前、類裝載後，進行class讀取後改造，並加載到classloader。有許多實現方式好比ASM、javassist、cglib等。

     這幾個的博客不少，都是比較成型的技術，各類利弊也就是asm 須要彙編語言，可是更爲靈活，速度更快；cglib 在asm上進行了封裝，效率比jdk自帶的代理反射快了不少。具體對比看下：

        http://stackoverflow.com/questions/2261947/are-there-alternatives-to-cglib

    這部分選擇了api簡易的動態編譯Jboss開源javassist包。實現原理是在jvm的運行期前，類加載器後，進行class的修改。邏輯相似dubbo的wrapper實現~~        

    

    源：http://jboss-javassist.github.io/javassist/

    在類加載器時期，進行class的選擇性動態編譯，動態添加實現其輸出日誌的代碼邏輯。

    傳輸日誌，使用了kafka 消息中間件，kafka的異步批量傳輸效率很是高並且比較穩定。kafka介紹如今較多：

        http://kafka.apache.org/documentation.html

        http://blog.csdn.net/lizhitao/article/details/39499283

        https://github.com/abhioncbr/Kafka-Message-Server

    kafka直接寫入es。即kafka的producer是由javassist 的agent進行動態編譯添加到全部應用中，而後consumer轉寫入es進行存儲，創建實時索引。

    

        elasticsearch-river-kafka實現源碼：

        https://github.com/xiaolongc/elasticsearch-river-kafka

        

      日誌分析olap系統，業務性能損耗和成本支出，可根據第一個博客裏面提到的兩種日誌源分：冷日誌文件處理，這種系統損耗在於日誌的io輸出到文件的過程會損耗業務代碼的響應效率，大多系統在線上會省去部分日誌代碼節約響應時間和物理空間，若是有對應日誌收集，就要有對輸出的文件再次轉化爲io流，進行過濾、聚合等應用成本；熱日誌數據傳輸，這種數據損耗發生在日誌的傳輸過程，由於這種對於日誌的發送和正常業務調度是同步的，這部分損耗若是對異常、日誌傳輸等進行優化，效率應該優於第一種，還有就是應用成本會下降。

 

    綜上，jvm agent+kafka+es +kibana 的OLAP日誌分析系統有如下優勢：成本較低、效率高、入侵性較低、可複用性強等。目前已經完成web事務traceid的方法級調用鏈跟蹤、業務埋點的統計、應用異常的抓取等功能。後續會繼續跟進。

 

 

------

補：Google的Dapper，淘寶的鷹眼，Twitter的ZipKin，京東商城的Hydra，eBay的Centralized Activity Logging (CAL)，大衆點評網的CAT~~~ 相同功能的架構體系。