數字化時代，企業對快速采集日志的需求日益遞增，對于個人開發者和企業來說，日志采集也有的截然不同的複雜度。
“快速”這個需求的本質在于，如何利用比較友善部署且成熟可靠的技術選型，來降低搭建一套能滿足業務訴求的日志平台所需的時間成本，其中要解決的核心問題就是：日志架構的複雜度。在此我們重點聚焦于企業使用者，深度解析企業級的日志平台架建構設複雜度以及建設思路分享。
01
企業級日志架構複雜度
一套企業級的日志平台架建構設複雜度總結歸納下來，主要展現在三個方面：
- 采集端部署分散；
- 服務端部署元件多；
- 日志流對性能有一定要求。
采集端部署分散
比較常用的采集器是開源的filebeat，filebeat功能強大，安裝配置也相對簡單。但問題在于，一旦需要采集的對象數量多起來，種類多起來，或者這些采集對象是動态變化的，即使單節點安裝簡易的filebeat也會需要花費大量的精力來安裝和維護。這也是很多企業在建設統一日志平台面臨的一個實際問題。這時，運維往往會寫腳本去批量下發，能做到部分解決問題，但是後期的配置維護、版本更新等等，都将帶來新的問題。
那麼，有什麼方案可以解決呢？有，那就是采取集中管理的思路，由一個統一的控制中心，通過在不同節點上安裝代理來收集資訊+下發配置。一般一個中大型企業，基本都會有一套自己的agent來控制各方資源，agent往往是在虛拟機模闆或者容器鏡像中就已經打入，主要的作用也就是上報資訊以及下發配置。日志的采集便可以利用好這種集中式的管理工具，基于agent做插件來充當采集端，統一管理采集配置（包括路徑、級别、過濾、預處理等等）。
服務端部署元件多
對于個人開發者或小規模企業來說，部署元件多也許還可以接受。拿開源的ELK舉例，日志服務端部署需要Logstash叢集和ES叢集，以及一個Kibana的前端，完整一套叢集也許就可以解決相當體量的日志集中管理。但對于一家中大型企業來講，體量和業務複雜度上來之後，情況往往是非常複雜的。
這時建設人員可能會有一種思路：直接采用多套ELK，也能解決問題，部署也就寫個腳本的事情，批量複制，還可以做“實體隔離”。這樣确實行之有效，但這種方案會帶來另外的問題，就是日志無法進一步聚合聚類，導緻各業務的日志資料成了資料孤島，如果組織内有那種橫向組織，他們就需要來回切換叢集進行諸如日志檢索，日志清洗等操作。
要解決這個問題，其實隻需要再增加一個服務端，能夠将分布在不同ELK的日志存儲統一管理起來，讓上述場景統一通過這個服務端提供的接口完成，也就能在使用日志的時候，不再受到存儲分散的影響。
性能要求高
日志資料不同于名額類資料，日志資料無論是從時間密度還是從空間密度上來說都要遠遠大于其他類型的觀測資料。是以，中大型企業的大型業務系統以及龐大的基礎設施産生的日志量讓企業開發者不得不思考這其中的性能和成本如何平衡。
總結三個關鍵的性能瓶頸以及對應的解決方案：
分散到集中存儲所消耗的帶寬壓力：
- 通過采集端做預先過濾
- 分多條傳輸鍊路
- 做好網絡鍊路規劃，盡量避免跨域傳輸
清洗和存儲壓力：
- 通過Kafka等消息隊列做寫入緩沖
- 使用非結構化分片存儲
檢索響應速度的壓力：
- 冷熱資料分離，減少索引大小
- 完善資料預處理和清洗，索引高效（一定程度依賴日志輸出規範化）
02
整體技術架構
整體技術架構介紹
藍鲸平台在騰訊内部業務場景的探索
其實剛剛展示的這套日志架構，源自騰訊IEG藍鲸日志平台的資料流示意圖。
藍鲸平台在早期就将日志的各類應用場景作為整個自動化營運中的關鍵環節，并規劃建造出了一套适合中大型企業使用的日志平台。直至目前，藍鲸日志平台已經曆經上百次的疊代，在騰訊内部積累了大量的實踐經驗，支援了上千項業務的日志需求，總結出了不少技術優化舉措，在此結合這個話題進行分享總結。
關鍵技術優化舉措&經驗
- 采集端統一Agent，用Agent裝采集插件的方式來實作日志采集，便于安裝管理。
- 對于難以運作Agent的裝置，可以采取用一些節點主動調用接口擷取syslog的方式，集中存儲再用Agent采集。
- Transfer預處理和Kafka高吞吐銜接，加強資料管道性能。
- 統一存儲端管理，支援第三方ES接入，通過索引集的設計拓展後續的日志應用場景。
- 分析類的計算任務會借助已有的成熟的資料平台，而并非在自己内部進行。
- 資料可視化重點關注名額和次元的體系建設，而并非界面的優化（grafana可以解決絕大部分可視化需求）。
- 各服務節點均可雲原生叢集化部署。
實踐效果
通過Agent，支援各類日志的采集。
統一服務端後，使用索引集進行跨節點的日志檢索。
配合grafana分析日志清洗後的名額資料（以Nginx通路日志為例）。
了解更多内容，歡迎關注公衆号嘉為藍鲸。