前面幾章蜻蜓點水的介紹了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集群中，設定乙個很短的有效期。我們目前設定的是乙個小時，乙個小時的資料量，我們的資源暫時還能接受。
7. 視覺化介面我們主要使用grafana，它支援的眾多資料來源中，其中就有普羅公尺修斯和elasticsearch，與普羅公尺修斯可謂是無縫對接。而kibana我們主要用於apm的可視分析
ps:目前ui已使用自研的ui
微服務之服務監控
服務描述 註冊中心 服務框架 服務監控 服務追蹤 服務治理 目錄 監控微服務 監控物件 監控指標 監控維度 搭建監控系統 監控系統原理 監控系統四個環節 服務監控在微服務改造過程中的重要性不言而喻，沒有強大的監控能力，改造成微服務架構後，就無法掌控各個不同服務的情況，在遇到呼叫失敗時，如果不能快速發...
如何監控微服務
首先要搞清楚三個問題 監控的物件是什麼？具體監控哪些指標？從哪些緯度進行監控？監控的物件可以分為四個層次，從上到下可以歸納為 監控指標 監控維度 監控系統原理 我們對服務呼叫進行監控，首先要能收集到每一次呼叫的詳細資訊，包括呼叫的響應時間，呼叫是否成功，呼叫的發起者和接受者分別是誰，這個過程叫做資料...
Micrometer 微服務監控
不同於單體架構的應用，微服務架構由於服務數量眾多，出故障的概率更大，這種時候不能單純依靠 人肉 運維，否則當服務數量越來越多時成本將變得不可控。乙個好的解決方案是我們需要對服務進行監控，監控服務執行的資料。當有異常情況出現時，服務能夠自動報警，方便運維工程師去處理。spring cloud 中對於服...