海量日誌分析與智能運維

1、AIOps 與智能日誌中心

1.1AIOps 五等級

要說智能日誌中心，首先要了解什麼是智能運維。目前業界對智能運維的運用，主要分爲以下五個等級。

一級是最容易的，只要你有個想法試試就行，到網管監控系統裏，拿一個監控指標的曲線下來，就能夠嘗試異常檢測。

一級尚未成熟的單點應用，當有了一個成熟的單點應用，就算是達到二級。二級必需要有必定的基礎設施建設做爲前提。當單場景模塊可以串聯起來，造成流程化 AI 運維，也就達到了三級的層次。

目前業界基本上處於從一二級，往二三級努力的階段，想實現4、五級還比較遠。

你們都知道，如今 AI 應用強、技術成熟，能被普遍應用的基本上僅有兩個模塊——語音識別和人臉識別。語音及人臉識別可以快速得以發展，主要由於國內市場的需求，及國內大人口基數下普遍的數據資源。

運維領域數據較少，且信息比較碎片化，這使得 AIOps 發展緩慢。日誌易五年前開始作日誌分析的時候，主要也是得益於海量的日誌數據，AI算法的應用下，得以實現智能日誌分析。目前日誌易智能日誌中心處於 AIOps 五等級的二級到三級之間。

1.2智能日誌中心介紹

爲了幫助你們實現更高級的 AIOps 能力，日誌易打造了一個智能日誌中心。以下圖，爲智能日誌中心的全景架構圖。

咱們都知道， AI 重要的是數據。因此，首先咱們要具有儘可能多類型的數據採集、處理及分析能力。

日誌易支持 Linux、Windows、AIX、HPUX 等各類平臺的數據採集，也能採集 ODBC、Syslog、APM 的數據，甚至手機 App 埋點數據，而後配合一些 CMDB 數據，流程工單數據，很是方便地實現業務運維層面的關聯分析。

採集以後，咱們有數十種 ETL 方法來對日誌進行規範化處理。日誌自己是非結構化的，而日誌分析須要格式化的數據，ETL 作好了，後續的分析才容易展開。

這個環節，會涉及到一些數據脫敏及業務日誌串聯，對於一些時間戳設計不合理的日誌，日誌易會自動對其進行補全，以便後續分析工做的展開。

對數據進行搜索時，業界主流開源解決方案是 ES。然而，因爲 ES 開源引擎是一個通用的搜索引擎，難以知足日誌處理的一些特殊需求，用Java 開發，內存消耗及性能上存在很大優化空間，在面臨海量日誌數據時，ES 每每顯得力不從心。

基於以上緣由，日誌易本身開發了比通用引擎快 5 倍以上的 Beaver 搜索引擎，保證了海量數據的實時存取。咱們還有上百個 SPL 指令進行統計分析，有多種不一樣場景的算法。搜索引擎能夠說是 AIOps 的大腦。

咱們有日誌易智能日誌中心，也有基於日誌開發的智能運維應用 Lynxee、大屏 Galaxee、數據工廠。安全審計、業務關聯分析等解決方案，也是基於智能日誌中心實現的。

智能日誌中心能夠與大屏展現、告警推送、按需調用腳本執行、公開的數據 API 和第三方平臺對接，這一部分能夠說是 AIOps 的手。

以上這些合在一塊兒，就是整個智能日誌中心，咱們也能夠把它看做 AIOps 的中控（或者中臺）。

日誌易有上百種不一樣類型數據的採集分析方案，能夠直接導入安裝，如思科、F五、天融信等各類網絡設備日誌，Oracle、MySQL 等數據庫日誌，Nginx、Apache 等中間件日誌等。這些內置數據採集分析方案，能夠節省數據採集處理的時間。

咱們在實踐中發現，作一個運維數據中心，70% 以上的時間是在作數據採集和處理。真正處理好了之後的分析過程仍是很快的。這和 AI 界說人工智能 80% 的工做是數據清洗，是比較吻合的。

2、圍繞日誌的 AIOps 場景與算法原理介紹

2.1AIOps 場景

說到 AIOps 的場景，咱們能夠從成本、質量、效率三個方面作出規劃，以下圖：

以質量保障而言，以往的異常檢測，須要運維工程師基於本身的經驗作出判斷和分析，咱們要作的，是藉助AI來實現這一目的。

故障的發生都是有先兆的，可能表現爲延時逐漸增大，響應逐漸變慢等。咱們能夠基於這些先兆及歷史數據作出模型，對即將發生的異常作出預判。

成本管理和效率提高要面臨的狀況更加複雜。成本管理面臨成本優化、資源優化、容量規劃、性能優化等複雜場景。

效率提高涉及複雜度較高的智能變動、智能問答、智能決策、容量預測等，以雙十一容量預測爲例，要基於歷史數據預估流量，同時結合業務（如促銷活動帶來的增量）等因素綜合分析。縱然如此，預估也每每會和現實存在較大出入。

就目前的階段，質量保障仍是最關鍵、性價比很高的，是能夠首先實現智能化的部分。咱們的智能日誌中心，目前主要關注的也是這個方向。

具體來講，在質量保障上，運維人員但願作到的，就是儘早告警、儘快定位、儘快修復。表如今「日誌+算法」的 AIOps 實踐上，具體流程爲如下三步：

一、快速發現故障：即基於多種算法進行異常預測；

二、問題歸因定位：即經過日誌模式洞察罕見報錯信息；

三、輔助修復決策：即經過多方位展示系統狀態加速決策。

2.2AIOps 之快速發現故障

快速發現故障即儘快告警。告警的本質，是告訴運維人員兩件事情：一，有問題了；二，問題有多嚴重。

咱們從日誌直接產生告警，或者通過統計分析變成時序指標，再監控告警。經過整合告警的優先級和重要程度，擬合出來一個服務的健康度，讓用戶對系統狀態一目瞭然。

通常而言，監控系統會有兩種告警：一種是匹配關鍵字，一種是採樣指標的閾值對比。匹配關鍵字的嚴重性，就是匹配 warning、critical 等；閾值的嚴重性，就是定義多個閾值區間，好比 CPU 大於 80% 發中危告警、大於 120% 發高危告警。在智能日誌中心，這兩種告警都支持。

從日誌、時序指標的監控告警，到服務健康度、故障定位，日誌易有一整套監控流程，這是智能日誌中心的重要組成部分，位於引擎的上層。告警這部分仍是以質量保障和 AI 算法爲主。

2.3AIOps 之問題歸因定位

2.3.1指標異常檢測

《SRE》是這幾年很火的書了，裏面有個概念值得推薦，就是所謂「黃金指標」。

無論是主機設備層面，仍是應用服務層面，或者集羣、端到端等等，均可以從延遲、流量、錯誤和飽和度四個最關鍵的角度，來衡量它的健康狀態。

在日誌易中，咱們能夠經過 SPL 語句，快速從不一樣的日誌數據，轉換成爲對應的指標數據。只須要更換紅字這段過濾條件，就能夠作到全面的指標數據覆蓋。

既然有了指標數據，下一步要考慮的就是如何智能地檢測指標，以便根據歷史狀況，智能地發現問題了。

由於指標的千差萬別，很難有一種單一的普適算法。因此日誌易針對不一樣場景需求，啓用不一樣的算法。下面稍微介紹部分算法的原理。

CVAE 算法

咱們都知道 VAE是深度學習裏的一種，通常你在網上搜這個算法解釋，都是講怎麼作圖像識別的。

指標就是一個很簡單的曲線，因此咱們把曲線按照滑動窗口的形式，切割成一段一段的小曲線，合在一塊兒，就成了一個特徵矩陣了，而後進入多層的編碼解碼，反覆迭代，獲得更好的模型。

爲了提升效果，在訓練數據上，還能夠主動添加一些噪聲偏差。

而後實際檢測的時候，咱們就把測試數據通過編解碼得出來的一小段模擬曲線的分佈，和實際數據做對比，是否是發生了嚴重偏離。由於模擬曲線是正態分佈的，因此這個偏離就是 3Sigma。

這個算法，很適合作強週期性的指標檢測。通常來講，由大量人羣行爲產生的數據，像業務訪問，就很適合。

咱們在這塊還有一個創新：增強了時間特徵上的處理。咱們知道，人的行爲確定是有大小週期的，今天和昨天、本週一和上週1、每月一號、每一年春節、每一年 61八、雙十一等，都是在算法上會重點增強學習的行爲。

iForest 算法

第二個是 iForest 算法，這是一個專門用來作異常檢測的隨機森林算法變種。

它適合一些和時間沒有強相關性的指標，好比主機的 CPU、內存等，數據自己離散度較大，沒有什麼規律，可能主要關心的就是它不要出現太明顯的偏離。

這種指標比較多，要求算法檢測速度夠快。

KDE 算法

第三個是 KDE 算法，這個算法針對的是一類特殊的場景。

咱們知道，有些服務並非 7x24 小時運行的。好比股票市場，天天 9 點開盤，15 點收盤。在閉市的時候，證券公司相關係統的業務指標徹底是零。閉市和開市兩個階段，涇渭分明，普通算法在這兩個躍遷的時刻幾乎確定是要誤報的。

同理，還有不少理財之類的金融場景，在週末兩天無業務輸出也是一個道理。

因此咱們按照天的維度，對天天的每一個時間點都選取它周圍的若干個點，造成一個集合，進行核密度分析，而後一天的全部點合起來，獲得最終的 KDE 模型。

這個模型有點相似於在 3D 地圖上，無數個正態分佈堆在一塊兒造成的山巒。那麼檢測的時候，對應時間過來的值，若是出如今平原地帶，就是明顯的異常了。

GRBT 算法

GRBT 算法，咱們會同時提取時序數據的統計學特徵，以及它的時間戳特徵。它的用途場景與 KDE 和 iForest 相比，有更普遍的普適性，突變的和業務的都能用。

能夠看到這個算法原理，和前面 iForest 比較像，由於都是決策樹森林。不過 iForest 是每次部分抽樣迭代，而 Boosting 是每次根據上一次迭代的結果來從新選取分界點。

可是這是一個監督學習，想用好，須要訓練樣本里有必定的異常點標註。

有這麼多不一樣的算法針對不一樣的場景，運維人員根據實際的區別，選用不一樣的算法，就能夠達到比較好的算法覆蓋了。

日誌易後續也會繼續研究指標數據的類型自動判斷，儘可能減小運維配置選取算法的工做量。

2.3.2日誌異常檢測

除了指標的異常，還有就是日誌的異常。前面提到，最多見的日誌告警就是關鍵字匹配。不過，大多數系統的研發，不會把日誌寫的那麼規範。

2016 年，中科院《軟件學報》發過一篇國防科大的《大規模軟件系統日誌研究綜述》，裏面引用了很多國內外的調查分析。其中有幾條數據蠻有趣的：

日誌代碼的更新頻率比其餘代碼要快約1倍；

約四分之一的日誌修改是把新的程序變量寫入日誌；

約一半的日誌修改是對日誌消息靜態文本的修改。

這些研究通常都是基於大型分佈式項目，好比 Hadoop、OpenStack 等。企業內部的系統開發，狀況應該會比這些著名的項目要嚴重的多。因此，你們輸出日誌的時候，很難作到特別規範，日誌格式常常在變更……

因此，依賴關鍵字或者固定的某種正則表達式提取，在長期運行的場景下，是不足以作到日誌異常檢測的，這時就須要 AI 算法來幫忙。

層次聚類獲得日誌模式

日誌易的思路，是採用層次聚類。

先對日誌進行最基礎的分詞和類型判斷，而後聚類合併。聚類能夠用最長子串，也能夠用文本頻率等等。聚類裏，不一樣的部分就用通配符替換掉。相似這張示意圖，把 8 條日誌，先合併成 4 個日誌格式，合併成 2 個，再合併成 1 個。

在研究領域，咱們通常把這種日誌格式的樹狀結構，叫模式樹。

固然咱們實踐的時候，不用真的算到最頂端，通常來講，模式數量收斂速度差很少了，或者模式裏的通配符數量差很少了，就能夠停下來了。

日誌模式的用法

獲得日誌模式，具體怎麼用呢？通常來講，有兩種用法，故障定位和異常檢測。

故障定位

一種是故障定位的時候。好比咱們查錯誤日誌，單純用關鍵詞，可能出來幾百上千條。你要一個一個看過去，翻好幾頁，耗時就比較長了。若是內容字不少，還可能看漏了。

模式 樹的信息，能夠直接查看匹配關鍵字的日誌的模式狀況，可能就只有那麼三五條信息，一眼就能夠看完，很快就能夠知道問題在哪，就能夠進行下一步了。

異常檢測

另外一個用途，就是把獲得的，加載到日誌採集的實時處理流程裏，進行異常檢測，提早發現問題，這時候，咱們除了模式，還能夠檢測參數，檢測佔比。

上圖是一個最簡單的示例，3 條日誌，獲得的模式是*are<NUM>，而後咱們同時能夠檢測符合這個模式的日誌，前邊的只能是 we 或 you，第三位只能落在平均值爲 93.三、標準差爲 9.4 的正態分佈區間內。

而後日誌採集進來，先檢測一下這個模式是否是合法的。若是合法，再檢測一下各個參數位置的取值是否是合法的。若是依然合法，再檢測一下這段時間這個模式的日誌數量，和以前相比是否是正常的。

這麼三層檢測下來，至關於把模式異常、數值異常、時序指標異常融合到了一塊兒。

這張截圖就是日誌異常檢測的一個歷史列表。能夠看到，哪怕在 INFO 級別，也是可能出現你歷來沒見過的古怪日誌的，這就須要密切關注了。

固然，由於日誌量特別大，因此他的訓練樣本很容易錯過一些正常狀況，因此上線初期，咱們須要一些迭代以及標註的優化過程。把初始樣本不斷豐富起來。

前面說了不少 AI 算法：如何來發現異常，定位異常。可是很惋惜，定位異常這件事情，目前很難作到能找出很是理想的根因的程度。通常的作法，是依賴於雲平臺、容器平臺的指標採集，作到定位出某臺機器有問題，具體仍是要登錄機器分析。

咱們從日誌的角度，能夠定位到某臺機器的一段日誌有問題，可是也不算找到 100% 的根因了，還須要後續查詢分析。

因此，作一個智能日誌中心，咱們也還須要提供更全面的統計分析和快速查詢的能力，來完成對全局的、細節的運行狀態的觀測，以及對變化的即時捕捉。

3、日誌分析實踐與案例

3.1業務交易的實時統計分析

對應前面說的 VAE 算法，咱們說他最適合的就是監控業務交易量這類指標。

咱們能夠經過儀表盤的可視化效果，對業務交易量的各個不一樣維度，進行很是細緻的統計分析。這樣有什麼變更的時候，一眼就能看到。

固然，因爲交易分析的常見維度比較少和明確，後續也能夠經過決策樹算法，來自動定位哪些維度的異常更明顯地形成了變化，好比某個省某個運營商某個手機型號打開慢之類。

從實踐來講，這種基於性能優化目的的根因分析，即便分析出來，後續的優化成本也比較高，極可能從性價比考慮，會放棄掉。

交易量指標仍是像這樣用來作實時統計和監控比較多。

3.2業務監控-多層業務指標鑽取

若是是業務結構比較複雜的場景，可能單看最終用戶層面的交易維度不足以定位故障。咱們還須要從內部的業務流轉關係來調查問題。這時候，就能夠用拓撲圖來觀測系統運行狀態。

在運行狀態出異常的時候，經過鑽取跳轉，把每層的狀況和調查路徑串聯起來。哪怕很基礎的運維人員，也能夠熟練地按照高級工程師定義好的路徑排查問題。

3.3業務監控-調用鏈展現分析

業務分析的另外一個層面，是針對用戶的分析，相似如今很流行的 Tracing 調用鏈系統。

對於智能日誌中心來講，Tracing 數據也是能很好支持的。在這個基礎上，能夠作到很好的展現。

日誌易提供了標準的調用鏈表格，還提供了循序圖分析。這是業界比較少見的方式，但對研發人員很友好，由於系統設計的時候，循序圖是研發人員很熟悉的方式。

3.4用戶端監控－DNS/CDN 日誌分析

除了系統內部，還能夠從 DNS 和 CDN 廠商獲取日誌，甚至包括收集本身的手機 App 日誌，來了解、監控端到端的狀況。

以上截圖，展現了 10TB 級別日誌量的實時返回碼趨勢分析、各站點緩存率分析、各站點響應時長分析、流量峯值分析，以及用戶行爲軌跡分析、高頻請求客戶分析、熱門站點分析、域名與運營商關係分析等。

此外，基於這些日誌能夠實現性能監控、故障排查等，也能夠跟第三方廠商的計費作二次覈算。

以上文字版根據《大咖·來了》第3期《海量日誌分析與智能運維》整理，回放連接：http://aix.51cto.com/activity/10011.html?dk=wz