前面幾章蜻蜓點水的介紹了elasticsearch、apm相關的內容。本片主要介紹怎麼使用ELK Stack幫助我們打造一個支撐起日產TB級的日誌監控系統
背景
在企業級的微服務環境中，跑着成百上千個服務都算是比較小的規模了。在生產環境上，日誌扮演着很重要的角色，排查異常需要日誌，性能優化需要日誌，業務排查需要業務等等。然而在生產上跑着成百上千個服務，每個服務都只會簡單的本地化存儲，當需要日誌協助排查問題時，很難找到日誌所在的節點。也很難挖掘業務日誌的數據價值。那麼將日誌統一輸出到一個地方集中管理，然後將日誌處理化，把結果輸出成運維、研發可用的數據是解決日誌管理、協助運維的可行方案，也是企業迫切解決日誌的需求。
我們的解決方案
通過上面的需求我們推出了日誌監控系統。
- 日誌統一收集、過濾清洗。
- 生成可視化界面、監控，告警，日誌搜索。
功能流程概覽
- 在每個服務節點上埋點，實時採集相關日誌。
- 統一日誌收集服務、過濾、清洗日誌後生成可視化界面、告警功能。
我們的架構
- 日誌文件採集端我們使用filebeat,運維通過我們的後台管理界面化配置，每個機器對應一個filebeat，每個filebeat日誌對應的topic可以是一對一、多對一，根據日常的日誌量配置不同的策略。除了採集業務服務日誌外，我們還收集了mysql的慢查詢日誌和錯誤日誌,還有別的第三方服務日誌，如:nginx等。最後結合我們的自動化發布平台，自動發布並啟動每一個filebeat進程。
- 調用棧、鏈路、進程監控指標我們使用的代理方式：Elastic APM，這樣對於業務側的程序無需任何改動。對於已經在運營中的業務系統來說，為了加入監控而需要改動代碼，那是不可取的，也是無法接受的。Elastic APM可以幫我們收集http接口的調用鏈路、內部方法調用棧、使用的sql、進程的cpu、內存使用指標等。可能有人會有疑問，用了Elastic APM，其它日誌基本都可以不用採集了。還要用filebeat幹嘛？是的，Elastic APM採集的信息確實能幫我們定位80%以上的問題，但是它不是所有的語言都支持的比如：C。其二、它無法幫你採集你想要的非error日誌和所謂的關鍵日誌，比如：某個接口調用時出了錯，你想看出錯時間點的前後日誌；還有打印業務相關方便做分析的日誌。其三、自定義的業務異常，該異常屬於非系統異常，屬於業務範疇，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加日期作後綴。這樣做的目的是為研發以原習慣性地去使用日誌
7. 可視化界面我們主要使用grafana，它支持的眾多數據源中，其中就有普羅米修斯和elasticsearch，與普羅米修斯可謂是無縫對接。而kibana我們主要用於apm的可視分析
日誌可視化
【版權聲明】
本文版權歸作者(深圳伊人網網絡有限公司)和博客園共有，歡迎轉載，但未經作者同意必須在文章頁面給出原文鏈接，否則保留追究法律責任的權利。如您有任何商業合作或者授權方面的協商，請給我留言：siqing0822@163.com
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※教你寫出一流的銷售文案?
※別再煩惱如何寫文案,掌握八大原則!