一虽画、概述
日志是記錄系統(tǒng)中各種問題信息的關(guān)鍵舞蔽，也是一種常見的海量數(shù)據(jù)。日志平臺為集團所有業(yè)務系統(tǒng)提供日志采集码撰、消費、分析个盆、存儲脖岛、索引和查詢的一站式日志服務。主要為了解決日志分散不方便查看颊亮、日志搜索操作復雜且效率低柴梆、業(yè)務異常無法及時發(fā)現(xiàn)等等問題。
隨著有贊業(yè)務的發(fā)展與增長终惑，每天都會產(chǎn)生百億級別的日志量（據(jù)統(tǒng)計绍在，平均每秒產(chǎn)生 50 萬條日志，峰值每秒可達 80 萬條）雹有。日志平臺也隨著業(yè)務的不斷發(fā)展經(jīng)歷了多次改變和升級偿渡。本文跟大家分享有贊在當前日志系統(tǒng)的建設、演進以及優(yōu)化的經(jīng)歷霸奕，這里先拋磚引玉溜宽，歡迎大家一起交流討論。
二质帅、原有日志系統(tǒng)
有贊從 16 年就開始構(gòu)建適用于業(yè)務系統(tǒng)的統(tǒng)一日志平臺适揉，負責收集所有系統(tǒng)日志和業(yè)務日志留攒，轉(zhuǎn)化為流式數(shù)據(jù)，通過 flume 或者 logstash 上傳到日志中心(kafka 集群)嫉嘀，然后共 Track炼邀、Storm、Spark 及其它系統(tǒng)實時分析處理日志剪侮，并將日志持久化存儲到 HDFS 供離線數(shù)據(jù)分析處理汤善，或?qū)懭?ElasticSearch 提供數(shù)據(jù)查詢。整體架構(gòu)如下圖 所示票彪。
隨著接入的應用的越來越多红淡，接入的日志量越來越大，逐漸出現(xiàn)一些問題和新的需求降铸，主要在以下幾個方面：
1.業(yè)務日志沒有統(tǒng)一的規(guī)范在旱，業(yè)務日志格式各式各樣，新應用接入無疑大大的增加了日志的分析推掸、檢索成本桶蝎。
2.多種數(shù)據(jù)日志數(shù)據(jù)采集方式，運維成本較高
3.存儲方面谅畅，
-采用了 Es 默認的管理策略登渣，所有的 index 對應 3*2個shard（3 個 primary，3 個 replica）毡泻，有部分 index 數(shù)量較大胜茧，對應單個 shard 對應的數(shù)據(jù)量就會很大，導致有 hot node仇味，出現(xiàn)很多 bulk request rejected呻顽，同時磁盤 IO 集中在少數(shù)機器上。
-對于 bulk request rejected 的日志沒有處理丹墨，導致業(yè)務日志丟失
-日志默認保留 7 天廊遍，對于 ssd 作為存儲介質(zhì)，隨著業(yè)務增長贩挣，存儲成本過于高昂
-另外 Elasticsearch 集群也沒有做物理隔離喉前，Es 集群 oom 的情況下，使得集群內(nèi)全部索引都無法正常工作王财，不能為核心業(yè)務運行保駕護航
4.日志平臺收集了大量用戶日志信息卵迂，當時無法直接的看到某個時間段，哪些錯誤信息較多搪搏，增加定位問題的難度狭握。
三、現(xiàn)有系統(tǒng)演進
日志從產(chǎn)生到檢索疯溺，主要經(jīng)歷以下幾個階段：采集->傳輸->緩沖->處理->存儲->檢索论颅，詳細架構(gòu)如下圖所示：
#3.1日志接入
日志接入目前分為兩種方式哎垦，SDK 接入和調(diào)用 Http Web 服務接入
-SDK 接入：日志系統(tǒng)提供了不同語言的 SDK，SDK 會自動將日志的內(nèi)容按照統(tǒng)一的協(xié)議格式封裝成最終的消息體恃疯，并最后最終通過 TCP 的方式發(fā)送到日志轉(zhuǎn)發(fā)層（rsyslog-hub）
-Http Web 服務接入：有些無法使用 SDk 接入日志的業(yè)務漏设，可以通過 Http 請求直接發(fā)送到日志系統(tǒng)部署的 Web 服務，統(tǒng)一由 web protal 轉(zhuǎn)發(fā)到日志緩沖層的 kafka 集群
3.2日志采集
現(xiàn)在有 rsyslog-hub 和 web portal 做為日志傳輸系統(tǒng)今妄，rsyslog 是一個快速處理收集系統(tǒng)日志的程序郑口，提供了高性能、安全功能和模塊化設計盾鳞。之前系統(tǒng)演進過程中使用過直接在宿主機上部署 flume 的方式犬性，由于 flume 本身是 java 開發(fā)的，會比較占用機器資源而統(tǒng)一升級為使用 rsyslog 服務腾仅。為了防止本地部署與 kafka 客戶端連接數(shù)過多乒裆，本機上的 rsyslog 接收到數(shù)據(jù)后，不做過多的處理就直接將數(shù)據(jù)轉(zhuǎn)發(fā)到 rsyslog-hub 集群推励，通過 LVS 做負載均衡鹤耍，后端的 rsyslog-hub 會通過解析日志的內(nèi)容，提取出需要發(fā)往后端的 kafka topic验辞。
3.3日志緩沖
Kafka 是一個高性能稿黄、高可用、易擴展的分布式日志系統(tǒng)跌造，可以將整個數(shù)據(jù)處理流程解耦杆怕，將 kafka 集群作為日志平臺的緩沖層，可以為后面的分布式日志消費服務提供異步解耦鼻听、削峰填谷的能力财著，也同時具備了海量數(shù)據(jù)堆積、高吞吐讀寫的特性撑碴。
3.4日志切分
日志分析是重中之重，為了能夠更加快速朝墩、簡單醉拓、精確地處理數(shù)據(jù)。日志平臺使用 spark streaming 流計算框架消費寫入 kafka 的業(yè)務日志收苏，Yarn 作為計算資源分配管理的容器亿卤，會跟不同業(yè)務的日志量級，分配不同的資源處理不同日志模型鹿霸。
整個 spark 任務正式運行起來后排吴，單個批次的任務會將拉取的到所有的日志分別異步的寫入到 ES 集群。業(yè)務接入之前可以在管理臺對不同的日志模型設置任意的過濾匹配的告警規(guī)則懦鼠，spark 任務每個 excutor 會在本地內(nèi)存里保存一份這樣的規(guī)則钻哩，在規(guī)則設定的時間內(nèi)屹堰，計數(shù)達到告警規(guī)則所配置的閾值后，通過指定的渠道給指定用戶發(fā)送告警街氢，以便及時發(fā)現(xiàn)問題扯键。當流量突然增加，es 會有 bulk request rejected 的日志會重新寫入 kakfa珊肃，等待補償荣刑。
3.5日志存儲
-原先所有的日志都會寫到 SSD 盤的 ES 集群，logIndex 直接對應 ES 里面的索引結(jié)構(gòu)伦乔，隨著業(yè)務增長厉亏，為了解決 Es 磁盤使用率單機最高達到 70%~80% 的問題,現(xiàn)有系統(tǒng)采用 Hbase 存儲原始日志數(shù)據(jù)和 ElasticSearch 索引內(nèi)容相結(jié)合的方式，完成存儲和索引烈和。
-Index 按天的維度創(chuàng)建爱只，提前創(chuàng)建index會根據(jù)歷史數(shù)據(jù)量，決定創(chuàng)建明日 index 對應的 shard 數(shù)量斥杜，也防止集中創(chuàng)建導致數(shù)據(jù)無法寫入∈牛現(xiàn)在日志系統(tǒng)只存近 7 天的業(yè)務日志，如果配置更久的保存時間的蔗喂，會存到歸檔日志中忘渔。
-對于存儲來說，Hbase缰儿、Es 都是分布式系統(tǒng)畦粮，可以做到線性擴展。
四乖阵、多租戶
隨著日志系統(tǒng)不斷發(fā)展宣赔，全網(wǎng)日志的 QPS 越來越大，并且部分用戶對日志的實時性瞪浸、準確性儒将、分詞、查詢等需求越來越多樣对蒲。為了滿足這部分用戶的需求钩蚊，日志系統(tǒng)支持多租戶的的功能，根據(jù)用戶的需求蹈矮，分配到不同的租戶中砰逻，以避免相互影響。
針對單個租戶的架構(gòu)如下：
-SDK：可以根據(jù)需求定制泛鸟，或者采用天網(wǎng)的 TrackAppender 或 SkynetClient
-Kafka 集群：可以共用蝠咆，也可以使用指定 Kafka 集群
-Spark 集群：目前的 Spark 集群是在 yarn 集群上，資源是隔離的北滥，一般情況下不需要特地做隔離
-存儲：包含 ES 和 Hbase刚操，可以根據(jù)需要共用或單獨部署 ES 和 Hbase
五闸翅、現(xiàn)有問題和未來規(guī)劃
目前，有贊日志系統(tǒng)作為集成在天網(wǎng)里的功能模塊赡茸，提供簡單易用的搜索方式缎脾，包括時間范圍查詢、字段過濾占卧、NOT/AND/OR
遗菠、模糊匹配等方式，并能對查詢字段高亮顯示华蜒，定位日志上下文辙纬，基本能滿足大部分現(xiàn)有日志檢索的場景，但是日志系統(tǒng)還存在很多不足的地方叭喜，主要有:
1.缺乏部分鏈路監(jiān)控：日志從產(chǎn)生到可以檢索贺拣，經(jīng)過多級模塊，現(xiàn)在采集捂蕴，日志緩沖層還未串聯(lián)譬涡，無法對丟失情況進行精準監(jiān)控，并及時推送告警啥辨。
2.現(xiàn)在一個日志模型對應一個 kafka topic涡匀，topic 默認分配三個 partition，由于日志模型寫入日志量上存在差異溉知，導致有的 topic 負載很高陨瘩，有的 topic 造成一定的資源浪費，且不便于資源動態(tài)伸縮级乍。topic 數(shù)量過多舌劳，導致 partition 數(shù)量過多，對 kafka 也造成了一定資源浪費玫荣，也會增加延遲和 Broker 宕機恢復時間甚淡。
3.目前 Elasticsearch 中文分詞我們采用 ik_max_word，分詞目標是中文捅厂，會將文本做最細粒度的拆分材诽，但是日志大部分都是英文，分詞效果并不是很好恒傻。
上述的不足之處也是我們以后努力改進的地方，除此之外建邓，對于日志更深層次的價值挖掘也是我們探索的方向盈厘，從而為業(yè)務的正常運行保駕護航。
4月27日（周六）下午13:30官边，有贊技術(shù)中間件團隊聯(lián)合Elastic中文社區(qū)沸手，圍繞Elastic的開源產(chǎn)品及周邊技術(shù)外遇，在杭州舉辦一場線下技術(shù)交流活動。
本次活動免費開放契吉，限額200名跳仿。
掃描下圖二維碼，回復“報名”即可參加
歡迎參加捐晶，我們一起聊聊~
