背景及現(xiàn)狀

奇安信集團(tuán)作為一家網(wǎng)絡(luò)安全公司，專(zhuān)門(mén)為政府、企業(yè)，教育、金融等機(jī)構(gòu)和組織提供企業(yè)級(jí)網(wǎng)絡(luò)安全技術(shù)、產(chǎn)品和服務(wù)，奇安信的 NGSOC 產(chǎn)品的核心引擎是一個(gè) CEP 引擎，用于實(shí)時(shí)檢測(cè)網(wǎng)絡(luò)攻擊，其技術(shù)演進(jìn)過(guò)程如下圖所示。

2015 年開(kāi)始使用基于 Esper 的 CEP 方案，但是當(dāng)時(shí)遇到了很多問(wèn)題，其中最顯著的是性能問(wèn)題，因?yàn)?Esper 對(duì)于規(guī)則條目的支持?jǐn)?shù)量不多，一般情況下超過(guò)幾十條就會(huì)受到嚴(yán)重影響；

2017 年奇安信的技術(shù)方案演進(jìn)到了使用 C++ 實(shí)現(xiàn)的 Dolphin 1.0，其在單機(jī)上的性能表現(xiàn)大幅度提升；

2018 年奇安信決定將技術(shù)方案全面轉(zhuǎn)向基于 Flink 的 Sabre。

奇安信產(chǎn)品具體的應(yīng)用場(chǎng)景是企業(yè)系統(tǒng)的安全檢測(cè)和數(shù)據(jù)分析，其自下而上分為四個(gè)業(yè)務(wù)處理流程，分別是數(shù)據(jù)的采集、解析、處理和展示結(jié)果，這其中最核心的是第三層數(shù)據(jù)處理。該產(chǎn)品的用戶主要是安全規(guī)則團(tuán)隊(duì)，其可以使用規(guī)則編輯器來(lái)對(duì)安全規(guī)則進(jìn)行添加、刪除、編輯和查找操作，并可批量啟動(dòng)/停用多個(gè)規(guī)則，同時(shí)可以將處于啟動(dòng)狀態(tài)的有效規(guī)則統(tǒng)一發(fā)送給產(chǎn)品。

在數(shù)據(jù)規(guī)模方面，產(chǎn)品解決的不是一個(gè)或幾個(gè)大型數(shù)據(jù)集群的問(wèn)題，而是數(shù)以百計(jì)的中小型數(shù)據(jù)集群的運(yùn)維問(wèn)題。在 B2B 領(lǐng)域，由于產(chǎn)品是直接部署到客戶方，很多客戶使用的是內(nèi)部隔離網(wǎng)，無(wú)法連接外網(wǎng)，且沒(méi)有專(zhuān)門(mén)人員負(fù)責(zé)集群的運(yùn)維，這種情況下哪怕一個(gè)小升級(jí)都會(huì)耗費(fèi)大量時(shí)間。因此，產(chǎn)品更多關(guān)注該領(lǐng)域下數(shù)據(jù)集群可運(yùn)維性問(wèn)題的解決。

奇安信在最初計(jì)劃使用 Flink 作為技術(shù)方案并進(jìn)行調(diào)研的過(guò)程中，發(fā)現(xiàn)了其一系列的痛點(diǎn)問(wèn)題。由于企業(yè)級(jí)硬件資源環(huán)境受限，規(guī)則集數(shù)量及種類(lèi)不確定，使得 Flink 程序運(yùn)行難以控制，并且現(xiàn)有的庫(kù)“Flink SQL”和“Flink CEP”均不能滿足其業(yè)務(wù)性能需求。具體的痛點(diǎn)如下：

**1.不能進(jìn)行語(yǔ)義優(yōu)化、不便于動(dòng)態(tài)更新規(guī)則。 ** 網(wǎng)絡(luò)安全事件井噴式發(fā)生的今天，安全需求迅速擴(kuò)展。為了能夠在有限時(shí)間內(nèi)對(duì)特定語(yǔ)義的快速支持，關(guān)聯(lián)引擎的整體架構(gòu)必須異常靈活，才能適應(yīng)未來(lái)安全分析場(chǎng)景的各種需求，而基于開(kāi)源關(guān)聯(lián)引擎實(shí)現(xiàn)的產(chǎn)品會(huì)在激烈的需求變化時(shí)遇到很多問(wèn)題。

2.狀態(tài)監(jiān)控 & 高可用支持不足。

面向企業(yè)級(jí)的網(wǎng)絡(luò)安全監(jiān)測(cè)引擎具有一些特定需求，當(dāng)前解決方案對(duì)此支持較差。

比如，現(xiàn)實(shí)情況中客戶對(duì)算子實(shí)例和 Taskmanager 概念較為模糊，真正關(guān)心的運(yùn)行狀態(tài)的基本單位是規(guī)則。Flink 監(jiān)控頁(yè)面顯示的是算子實(shí)例及 Task manager 進(jìn)程整體內(nèi)存的運(yùn)行狀態(tài)，而在網(wǎng)絡(luò)安全監(jiān)控的業(yè)務(wù)場(chǎng)景中，對(duì)運(yùn)行狀態(tài)和資源的監(jiān)控均需要細(xì)化到規(guī)則層面。

其次，在算子層面，F(xiàn)link 原生 Window 算子，沒(méi)有較好的資源（CPU / 內(nèi)存）保護(hù)機(jī)制，且存在大量重復(fù)告警，不符合網(wǎng)絡(luò)安全監(jiān)測(cè)領(lǐng)域的業(yè)務(wù)需求。

再次，F(xiàn)link 缺乏一些必要算子，例如不支持“不發(fā)生算子”。一個(gè)較為常見(jiàn)的應(yīng)用場(chǎng)景，某條規(guī)則指定在較長(zhǎng)時(shí)間內(nèi)沒(méi)收到某臺(tái)服務(wù)器的系統(tǒng)日志，則認(rèn)為此臺(tái)服務(wù)器發(fā)生了異常，需要及時(shí)通知用戶。

3.CEP 網(wǎng)絡(luò)負(fù)載高、CPU 利用率低。

和互聯(lián)網(wǎng)企業(yè)內(nèi)部使用的大型集群相比，奇安信面向的企業(yè)級(jí)應(yīng)用集群規(guī)模較小，硬件資源受限，且客戶的定制需求較多，導(dǎo)致安全監(jiān)測(cè)的規(guī)則要求更嚴(yán)格，引擎發(fā)布成本較高。但是，現(xiàn)有的 Flink 開(kāi)源解決方案，或者需要根據(jù)業(yè)務(wù)需求進(jìn)行改造，或者性能較差，均不能較好地解決上述問(wèn)題。

首先，原生 Flink 只提供了函數(shù)式編程模式，即需要手動(dòng)編寫(xiě)復(fù)合特定業(yè)務(wù)需求的固定程序代碼，由此導(dǎo)致開(kāi)發(fā)測(cè)試周期較長(zhǎng)，不便于動(dòng)態(tài)更新規(guī)則，可復(fù)用性較弱，且不能從全局語(yǔ)義層面進(jìn)行優(yōu)化，性能較差。

其次，F(xiàn)link-CEP 僅是一個(gè)受限的序列算子，在運(yùn)行時(shí)需要將所有數(shù)據(jù)傳輸?shù)?CEP 算子，然后在 CEP 算子中串行執(zhí)行各個(gè)條件語(yǔ)句。這種匯集到單點(diǎn)的運(yùn)行模式，較多的冗余數(shù)據(jù)需要執(zhí)行條件匹配，由此產(chǎn)生了不必要的網(wǎng)絡(luò)負(fù)載，而且降低了 CPU 利用率。

再次，還存在一些非官方開(kāi)源的輕量級(jí) CEP 引擎，比如 Flink-siddhi，功能簡(jiǎn)單，不是一個(gè)完整的解決方案。

其他的痛點(diǎn)問(wèn)題還包括不支持空值窗口出發(fā)、以及聚合不保存原始數(shù)據(jù)等。

為了解決上述問(wèn)題，奇安信在 Flink 的基礎(chǔ)上推出了一種全新的 CEP 引擎， Sabre。其整體架構(gòu)如下圖所示，其中包含三大核心模塊，左側(cè)是配置端，中間是 Sabre-server，右側(cè)是 Sabre 運(yùn)行端。核心數(shù)據(jù)流存在兩條主線，紅線表示規(guī)則的提交、編譯、發(fā)布和運(yùn)行流程。綠線表示狀態(tài)監(jiān)控的生成、收集、統(tǒng)計(jì)和展示流程。如圖所示，此架構(gòu)與 Hive 極為相似，是一種通用的大數(shù)據(jù) OLAP 系統(tǒng)架構(gòu)。下面詳細(xì)介紹三大核心模塊和兩大核心數(shù)據(jù)流。

首先，通過(guò)規(guī)則配置端創(chuàng)建規(guī)則，采用性能保護(hù)配置端修改性能保護(hù)策略；

然后，將任務(wù)所屬的規(guī)則文件和性能保護(hù)策略文件一并推送到 Sabre-server 提供的 REST 接口，該接口會(huì)調(diào)用文件解析及優(yōu)化方法構(gòu)建規(guī)則有向無(wú)環(huán)圖。

接著，執(zhí)行詞法語(yǔ)法分析方法，將規(guī)則有向無(wú)環(huán)圖中各個(gè)節(jié)點(diǎn)的 EPL 轉(zhuǎn)換為與其對(duì)應(yīng)的 AST（AbstractSyntax Tree，抽象語(yǔ)法樹(shù)），再將 AST 翻譯為任務(wù) java 代碼。

最后，調(diào)用 maven 命令打包 java 代碼為任務(wù) jar 包，并將任務(wù) jar 包及基礎(chǔ)運(yùn)行庫(kù)一并提交到 Flink-on-YARN 集群。

Flink 有多種運(yùn)行模式（例如 standalone Flink cluster、Flink cluster on YARN、Flink job on YARN 等），Sabre 采用了“Flink job on YARN”模式，在奇安信 NGSOC 應(yīng)用的特定場(chǎng)景下，采用 YARN 可統(tǒng)一維護(hù)硬件資源，并且使用 Flink job on YARN 可與 Hadoop 平臺(tái)進(jìn)行無(wú)縫對(duì)接，以此很好的實(shí)現(xiàn)了任務(wù)間資源隔離。

在 Sabre 任務(wù)執(zhí)行過(guò)程中，Kafka 數(shù)據(jù)源向引擎提供原始事件。引擎處理結(jié)果分為回注事件和告警事件兩類(lèi)。告警事件會(huì)輸出到目的 Kafka，供下級(jí)應(yīng)用消費(fèi)?；刈⑹录硎疽粭l規(guī)則的處理結(jié)果可直接回注到下級(jí)規(guī)則，作為下級(jí)規(guī)則的數(shù)據(jù)源事件，由此可實(shí)現(xiàn)規(guī)則的相互引用。

綠線流程表示任務(wù)執(zhí)行過(guò)程中會(huì)定時(shí)輸出節(jié)點(diǎn)的運(yùn)行監(jiān)控消息到 Sabre-server 的監(jiān)控消息緩存器，然后監(jiān)控消息統(tǒng)計(jì)器再匯總各個(gè)規(guī)則實(shí)例的運(yùn)行監(jiān)控消息，統(tǒng)計(jì)為整條規(guī)則的運(yùn)行監(jiān)控狀態(tài)，最后通過(guò) Sabre-server 提供的 REST 接口推送給規(guī)則監(jiān)控端。

技術(shù)架構(gòu)

Sabre 的組件依賴(lài)與版本兼容情況如下圖所示。

大多數(shù)情況下，奇安信會(huì)以黑盒的方式發(fā)布產(chǎn)品，但是如果用戶方已經(jīng)部署大數(shù)據(jù)處理平臺(tái)，則產(chǎn)品會(huì)以 APP 的方式提供使用。

由于客戶規(guī)模較大，項(xiàng)目種類(lèi)較多，部署環(huán)境較為復(fù)雜，或者存在多種 Yarn 集群版本，或者 Sabre 需作為單一 Flink 應(yīng)用發(fā)布到客戶已部署的 Flink 集群。

如何節(jié)省成本及提高實(shí)施效率，快速適配上述復(fù)雜的部署環(huán)境是個(gè)亟需解決的問(wèn)題，為此 Sabre 的設(shè)計(jì)原則是僅采用 Flink 的分布式計(jì)算能力，業(yè)務(wù)代碼盡可能減少對(duì) API 層的依賴(lài)，以便于兼容多種 Flink 版本。

如圖所示，Deploy、Core、APIs、Libraries 四層是大家熟知的 Flink 基本的組件棧。Sabre 對(duì) API 層的依賴(lài)降到了最低，只引用了 DataStream、KeyedStream 和 SplitStream 三種數(shù)據(jù)流 API。函數(shù)依賴(lài)只包括 DataStream 的 assignTimestamps、flatMap、union、keyBy、split、process、addSink 等函數(shù)，KeyedStream 最基礎(chǔ)的 process 函數(shù)，以及 SplitStream 的 select 函數(shù)。由于依賴(lài)的 Flink API 較少，Sabre 可以很容易適配到各個(gè) Flink 版本，從而具有良好的 Flink 版本兼容性。

在算子方面，Sabre 對(duì) Flink 進(jìn)行了一系列的重構(gòu)，下圖展示了這 Flink 和 Sabre 這二者之間的對(duì)比關(guān)系，其中主要包含三列，即 Flink 原生算子、Sabre 算子和兩者之間的比較結(jié)果。比較結(jié)果主要有四種情況，相同（Same）、實(shí)現(xiàn)（Implement）、優(yōu)化(優(yōu)化)和新增（New）。Sabre 共有 13 種完全自研的核心算子，其中 Datasource、CustomKafkaSink 和 CustomDatabase 按照 Flink 接口要求做了具體實(shí)現(xiàn)，F(xiàn)ilter、Key、Join 和 Aggregation 按照 Flink 原有算子的語(yǔ)義做了重新實(shí)現(xiàn)，CustomWindow 和 Sequence 在 Flink 原有算子語(yǔ)義的基礎(chǔ)上做了優(yōu)化實(shí)現(xiàn)。

下圖展示了 Sabre 的規(guī)則與 EPL 設(shè)計(jì)。序列 Sequence、聚合 Aggregation、不發(fā)生 NotOccur、流式機(jī)器學(xué)習(xí) StreamML 和連接 Join 均屬于 Window 執(zhí)行時(shí)間包含的計(jì)算性算子。藍(lán)色虛線表示引用動(dòng)態(tài)數(shù)據(jù)（Dynamic data），紫色虛線表示 Filter 無(wú)須經(jīng)過(guò) Window 可直連輸出組件。

Window 算子

眾所周知，Join 和 Aggregation 的時(shí)間范圍由 Window 限定，而 Flink 原有 Window 算子不適合網(wǎng)絡(luò)安全監(jiān)測(cè)需求，為此 Sabre 設(shè)計(jì)了一種“自定義 Window 算子”，且重新實(shí)現(xiàn)了與“自定義 Window 算子”相匹配的 Join 和 Aggregation 算子。全新的 Window 具有以下六個(gè)主要特點(diǎn)：

實(shí)時(shí)觸發(fā)、即刻匹配：其目的是為了滿足自動(dòng)化實(shí)時(shí)響應(yīng)的需求，一旦告警發(fā)出，會(huì)及時(shí)觸發(fā)響應(yīng)；

匹配不重復(fù)：重復(fù)告警對(duì)于規(guī)則引擎來(lái)講是一個(gè)常見(jiàn)問(wèn)題，大量重復(fù)告警會(huì)增加安全人員的工作量，而該算子會(huì)將整個(gè)窗口與告警相關(guān)的事件全部清空，以此減少重復(fù)告警的數(shù)量；

糾正亂序：將 Window 窗口以特定單位為邊界切成一個(gè)個(gè)的時(shí)間槽，一旦發(fā)現(xiàn)亂序情況，插入亂序事件時(shí)可直接定位時(shí)間槽，基于流式狀態(tài)機(jī)進(jìn)行局部計(jì)算，并且窗口事件超時(shí)，同步更新計(jì)算性算子的值，并入 count 算子，刪除超時(shí)事件的同時(shí)，同步減少 count 值；

實(shí)時(shí)資源和狀態(tài)監(jiān)控：由于 Window 對(duì)與內(nèi)存和 CPU 的影響比較大，因此需要對(duì)該類(lèi)資源進(jìn)行特別監(jiān)控以及保護(hù)；

流量控制：主要是為了更好地保護(hù)下級(jí)應(yīng)用。

Sequence 序列算子

Sabre 用 EPL 對(duì) Flink CEP 實(shí)現(xiàn)的序列算子進(jìn)行了重新設(shè)計(jì)，左邊是 Flink CEP 官方代碼展示，采用程序代碼的方式拼湊“NFA 自動(dòng)機(jī)”。右邊是 Sabre 中 Sequence 算子的實(shí)現(xiàn)方式，其中包含了三個(gè)不同的 filter,通過(guò)正則表達(dá)式的使用來(lái)提升其表達(dá)的能力，并且，Sabre 將 filter 前置，無(wú)效事件不會(huì)傳輸?shù)?window 算子，從而較少了不必要的網(wǎng)絡(luò)負(fù)載。并且，只有較少的有效數(shù)據(jù)需要執(zhí)行正則匹配，降低了 CPU 利用率（filter 可以并行）。

NotOccur 不發(fā)生算子

NotOccur 是 Sabre 在 Flink 基礎(chǔ)上新增的一個(gè)算子，支持空事件觸發(fā)。

Trigger 全局算子

Sabre 還實(shí)現(xiàn)了一種針對(duì)窗口的全局觸發(fā)器 Trigger，Trigger 能夠?qū)⒍鄠€(gè)子計(jì)算性算子組合為復(fù)雜表達(dá)式，并實(shí)現(xiàn)了具有 GroupBy/Distinct 功能的 Key 算子以適配此 Trigger 算子。

Dynamic Data

Dynamicdata 可以映射為數(shù)據(jù)庫(kù)中的一個(gè)表，但是對(duì)這個(gè)表要進(jìn)行特別的優(yōu)化，具體來(lái)講，如果一個(gè)事件的 IP 在威脅情報(bào)列表中，而這個(gè)威脅情報(bào)有可能比較長(zhǎng)，比如十幾萬(wàn)行甚至更長(zhǎng)，這種情況下需要對(duì)該表數(shù)據(jù)結(jié)構(gòu)進(jìn)行優(yōu)化以提升效率。Dynamic data 可以在其他算子中使用，如 Filter、Join 等。

流式統(tǒng)計(jì)與機(jī)器學(xué)習(xí) StreamML

機(jī)器學(xué)習(xí)在網(wǎng)絡(luò)異常檢測(cè)上已經(jīng)越來(lái)越重要，為適應(yīng)實(shí)時(shí)檢測(cè)的需求，Sabre 沒(méi)有使用 Flink MachineLearning，而是引入了自研的流式機(jī)器學(xué)習(xí)算子 StreamML。

Flink MachineLearning 是一種基于批模式 DataSetApi 實(shí)現(xiàn)的機(jī)器學(xué)習(xí)函數(shù)庫(kù)，而 StreamML 是一種流式的機(jī)器學(xué)習(xí)算子，其目的是為了滿足網(wǎng)絡(luò)安全監(jiān)測(cè)的特定需求。與阿里巴巴開(kāi)源的 Alink 相比，StreamML 允許機(jī)器學(xué)習(xí)算法工程師通過(guò)配置規(guī)則的方式即可快速驗(yàn)證算法模型，無(wú)需編寫(xiě)任何程序代碼。并且，流式機(jī)器學(xué)習(xí)算子 StreamML 實(shí)現(xiàn)了“模型訓(xùn)練/更新”與“模型使用”統(tǒng)一的理念。其核心功能是通過(guò)算法、技術(shù)及模型實(shí)現(xiàn)數(shù)據(jù)訓(xùn)練及對(duì)新數(shù)據(jù)檢測(cè)。該流式機(jī)器學(xué)習(xí)算子 StreamML 引入的輸入有三類(lèi)，分別是：事件流、檢測(cè)對(duì)象和對(duì)象屬性；輸出也包含三類(lèi)，分別是：事件、告警和預(yù)警。

流式機(jī)器學(xué)習(xí)算子 StreamML 的組件棧包含三部分，從下往上依次為：機(jī)器學(xué)習(xí)方法、應(yīng)用場(chǎng)景和產(chǎn)品業(yè)務(wù)。通過(guò)基本的機(jī)器學(xué)習(xí)算法（比如：統(tǒng)計(jì)學(xué)習(xí)算法、序列分析算法、聚類(lèi)分析算法），流式機(jī)器學(xué)習(xí)算子 StreamML 可滿足具體特定的安全監(jiān)測(cè)應(yīng)用場(chǎng)景（比如：行為特征異常檢測(cè)、時(shí)間序列異常檢測(cè)、群組聚類(lèi)分析），進(jìn)而為用戶提供可理解的產(chǎn)品業(yè)務(wù)（比如：基線、用戶及實(shí)體行為分析 UEBA）。

行為特征異常檢測(cè)：根據(jù)采集的樣本數(shù)據(jù)（長(zhǎng)時(shí)間）對(duì)統(tǒng)計(jì)分析對(duì)象建立行為基線，并以此基線為準(zhǔn)，檢測(cè)發(fā)現(xiàn)偏離正常行為模式的行為。例如：該用戶通常從哪里發(fā)起連接？哪個(gè)運(yùn)營(yíng)商？哪個(gè)國(guó)家？哪個(gè)地區(qū)？這個(gè)用戶行為異常在組織內(nèi)是否為常見(jiàn)異常？

時(shí)間序列異常檢測(cè)：根據(jù)某一個(gè)或多個(gè)統(tǒng)計(jì)屬性，判斷按時(shí)間順序排列的數(shù)值序列是否異常，由此通過(guò)監(jiān)測(cè)指標(biāo)變化來(lái)發(fā)現(xiàn)安全事件。例如：監(jiān)測(cè)某網(wǎng)站每小時(shí)的訪問(wèn)量以防止 DDOS 攻擊；建模每個(gè)賬號(hào)傳輸文件大小的平均值，檢測(cè)出傳輸文件大小的平均值離群的賬號(hào)。

群組聚類(lèi)分析：對(duì)數(shù)據(jù)的特征屬性間潛在相關(guān)性進(jìn)行挖掘，將具有類(lèi)似特征值的數(shù)據(jù)進(jìn)行分組聚類(lèi)。例如：該用戶是否擁有任何特殊特征？可執(zhí)行權(quán)限/特權(quán)用戶？基于執(zhí)行的操作命令和可訪問(wèn)的實(shí)體，來(lái)識(shí)別IT管理員、DBA 和其它高權(quán)限用戶。

因?yàn)椴捎昧?Flink 作為底層運(yùn)行組件，所以 Sabre 具有與 Flink 等同的執(zhí)行性能。并且，針對(duì)網(wǎng)絡(luò)安全監(jiān)測(cè)領(lǐng)域的特定需求，Sabre 還在以下方面進(jìn)行了性能優(yōu)化：

全局組件（數(shù)據(jù)源、動(dòng)態(tài)表）引用優(yōu)化。由于 Kafka 類(lèi)型的數(shù)據(jù)源 topic 有限，而規(guī)則數(shù)量可動(dòng)態(tài)擴(kuò)展，導(dǎo)致多個(gè)規(guī)則會(huì)有極大概率共用同一個(gè)數(shù)據(jù)源，根據(jù) EPL 語(yǔ)義等價(jià)原則合并相同的數(shù)據(jù)源，進(jìn)而可以減少數(shù)據(jù)輸入總量及線程總數(shù)。

全新的匹配引擎。序列 Sequence 算子采用了新穎的流式狀態(tài)機(jī)引擎，復(fù)用了狀態(tài)機(jī)緩存的狀態(tài)，提升了匹配速度。類(lèi)似優(yōu)化還包含大規(guī)模 IP 匹配引擎和大規(guī)模串匹配引擎。在流量、日志中存在大規(guī)模 IP 和字符串匹配需求，通過(guò) IP 匹配引擎和大規(guī)模串匹配引擎進(jìn)行優(yōu)化以提高效率。

表計(jì)算表達(dá)式優(yōu)化。對(duì)于規(guī)則中引用的動(dòng)態(tài)表，會(huì)根據(jù)表達(dá)式的具體特性構(gòu)建其對(duì)應(yīng)的最優(yōu)計(jì)算數(shù)據(jù)結(jié)構(gòu)，以避免掃描全表數(shù)據(jù)，進(jìn)而確保了執(zhí)行的時(shí)間復(fù)雜度為常量值。

自定義流式 Window 算子。采用“時(shí)間槽”技術(shù)實(shí)現(xiàn)了亂序糾正功能，并具有可以實(shí)時(shí)輸出無(wú)重復(fù)、無(wú)遺漏告警的特性。

圖上字段自動(dòng)推導(dǎo)，優(yōu)化事件結(jié)構(gòu)。根據(jù)規(guī)則前后邏輯關(guān)系，推導(dǎo)出規(guī)則中標(biāo)注使用的原始日志相關(guān)字段，無(wú)須輸出所有字段，以此優(yōu)化輸出事件結(jié)構(gòu)，減少了輸出事件大小。

圖上數(shù)據(jù)分區(qū)自動(dòng)推導(dǎo)，優(yōu)化流拓?fù)洹Ｓ捎谔囟ǖ墓δ苄枰?，Window 往往會(huì)緩存大量數(shù)據(jù)，以致消耗較多內(nèi)存。通過(guò)對(duì)全局窗口 Hash 優(yōu)化，避免所有全局窗口都分配到同一個(gè) Taskmanager 進(jìn)程，由此提高了引擎整體內(nèi)存的利用率。

上圖是 Sabre 流式狀態(tài)機(jī)引擎的表示，其主要負(fù)責(zé)的功能是序列匹配。圖中左邊是標(biāo)準(zhǔn)的正則引擎，通常的流程可以從 Pattern 到語(yǔ)法樹(shù)到 NFA 再到 DFA，也可以從 Paterrn 直接到 NFA；圖左下側(cè)是一個(gè)正則表達(dá)式的 NFA 表示，右側(cè)是該正則表達(dá)式的 DFA 表示，使用該 DFA 的時(shí)候進(jìn)行了改進(jìn)（如圖中綠色線）。其目的是為了在出現(xiàn)亂序的時(shí)候提升處理性能，在亂序發(fā)生在正則表達(dá)式后半段的時(shí)候，該改進(jìn)對(duì)于性能提升的效果最好。

大規(guī)模正則引擎主要使用了兩種互補(bǔ)的方法（圖上半側(cè)和下半側(cè)）。在將 NFA 轉(zhuǎn)向 DFA 的時(shí)候，很多情況下是不成功的，這種情況下往往會(huì)生成 DFA 的半成品，稱(chēng)為Unfinished-DFA，第一種方法屬于混合狀態(tài)自動(dòng)機(jī)，包含 NFA 和 DFA，其適用于Pattern 量少于 1000 的情況。而第二種方法適用于 Pattern 量大于 1000 甚至上萬(wàn)的情況，該方法中首先需要尋找錨點(diǎn)，再做匹配，以降低整體的時(shí)間復(fù)雜度。這兩種方法相結(jié)合能夠較好地解決大規(guī)模正則匹配的問(wèn)題。

產(chǎn)品運(yùn)維

多級(jí)規(guī)則

多級(jí)規(guī)則是產(chǎn)品運(yùn)維的一個(gè)顯著特點(diǎn)。如下圖所示，為滿足復(fù)雜場(chǎng)景需求，一種規(guī)則的輸出可直接作為另一種規(guī)則的輸入。通過(guò)這種規(guī)則拆分的方式，能分層構(gòu)造較為復(fù)雜的“多級(jí)規(guī)則”。如：圖中的“暴力探測(cè)”規(guī)則結(jié)果可以直接回注到下面的“登陸成功 ”規(guī)則，而無(wú)須額外的通信組件，由此實(shí)現(xiàn)更為復(fù)雜的“暴力破解”規(guī)則。

服務(wù)化/多租戶/資源監(jiān)控

產(chǎn)品采用微服務(wù)架構(gòu)，使用多租戶、多任務(wù)來(lái)滿足多個(gè)規(guī)則引擎的使用場(chǎng)景，同時(shí)對(duì)資源進(jìn)行了實(shí)時(shí)監(jiān)控來(lái)保證系統(tǒng)的穩(wěn)定運(yùn)行。

規(guī)則級(jí)的狀態(tài)/資源監(jiān)控

規(guī)則級(jí)的狀態(tài)和資源監(jiān)控是非常重要的產(chǎn)品需求，產(chǎn)品采用分布式監(jiān)控，提供三級(jí)分布式監(jiān)控能力（用戶、任務(wù)和規(guī)則），并支持吞吐量、EPS、CPU 和內(nèi)存的監(jiān)控。

整體系統(tǒng)保護(hù)

整體系統(tǒng)保護(hù)主要涉及兩方面，即流量控制和自我保護(hù)。

流量控制：為了增強(qiáng) Sabre 引擎的健壯性，避免因規(guī)則配置錯(cuò)誤，導(dǎo)致生成大量無(wú)效告警，在輸出端做了流量控制，以更好地保護(hù)下級(jí)應(yīng)用。當(dāng)下級(jí)抗壓能力較弱時(shí)（例如數(shù)據(jù)庫(kù)），整個(gè)系統(tǒng)會(huì)做輸出降級(jí)。

自我保護(hù)：跑在 JVM 上的程序，經(jīng)常會(huì)遇到由于長(zhǎng)時(shí)間 Full GC 導(dǎo)致 OOM 的錯(cuò)誤，并且此時(shí) CPU 占用率往往非常高，F(xiàn)link 同樣存在上述問(wèn)題。自我保護(hù)功能采用了同時(shí)兼顧“Window隸屬規(guī)則的優(yōu)先級(jí)”及“Window引用規(guī)則數(shù)量”兩個(gè)條件的加權(quán)算法，以此根據(jù)全局規(guī)則語(yǔ)義實(shí)現(xiàn)自動(dòng)推導(dǎo) Window 優(yōu)先級(jí)，并根據(jù)此優(yōu)先級(jí)確定各個(gè) Window 的自我保護(hù)順序。實(shí)時(shí)監(jiān)控 CPU 及內(nèi)存占用，當(dāng)超過(guò)一定閾值時(shí)，智能優(yōu)化事件分布，以防出現(xiàn) CPU 長(zhǎng)期過(guò)高或內(nèi)存使用率過(guò)大而導(dǎo)致的 OOM 問(wèn)題。

未來(lái)發(fā)展與思考