雲時代架構之中國民生銀行天眼日誌平臺架構演進的平凡之路

中國民生銀行天眼日誌平臺架構演進的平凡之路

　　對於一個簡單的日誌應用場景，一般會準備 master/slave 兩個應用。咱們只需運行一個 Shell 腳本，即可查看是否存在錯誤信息。隨着業務複雜度的增長，應用場景也會變得複雜。雖然監控系統可以顯示某臺機器或者某個應用的錯誤。然而在實際的生產環境中，因爲實施了隔離，一旦在上圖下側的紅框內某個應用出現了 Bug，則沒法訪問到其對應的日誌，也就談不上將日誌取出了。另外，有些深度依賴日誌平臺的應用，也可能在日誌產生的時候就直接採集走，進而刪除掉原始的日誌文件。這些場景給咱們日誌系統的維護都帶來了難度。

　　咱們能夠從實時性和錯誤分析兩個維度來區分不一樣的日誌數據場景：

　　實時，通常適用於咱們常說的一級應用，如：直接面向用戶的應用。咱們能夠自定義各種關鍵字，以方便在出現各類 error 或 exception 時，相關業務人員可以在第一時間被通知到。準實時，通常適用於一些項目管理的平臺，如：在須要填寫工時的時候出現了宕機，但這並不影響工資的發放。平臺在幾分鐘後完成重啓，咱們能夠再登陸填寫，該狀況並不形成原則性的影響。所以，咱們能夠將其列爲準實時的級別。除了直接採集錯誤與異常，咱們還須要進行分析。例如：僅知道某人的體重是沒什麼意義的，可是若是增長了性別和身高兩個指標，那麼咱們就能夠判斷出此人的體重是否爲標準體重。也就是說：若是能給出多個指標，就能夠對龐大的數據進行去噪，而後經過迴歸分析，讓採集到的數據更有意義。此外，咱們還要不斷地去還原數字的真實性。特別是對於實時的一級應用，咱們要能快速地讓用戶明白他們所碰到現象的真實含義。例如：商家在上架時錯把商品的價格標籤 100 元標成了 10 元。這會致使商品立刻被搶購一空。可是這種現象並不是是業務的問題，很難被發現，所以咱們只能經過日誌數據進行邏輯分析，及時反饋以保證在幾十秒以後將庫存修改成零，從而有效地解決此問題。可見，在此應用場景中，實時分析就顯得很是有用。最後是追溯，咱們須要在獲取歷史信息的同時，實現跨時間維度的對比與總結，那麼追溯就可以在各類應用中發揮其關聯性做用了。

　　最後是我考慮到一個實際狀況，咱們儘量少的佔有服務器，而後傳輸須要過濾轉換，日誌能夠比較簡單，符合這種 Key value（KV）格式。咱們能夠按照取了一個 Rsyslog、取了一個 Fluentd、取了一個 Hbase，取了一個 echars 等這麼一個方式作一個方案就能夠了。我以爲 Rsyslog、Fluentd、heka 這些均可以作採集。而後傳輸這塊有 Fluentd 傳輸，由於 Fluentd 和 Kafka 到插件很是靈活能夠直接對接咱們不少存儲設備，也能夠對應不少的文件、連 ES 均可以。

文章來源：

https://mp.weixin.qq.com/s?__biz=MzU1NDA4NjU2MA==&mid=2247487107&idx=1&sn=59ae4e09c6418cfac534f45e8572a577&chksm=fbe9b74ccc9e3e5aa3894166619833aab6ba4eec9c8099e4b1ea1c3ca54aa4901fed70f2642f&scene=21#wechat_redirect