老大要我搭建一個TB級的日誌監控系統，據說 ELK 不錯

本文主要介紹怎麼使用 ELK Stack 幫助咱們打造一個支撐起日產 TB 級的日誌監控系統。

在企業級的微服務環境中，跑着成百上千個服務都算是比較小的規模了。在生產環境上，日誌扮演着很重要的角色，排查異常須要日誌，性能優化須要日誌，業務排查須要業務等等。然而在生產上跑着成百上千個服務，每一個服務都只會簡單的本地化存儲，當須要日誌協助排查問題時，很難找到日誌所在的節點。也很難挖掘業務日誌的數據價值。那麼將日誌統一輸出到一個地方集中管理，而後將日誌處理化，把結果輸出成運維、研發可用的數據是解決日誌管理、協助運維的可行方案，也是企業迫切解決日誌的需求。

咱們的解決方案

經過上面的需求咱們推出了日誌監控系統，如上圖：

• 日誌統一收集、過濾清洗。
• 生成可視化界面、監控，告警，日誌搜索。

功能流程概覽如上圖：

• 在每一個服務節點上埋點，實時採集相關日誌。
• 統一日誌收集服務、過濾、清洗日誌後生成可視化界面、告警功能。

咱們的架構

①日誌文件採集端咱們使用 FileBeat，運維經過咱們的後臺管理界面化配置，每一個機器對應一個 FileBeat，每一個 FileBeat日誌對應的 Topic 能夠是一對1、多對一，根據平常的日誌量配置不一樣的策略。

除了採集業務服務日誌外，咱們還收集了 MySQL 的慢查詢日誌和錯誤日誌，還有別的第三方服務日誌，如：Nginx 等。

最後結合咱們的自動化發佈平臺，自動發佈並啓動每個 FileBeat 進程。

②調用棧、鏈路、進程監控指標咱們使用的代理方式：Elastic APM，這樣對於業務側的程序無需任何改動。

對於已經在運營中的業務系統來講，爲了加入監控而須要改動代碼，那是不可取的，也是沒法接受的。

Elastic APM 能夠幫咱們收集 HTTP 接口的調用鏈路、內部方法調用棧、使用的SQL、進程的 CPU、內存使用指標等。

可能有人會有疑問，用了 Elastic APM，其它日誌基本均可以不用採集了。還要用 FileBeat 幹嗎？

是的，Elastic APM 採集的信息確實能幫咱們定位 80% 以上的問題，可是它不是全部的語言都支持的好比：C。

其2、它沒法幫你採集你想要的非 Error 日誌和所謂的關鍵日誌，好比：某個接口調用時出了錯，你想看出錯時間點的先後日誌；還有打印業務相關方便作分析的日誌。

其3、自定義的業務異常，該異常屬於非系統異常，屬於業務範疇，APM 會把這類異常當成系統異常上報。

若是你後面對系統異常作告警，那這些異常將會干擾告警的準確度，你也不能去過濾業務異常，由於自定義的業務異常種類也很多。

③同時咱們對 Agent 進行了二開。採集更詳細的 GC、堆棧、內存、線程信息。

④服務器採集咱們採用普羅米修斯。

⑤因爲咱們是 Saas 服務化，服務 N 多，不少的服務日誌作不到統一規範化，這也跟歷史遺留問題有關，一個與業務系統無關的系統去間接或直接地去對接已有的業務系統，爲了適配本身而讓其更改代碼，那是推不動的。

牛逼的設計是讓本身去兼容別人，把對方當成***本身的對象。不少日誌是沒有意義的，好比：開發過程當中爲了方便排查跟蹤問題，在 if else 裏打印只是有標誌性的日誌，表明是走了 if 代碼塊仍是 else 代碼塊。

甚至有些服務還打印着 Debug 級別的日誌。在成本、資源的有限條件下，全部全部的日誌是不現實的，即便資源容許，一年下來將是一比很大的開銷。

因此咱們採用了過濾、清洗、動態調整日誌優先級採集等方案。首先把日誌全量採集到 Kafka 集羣中，設定一個很短的有效期。

咱們目前設置的是一個小時，一個小時的數據量，咱們的資源暫時還能接受。

⑥Log Streams 是咱們的日誌過濾、清洗的流處理服務。爲何還要 ETL 過濾器呢？

由於咱們的日誌服務資源有限，但不對啊，原來的日誌分散在各各服務的本地存儲介質上也是須要資源的哈。

如今咱們也只是聚集而已哈，收集上來後，原來在各服務上的資源就能夠釋放掉日誌佔用的部分資源了呀。

沒錯，這樣算確實是把原來在各服務上的資源化分到了日誌服務資源上來而已，並無增長資源。

不過這只是理論上的，在線上的服務，資源擴大容易，收縮就沒那麼容易了，實施起來極其困難。

因此短期內是不可能在各服務上使用的日誌資源化分到日誌服務上來的。這樣的話，日誌服務的資源就是當前全部服務日誌使用資源的量。

隨存儲的時間越長，資源消耗越大。若是解決一個非業務或非解決不可的問題，在短期內須要投入的成本大於解決當前問題所帶來收益的話，我想，在資金有限的狀況下，沒有哪一個領導、公司願意採納的方案。

因此從成本上考慮，咱們在 Log Streams 服務引入了過濾器，過濾沒有價值的日誌數據，從而減小了日誌服務使用的資源成本。

技術咱們採用 Kafka Streams 做爲 ETL 流處理。經過界面化配置實現動態過濾清洗的規則。

大概規則以下：

• 界面化配置日誌採集。默認 Error 級別的日誌全量採集。
• 以錯誤時間點爲中心，在流處理中開窗，輻射上下可配的 N 時間點採集非 Error 級別日誌，默認只採 info 級別。
• 每一個服務可配 100 個關鍵日誌，默認關鍵日誌全量採集。
• 在慢 SQL 的基礎上，按業務分類配置不一樣的耗時再次過濾。
• 按業務需求實時統計業務 SQL，好比：高峯期階段，統計一小時內同類業務 SQL 的查詢頻率。可爲 DBA 提供優化數據庫的依據，如按查詢的 SQL 建立索引。
• 高峯時段按業務類型的權重指標、日誌等級指標、每一個服務在一個時段內日誌最大限制量指標、時間段指標等動態清洗過濾日誌。
• 根據不一樣的時間段動態收縮時間窗口。
• 日誌索引生成規則：按服務生成的日誌文件規則生成對應的 index，好比：某個服務日誌分爲：debug、info、error、xx_keyword，那麼生成的索引也是 debug、info、error、xx_keyword 加日期做後綴。這樣作的目的是爲研發以原習慣性地去使用日誌。

⑦可視化界面咱們主要使用 Grafana，它支持的衆多數據源中，其中就有普羅米修斯和 Elasticsearch，與普羅米修斯可謂是無縫對接。而 Kibana 咱們主要用於 APM 的可視分析。

日誌可視化

咱們的日誌可視化以下圖：

來源 | 8rr.co/6UEz