自有贊成立以來，發展迅猛，業務增長很快，業務系統數量大，每天都會產生大量的系統日誌和業務日誌(據統計，平均每秒產生日誌1.1萬條，峰值1.5萬條，每天的日誌量約9億條，占用空間2.4t左右)。
在網際網路高速發展的今天，有那麼多優秀的日誌收集系統，諸如kafka、flume、scribe、chukwa、elk等。對於如何選型在此不做討論，而且本人才疏學淺，也未做深入調研和效能分析對比測試，還不夠資格討論。相信前人的選擇是有其理由的，接下來我們來看看秉著「短平快」的網際網路精神，構建的這套適合有讚業務系統的統一日誌平台。
廢話不多說，直接上總體架構圖，如圖2-1所示：
圖2-1 總體架構圖
有讚統一日誌系統，負責收集所有系統日誌和業務日誌，轉化為流式資料，通過flume或logstash上傳到日誌中心(kafka集群)，然後供track、storm、spark及其它系統實時分析處理日誌，並將日誌持久化儲存到hdfs供離線資料分析處理，或寫入elasticsearch提供資料查詢，或寫入hawk發起異常報警或提供指標監控查詢。
從上面總體架構圖中，我們可以看到整個日誌平台架構分為四層，從左到右依次是日誌接入層、日誌中心、日誌處理層、日誌儲存層。
日誌接入層主要有兩種方式，方式1基於rsyslog和logstash，方式2基於flume-ng。
圖3-1 日誌接入方式1
對於一些穩定的日誌，比如系統日誌或框架日誌(如nginx訪問日誌、phpfpm異常日誌等)，我們新增nginx配置，通過rsyslog寫到本地目錄local0，然後logstash根據其配置，會將local0中的增量日誌上傳到日誌中心對應的topic中，具體資料流圖見圖3-1所示：
3.1.2
flume ng是乙個分布式，高可用，可靠的系統，它能將不同的海量資料收集，移動並儲存到乙個資料儲存系統中。輕量，配置簡單，適用於各種日誌收集，並支援failover和負載均衡。並且它擁有非常豐富的元件。flume ng採用的是三層架構：agent層，collector層和store層，每一層均可水平拓展。其中agent包含source，channel和sink，三者組建了乙個agent。三者的職責如下所示：
source：用來消費（收集）資料來源到channel元件中，簡單說就是蒐集資料的入口。
channel：中轉臨時儲存，儲存所有source元件資訊，其實就是個訊息佇列，可配置多個chanel。
sink：從channel中讀取，讀取成功後會刪除channel中的資訊，簡單說就是蒐集資料的出口。
在有贊日誌平台中，我們只用了agent層。具體可以見圖3-2:
圖3-2 日誌接入方式2
日誌中心的kafka是根據topic訪問資料的，所以需要在日誌中加入topic欄位。為了統一，我們對日誌格式做了約定，格式如下:
細心的同學會發現，在圖3-2中，我們用了tracksink，這個是做什麼的呢？雖然flume自帶豐富的元件，也包括kafkasink，但是為什麼我們不用呢？考慮到自帶的kafkasink不能按我們需要的topic來分發資料，所以只能自定義實現了sink來達到寫不同topic日誌到不同日誌中心topic中去的目的。
另外，flume是通過supervisor啟動的，並且新增了監控報警，但是為了避免日誌寫失敗，在flume中，我們使用了failover策略，假如寫日誌中心失敗，則將日誌寫到本地，保證日誌不丟失。
美其名曰日誌中心，但實際上只是日誌中心快取，我們只儲存最近24小時的日誌，需要持久化的日誌都會刷入hdfs。至於為什麼選用kafka集群來構建日誌中心，理由主要如下:
1、分布式架構，可支援水平擴充套件。
2、高吞吐量，在普通的伺服器上每秒鐘也能處理幾十萬條訊息(遠高於我們的峰值1.5萬條/秒)。
3、訊息持久化，按topic分割槽儲存，支援可重複消費。
4、日誌系統不需要保證嚴格的訊息準確性。
5、資料在磁碟上的訪問代價為o(1)。
6、可根據broker配置定期刪除過期資料。
基於日誌中心，可做的事情有很多。只要我們對某topic日誌感興趣，那麼便可以將該topic日誌消費來滿足我們的業務需求。我們可以：
1、將日誌聚合，根據業務不同，建立不同的索引，存入elasticsearch提供查詢。
2、發現異常日誌時，發往監控中心，向對應的業務方發起報警，發現和預發問題的實時性提高了。
3、統計一些訪問日誌或呼叫日誌等指標資訊，發往監控中心來掌握相關呼叫趨勢。
4、呼叫鏈開始做起來了，系統效能瓶頸一目了然了。
5、使用者日誌行為可分析了。
突然接手如此規模的乙個基礎產品，遇到的問題還是比較多的:
1、業務日誌接入，每一次對接不僅需要開發日誌消費模組，解析相應日誌，建立相應的索引並寫入elasticsearch，還需要開發對應定製的查詢頁面。由於自己本身對系統不熟悉，另外文件缺失，以及每一次對接的都是「新人」，還時不時可能會遇到各種千奇百怪的問題，需要排查定位並解決問題。這塊急需解放，不然乙個人真的忙不過來，針對該問題，接下來會抽象出日誌消費和elasticsearch讀寫sdk，供業務接入方自己開發和維護。
2、對於各個元件(如logstash、flume、kafka、elasticsearch等)都未曾接觸過的情況下，短時間接手這麼乙個新產品，需要學習的東西很多，壓力還是很大的，但總算熬過來了。
3、缺失的開發測試環境，到寫此文章時總算搭建起來了。
4、elasticsearch記憶體占用高，以及索引的管理與維護，還在優化和考慮中。
5、需要開發更加人性化且更易擴充套件和維護的運控平台供使用方查詢日誌。
6、日誌收集到flume增加支援udp協議。
7、將儲存層的hdfs移到日誌中心，支援日誌同時寫入kafka集群和hdfs集群。
8、是時候做點日誌挖掘的事情了。
統一日誌處理
日誌是幹啥的.不多說.這裡只記錄怎麼配置日誌.logger 日誌記錄器.可以配置不同的日誌級別.不同的級別顯示的日誌資訊不同的.越往後的日誌級別會包含前面所有日誌級別顯示的資訊 off,fatal,error,warn,info,debug,all loggin.level.root warn這是 ...
統一日誌框架
常見的框架有log4j log4j2 logback 如果乙個專案中整合元件有單獨的框架那麼日誌配置就很混亂 log4j log4j2是沒有實現slf4j門面的 logback是實現的 就是我們獲取logger的包 是從slf4j獲取的 將我們自己的日誌框架通過slf4j實現 如果是log4j通過s...
springboot靜態資源處理，統一日誌攔截
靜態資源 對於一些小型的系統，如果要使得專案結構視覺化可讀性比較好，頁面的靜態資源管理，路徑的管理等都需要有一定規範。我們先看看路徑包含哪些 1.jar包內的本地路徑，也即伺服器容器路徑 2.http的url路徑，即網路請求路徑 3.靜態資源儲存路徑 通過url請求，css等檔案路徑 我們來看看sp...