https://tech.youzan.com/you-zan-tong-ri-zhi-ping-tai-chu-tan/

一、引言

自有贊成立以來，發展迅猛，業務增長很快，業務系統數量大，每天都會產生大量的系統日志和業務日志(據統計，平均每秒產生日志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發起異常報警或提供指標監控查詢。

三、模塊分解

從上面總體架構圖中，我們可以看到整個日志平臺架構分為四層，從左到右依次是日志接入層、日志中心、日志處理層、日志存儲層。

3.1 日志接入層

日志接入層主要有兩種方式，方式1基于rsyslog和logstash，方式2基于flume-ng。

3.1.1

圖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字段。為了統一，我們對日志格式做了約定，格式如下:

<158>yyyy-MM-dd HH:mm:ss host/ip level[pid]: topic=track.**** {"type":"error","tag":"redis connection refused","platform":"java/go/php","level":"info/warn/error","app":"appName","module":"com.youzan.somemodule","detail":"any things you want here"} 1

對于PHP Server，我們在PHP框架中封裝了日志SDK，PHP開發的同學只需調用寫日志接口，就可以將日志傳到Flume中。同樣的，對于Java Server，也封裝了日志SDK(基于logback自定義了TrackAppender)，并集成在Dubbox框架中，業務開發的同學只需在其工程的logback.xml中添加相應的appender配置，指明應用名和日志topic即可將日志異步傳到Flume中。對于其它應用或服務(比如基于Go、Node.JS、Python等)，如果需要接入日志平臺，只需按照以上日志格式組裝日志，并將其上傳到Flume即可。

細心的同學會發現，在圖3-2中，我們用了TrackSink，這個是做什么的呢？雖然Flume自帶豐富的組件，也包括KafkaSink，但是為什么我們不用呢？考慮到自帶的KafkaSink不能按我們需要的topic來分發數據，所以只能自定義實現了Sink來達到寫不同topic日志到不同日志中心topic中去的目的。

另外，Flume是通過Supervisor啟動的，并且添加了監控報警，但是為了避免日志寫失敗，在Flume中，我們使用了Failover策略，假如寫日志中心失敗，則將日志寫到本地，保證日志不丟失。

3.2 日志中心

美其名曰日志中心，但實際上只是日志中心緩存，我們只保存最近24小時的日志，需要持久化的日志都會刷入HDFS。至于為什么選用kafka集群來構建日志中心，理由主要如下:

1、分布式架構，可支持水平擴展。2、高吞吐量，在普通的服務器上每秒鐘也能處理幾十萬條消息(遠高于我們的峰值1.5萬條/秒)。3、消息持久化，按topic分區存儲，支持可重復消費。4、日志系統不需要保證嚴格的消息準確性。 5、數據在磁盤上的存取代價為O(1)。 6、可根據broker配置定期刪除過期數據。 123456

3.3 日志處理層和日志存儲層

日志處理層，是我們真正做事的地方；日志存儲層，則是我們存放日志分析結果的地方。

基于日志中心，可做的事情有很多。只要我們對某topic日志感興趣，那么便可以將該topic日志消費來滿足我們的業務需求。我們可以：

1、將日志聚合，根據業務不同，建立不同的索引，存入ElasticSearch提供查詢。 2、發現異常日志時，發往監控中心，向對應的業務方發起報警，發現和預發問題的實時性提高了。 3、統計一些訪問日志或調用日志等指標信息，發往監控中心來掌握相關調用趨勢。 4、調用鏈開始做起來了，系統性能瓶頸一目了然了。 5、用戶日志行為可分析了。 12345

這里我們做了不少，但是需要做的還有更多，就不一一例舉了。

四、遇到的問題和要做的事情

突然接手如此規模的一個基礎產品，遇到的問題還是比較多的:

1、業務日志接入，每一次對接不僅需要開發日志消費模塊，解析相應日志，建立相應的索引并寫入elasticsearch，還需要開發對應定制的查詢頁面。由于自己本身對系統不熟悉，另外文檔缺失，以及每一次對接的都是“新人”，還時不時可能會遇到各種千奇百怪的問題，需要排查定位并解決問題。這塊急需解放，不然一個人真的忙不過來，針對該問題，接下來會抽象出日志消費和elasticsearch讀寫SDK，供業務接入方自己開發和維護。 2、對于各個組件(如logstash、flume、kafka、elasticsearch等)都未曾接觸過的情況下，短時間接手這么一個新產品，需要學習的東西很多，壓力還是很大的，但總算熬過來了。 3、缺失的開發測試環境，到寫此文章時總算搭建起來了。 4、elasticsearch內存占用高，以及索引的管理與維護，還在優化和考慮中。 5、需要開發更加人性化且更易擴展和維護的運控平臺供使用方查詢日志。 6、日志收集到Flume增加支持UDP協議。 7、將存儲層的HDFS移到日志中心，支持日志同時寫入Kafka集群和HDFS集群。 8、是時候做點日志挖掘的事情了。 12345678

五、結語

為什么做這次分享？

由于之前交接時間較短，實際只有2天，然后統一日志平臺涉及的內容比較多，接手日志平臺的這一個多月是痛苦的，然后找崔(有贊CTO)吐槽了一下。結果崔知道我在梳理日志平臺，就讓我順便寫篇介紹有贊的日志架構的文章，幫助大家了解一下。怎奈我這人臉皮太薄，在對日志平臺還不熟悉的情況下，竟然應承下來了，俗話說的好，死要面子活受罪。

轉載于:https://www.cnblogs.com/davidwang456/articles/9239205.html

總結

以上是生活随笔為你收集整理的有赞统一日志平台初探的全部內容，希望文章能夠幫你解決所遇到的問題。

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