如何用ELK搭建TB級的日志監控系統？
本文主要介紹怎么使用 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 加日期作后綴。這樣做的目的是為研發以原習慣性地去使用日志。
⑦可視化界面我們主要使用 Grafana，它支持的眾多數據源中，其中就有普羅米修斯和 Elasticsearch，與普羅米修斯可謂是無縫對接。而 Kibana 我們主要用于 APM 的可視分析。
日志可視化
我們的日志可視化如下圖：
作者：非洲羚羊
編輯：陶家龍
出處：https://www.cnblogs.com/dengbangpang/p/12961593.html
