有贊百億級日誌系統架構設計

1、概述

日誌是記錄系統中各類問題信息的關鍵，也是一種常見的海量數據。日誌平臺爲集團全部業務系統提供日誌採集、消費、分析、存儲、索引和查詢的一站式日誌服務。主要爲了解決日誌分散不方便查看、日誌搜索操做複雜且效率低、業務異常沒法及時發現等等問題。

隨着有贊業務的發展與增加，天天都會產生百億級別的日誌量（據統計，平均每秒產生 50 萬條日誌，峯值每秒可達 80 萬條）。日誌平臺也隨着業務的不斷髮展經歷了屢次改變和升級。本文跟你們分享有贊在當前日誌系統的建設、演進以及優化的經歷，這裏先拋磚引玉，歡迎你們一塊兒交流討論。

2、原有日誌系統

有贊從 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、現有系統演進

日誌從產生到檢索，主要經歷如下幾個階段：採集->傳輸->緩衝->處理->存儲->檢索，詳細架構以下圖所示：

#3.1日誌接入

日誌接入目前分爲兩種方式，SDK 接入和調用 Http Web 服務接入

-SDK 接入：日誌系統提供了不一樣語言的 SDK，SDK 會自動將日誌的內容按照統一的協議格式封裝成最終的消息體，並最後最終經過 TCP 的方式發送到日誌轉發層（rsyslog-hub）

-Http Web 服務接入：有些沒法使用 SDk 接入日誌的業務，能夠經過 Http 請求直接發送到日誌系統部署的 Web 服務，統一由 web protal 轉發到日誌緩衝層的 kafka 集羣

3.2日誌採集

如今有 rsyslog-hub 和 web portal 作爲日誌傳輸系統，rsyslog 是一個快速處理收集系統日誌的程序，提供了高性能、安全功能和模塊化設計。以前系統演進過程當中使用過直接在宿主機上部署 flume 的方式，因爲 flume 自己是 java 開發的，會比較佔用機器資源而統一升級爲使用 rsyslog 服務。爲了防止本地部署與 kafka 客戶端鏈接數過多，本機上的 rsyslog 接收到數據後，不作過多的處理就直接將數據轉發到 rsyslog-hub 集羣，經過 LVS 作負載均衡，後端的 rsyslog-hub 會經過解析日誌的內容，提取出須要發日後端的 kafka topic。

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 都是分佈式系統，能夠作到線性擴展。

4、多租戶

隨着日誌系統不斷髮展，全網日誌的 QPS 愈來愈大，而且部分用戶對日誌的實時性、準確性、分詞、查詢等需求愈來愈多樣。爲了知足這部分用戶的需求，日誌系統支持多租戶的的功能，根據用戶的需求，分配到不一樣的租戶中，以免相互影響。

針對單個租戶的架構以下：

-SDK：能夠根據需求定製，或者採用天網的 TrackAppender 或 SkynetClient

-Kafka 集羣：能夠共用，也可使用指定 Kafka 集羣

-Spark 集羣：目前的 Spark 集羣是在 yarn 集羣上，資源是隔離的，通常狀況下不須要特意作隔離

-存儲：包含 ES 和 Hbase，能夠根據須要共用或單獨部署 ES 和 Hbase

5、現有問題和將來規劃

目前，有贊日誌系統做爲集成在天網裏的功能模塊，提供簡單易用的搜索方式，包括時間範圍查詢、字段過濾、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的開源產品及周邊技術，在杭州舉辦一場線下技術交流活動。

本次活動免費開放，限額200名。

掃描下圖二維碼，回覆「報名」便可參加

歡迎參加，咱們一塊兒聊聊~