如何建設高吞吐量的日誌平臺






7 月 24 日晚上 8 點，七牛雲高級大數據架構師王珂在飛馬網進行了題爲《如何快速搭建智能化的統一日誌管理系統》的音頻直播，和你們探討了日誌平臺建設中須要考慮的要點，並分享了七牛雲在提升日誌平臺吞吐量上的實踐經驗。本文是對直播內容的整理。



日誌樣例

上圖列舉了一些日誌的例子，方便你們瞭解日誌 概念，這裏簡單解釋一下前兩項。


第一項是某網站的用戶行爲日誌，以這條日誌爲例，包含了兩類信息：一類是用戶信息，例如「city」 這個是用戶 訪問來源地點 ，「useAgent」 用戶的瀏覽器版本 ；還有一類是程序信息，例如 「pageSize」 還有 「pageView」表示頁面尺寸。


第二項是一個典型的 nginx 服務的日誌，「remote_addr」 是請求來源地址，「request」是請求內容，「status」 是請求狀態碼。



三個基礎問題

關於日誌有三個基礎的問題。


 
第一個問題，什麼是日誌？


維基百科上的描述是：日誌是設備或者程序對自身狀態和運做行爲的記錄。這裏個人理解是，如今設備和程序會按預先定義好的模式輸出自身的事件信息，這些事件信息被寫入到文件或者數據庫中就造成了日誌；因此，日誌其實是對於事件信息的記錄，上例中的nginx日誌就是對一次請求事件的記錄。


 
第二個問題，爲何須要日誌？


爲何須要日誌呢？由於設備和程序經過事件輸出了運行情況相關的關鍵信息，例如服務器是否出現過異常，出現了什麼異常，這些事件是設備和程序在設計時候預先定義好的，用來幫助使用者進行維護的。日誌記錄了事件，經過日誌就能夠看到設備和程序運行的歷史信息，經過這些信息，能夠了解設備和程序運行狀況的變化，以更好的對於設備和程序進行維護。



 
第三個問題，什麼時間須要日誌？


主要是在系統出現問題的時候，經過對於運行過程當中發生的歷史事件，能夠查找問題出現的緣由。另外，統計系統的運行指標時也須要日誌。



日誌平臺建設探討

ELK 方案介紹



業內最多見的日誌採集方案就是 ELK，ELK 分別是方案中 3 個組件的縮寫。


• E 是 Elasticsearch，它是一個開源的實時分佈式搜索引擎，它主要被用做日誌數據的存儲和搜索。


• L 是 Logstash，這個組件是日誌解析工具，用於經過正則表達式解析，將日誌中的字段分解出來再傳入 Elasticsearch 中。


• K 是 Kibana，這個組件是展現工具。用於展現保存 Elasticsearch 中的日誌數據，經過可視化的圖表能夠清楚瞭解到一段時間內日誌中新進入了多少條記錄，即發生了多少個事件，還能夠看到不一樣類型的事件數目隨時間的波動狀況。


在 ELK 出來以前，日誌管理基本上都是經過登錄日誌所在機器而後使用 Linux 命令或人爲查看和統計 ，這樣是很是沒有效率的。ELK 有三個優勢：快速、易上手、可擴展 ：快速，ELK 將日誌統一存儲在 Elasticsearch 中，經過搜索查詢日誌的速度要比登錄機器上查詢要快速的多；易上手，ELK 自己部署方便，經過官網上的教程就能夠搭建起一套簡單的 ELK；可擴展，Elasticsearch 和 Kibana 都有一些擴展插件，擴展插件提供了不少新的功能可使用，和 Logstash 與 Kibana 具備相同功能的開源組件也有很多，能夠按照使用的場景進行替換。



其餘日誌相關組件介紹



除了 Logstash 還有幾種經常使用日誌採集工具。


• Rsyslog 通常用於收集系統的 syslog 日誌；
• Fluentd 主要用於容器日誌收集；
• Filebeat go 語言編寫，專一於文件日誌收集；
• Flume 在傳輸鏈路中增長了 Channel 組件做爲數據緩存，能夠把數據保存到磁盤上以免數據丟失。


收集日誌時除了收集工具還會用到緩存組件，主要的緩存組件有 2 個：Kafka 消息隊列和 Redis 內存數據庫。


• Redis 主要用於小數據量低延遲要求的場景，多數狀況下和 Storm 聯用來處理實時數據。


• Kafka 是通用的消息隊列組件，適合場景比較多，相似 Kafka 的消息隊列組件還有幾種。



構建日誌採集方案的三要素和四原則



使用接入工具和緩存組件構建日誌採集方案時，咱們須要考慮的三個要素：時效性、數量級和複雜度。


• 時效性就是日誌是否須要保障低時間延遲的傳輸，即個人設備和程序發生的事件須要在最短期內拿到，仍是能夠容許有延遲，容許多長時間的延遲，幾分鐘仍是幾小時、或者半天也行。在方案制定過程當中，時效性決定了是否要選擇 Storm 實時流式方案。並做爲測試過程的硬指標發揮做用，在模擬測試環節判斷方案是否可用。


• 數量級是對於日誌條目數和空間大小的衡量要素。運行出錯才作事件記錄的程序日誌和每秒收集一次傳感器日誌在數據條目和文件佔用的磁盤空間上是有很大區別的，進行採集的時候對於採集組件的要求也是不一樣的。數量級影響採集工具和緩存組件的選擇，在方案制定過程當中，天天採集的條目數超過百萬時候就須要增長緩存組件了，條目數過億時候就須要考慮如何平衡數據寫入和數據查詢的資源了。


• 最後一個要素就是複雜度，採集方案複雜度的產生主要因爲緣由：數量級、網絡環境和採集工具。在數量級要求下，咱們不得不添加緩存組件，把日誌先寫到 Kafka，再把日誌寫到 ES，增長一個 Kafka，就須要考慮 Kafka 的高可用問題和數據丟失問題，方案複雜度就提高了。方案的複雜度會影響方案的實施難度和維護難度，複雜度過高的方案即便設計出來也比較難落地。


考慮到這三種因素，咱們在選擇日誌採集方案的時候要考慮到四個原則。


• 時效性要求不高，數量級也不大的狀況優先採集文件，由於文件是最簡單的也是最好採集的。


• 在日誌生成的過程當中解決解析問題，而不是在傳輸過程當中，也就是在日誌生成的過程當中就約束它的格式，而不是考慮在傳輸過程當中統一它的格式。大部分的採集工具都支持中間改寫日誌信息，增長內容或者拆份內容，這些操做實際上增長了採集方案的複雜度，也使得替換採集工具的成本增長，須要儘可能避免。


• 不一樣的日誌都有它的特色，那麼是否是咱們每個具體的場景，都要選擇不一樣的工具呢 ？我以爲是須要比較這個工具的特色帶來的收益和增長工具來的的複雜度變化，若是新增工具不會對於原來的組件產生影響，也不會新增開發內容，運維上也能接受；那麼是能夠增長工具的，不然工具數量越少越好。


• 若是數據量比較大的話，就要考慮多級的緩存處理。引入緩存主要就是爲了分離上下游操做，在不影響 ES 性能的狀況下，寫入更多的數據。

規劃容器日誌採集方案的要點題



因爲如今容器概念比較熱，單獨和你們聊一下容器日誌採集須要考慮的內容。

01 採集方式


• 如今主流容器分配管理都是用的 K8s 架構，K8s 日誌數據的收集比較簡單，能夠直接從 var/log/containers 下按照文件的形式獲取；內部應用日誌使用 Daemonset 的方式部署日誌收集工具就能夠完成收集。


• 若是沒有使用 K8s，僅使用了 Docker ，日誌數據的收集會稍微麻煩一些，容器自身的 stdout 能夠經過 Docker 自帶的 logdriver 去歸集。容器內部的應用日誌，能夠經過 Docker 自帶的一些命令查看，或者使用第三方組件，好比 fluend-pilot 能夠收集這部分日誌。對於七牛雲的實踐來講，你也能夠把容器內的日誌投遞出去。


02 常見業務需求點


• 避免容器遷移中日誌丟失：在 K8s 中用 PVC 作持久化存儲，將日誌都寫進去便可。 但帶來的額外問題是，須要管理這個持久化存儲。


• 支持多種日誌採集工具：每種日誌採集工具配置不一樣的 Pod，而後用 Daemonset 去調用。


• 在容器內應用日誌中體現容器信息：K8s 1.7 裏面提供了一個功能，在啓動容器時能夠把容器的信息寫成容器內的公有變量。另外一種方式在 Daemonset 裏仍是可以拿到容器系統變量的。



七牛雲日誌平臺面臨的挑戰





七牛雲日誌平臺日誌主要有三個來源，第一是七牛雲存儲系統的日誌，第二個是七牛雲容器平臺的日誌，第三個是使用七牛雲智能日誌管理平臺的客戶上傳的私有日誌。如今日均數據流入量超 250 TB，3650 億條，其中最大的客戶日均數據流入量超過 45 TB。


七牛雲日誌平臺面臨的主要挑戰以下：


• 數據量大，須要穩定支持大量數據的寫入和查詢；
• 數據來源多，須要支持多種數據源的數據採集，而且採集過程要穩定可監控；
• 平臺用戶功能需求多，須要支持豐富的擴展功能；

• 平臺用戶大部分是企業用戶，須要支持多租戶場景，並提供用戶權限管理功能。


其中最大挑戰，就是如何把大量的數據，高效的存儲下來，保障數據不丟失的同時儘量減小資源佔用。



七牛雲日誌平臺架構介紹

七牛雲平臺在技術選型階段對於 ELK 方案進行了深度的使用和測試，具體實踐中發現 ELK 方案主要有如下 4 點問題：


• ELK 方案達不到七牛雲在超大規模數據量的狀況下系統穩定性及數據處理性能的要求；


• ELK 方案達不到七牛雲在多種數據源採集穩定性上的要求；


• ELK 方案達不到七牛雲用戶多租戶的要求；


• ELK 方案達不到七牛雲在機器學習等拓展功能方面的要求。


最終評估的結果是 ELK 方案並不能解決七牛雲面臨的挑戰，因此七牛雲走上了自研的道路，當前七牛雲的日誌平臺架構描述以下。


• Logkit：統一採集日誌數據，支持上百種數據源（包括文件、MySQL、MSSQL、ElasticSearch、MongoDB、AWS CloudTrail 等）；支持在採集端完成對數據格式的解析與字段轉換；內置 Channel 組件保證傳輸過程當中數據不丟失；能夠經過管理界面查看採集任務狀態並管理任務配置。


• Pipeline：日誌平臺統一的入口，能夠接收從 log 文件、SDK、Web 端、IOT、雲存儲上經過 API 傳輸過來的數據。數據進入 Pipeline 後，咱們基於 Kafka 作了實時計算組件，支持自定義的計算過程，計算的結果咱們經過 Export 組件，根據不一樣狀況將數據傳輸到後臺 3 種存儲組件當中。


• Insight 集羣：七牛雲基於深度定製的 ES 開發的日誌存儲組件，主要用於支持超大規模日誌數據的檢索查詢。另外，Insight 集羣能夠支持多租戶的使用要求，而且集成了監控告警、報表和機器學習等拓展功能;


• 七牛雲的對象存儲：七牛雲通用存儲組件，用於存儲過了搜索期的冷數據，並支持自定義離線計算過程進行數據分析；



七牛雲經驗分享-吞吐量問題

七牛雲是如何解決日誌平臺吞吐量的挑戰的呢？



首先，Pipeline 的 Kafka 集羣經過擴展，是可以承接百 TB 級別的數據的；那麼問題的瓶頸就變成了如何將百 TB 量級的數據從 Kafka中寫入到 ES 上。因爲原始數據進入到 Pipeline 中可能存在計算流程，負責寫入 ES 的 Export 組件是不能直接從 Kafka 中拉取數據的，只能等待 Pipeline 的調用，即 Export 不能自主的安排寫入進度而是必需要和用戶的數據操做保持一致。在這樣的狀況下，Export 是不能直接去寫 ES，由於可能同時出現多個用戶的數據須要執行寫入操做的狀況，若是 Export 直接去寫入，會產生資源競爭和阻塞。


數據傳輸優化思路




七牛雲對數據傳輸優化主要分爲 2 部分。首先，咱們把獲取 Kafka 數據、數據格式轉換和過濾操做放在 Export 中操做，保持 Export 操做完成後的數據是能夠直接寫入 ES 中的；基於客戶任務的調度的操做也放在 Export 這裏，跟蹤 Export 的狀態就能夠把數據接入的狀況實時的反饋給客戶。而後，在 Export 下面，咱們作了一層傳輸隊列層，經過傳輸隊列提供緩存，數據先進入傳輸隊列，而後根據當前 ES 的狀況非對稱的寫入，保障數據寫入過程不影響客戶的查詢檢索，而且設計了一些故障恢復的措施。


傳輸隊列架構圖




傳輸隊列的實現是基於內存隊列和本地文件隊列，這就跟 Flume 的 Channel 是類似的概念。可是在實現的過程當中，還對它作了一些額外的分裝。首先是 agent 組件，agent 能夠理解爲 scheduler 組件，它負責任務的建立和分配；第二個是 transaction 事務池，這個內存隊列的入隊和出隊，都是經過 transaction 的事務池去處理的。爲何這裏要用事務的概念？由於咱們在寫入 ES 的時候，若是寫 200 條數據，會告訴咱們有 150 條數據寫進去了，有 50 條數據沒有寫進去，它不會區分是哪 50 條沒有寫進去。因此說，在這裏使用 transaction 的意義就在於，若是真實的狀況下，咱們遇到這種狀況，能夠這 50 條數據從新發回 memary queue 裏面，讓內存隊列繼續寫這 50 條數據。



事務池的設計


這是 transaction 內部的一個狀況，當數據進入 Channel 的時候，若是有空間進，就會正常的寫入數據；若是沒有空間進，會返回 503 的錯誤。當數據出 Channel 之後，經過 transaction 保證數據的寫入是完整的，若是這一次寫入不成功，會將一些沒有寫入的數據回滾到 Channel 中。當數據須要中止的時候，會先中止下游的 sink ，而且啓動一些磁盤的 sink ，將數據回滾到 Channel ，再經過磁盤 sink 寫入到本地磁盤中。最後啓動的時候，會直接先從本地磁盤把數據寫入到 Channel 裏面，而後再從正常的數據流中去寫 Channel。



經過傳輸隊列層的設計七牛雲實現了大量數據的穩定寫入，總體上看傳輸隊列經過多級緩存和任務分解機制實現了動態資源調配，將任務不斷的分解，而後根據 ES 的狀況，逐步把分解後的小數據塊寫入到 ES 中，避免了 ES 由於大量寫入而崩潰；同時從 Kafka 取出數據後操做一直在內存中進行也保證了數據傳輸的速度。



七牛雲智能日誌管理平臺



七牛雲智能日誌管理平臺 能力全景圖



基礎功能




前邊分享了咱們的架構設計和實踐經驗，而在功能細節上，咱們也針對傳統方案的缺陷，好比 ELK 沒法解決的需求點，進行了自主研發調優。


• 數據採集層面，logkit 能夠實現可視化的數據採集；而且在採集數據的過程當中，能夠看到實時流量和細分到每臺機器的狀況。


• 日誌搜索層面，咱們支持多用戶與用戶權限管理；，可自動完成 Reblance 操做，無需用戶過多關注，不會影響用戶的查詢效率；對於 ES 寫入也作了深度的優化，能夠在大量數據寫入的同時保證 ES 的查詢效率。


• 數據可視化層面， 咱們提供了用戶體驗極佳的搜索界面，而且提供了完整的報表體系，輕鬆知足用戶的全部報表需求。另外一方面，除了原生支持監控告警外，咱們也支持對接第三方可視化工具，如 Grafana。


智能化組件




考慮到將來數據智能的趨勢，咱們還爲用戶提供了機器學習組件。組件的操做門檻很低，只要選定對應的索引和關注的指標 ，就能自動對指標曲線作學習建模；實現經過監控指標數據，智能發現異常值好比及時發現漏報狀況；同時基於歷史數據的全面學習咱們也支持將來趨勢的預測，可按時間緯度給出將來的預測曲線。


七牛雲智能日誌管理平臺覆蓋了數據的全生命週期，適用於運維監控、安全審計及業務數據分析等場景，致力於下降用戶的心智負擔，幫助客戶數字化升級。



 

牛人說


「牛人說」專欄致力於技術人思想的發現，其中包括技術實踐、技術乾貨、技術看法、成長心得，還有一切值得被發現的內容。咱們但願集合最優秀的技術人，挖掘獨到、犀利、具備時代感的聲音。