一、概述
日誌是記錄系統中各種問題資訊的關鍵，也是一種常見的海量資料。日誌平臺為集團所有業務系統提供日誌採集、消費、分析、儲存、索引和查詢的一站式日誌服務。主要為了解決日誌分散不方便檢視、日誌搜尋操作複雜且效率低、業務異常無法及時發現等等問題。
隨著有贊業務的發展與增長，每天都會產生百億級別的日誌量（據統計，平均每秒產生 50 萬條日誌，峰值每秒可達 80 萬條）。日誌平臺也隨著業務的不斷髮展經歷了多次改變和升級。本文跟大家分享有贊在當前日誌系統的建設、演進以及優化的經歷，這裡先拋磚引玉，歡迎大家一起交流討論。
二、原有日誌系統
有贊從 16 年就開始構建適用於業務系統的統一日誌平臺，負責收集所有系統日誌和業務日誌，轉化為流式資料，通過 flume 或者 logstash 上傳到日誌中心(kafka 叢集)，然後共 Track、Storm、Spark 及其它系統實時分析處理日誌，並將日誌持久化儲存到 HDFS 供離線資料分析處理，或寫入 ElasticSearch 提供資料查詢。整體架構如下圖 所示。
隨著接入的應用的越來越多，接入的日誌量越來越大，逐漸出現一些問題和新的需求，主要在以下幾個方面：
1.業務日誌沒有統一的規範，業務日誌格式各式各樣，新應用接入無疑大大的增加了日誌的分析、檢索成本。 2.多種資料日誌資料採集方式，運維成本較高 3.儲存方面，
-採用了 Es 預設的管理策略，所有的 index 對應 3*2個shard（3 個 primary，3 個 replica），有部分 index 數量較大，對應單個 shard 對應的資料量就會很大，導致有 hot node，出現很多 bulk request rejected，同時磁碟 IO 集中在少數機器上。
-對於 bulk request rejected 的日誌沒有處理，導致業務日誌丟失
-日誌預設保留 7 天，對於 ssd 作為儲存介質，隨著業務增長，儲存成本過於高昂
-另外 Elasticsearch 叢集也沒有做物理隔離，Es 叢集 oom 的情況下，使得叢集內全部索引都無法正常工作，不能為核心業務執行保駕護航
4.日誌平臺收集了大量使用者日誌資訊，當時無法直接的看到某個時間段，哪些錯誤資訊較多，增加定位問題的難度。
三、現有系統演進
日誌從產生到檢索，主要經歷以下幾個階段：採集->傳輸->緩衝->處理->儲存->檢索，詳細架構如下圖所示：
#3.1日誌接入
日誌接入目前分為兩種方式，SDK 接入和呼叫 Http Web 服務接入
-SDK 接入：日誌系統提供了不同語言的 SDK，SDK 會自動將日誌的內容按照統一的協議格式封裝成最終的訊息體，並最後最終通過 TCP 的方式傳送到日誌轉發層（rsyslog-hub）
-Http Web 服務接入：有些無法使用 SDk 接入日誌的業務，可以通過 Http 請求直接傳送到日誌系統部署的 Web 服務，統一由 web protal 轉發到日誌緩衝層的 kafka 叢集
3.2日誌採集
3.3日誌緩衝
Kafka 是一個高效能、高可用、易擴充套件的分散式日誌系統，可以將整個資料處理流程解耦，將 kafka 叢集作為日誌平臺的緩衝層，可以為後面的分散式日誌消費服務提供非同步解耦、削峰填谷的能力，也同時具備了海量資料堆積、高吞吐讀寫的特性。
3.4日誌切分
日誌分析是重中之重，為了能夠更加快速、簡單、精確地處理資料。日誌平臺使用 spark streaming 流計算框架消費寫入 kafka 的業務日誌，Yarn 作為計算資源分配管理的容器，會跟不同業務的日誌量級，分配不同的資源處理不同日誌模型。
整個 spark 任務正式執行起來後，單個批次的任務會將拉取的到所有的日誌分別非同步的寫入到 ES 叢集。業務接入之前可以在管理臺對不同的日誌模型設定任意的過濾匹配的告警規則，spark 任務每個 excutor 會在本地記憶體裡儲存一份這樣的規則，在規則設定的時間內，計數達到告警規則所配置的閾值後，通過指定的渠道給指定使用者傳送告警，以便及時發現問題。當流量突然增加，es 會有 bulk request rejected 的日誌會重新寫入 kakfa，等待補償。
3.5日誌儲存
-原先所有的日誌都會寫到 SSD 盤的 ES 叢集，logIndex 直接對應 ES 裡面的索引結構，隨著業務增長，為了解決 Es 磁碟使用率單機最高達到 70%~80% 的問題,現有系統採用 Hbase 儲存原始日誌資料和 ElasticSearch 索引內容相結合的方式，完成儲存和索引。
-Index 按天的維度建立，提前建立index會根據歷史資料量，決定建立明日 index 對應的 shard 數量，也防止集中建立導致資料無法寫入。現在日誌系統只存近 7 天的業務日誌，如果配置更久的儲存時間的，會存到歸檔日誌中。
-對於儲存來說，Hbase、Es 都是分散式系統，可以做到線性擴充套件。
四、多租戶
隨著日誌系統不斷髮展，全網日誌的 QPS 越來越大，並且部分使用者對日誌的實時性、準確性、分詞、查詢等需求越來越多樣。為了滿足這部分使用者的需求，日誌系統支援多租戶的的功能，根據使用者的需求，分配到不同的租戶中，以避免相互影響。
針對單個租戶的架構如下：
-SDK：可以根據需求定製，或者採用天網的 TrackAppender 或 SkynetClient
-Kafka 叢集：可以共用，也可以使用指定 Kafka 叢集
-Spark 叢集：目前的 Spark 叢集是在 yarn 叢集上，資源是隔離的，一般情況下不需要特地做隔離
-儲存：包含 ES 和 Hbase，可以根據需要共用或單獨部署 ES 和 Hbase
五、現有問題和未來規劃
目前，有贊日誌系統作為整合在天網裡的功能模組，提供簡單易用的搜尋方式，包括時間範圍查詢、欄位過濾、NOT/AND/OR 、模糊匹配等方式，並能對查詢欄位高亮顯示，定位日誌上下文，基本能滿足大部分現有日誌檢索的場景，但是日誌系統還存在很多不足的地方，主要有:
1.缺乏部分鏈路監控：日誌從產生到可以檢索，經過多級模組，現在採集，日誌緩衝層還未串聯，無法對丟失情況進行精準監控，並及時推送告警。
2.現在一個日誌模型對應一個 kafka topic，topic 預設分配三個 partition，由於日誌模型寫入日誌量上存在差異，導致有的 topic 負載很高，有的 topic 造成一定的資源浪費，且不便於資源動態伸縮。topic 數量過多，導致 partition 數量過多，對 kafka 也造成了一定資源浪費，也會增加延遲和 Broker 當機恢復時間。
3.目前 Elasticsearch 中文分詞我們採用 ik_max_word，分詞目標是中文，會將文字做最細粒度的拆分，但是日誌大部分都是英文，分詞效果並不是很好。
上述的不足之處也是我們以後努力改進的地方，除此之外，對於日誌更深層次的價值挖掘也是我們探索的方向，從而為業務的正常執行保駕護航。
4月27日（週六）下午13:30，有贊技術中介軟體團隊聯合Elastic中文社群，圍繞Elastic的開源產品及周邊技術，在杭州舉辦一場線下技術交流活動。
歡迎參加，我們一起聊聊~