一、AIOps 與智能日志中心

1.1AIOps 五等級

要說智能日志中心，首先要了解什么是智能運維。目前業界對智能運維的運用，主要分為如下五個等級。

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

 

一級還沒有成熟的單點應用，當有了一個成熟的單點應用，就算是達到二級。二級必須要有一定的基礎設施建設作為前提。當單場景模塊能夠串聯起來，形成流程化 AI 運維，也就達到了三級的層次。

 

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

 

大家都知道，現在 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 的中控（或者中臺）。

 

日志易有上百種不同類型數據的采集分析方案，可以直接導入安裝，如思科、F5、天融信等各種網絡設備日志，Oracle、MySQL 等數據庫日志，Nginx、Apache 等中間件日志等。這些內置數據采集分析方案，可以節省數據采集處理的時間。

 

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

 

二、圍繞日志的 AIOps 場景與算法原理介紹

 

2.1AIOps 場景

 

說到 AIOps 的場景，我們可以從成本、質量、效率三個方面做出規劃，如下圖：

以質量保障而言，以往的異常檢測，需要運維工程師基于自己的經驗做出判斷和分析，我們要做的，是借助AI來實現這一目的。

 

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

 

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

 

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

 

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

 

具體來說，在質量保障上，運維人員希望做到的，就是盡早告警、盡快定位、盡快修復。表現在“日志+算法”的 AIOps 實踐上，具體流程為以下三步：

 

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

2、問題歸因定位：即通過日志模式洞察罕見報錯信息；

3、輔助修復決策：即通過多方位展現系統狀態加速決策。

 

2.2AIOps 之快速發現故障

 

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

 

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

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

 

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

 

2.3AIOps 之問題歸因定位

 

2.3.1指標異常檢測

 

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

 

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

在日志易中，我們可以通過 SPL 語句，快速從不同的日志數據，轉換成為對應的指標數據。只需要更換紅字這段過濾條件，就可以做到全面的指標數據覆蓋。

 

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

 

因為指標的千差萬別，很難有一種單一的普適算法。所以日志易針對不同場景需求，啟用不同的算法。下面稍微介紹部分算法的原理。

 

CVAE 算法

 

我們都知道 VAE是深度學習里的一種，一般你在網上搜這個算法解釋，都是講怎么做圖像識別的。

指標就是一個很簡單的曲線，所以我們把曲線按照滑動窗口的形式，切割成一段一段的小曲線，合在一起，就成了一個特征矩陣了，然后進入多層的編碼解碼，反復迭代，得到更好的模型。

 

為了提高效果，在訓練數據上，還可以主動添加一些噪聲誤差。

 

然后實際檢測的時候，我們就把測試數據經過編解碼得出來的一小段模擬曲線的分布，和實際數據作對比，是不是發生了嚴重偏離。因為模擬曲線是正態分布的，所以這個偏離就是 3Sigma。

 

這個算法，很適合做強周期性的指標檢測。一般來說，由大量人群行為產生的數據，像業務訪問，就很適合。

 

我們在這塊還有一個創新：加強了時間特征上的處理。我們知道，人的行為肯定是有大小周期的，今天和昨天、本周一和上周一、每個月一號、每年春節、每年 618、雙十一等，都是在算法上會重點加強學習的行為。

 

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.3、標準差為 9.4 的正態分布區間內。

 

然后日志采集進來，先檢測一下這個模式是不是合法的。如果合法，再檢測一下各個參數位置的取值是不是合法的。如果依然合法，再檢測一下這段時間這個模式的日志數量，和之前相比是不是正常的。

 

這么三層檢測下來，相當于把模式異常、數值異常、時序指標異常融合到了一起。

這張截圖就是日志異常檢測的一個歷史列表?？梢钥吹剑呐略?INFO 級別，也是可能出現你從來沒見過的古怪日志的，這就需要密切關注了。

 

當然，因為日志量特別大，所以他的訓練樣本很容易錯過一些正常情況，所以上線初期，我們需要一些迭代以及標注的優化過程。把初始樣本不斷豐富起來。

 

前面說了很多 AI 算法：如何來發現異常，定位異常。但是很可惜，定位異常這件事情，目前很難做到能找出非常理想的根因的程度。一般的做法，是依賴于云平臺、容器平臺的指標采集，做到定位出某臺機器有問題，具體還是要登陸機器分析。

 

我們從日志的角度，可以定位到某臺機器的一段日志有問題，但是也不算找到 100% 的根因了，還需要后續查詢分析。

 

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

 

三、日志分析實踐與案例

 

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

 

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

 

我們可以通過儀表盤的可視化效果，對業務交易量的各個不同維度，進行非常細致的統計分析。這樣有什么變動的時候，一眼就能看到。

當然，由于交易分析的常見維度比較少和明確，后續也可以通過決策樹算法，來自動定位哪些維度的異常更明顯地造成了變化，比如某個省某個運營商某個手機型號打開慢之類。

 

從實踐來說，這種基于性能優化目的的根因分析，即使分析出來，后續的優化成本也比較高，很可能從性價比考慮，會放棄掉。

 

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

 

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

 

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

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

 

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

 

業務分析的另一個層面，是針對用戶的分析，類似現在很流行的 Tracing 調用鏈系統。

對于智能日志中心來說，Tracing 數據也是能很好支持的。在這個基礎上，可以做到很好的展示。

 

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

 

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

 

除了系統內部，還可以從 DNS 和 CDN 廠商獲取日志，甚至包括收集自己的手機 App 日志，來了解、監控端到端的情況。

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

 

此外，基于這些日志可以實現性能監控、故障排查等，也可以跟第三方廠商的計費做二次核算。