數字化時代，企業對快速采集日志的需求日益遞增，對于個人開發者和企業來說，日志采集也有的截然不同的復雜度。

“快速”這個需求的本質在于，如何利用比較方便部署且成熟可靠的技術選型，來降低搭建一套能滿足業務訴求的日志平臺所需的時間成本，其中要解決的核心問題就是：日志架構的復雜度。在此我們重點聚焦于企業用戶，深度解析企業級的日志平臺架構建設復雜度以及建設思路分享。

01. 企業級日志架構復雜度

一套企業級的日志平臺架構建設復雜度總結歸納下來，主要體現在三個方面：

• 采集端部署分散；
• 服務端部署組件多；
• 日志流對性能有一定要求。

1）采集端部署分散

比較常用的采集器是開源的filebeat，filebeat功能強大，安裝配置也相對簡單。但問題在于，一旦需要采集的對象數量多起來，種類多起來，或者這些采集對象是動態變化的，即使單節點安裝簡易的filebeat也會需要花費大量的精力來安裝和維護。這也是很多企業在建設統一日志平臺面臨的一個實際問題。這時，運維往往會寫腳本去批量下發，能做到部分解決問題，但是后期的配置維護、版本更新等等，都將帶來新的問題。

那么，有什么方案可以解決呢？有，那就是采取集中管理的思路，由一個統一的控制中心，通過在不同節點上安裝代理來收集信息+下發配置。一般一個中大型企業，基本都會有一套自己的agent來控制各方資源，agent往往是在虛擬機模板或者容器鏡像中就已經打入，主要的作用也就是上報信息以及下發配置。日志的采集便可以利用好這種集中式的管理工具，基于agent做插件來充當采集端，統一管理采集配置（包括路徑、級別、過濾、預處理等等）。

2）服務端部署組件多

對于個人開發者或小規模企業來說，部署組件多也許還可以接受。拿開源的ELK舉例，日志服務端部署需要Logstash集群和ES集群，以及一個Kibana的前端，完整一套集群也許就可以解決相當體量的日志集中管理。但對于一家中大型企業來講，體量和業務復雜度上來之后，情況往往是非常復雜的。

這時建設人員可能會有一種思路：直接采用多套ELK，也能解決問題，部署也就寫個腳本的事情，批量復制，還可以做“物理隔離”。這樣確實行之有效，但這種方案會帶來另外的問題，就是日志無法進一步聚合聚類，導致各業務的日志數據成了數據孤島，如果組織內有那種橫向組織，他們就需要來回切換集群進行諸如日志檢索，日志清洗等操作。

要解決這個問題，其實只需要再增加一個服務端，能夠將分布在不同ELK的日志存儲統一管理起來，讓上述場景統一通過這個服務端提供的接口完成，也就能在使用日志的時候，不再受到存儲分散的影響。

3）性能要求高

日志數據不同于指標類數據，日志數據無論是從時間密度還是從空間密度上來說都要遠遠大于其他類型的觀測數據。因此，中大型企業的大型業務系統以及龐大的基礎設施產生的日志量讓企業開發者不得不思考這其中的性能和成本如何平衡。

總結三個關鍵的性能瓶頸以及對應的解決方案：

① 分散到集中存儲所消耗的帶寬壓力：

• 通過采集端做預先過濾
• 分多條傳輸鏈路
• 做好網絡鏈路規劃，盡量避免跨域傳輸

② 清洗和存儲壓力：

• 通過Kafka等消息隊列做寫入緩沖
• 使用非結構化分片存儲

③ 檢索響應速度的壓力：

• 冷熱數據分離，減少索引大小
• 完善數據預處理和清洗，索引高效（一定程度依賴日志輸出規范化）

02. 整體技術架構

1）整體技術架構介紹

2）藍鯨平臺在騰訊內部業務場景的探索

其實剛剛展示的這套日志架構，源自騰訊IEG藍鯨日志平臺的數據流示意圖。

藍鯨平臺在早期就將日志的各類應用場景作為整個自動化運營中的關鍵環節，并規劃建造出了一套適合中大型企業使用的日志平臺。直至目前，藍鯨日志平臺已經歷經上百次的迭代，在騰訊內部積累了大量的實踐經驗，支持了上千項業務的日志需求，總結出了不少技術優化舉措，在此結合這個話題進行分享總結。

3）關鍵技術優化舉措&經驗

• 采集端統一Agent，用Agent裝采集插件的方式來實現日志采集，便于安裝管理。
• 對于難以運行Agent的設備，可以采取用一些節點主動調用接口獲取syslog的方式，集中存儲再用Agent采集。
• Transfer預處理和Kafka高吞吐銜接，加強數據管道性能。
• 統一存儲端管理，支持第三方ES接入，通過索引集的設計拓展后續的日志應用場景。
• 分析類的計算任務會借助已有的成熟的數據平臺，而并非在自己內部進行。
• 數據可視化重點關注指標和維度的體系建設，而并非界面的優化（grafana可以解決絕大部分可視化需求）。
• 各服務節點均可云原生集群化部署。

4）實踐效果

通過Agent，支持各類日志的采集。

統一服務端后，使用索引集進行跨節點的日志檢索。

配合grafana分析日志清洗后的指標數據（以Nginx訪問日志為例）。