日志是記錄系統中各種問題信息的關鍵，也是一種常見的海量數據。

日志平臺為集團所有業務系統提供日志采集、消費、分析、存儲、索引和查詢的一站式日志服務。

主要為了解決日志分散不方便查看、日志搜索操作復雜且效率低、業務異常無法及時發現等等問題。

隨著業務的發展與增長，每天都會產生百億級別的日志量(據統計，平均每秒產生 50 萬條日志，峰值每秒可達 80 萬條)。日志平臺也隨著業務的不斷發展經歷了多次改變和升級。

本文跟大家分享在當前日志系統的建設、演進以及優化的經歷，這里先拋磚引玉，歡迎大家一起交流討論。

原有日志系統

從 2016 年就開始構建適用于業務系統的統一日志平臺，負責收集所有系統日志和業務日志，轉化為流式數據。

通過 Flume 或者 Logstash 上傳到日志中心(Kafka 集群)，然后供 Track、Storm、Spark 及其他系統實時分析處理日志。

并將日志持久化存儲到 HDFS 供離線數據分析處理，或寫入 ElasticSearch 提供數據查詢。

整體架構如圖 2-1 所示：

圖 2-1：原有日志系統架構

隨著接入的應用越來越多，接入的日志量越來越大，逐漸出現一些問題和新的需求，主要在以下幾個方面：

業務日志沒有統一的規范，業務日志格式各式各樣，新應用接入無疑大大的增加了日志的分析、檢索成本。

多種數據日志數據采集方式，運維成本較高。

日志平臺收集了大量用戶日志信息，當時無法直接的看到某個時間段，哪些錯誤信息較多，增加定位問題的難度。

關于存儲方面：

采用了 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 的情況下，使得集群內全部索引都無法正常工作，不能為核心業務運行保駕護航。

現有系統演進

日志從產生到檢索，主要經歷以下幾個階段：

采集

傳輸

緩沖

處理

存儲

檢索

詳細架構如圖 3-1 所示：

圖 3-1：現有系統架構

日志接入

日志接入目前分為兩種方式：

SDK 接入：日志系統提供了不同語言的 SDK，SDK 會自動將日志的內容按照統一的協議格式封裝成最終的消息體，并最后最終通過 TCP 的方式發送到日志轉發層(Rsyslog-Hub)。

HTTP Web 服務接入：有些無法使用 SDK 接入日志的業務，可以通過 HTTP 請求直接發送到日志系統部署的 Web 服務，統一由 Web Protal 轉發到日志緩沖層的 Kafka 集群。

日志采集

現在有 Rsyslog-Hub 和 Web Portal 做為日志傳輸系統，Rsyslog 是一個快速處理收集系統日志的程序，提供了高性能、安全功能和模塊化設計。

之前系統演進過程中使用過直接在宿主機上部署 Flume 的方式，由于 Flume 本身是 Java 開發的，會比較占用機器資源而統一升級為使用 Rsyslog 服務。

為了防止本地部署與 Kafka 客戶端連接數過多，本機上的 Rsyslog 接收到數據后，不做過多的處理就直接將數據轉發到 Rsyslog-Hub 集群。通過 LVS 做負載均衡，后端的 Rsyslog-Hub 會通過解析日志的內容，提取出需要發往后端的 Kafka Topic。

日志緩沖

Kafka 是一個高性能、高可用、易擴展的分布式日志系統，可以將整個數據處理流程解耦。

將 Kafka 集群作為日志平臺的緩沖層，可以為后面的分布式日志消費服務提供異步解耦、削峰填谷的能力，也同時具備了海量數據堆積、高吞吐讀寫的特性。

日志切分

日志分析是重中之重，為了能夠更加快速、簡單、精確地處理數據。日志平臺使用 Spark Streaming 流計算框架消費寫入 Kafka 的業務日志。

Yarn 作為計算資源分配管理的容器，會跟不同業務的日志量級，分配不同的資源處理不同日志模型。

整個 Spark 任務正式運行起來后，單個批次的任務會將拉取到的所有的日志分別異步的寫入到 ES 集群。

業務接入之前可以在管理臺對不同的日志模型設置任意的過濾匹配的告警規則，Spark 任務每個 Excutor 會在本地內存里保存一份這樣的規則。

在規則設定的時間內，計數達到告警規則所配置的閾值后，通過指定的渠道給指定用戶發送告警，以便及時發現問題。

當流量突然增加，ES 會有 bulk request rejected 的日志重新寫入 Kakfa，等待補償。

日志存儲

原先所有的日志都會寫到 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、模糊匹配等方式。

并能對查詢字段高亮顯示，定位日志上下文，基本能滿足大部分現有日志檢索的場景。

但是日志系統還存在很多不足的地方，主要有:

缺乏部分鏈路監控：日志從產生到可以檢索，經過多級模塊，現在采集，日志緩沖層還未串聯，無法對丟失情況進行精準監控，并及時推送告警。

現在一個日志模型對應一個 Kafka Topic，Topic 默認分配三個 Partition。 由于日志模型寫入日志量上存在差異，導致有的 Topic 負載很高，有的 Topic 造成一定的資源浪費，且不便于資源動態伸縮。 Topic 數量過多，導致 Partition 數量過多，對 Kafka 也造成了一定資源浪費，也會增加延遲和 Broker 宕機恢復時間。

目前 Elasticsearch 中文分詞我們采用 ikmaxword，分詞目標是中文，會將文本做最細粒度的拆分，但是日志大部分都是英文，分詞效果并不是很好。

上述的不足之處也是我們以后努力改進的地方，除此之外，對于日志更深層次的價值挖掘也是我們探索的方向，從而為業務的正常運行保駕護航。

總結

以上是生活随笔為你收集整理的日志写入hbase_千亿级日志系统设计思路，牛人必学！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。