前面幾章走馬觀花的介紹了elasticsearch、apm相關的內容。本片主要介紹怎麼使用ELK Stack幫助咱們打造一個支撐起日產TB級的日誌監控系統mysql
背景
在企業級的微服務環境中,跑着成百上千個服務都算是比較小的規模了。在生產環境上,日誌扮演着很重要的角色,排查異常須要日誌,性能優化須要日誌,業務排查須要業務等等。然而在生產上跑着成百上千個服務,每一個服務都只會簡單的本地化存儲,當須要日誌協助排查問題時,很難找到日誌所在的節點。也很難挖掘業務日誌的數據價值。那麼將日誌統一輸出到一個地方集中管理,而後將日誌處理化,把結果輸出成運維、研發可用的數據是解決日誌管理、協助運維的可行方案,也是企業迫切解決日誌的需求。nginx
咱們的解決方案
經過上面的需求咱們推出了日誌監控系統。sql
![](http://static.javashuo.com/static/loading.gif)
- 日誌統一收集、過濾清洗。
- 生成可視化界面、監控,告警,日誌搜索。
功能流程概覽
![](http://static.javashuo.com/static/loading.gif)
- 在每一個服務節點上埋點,實時採集相關日誌。
- 統一日誌收集服務、過濾、清洗日誌後生成可視化界面、告警功能。
咱們的架構
![](http://static.javashuo.com/static/loading.gif)
- 日誌文件採集端咱們使用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是咱們的日誌過濾、清洗的流處理服務。咱們採用Kafka Streams做ETL流處理。經過界面化配置實現動態過濾清洗的規則。大概規則以下:
- 界面化配置日誌採集。默認error級別的日誌全量採集
- 以錯誤時間點爲中心,在流處理中開窗,輻射上下可配的N時間點採集非error級別日誌,默認只採info級別
- 每一個服務可配100個關鍵日誌,默認關鍵日誌全量採集
- sql日誌按配置耗時過濾
- 高峯時段按業務類型的權重指標、日誌等級指標、每一個服務在一個時段內日誌最大限制量指標、時間段指標等動態清洗過濾日誌
- 根據不一樣的時間段動態收縮時間窗口
- 日誌索引生成規則:按服務生成的日誌文件規則生成對應的index,好比:某個服務日誌分爲:debug、info、error、xx_keyword,那麼生成的索引也是debug、info、error、xx_keyword加日期做後綴。這樣作的目的是爲研發以原習慣性地去使用日誌
7. 可視化界面咱們主要使用grafana,它支持的衆多數據源中,其中就有普羅米修斯和elasticsearch,與普羅米修斯可謂是無縫對接。而kibana咱們主要用於apm的可視分析安全
日誌可視化
出於安全考慮,公司線上可視化數據不便於使用,如下只是簡單的上幾張開發環境的效果圖性能優化
權限認證服務器
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
可視化分析架構
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
![](http://static.javashuo.com/static/loading.gif)
聲明:本文版權歸做者和博客園共有,歡迎轉載,但未經做者贊成必須在文章頁面給出原文連接,不然保留追究法律責任的權利