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

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

- 日誌分析平臺出現的必要性；
- 日誌分析平臺架構設計；
- Erda 目前是怎麼做的、做了哪些工作以及未來的發展方向。

# 日誌分析平臺的必要性

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

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

## 需要解決的問題

![image.png](https://ucc.alicdn.com/pic/developer-ecology/041faf4297b646d08dbc2b30097b1e66.png)

### 1. 介面報錯了，如何在應用的多個容器中快速的找到詳細的異常日誌？

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

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

### 2. 如何方便的檢視已經當機的應用容器的日誌？

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

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

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

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

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

## 日誌分析平臺能提供什麼

![image.png](https://ucc.alicdn.com/pic/developer-ecology/a3a64e158df6496894e4947ddb867d60.png)

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

### 1. 集中式、一站式查詢

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

### 2. 持久化，歷史可追溯

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

### 3. 智慧化，主動發現問題

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

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

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

# 日誌分析平臺架構設計

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

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

![image.png](https://ucc.alicdn.com/pic/developer-ecology/ce11808350e64cec91a6fb819f550a6c.png)

## 資料特點

### 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. 告警模組

最後一點就是架構裡必須規劃告警模組如何去做。

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

![image.png](https://ucc.alicdn.com/pic/developer-ecology/d90e8b4c36a946b09891acbae5aeefb6.png)
  
## 儲存方案選型

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

![image.png](https://ucc.alicdn.com/pic/developer-ecology/290cebff50b34a5284266e42f31370bd.png)

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

# Erda 日誌分析平臺實踐

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

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

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

![image.png](https://ucc.alicdn.com/pic/developer-ecology/8561287f4679410380eeba4499900b5f.png)

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

![image.png](https://ucc.alicdn.com/pic/developer-ecology/a91b33f3b5c24d06bcb5c7dc1e9ecd86.png)

總的來說，Erda 目前採用的其實還是比較常規的方案，並在此基礎上有一些小的最佳化，整個程式碼結構上也是做了一層抽象，並沒有說以後就是綁死在 Elasticsearch 上面，後續我們還會考慮支援一些其他可替換方案。
 
## Erda 日誌分析平臺未來的方向

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

![image.png](https://ucc.alicdn.com/pic/developer-ecology/eb3838bbe5eb4a348f924b2be74fea49.png)
 
### 1. 儲存更高效、可擴充套件

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

另外，自研儲存也將會是我們的一個投入方向，因為監控領域除了日誌，還有指標、Trace 資料。這些資料能否採用一個統一的儲存核心來降低系統的複雜度，同時可以對不同資料型別做專項最佳化來平衡成本和效能，這些都是我們考慮自研儲存的出發點。

### 2. 告警更便捷、更智慧

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

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

----

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

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

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

相關文章