一個完整的監控生態體系包括“監、析、控”三個環節，預警平台作為偏“析”的一環，既要對監控數據做規則分析，又要為控制系統生成預警日志，起着承上啟下的作用。監控平台收集的數據，是典型的隨着時間變化的時間序列數據（以下簡稱“時序數據”），如何針對時序數據設計靈活可控的預警引擎，是預警平台的首要任務。本文根據筆者的實踐體會，探討一下基於時序數據的微內核預警引擎架構設計，希望能給感興趣的同行帶來些許共鳴。
隨着移動互聯網、工業互聯網、物聯網、邊緣計算的興起及發展，時序數據最近兩年呈爆發式增長，根據DB-Engines公布的權威數據，可以發現在各種類型數據庫發展趨勢中，時序數據庫的發展勢頭異常強勁。
最近兩年數據庫發展趨勢
而在時序數據庫TOP 10排名中，半開源的InfluxDB作為新一代時序數據庫標桿，綜合得分遙遙領先，因此在需要存儲時序數據的應用場景中，InfluxDB無疑是首選。
時間序列數據庫綜合得分排名
特來電雲平台監控系統亦基於InfluxDB存儲監控數據，盡管InfluxDB生態有Kapacitor作為預警系統，但綜合考慮到靈活可控、功能可擴展、與業務靈活結合等需求特點，我們最終選擇了自主設計微內核的預警引擎，主要由以下三部曲組成：
一、 抓數據
任何一個數據處理系統，都源起於數據，因此預警系統首先要提供支持可擴展的數據源管理，用於從時序數據庫、關系數據庫、NO-SQL數據庫、WebAPI等抓取數據。一般可通過數據中心、數據源類型、數據源連接地址、數據庫名稱、端口、用戶名、密碼等屬性描述一個數據源實體。預警引擎啟動時，需要動態加載配置好的數據源。
二、 判規則
預警引擎本質上是一個規則引擎，需要具有高度的描述性與抽象性。幾乎全部的預警引擎，都是獨創一套表達式規范，以期通過各種表達式組合，完成對預警規則的描述。筆者認為表達式是封閉的，有門檻的，尤其需要綜合使用多個表達式進行預警描述時，很難掌握也很難理解。那對開發人員來講，什么是最容易掌握的呢？答案是SQL、SQL、SQL。
筆者認為一個典型的基於SQL的規則引擎，具有如下的結構：
|
有了數據源，SELECT DATA FROM TABLE就很容易實現，WHERE FILTER就是本節要闡述的校驗規則，THEN ACTION就是后一節要講的動作。
每一條時序數據曲線，都是對一個Tag的描述，因此依據Tag的數量以及數據的有無，可以將校驗規則進行如下分類：
如果預警引擎能提供上面校驗規則的默認實現，就可以滿足90%以上的場景，同時再提供可擴展機制，針對個性化場景支持擴展開發，動態加載不同校驗規則插件，基本上就能涵蓋所有的業務需求。
由於不同的SQL寫法，返回的數據結果可能不同，需要用一個統一的內存模型來表示結果集，而DataTable無疑是一個絕佳的選擇，因此實現校驗規則的很多工作是在做數據轉換，有了統一的數據模型后，利用DataTable的一些內置方法進行規則判斷就易如反掌了。
針對無監控數據的情況進行校驗規則判斷是一個難點，因為監控數據的上報很容易受監控系統自身波動、網絡波動等干擾，如果依賴單一校驗規則，很容易產生誤判，因此針對無監控數據的情況，要采用多校驗規則依賴判斷方式，這些依賴規則依舊是SQL，並且作為主校驗規則的參數注入到規則判斷中，從而可以靈活解決誤判問題，提高准確率。
三、 做動作
預警觸發后，需要執行的動作主要分為兩類：通知、命令。
通知方式有郵件、短信、微信、釘釘等，隨着系統規模的增長，當有故障發生時，很容易產生預警風暴：短時間內收到大量的預警消息，因此需要對預警規則划分重要級別、設置收斂區間、發送時間段，同時結合根因分析，保證運維人員收到有效的預警消息。
命令是指對控制系統下發運維指令，做一些常規的運維操作，比如重啟進程、回收應用程序池、抓取Dump、轉儲日志等，及時止損，防止系統進一步惡化。
動作這塊需要考慮的一個因素是通知的用戶，即要求預警規則對應的接收人，既可以設置靜態的默認接收人，也可以動態計算，比如根據預警實際發生時所在的機器、進程等信息計算出具體的接收人，從而做到定義一條預警規則，根據實際情況靈活發給不同接收人的效果。
四、 總結
基於時序數據的微內核預警引擎，需要提供可擴展及動態加載功能，基於SQL實現規則解析，驅動監控數據從抓取、判斷到動作流暢運轉。
五、特來電雲計算與大數據微信公眾號
1.微信公眾號名稱：特來電雲計算與大數據
2.二維碼：
