終極指南：企業級云原生 PaaS 平臺日志分析架構全面解析

早些時候 Erda Show 針對微服務監控、日志等內容做了專場分享，很多同學聽完后意猶未盡，想了解更多關于日志分析的內容。Erda 團隊做日志分析也有一段時間了，所以這次打算和大家詳細分享一下我們在做的一些事情，希望對大家有所幫助。

日志分析平臺其實是 Erda 微服務治理子平臺下面的一個功能模塊，那么今天我將從三個方面來展開分享：

日志分析平臺出現的必要性；

日志分析平臺架構設計；

Erda 目前是怎么做的、做了哪些工作以及未來的發展方向。

日志分析平臺的必要性

“微服務”這一概念大概在 2013 年出現，從這一概念初期到現在，大部分應用的業務場景皆是分布式、容器化的部署架構，或者至少是多服務架構，每個服務基本上是非單點的，并且會做單服務多實例的高可用部署。

在這種場景下，我們需要重點解決關于日志的幾個問題。

需要解決的問題

1. 接口報錯了，如何在應用的多個容器中快速的找到詳細的異常日志？

第一個要解決的問題是關于異常日志的定位效率問題。比如，前端在請求某個頁面，接口報錯了，隨后反饋給開發人員，常規的接口報錯通常不會直接給用戶暴露特別詳細的異常信息，只會有一個狀態或是簡要的錯誤概述，這時需要開發者通過日志找到具體的異常信息（比如堆棧等）。

一般來說，通過接口路徑我們可以定位是哪個服務的報錯，但進一步講，我們如何確定是這個服務下的哪個實例的報錯呢？如果說我們采用這種比較原始的方式，可能需要開發者分別查看每個實例（容器）的日志，這樣會直接對開發效率產生影響。

2. 如何方便的查看已經宕機的應用容器的日志？

另外一個需要解決的問題是日志存儲的持久性問題。比如說在 K8s 平臺下，某個應用服務的某個 pod 掛掉了被重新調度到了其他節點，或者本地存儲的容器日志由于時間的滾動而滾動沒了，這時如果我們想去回頭看一下之前的日志，在機器上已經不太容易找到了。

3. 如何能及時的發現某個應用容器發生了異常？

前兩個問題屬于被動型的需求，也就是說前端業務上已經暴露出一些問題，然后我們去回溯、查找一些日志的詳細記錄的需求。因為是用戶反饋，這個流程鏈上的故障處理時間是相對較長的，那么應該如何縮短故障處理時間？

很自然我們會想到主動告警，在還沒有大面積前端接口被大量用戶發現前，后端出現異常時，系統能夠更及時的進行告警，并通知相關人員及時處理，減少故障時間。這時我們就非常需要一個系統可以持續監聽所有容器的日志，協助開發者發現其中的異常并主動告警。

如果說沒有日志分析平臺，其實以上三個問題并不是不能解決，但是會極大程度的影響效率。那么假如有了這樣的日志分析平臺，由它來提供集中式查詢、持久化存儲以及主動告警等功能，我們可以快速且高效的解決這三個問題。

日志分析平臺能提供什么

說到日志分析平臺的必要性，我們務必要了解一下它能為我們提供什么樣的服務，下面我們就來詳細看一下：

1. 集中式、一站式查詢

在查詢方面，日志分析平臺應該是集中式、一站式的查詢，不再需要登錄不同機器或者容器去低效地手動查看日志，而只需要在一個統一的頁面上輸入一些查詢語句，就能輕松查詢所有容器的日志了。

2. 持久化，歷史可追溯

在存儲方面，可以給日志分析平臺配備有預期的專門存儲配額，以便能夠更好地應對宕機、升級、調度等導致日志跨節點的情況，保持查詢歷史日志時的簡單性。

3. 智能化，主動發現問題

智能化告警通常也是一個必要功能，這里的智能化有兩層意思：

你可以主動配置一些規則，比如說根據代碼或已經發生的一些異常日志，可以知道特定異常是什么樣子，隨后配一個規則，系統就會持續對輸入的日志做一些規則檢測，如果發現匹配項，就會進一步通過你提前配置的告警渠道，通知到具體的人；

自動發現“異常”，其實有點類似目前的機器學習、深度學習，也就是說，即使你沒有配置任何規則，但是系統可以通過對日志流的監聽和學習，去發現異常的日志，然后通知你去關注，這是更智能化的一些東西。

日志分析平臺架構設計

我們已經知道，日志分析平臺可以給我們帶來便利及效率的提升，那么如果我們想實現這樣一個平臺，需要如何進行架構設計呢？

想要做架構設計，首先要了解業務場景和需求，然后結合被處理數據的特點，才能夠推斷平臺架構設計應該具有哪些能力。之后我們再根據這些能力去尋找、設計相匹配的方案，并在這些方案中挑選真正可落地的去執行。

數據特點

1. 時序數據

我們知道日志屬于時序數據，只新增、不刪除。它有幾個字段比較關鍵：timestamp，tags，fields

timestamp：時間字段對時序型數據是用來進行比較和關鍵的字段；

tags：tags 代表一組字段，通常對于時序數據來講，作為標簽類型的字段一般都是可以搜索的，也就是這些字段需要建立索引，如：服務名、容器名、容器 IP 等；

fields：fields 也代表一組字段，這些字段相對于 tags 的不同在于，fields 字段是通常存儲那些不需要搜索的內容，比如：假如對于具體的日志內容你不打算去搜索，就可以用 fields 類型字段存儲。

日志時序數據的特點提示我們，可以考慮使用時序數據庫來存儲日志，比如 cassandra。

2. 時效性強

對于日志數據來講，我們一般只關心一段時間的數據，對于很早之前的數據，比如一個月、兩個月之前，甚至半年之前的數據，我們基本上是不會去關心的。因為一般有故障的時候，我們可能才需要去看一下具體的日志信息，而出現故障時不大可能會拖到很久之后才去解決和復盤這個問題。

3. 數據量大

數據量大有兩個含義：一是說數據的單條日志可能比較大，比如像 Java 應用的一個異常堆棧，尤其那種 Caused by 嵌套了好幾層的，可能單條日志就會有幾百行；另外一個是說，日志的條數多，隨著業務和應用的增多，加上某些應用還可能會開啟 DEBUG 級別的日志，整體的日志量也會比較大，而且可能出現短時的峰值。

以上是日志數據的特點，然后我們對從我們日志分析平臺這個角度來看看，我們對系統有什么需求。

業務需求特點

1. 查詢速度快，秒級響應

首先，我們希望它能夠快速查詢，輸入查詢關鍵字，就能夠秒級響應查詢結果。

2. 時間段范圍查詢

通常，查詢會按照一個明確的時間范圍操作，這有一個好處：后端存儲的選擇會更多一些。

3. 高基數值點查詢

什么是高基數值呢？像用戶 IP、Trace ID 這類數據，幾乎每個用戶請求的值都不一樣，這就屬于高基數。關于這類數據的查詢也是一個強需求，比如前端 web 接口報錯，而響應里加了 Trace ID 這樣的字段，此時就可以通過 Trace ID 字段去查看整個過程中記錄的異常日志或關鍵日志，這也是一個比較常見的需求。

4. 標簽查詢

標簽查詢一般可以認為是對服務名、容器 IP 這樣的字段查詢需求，這也屬于強需求之一。

5. 全文檢索查詢

全文檢索查詢是否屬于強需求之一，其實是個值得權衡的問題。如果客戶端在采集端已經做了一些預處理，如：把整行的日志 content 在采集時拆分成了具體的時間級別、異常類型等單個關鍵字段，這樣來講，全文檢索查詢可能就不是一個強需求了，但同時，備選方案的范圍可能會更大一些。這里需要提醒的是，沒有全文檢索支持，并不代表不能模糊檢索。借助列存儲的高壓縮率和高 IO 效率，在內存中進行模糊過濾的效果也很贊！

6. 聚合統計

聚合統計中最簡單的是 Count 統計，更復雜一點的有基于更多字段維度的復雜聚合圖表支持，這些功能在一些產品中也有提供，但需根據個體具體需求來判斷該項是不是強需求。

7. 主動告警

主動告警意味著系統不僅具備被動查詢功能，同時也能夠及時發現問題并告警，這樣才能減少故障時間。

介紹完業務需求方面的 7 個特點后，在設計架構時，就能夠助力我們迅速 get 到需要考慮哪些方面了。

架構要求

1. 軟硬成本

當然，成本是一定要的，不管是做什么設計，肯定需要考慮成本，這其中包括軟硬的成本。

硬件成本指的是我們的機器數量：CPU、內存、磁盤等這樣的資源。這里面存在一個問題，因為對于日志而言，我們講數據量大，單條的體積可能也比較大，如果確定不需要全文檢索，或只檢索其中很少的幾個關鍵字段，對于那些較長的字段，僅僅只是想隨著搜索條件把它展示出來，這個時候我們可能就會考慮，對于不需要索引的這些數據，是不是可以通過一些更廉價的存儲方式（比如像 OSS）存下來，這樣可以節省整體的存儲成本。

另一方面需要考慮軟件成本，拿剛才 OSS 存儲的例子，如果我們想用很高效的存儲方式來存儲索引的數據，而那些不需要查詢的字段用 OSS 存儲，這時的架構方案可能會稍微復雜一些，開發復雜度和難度，以及人力投入也會相對高一些，軟件的整體成本也會相應增加。

2. 存儲要有過期機制

數據的實效性對存儲機制也提出了要求，對于數據的過期機制，需要考慮，如何保證和限制執行數據過期刪除時的性能消耗不會對整個系統的吞吐有過大影響。

3. 異步處理，吞吐要大，不能被業務流量打垮

在數據量大的場景下，要求日志系統在接受采極端數據的時候，需要考慮異步處理等手段，保證不能被業務流量打垮。如果說業務系統有問題了，日志系統也因此出現問題，導致不能使用日志系統來查詢、排查業務問題，那這個平臺存在的意義就會受到挑戰。一般來說我們會用 MQ 這樣的中間件來做異步的削峰填谷處理。

4. 即席查詢能力（內存、緩存、并行、高效過濾等機制）

基于對查詢速度的要求，能夠秒級響應的存儲方案會被優先選擇。

5. 存儲結構對時間范圍查詢友好

基于時間段的范圍查詢是最高頻的場景之一，針對此類場景，我們可以考慮選擇時序數據庫，因其本身對時間序列查詢做了成本上的優化，同時也是效率較高的方案。

6. 二級索引能力

高基數單點查詢對索引能力提出了要求，這將限制我們對于時序數據庫的選擇。因為像 promethus 這樣的時序數據庫對高基數值的單點查詢是存在問題的，這是由于它的存儲的特點決定的。一般來說，如果我們想支持高基數值的單點查詢，需要需要有一個二級屬性能力的數據庫。

7. 全文檢索能力

如何支持模糊查詢，也是我們要考量的一個因素。因為如果要做完整的全文檢索能力支持，比如：分詞、相關性算分排序等，我們的可選方案會被進一步限制。

8. 存儲結構聚合操作友好（如列存儲）

們知道對于聚合統計操作對話，列存儲的聚合性能是比較高的，因為它有很高對壓縮比，一次讀盤可以讀到很多有效的數據，整體對 IO 效率會很高。

9. 告警模塊

最后一點就是架構里必須規劃告警模塊如何去做。

以上內容針對數據特點、業務需求提出的一些架構要求進行介紹，可以看出，核心取舍在于存儲。下面一張圖，展示了整個架構的處理流程和關鍵組件，接下來的內容將對存儲部分的選型進行展開介紹。

存儲方案選型

上圖中關于存儲部分，有幾個開源的可選存儲中間件：像 Cassandra、Hbase、ElasticSearch、ClickHouse、Grafana Loki等。下圖將會針對這些中間件的優缺點進行對比分析：

上圖的方案選型圖表對各個方案的描述已經相對比較詳細，在此就不再贅述，接下來我們看下在 Erda 中是如何做的。

Erda 日志分析平臺實踐

Erda 目前采用的其實是比較常見的實現方案：使用 Elasticsearch 作為底層存儲。當然，其中也存在歷史原因，Erda 的開源時間雖然并不是很長，但是其存在歷史可以算比較久了。在當時看來，選擇 Elasticsearch 也是比較合理的選擇。當然，現狀并不是終點，我們后面仍會持續探索在成本、效率方面更優的方案。

如果說選擇 ES 這樣的一個方案的話，具體應該怎么做呢？

剛才的方案選型圖表中列出了使用 Elasticsearch 的大致核心思路，接下來我們具體深入看下如何去做。

之前提到，使用 Elasticsearch 方案的特點就是功能全和開箱即用，上圖中列出了在 Erda 中所利用的一些關鍵能力來實現目前 Erda 想要提供的部分關鍵功能，如下圖所示。

總的來說，Erda 目前采用的其實還是比較常規的方案，并在此基礎上有一些小的優化，整個代碼結構上也是做了一層抽象，并沒有說以后就是綁死在 Elasticsearch 上面，后續我們還會考慮支持一些其他可替換方案。

Erda 日志分析平臺未來的方向

對 Erda 日志分析平臺而言，未來我們有幾個努力的方向：

1. 存儲更高效、可擴展

首先是存儲方面，上文我們也提到，Erda 目前主要采用基于 Elasticsearch 的存儲方案，但使用 Elasticsearch 有一個不可忽視的缺點，那就是它的整體資源占用成本相對較高，而像 Clickhouse、Grafana Loki 等，確實有各自的優勢需要我們去借鑒。所以說 Erda 作為一個開源產品，后續可能會支持更多的底層存儲，用戶可以在這些方案之間根據自身的需求和成本來進行選擇。

另外，自研存儲也將會是我們的一個投入方向，因為監控領域除了日志，還有指標、Trace 數據。這些數據能否采用一個統一的存儲內核來降低系統的復雜度，同時可以對不同數據類型做專項優化來平衡成本和性能，這些都是我們考慮自研存儲的出發點。

2. 告警更便捷、更智能

目前在 Erda 平臺上，如果想從日志分析出發去創建告警規則，實際使用的鏈路還是有點長，所以后續我們會優化這條鏈路上的產品和功能體驗。

另外的一個方向就是智能化，基于日志的自動異常檢測。在上文中有簡單提到這點，就是說即使用戶沒有顯式的去配置任何規則，系統也可以幫助用戶去發現預期之外的一些異常。這里的異常，不一定非得是業務應用拋出的錯誤的堆棧，它是一個相對于“正常”的概念，即正常數據流中突然出現了一個非常不同尋常的數據，這可能會需要用到一些機器學習的模型來檢測。

以上就是本次想要和大家分享的有關日志分析架構的一些內容，后續我們也將不忘初心，持續優化產品功能和用戶體驗，也非常期待有更多對此感興趣的開發者參與進來與我們共建 Erda，每一條建議我們都會認真聆聽，期待更多的聲音幫助我們變得更好！

更多技術干貨請關注【爾達 Erda】公眾號，與眾多開源愛好者共同成長～

云原生 容器 開源 日志分析服務 LOG

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。