自研實時計算模塊介紹及運維數據應用場景實施
點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了?。。?/strong>
隨著現場生產業務的不斷壯大和發展，信息化系統建設的不斷推進，業務鏈條越來越長，所涉及到的業務處理環節也越來越多。各類運營數據、運維數據都呈爆炸式增長。對于我們運維團隊來說，以往通過將各類運維狀態數據或性能數據通過各種自動化運維工具采集并存放到數據庫，然后通過定時任務跑存儲過程，或者通過程序撈取一定周期的數據來進行統計分析的方式，在當前環境下已是捉襟見肘。再加上現場構建運維分析場景的需要，為了更好的分析系統運行狀態和更深入的多維運維分析，又納管了云環境指標數據、業務數據、各類日志數據、業務鏈路數據等等都接入并進行關聯分析，原有的離線（批量）計算模式已經完全不再適用了。為了解決上述運維分析的困境，我們自研了一套實時計算模塊，在各類運維數據采集后、入庫前實現對數據的加工、關聯、統計、告警等計算操作。一方面避免在數據入庫之后再撈出，減少對數據存儲組件的依賴和壓力，另一方面也大大增加運維數據分析的時效性，提升運維團隊對系統異常狀況的感知能力。值得一提的是，該自研實時計算模塊的功能，并未與數據的業務場景做任何綁定，也并不是只能用于運維數據的加工和分析場景。通過對接任何格式的流式數據，均可實現各類數據的加工、統計、規則判斷、關聯、復合統計等等處理邏輯，滿足不同的使用場景需求。
自研實時計算模塊（以下簡稱DOMP模塊）基于FLINK開源框架構建。與市面上多數的基于FLINK的通用實時計算有所不同，DOMP模塊在單個計算任務中可配置對多個指標的計算。這種架構模式的建立，來源于現場運維資源分配一般是偏小的。由于運維的價值輸出不像業務系統或經營分析系統這樣明顯和受到領導重視（雖然發生異常或故障時帶來的損失巨大……），所以我們需要考慮在有限的資源下支撐盡可能多的運維數據加工（分析），減少數據入庫后的再處理量。基于上述的背景及需求考慮，我們主要構建了以下功能模塊：
該子模塊用于管理平臺所使用到的各類PAAS層組件，包括FLINK、Kafka、Redis、mysql、ES、Oracle等。
這個功能模塊實現對FLINK集群的界面話管理功能，支持對后臺FLINK集群的新增、參數配置維護、刪除等白屏化操作管理。（本期建設中尚未實現對后臺FLINK集群的自動創建，需要在后臺建好集群后，在前臺配置將集群的屬性進行維護，用于在集群中操作創建任務，后續會考慮支持自動化方式實現集群的創建場景，并通過前臺管理對接）創建或修改FLINK集群屬性時，可以設定部署路徑、日志路徑、節點地址、checkpoint等信息。這些信息用于創建或啟動任務時的通用配置讀取。1.2 Kafka集群管理
Kafka集群管理實現將后臺搭建好的kafka集群及topic主題納入到平臺管理，記錄集群及通道的版本、zookeeper連接、broker連接、分區、副本等信息。Kafka信息用于在flink任務配置時指定接入數據源及輸出數據源配置。1.3 數據組件管理
與kafka集群管理的功能一樣，將flink任務配置時需要指定的入庫或入redis等數據組件的參數配置進行統一管理，方便任務配置時使用，一方面方便管理，另一方面也有利于在任務配置時根據數據組件配置的邏輯語義來選擇。目前平臺支持mysql、oracle、redis、es等數據組件的配置及使用。
2.1 數據類型管理
正如前述所說，運維使用的資源偏小，所以很多場景下都會存在資源復用，不同類型的數據時常會使用同一個數據管道來進行傳輸。并且數據打標的工作，上游也不一定會配合實現。由此，對于平臺來說，如果在同一個接入源（kafka-topic）中包含有多類不同的數據，如何讓不同的數據支持不同的計算規則就成為一個難題。數據類型的作用是為了在后續的數據加工、指標計算等場景中區分標識不同的數據，通過設定數據中的識別關鍵字的方式來實現。需要說明的是，對于平臺自己通過采集獲取到的數據，會在采集或分詞時設定好數據類型標識，只需要通過“導入日志模板”方式即可自動生成數據類型定義。而對于第三方平臺推送來的數據，需要配置兩次數據類型，第一次用于標識源數據中的識別關鍵字，第二次定義一個數據類型標識，然后通過“數據加工”計算的方式來完成由源數據類型到帶標識的數據類型的轉換輸出，這樣在后續的指標計算中即可使用帶數據類型標識的數據了，可以更好的提升指標計算的效率。數據類型配置時，支持從日志模板導入，也支持從kafka-topic中撈取樣例數據來提取關鍵字及屬性字段進行快速配置。2.2 計算規則管理
DOMP模塊包含加工規則、指標規則、告警規則這三類實時計算規則。2.2.1 加工規則
加工規則是指針對原始數據的基于原始的字符串狀態的加工處理，因此所有的字符串類型數據都可做加工規則配置。包含分詞規則和數據加工兩種。1）分詞規則
分詞規則在日志采集時需要配置分詞，所以將計算規則的配置合并到日志采集模板配置流程中了，使其更符合場景使用流程。需要說明的是，由于分詞規則是在FLINK平臺上實現的，與數據的采集無關。因此是可以在不中斷采集的情況下修改分詞配置并生效的。另外，通過jdbc方式采集的數據，默認會自動在采集時按sql語句輸出的字段做分詞處理，不需要通過FLINK平臺來做分詞計算。但是，基于一些場景的需求，需要將數據庫中某一些字段提取其中的關鍵信息生成新的分詞信息用于后續的統計分析，則需要配置二次分詞規則。而二次分詞是需要通過FLINK實時計算的，在具體的場景實施時要根據需求來靈活應用。分詞計算模塊支持對原始數據及分詞出來的數據做脫敏處理。對于需要脫敏的原始數據，必須配置分詞，并在分詞配置中勾選脫敏動作。分詞計算后輸出的結果數據中，不論是原始的日志數據還是分離出的關鍵字段數據，都會脫敏，且轉換值規則具有統一性，以保障數據的可關聯查詢。2）數據加工
數據加工是對于原始數據所做的加工處理，使其滿足后續的指標計算規則的格式需求或業務表達需求。數據加工功能實現的是兩種數據類型之間的轉換。即從數據類型A轉換到數據類型B，所以轉換前后的數據類型均需在數據類型管理中先行配置。數據加工的配置及處理過程中支持對原始數據（分詞后）中的字段做過濾，即滿足條件才做加工。
基于數據集加工規則
數據加工處理過程中，往往會碰到一種場景，即需要根據數據中的某個信息擴展關聯其他的信息并添加到數據中，以方便后續的統計分析。例如原始數據中存在ip地址信息，需要根據這個ip地址信息關聯到其所屬的業務系統名稱或管理部門、管理人等信息，用于相應的業務邏輯統計。
基于上述的業務場景需求，模塊實現了這種基于數據集的加工規則。通過配置一條sql語句從數據庫中查詢維表數據并加載到緩存中，當源數據類型的數據流匹配到該加工規則時，根據維表所建立的字段映射關系，將目標字段值生成添加到目標數據類型的數據中。
維表的映射關系支持兩種過濾關系：
一種是維表字段與源數據類型中字段的“等于”關系，即當A(維表).x（字段）=B（源數據）.y（字段）時，滿足條件。
另一種是維表字段與源數據類型中字段的“包含于”關系，即維表中的字段是包含多個字符串的，判斷A(維表).x（字段）in B（源數據）.y（字段）時，滿足條件。其中A(維表).x（字段）中是可以包含多個字符串的，以豎線分隔，該規則用于判斷在源數據中是否同時滿足包含多個字符串。
在現場使用該功能的過程中，還添加了一類特定的場景規則，即需要判斷某個sql語句中是否包含某些特定字符串（如特定的業務表或特定的操作關鍵字），由于sql語句中某些表名或字段名存在相似性，導致使用“包含于”規則無法正確匹配，所以我們增加了一類 “包含于（SQL專用）”規則，在匹配字段時需要額外判斷前后的空格字符，以此來區分該字符串是一個表名（或字段名、關鍵字），而不是某個其他相似字符串的一部分。
需要特別注意的是，在一個數據集加工規則中如果包含多個判斷（過濾）條件，需要先配置“等于”規則，再配置“包含于”規則。多個“等于”規則的情況下，也優先配置能過濾掉更多數據的判斷條件。這與數據庫的查詢相同，盡量減輕后面判斷邏輯的壓力。
基于源數據的轉換規則
在對源數據類型的轉化需求里，我們總結了一些特定但具備共性的轉換需求，如時間格式化轉換、ip地址歸屬地域等，并將這些規則的實現固化到數據加工模塊里。
“時間規整到分鐘”是由于原始數據在上游采集時出現數秒的延遲，而統計需要按分鐘整點進行規整。
日志里的時間格式不統一，有些有毫秒、有些只到秒，有些是linux的基于毫秒的時間戳，有些是基于秒的時間戳，需要統一按yyyy-MM-dd HH24:mm:ss來規整。
而對于ip地址，在一些安全相關的場景中，需要識別該公網ip地址歸屬的國家或地區，并在后續的統計分析中基于其歸屬地進行分類統計，因此模塊中增加了一個“ip轉歸屬”的特定規則，實現對公網ip地址的自動關聯生成其歸屬國家或地區。
數據轉換的規則是在現場使用過程中，基于業務場景逐漸添加的，后續也將不斷擴展。添加時間字段的加工規則
某些從其他平臺傳入的源數據類型，可能并不包含時間信息，而指標計算往往是需要依據時間來進行統計的，所以需要一個數據加工規則，將數據中增加一個時間字段，目前是以實時計算程序接收到數據的時間作為其數據時間。
自動復制未配置規則的同名字段
在數據加工配置過程中，從數據類型A到數據類型B的配置轉換，除了少數字段會需要使用 “基于數據集加工規則”、“基于源數據的轉換規則”、“添加時間字段的加工規則”方式來配置數據字段的加工處理，其他字段都需要沿用源數據類型的同名字段，因此增加了這個配置功能，自動完成同名字段的配置。在實際的使用過程中，應該先執行“自動復制未配置規則的同名字段”的配置動作，將可以復制的字段全部生成出來，再根據需要將其中的某些字段配置進行修改。（后續會將此配置功能實現自動化，當新增A數據類型到B數據類型的數據加工規則項時，自動復制同名字段的配置規則）
2.2.2 指標規則
指標計算是指根據業務需求，對帶有數據標識的數據進行統計分析，并輸出結果的計算過程。而指標規則配置即是統計分析業務邏輯的具體體現。在該模塊在現場的磨合過程中迭代出了以下類型的指標計算規則：1）簡單指標計算
簡單指標是面向原始數據類型的統計計算，這個模塊的設計思路是以數據類型為表，以數據類型中的屬性字段為表字段，選擇數據類型中的屬性字段作為指標key字段，實現類似sql語句的group by的分組統計邏輯。簡單指標計算在配置時需要指定統計周期，目前能支持到1,2,3,4,5,10,15,30（分鐘）的統計周期，統計是按規整時間輸出的，而不是任務的啟動時間開始計時，這樣是為了方便數據使用時的時間具有一致性。例如3分鐘的統計周期，其輸出的時間點就是按每個小時的0分，3分，6分，9分……51分，54分，57分，如此反復。另外，基于不同需求的統計口徑要求不同，還將統計輸出規整時間分為后向（默認）和前向（非默認）兩種，支持對統計輸出的時間歸屬向前或向后規整。例如按1分鐘周期做指標統計時，如果是后向（默認）統計規則，則被統計數據中08:00:03這個時間點的歸屬統計時間是08:01:00，但如果是前向統計規則，那歸屬時間點則是08:00:00，需要現場按照各自的業務規則來進行選擇。目前模塊中實現的簡單指標計算的分組統計規則包括以下幾種：
等于value值
等于value值準確來說不是一種統計邏輯，其作用的場景是針對每一條數據生成一個指標，用于實現對原始數據的指標化（格式化）。在運維場景中，從后臺主機采集到的性能數據，或從第三方平臺傳輸過來的性能數據，格式各不相同，通過“等于value值”的計算邏輯，根據業務場景的需要提取原始數據中的關鍵字段作為指標key值，以及獲取原始數據中的性能數據值作為value值，生成統一格式的指標，用于下游的應用場景。需要特別注意的是，如果數據中根據分組邏輯存在一個分組中多條數據的情況，是不適用于這種規則的。因此必須根據原始數據中各屬性字段的邏輯，在選擇分組字段時必須控制保證每個分組只會包含一條數據。舉例來說，對于一臺主機上的磁盤空間使用率的采集數據，如果分組字段只選擇了ip地址的話，使用該統計規則是無法正確生成每個磁盤的使用率的（只會獲取到第一條數據生成指標），必須在分組時選擇ip（主機ip）和dataspace_name（磁盤分區名）兩個字段，才能正確生成每一個磁盤空間的使用率指標。另一種適配使用的場景，是配合數據的過濾條件規則，獲取到某個最值數據所對應的數據的指定屬性信息。同樣舉個例子，對于獲取到的一個時間周期內某個應用集群下的所有主機的cpu使用率，如果需求是要獲取到其中cpu使用率最高的ip地址信息，則可以通過此規則配置key的分組字段是時間字段（默認自動會按時間分組，無需配置）及應用集群名（app_name），配置value字段是ip地址字段（ip），統計規則是“等于value值”，同時在數據過濾規則中，配置為cpu使用率字段（cpu_use）的操作符為“等于最大值”。
等于最大（最小）value值
最值統計是一類常用的統計規則，即按分組規則統計組內的數據某個字段的最大（最?。┲?/span>。例如統計一定時間周期內各個接口調用的最大耗時，就是一個典型的最值統計場景。根據業務統計的需要配置指標的key字段為應用集群名（app_name）和接口名（intf_name），指標value字段配置為獲取耗時字段（cost），統計規則是“等于最大value值”。
等于value平均值
均值統計是一類常用的統計規則，即按分組規則統計組內的數據某個字段的均值。例如統計一定時間周期內接口調用的平均耗時，就是一個典型的均值統計場景。根據業務統計的需要配置指標的key字段為應用集群名（app_name）和接口名（intf_name），指標value字段配置為獲取耗時字段（cost），統計規則是“等于value平均值”。
累加value值
累加value值是對原始數據某個字段數據的累加統計。例如某個應用集群包含多個應用實例，每個實例在每分鐘都會輸出服務調用請求量數據，而我們所需要展示的是這個應用集群的總服務調用請求量時，就可以使用這種規則。配置統計分組key字段是應用集群名（app_name），value字段是調用請求量（call_count）,統計規則為“累加value值”。
去重獲取所有value值
去重獲取所有value值是對原始數據某個字段中的字符串信息的整合獲取。例如在運維分析場景中，要獲取實時（1分鐘內）接口調用耗時超過15秒的所有接口名稱，可以使用該規則。配置統計分組key字段是應用集群名（app_name），配置數據過濾條件是接口調用耗時（cost）大于15000（毫秒），value字段是接口名（intf_name），規則是“去重獲取所有的value值”。該規則會將所有調用超過15秒的接口名稱去重后形成逗號分隔的清單作為指標值輸出。
去重獲取value值數量
與去重獲取所有value值類似，去重獲取所有value值同樣是對原始數據某個字段中的字符串信息的整合獲取。源于需求中需要統計的是數量，而不是明細清單。在運維分析中時長會存在同一個對象在周期時間（1分鐘內）多次輸出信息的場景。例如基于接口調用日志的數據統計分析，高頻的接口往往高達成百上千甚至上萬次，當我們需要知道一個應用集群中到底有多少個接口存在調用失敗時，需要對接口名稱去重來統計數量。上述的場景可以配置統計分組key字段是應用集群名（app_name），配置數據過濾條件是接口調用結果（result）為-1，value字段是接口名（intf_name），規則是“去重獲取value值數量”。該規則會將所有調用失敗的接口名稱去重后統計數量作為指標值輸出。
統計數量
統計數量是最常用的一類統計規則。根據業務需要調整指標key的分組字段，可以按不同的分組邏輯來對原始數據做各種維度的統計分析，結合原始數據的過濾條件，達到絕大多數統計目的。
統計比率
統計比率也是常見的數據統計需求，模塊支持按原始數據的某個字段的枚舉值，自動生成各值所占比率的指標。例如接口調用成功率的計算指標就是個很典型的例子。配置原始數據中接口名（intf_name），調用結果（result）為key的分組字段，value字段是調用結果（result），統計規則是“統計比率”。按照這個配置，會自動根據調用結果（result）的成功（0）和失敗（-1）自動生成分別的占比情況。根據上述的場景描述，相信很多人會發現，這個指標的配置實際上是會根據枚舉值的不同生成兩條指標的，而不是只生成了“成功率”這一條指標，“失敗率”這個指標就成了一個副產品輸出了。優點是在場景需求有需要時可以同時滿足，但其實缺點更明顯，會占用更多的存儲資源……需要注意的是，在使用“統計比率”規則時，不要（也無需）通過數據過濾來去除不想統計的枚舉值。例如只想統計成功率，于是想通過數據過濾的方式將調用結果（result）為失敗（-1）的數據給過濾掉，那其實是把總數減去了失敗數，統計成功比率就成100%了，失去了統計的意義。另一個需要提前考慮的點是，這種統計比率在字段枚舉值相對固定時是可控的，但如果字段可能的值會非常多的情況下，每個統計生成的指標數量是與枚舉值的數量一樣多的，也就是可能會產生海量指標數據，對實時計算和下游的傳輸、最后的存儲都帶來巨大壓力。所以在使用時需要特別慎重考慮，提前規劃。舉個例子，統計一個應用集群中的服務調用的分別占比的指標，如果這個應用集群中有1000個服務，那么理論上在一個統計周期最多就會生成1000條記錄每個服務調用次數占比的指標數據，如果再加上調用成功率的占比的話，按調用結果為成功或不成功兩類，就會有2000條指標生成。其他如統計數量等指標也類似，一定要提前預估好可能生成的指標數，避免出現不可控的“指標風暴”。
TopN
在發現上述統計比率或統計數量的方式可能存在海量指標生成的風險后，以前直接按所有枚舉值統計數量或比率，再從表中撈取前10這樣的實現方式就不太好用了。例如統計并展示調用失敗率最高的10個接口這樣的需求，如果接口數量高達數千個，那生成的指標的數量也必然是海量的，于是我們新增了TopN這樣的統計規則。這個規則在配置key分組字段和過濾條件時與其他指標規則是類似的，但在配置value字段時有較大區別。TopN的計算對象屬性字段（value）需要配置3段內容，分別是“統計對象字段”、“展示字段”、“TopN條數”，用#分隔。舉個例子，假設要統計一個應用集群的服務調用耗時top10數據指標，可以配置key的分組字段是應用集群名稱（app_name），統計規則是TopN，計算對象屬性字段即value字段是“耗時字段”#“服務名字段”#10（cost#servie_name#10）,這樣配置會輸出10條指標數據，分別對應調用耗時top10的服務名。需要說明的是，TopN的指標規則并不適用于對周期時間內的先統計再排序的場景。例如一分鐘內按接口名統計調用次數（或調用成功率），再根據調用次數（或調用成功率）進行TopN排序的需求，無法用該規則來實現。目前的實現這種場景的方式暫時只能是先按調用次數（或調用成功率）來對接口做分組統計，然后再利用入庫后的數據，使用sql語句撈取，用order by進行排序。相對來說，上述的場景實現會比較難保證實時性和效率，入庫數據量也會大很多。這也是我們為什么在大力推動計算分析過程實時化的主要原因。對于上述的這個場景，后續我們也將實現相應的通用規則來滿足實時化計算的支撐。
指標數據過濾規則
在上述指標計算的計算規則中有提到對數據的過濾規則。數據過濾規則是指在同一種數據類型中，只針對某一類數據按指標規則進行計算，其他同類型的數據并不參與統計。這個過濾規則類似于sql語句的where條件，通過對各個字段的條件判斷將數據過濾到業務邏輯所需要的范圍。需要注意的是，應優先配置能過濾掉更多數據的判斷條件。這與數據庫的查詢相同，盡量減輕后面判斷邏輯的壓力。數據過濾的規則項，與指標告警計算的規則項基本相同，放到指標告警計算中一并介紹，如需要了解的請跳轉到對應章節即可。
2）復合指標計算
復合指標計算是區別于簡單指標計算而言的，是指對同模板源指標數據（告警數據）基于同一時間戳的二次統計，或對異構源指標數據（告警數據）基于同一時間戳的二次統計。計算的源數據是經由DOMP實時計算所產生的指標數據（滿足平臺制訂的指標數據格式，可以是簡單指標計算的輸出結果，也可以是復合指標計算的結果），或基于指標的告警規則所生成的告警數據（符合平臺制訂的告警數據格式）。復合指標計算適配的場景包括以下幾種：
基于打分規則的轉換
原始采集到的源數據中的性能值或簡單指標計算輸出的指標值，是貼近原始狀態的。例如cpu使用率的百分比值，接口調用成功率的百分比值，服務調用總量的值等，都是相對真實信息的記錄。但在很多分析場景中，需要對這些值進行轉換處理。例如cpu使用率低于50%記為10分，使用率每提高10%則降2分，如果使用率大于95%則記為0分，這就需要對源指標的值做轉換操作了。上述的這個邏輯我們可以通過一個打分規則配置來實現：平臺支持配置多種打分規則，同一個打分規則可以用在不同的復合指標計算中。例如在上圖的配置中，0<值<40的會被轉換為10分，40<值<80的會被轉換為20分。操作符可以有大于，大于等于、小于、小于等于等判斷規則，對值的上下區間門限進行判斷。需要注意的是，打分規則有執行順序的判斷，對于一個指標的值，會將所有規則按順序執行一遍，最后輸出分值轉換結果。如果打分規則存在對值區間的重疊，則會以最后一條符合條件的規則來輸出轉換結果。這樣在進行指標復合計算時，該指標的值會被按打分規則轉換后再進入復合計算邏輯。
對異構源指標的組合統計
在一些分析場景中，我們需要對多種不同的指標組合來完成統計分析。計算某個對象的健康度是一個典型場景。健康度的計算往往是基于多個黃金（核心）指標項，通過加權計算的方式來實現的（雖然加權計算這種方式存在太多主觀思維，有拍腦袋的嫌疑，但在實際的場景構建中仍難以避免）。常見的健康度計算方式，是基于一個總分，按不同指標對目標業務影響程度的比重不同來設定權重值，然后對這些指標加權累加得到一個分值，用來代表當前評分對象的健康度。其中在設定各個指標的分值時會用到上面所說的“基于打分規則的轉換”邏輯，實現從指標值到分數值的轉換，不再贅述。針對每個復合計算用到的指標，可以設定一個別名，別名的定義包含字母和數字（如A1,A2,B3,C4等），在選擇自定義規則后可以使用例如A1*0.2+B1*0.3+C1*0.5這樣的四則運算公式來實現按權重的指標復合計算規則。復合指標的計算周期必須大于或等于源指標周期。例如需要對兩個源指標配置復合，一個源指標的生成周期是5分鐘，另一個是10分鐘，那么復合指標周期必須大于等于10分鐘，否則會出現在一個計算周期中源指標不滿足條件的情況。在選擇計算復合所需要使用的指標模板后，除了對指標值做分值轉換，也可以對各源指標的字段取值做固定值限制。比如根據源指標模板（主機cpu使用率）生成了所有分析對象指標，但在復合計算時只需要對其中的某一個對象（某一臺主機或某一個集群）進行復合計算，則可以在變量取值規則處限定需要過濾的字段取值。另外，由于一個源指標模板在不同的維度上存在多個指標值的情況，例如一個應用集群中包含多個主機對象，又或者復合計算的統計周期包含多個源指標的統計周期（例如：源指標統計1分鐘一次，復合指標統計30分鐘一次），那么對于這個集群（或更大事件周期）的統計分析來說是會包含有多個同源指標值的，根據需要可以使用使用指標規則獲取“最大值”、“最小值”、“平均值”、“求和”、“求數量”等邏輯計算，將計算的結果代入復合計算邏輯。
對指標告警數據的統計
在實際運維數據分析場景中，我們會用到對于告警數量的統計，并基于這個統計生成一個指標。舉個例子，我們會需要獲取一個應用集群中接口調用成功率低于85%的接口的數量，這里面就涉及到兩次的統計規則。一次是計算得到每個接口的調用成功率，另一個是統計調用成功率低于85%的接口數量。實現這個需求場景，需要先配置一個簡單指標，使用統計比率規則，就可以得到各個接口的調用成功率。對于接口成功率低于85%的指標，可以配置生成一條閾值告警規則，這樣我們就可以得到了“某接口1分鐘調用成功率低于85%”的告警數據。通過將告警數據輸出到復合計算的前置kafka-topic中，配置一個基于告警的復合指標，規則是統計某個集群中這類告警的數量，則可以得到該應用集群里接口成功率低于85%的接口數量。當然，我們也可以在此對該指標配置一個告警，例如當符合條件的接口的數量大于10個時，應該才產生一條升級的告警（無限套娃，哈哈）。還有一種場景是基于不同維度的復合指標統計。例如在一個應用集群中包含很多的主機，一臺主機有多個黃金（核心）指標項，例如cpu使用率、內存使用率、磁盤空間使用率等等。一臺主機可能同時會觸發多個告警（例如cpu和內存同時告警，又或者多個磁盤空間產生告警），而對于應用集群維度的管理需求，是需要知道這個應用集群里有多少臺主機在當前正在告警。所以在統計應用集群維度的告警主機數量時，要按主機維度做告警信息的去重統計數量。而在統計應用集群維度的告警總數時，是不應該去重統計的。上述的不同需求場景，都能在復合指標計算模塊的配置中找到對應的規則選項進行支撐。
兩種指標數據的關聯合并
在使用關系型數據庫時，常見的一個數據使用場景是根據兩張表中的某些字段相等關系，對于兩張表做關聯查詢，這樣能輸出一個包含兩張表中字段的數據視圖。在實時數據計算的場景中，我們同樣會面臨這樣的需求。例如一個用戶行為分析的場景，當某個連接使用VPN登錄企業內網獲得一個內網地址，再通過內網的防火墻訪問某個DCN的設備時，我們能分別從VPN設備日志、DCN網的防火墻日志中分別獲取到兩段數據，即數據A（外網IP、外網端口、內網IP、內網端口），以及數據B（內網IP、內網端口，DCN設備IP，DCN設備端口），原始日志數據如下（已脫敏）：在安全防護運維工作中，經常面臨的一個分析場景，是需要根據異常的DCN設備的訪問行為，去反向查找這個訪問的來源，再判斷是否要將該外網地址在VPN設備端進行封堵。以前的做法是把兩個日志數據關鍵字段提取后分別入庫到兩張表，再按表關聯查詢的方式來獲取到訪問來源外網地址。但這兩個日志的數據量都是海量的，表關聯查詢的效率難以保證，因此我們在實時計算中實現了一類復合關聯計算的邏輯。通過源數據中內網ip和內網端口這兩個關鍵字段的一致性，將外網地址與DCN網設備直接建立關聯輸出為一條指標數據，這樣在后續分析查詢時可以更高效地完成檢索工作。
3）加工指標計算
加工指標的場景和數據加工的場景是類似的，但數據加工的對象是數據類型，而加工指標的對象是指標類型。在指標已經生成后，再根據指標所包含的關鍵信息字段進行轉換或增加key規則中的關鍵信息字段。例如通過部署在主機上的agent采集到的cpu、內存等性能數據，通過簡單指標計算生成了相應的性能指標，但如果要輸出告警，還需要將指標里加入其歸屬的業務系統或責任人信息，這就需要與CMDB的配置數據庫進行關聯，為指標數據做信息擴展。另一個常見的場景是根據維表中定義的關系，將指標值進行轉換，例如“-1”轉換為“失敗”，“1”轉換為“成功”等加工，使輸出的信息具有更好的可讀性。加工指標計算的配置邏輯和數據加工是類似的，在此不再贅述。為什么我們有了數據加工，還需要做加工指標呢？這里有對計算資源消耗的考慮有關。相對來說，原始數據做加工要處理的數據量是巨大的。而指標是基于原始數據按某規則的統計輸出，數據量只有原始數據的幾分之一甚至幾百分之一。所以在指標數據的基礎上去做加工，計算量會小很多，需要分配的計算資源也可以小很多。在實際的數據加工分析場景中，也應盡量遵循少數據加工而多指標加工的方式來實現需求。2.2.3 告警規則
指標告警計算是針對前述簡單指標、復合指標、加工指標等模塊所生成的指標的告警規則配置及后臺實現。在告警配置時，需要指定該規則所作用的對象指標，如果配置界面是由指標配置界面進入時，會自動填入對應的指標信息。告警信息以指標key和value中包含的各關鍵字段信息作為變量來配置告警的內容，具備靈活配置告警輸出信息的能力。告警規則配置是以指標key和value中包含的各關鍵字段信息作為規則判斷對象，告警規則支持配置多個條件，各條件的滿足是與的關系，即必須所有條件都滿足，才會產生告警。1）等于value值
判斷指標對象字段的值與判斷條件值是否相等，是常見的判斷場景。例如判斷某個接口調用的結果是否成功，通過條件判斷result_code是否等于1即可。2）包含value值（多個值以逗號分隔）
判斷指標對象字段的值在判斷條件值的列表中是否存在。此類判斷規則多用于指標的某個字段值存在多個的情形。例如某個告警需要針對3類業務編碼進行設置，判斷busi_code為10,11,12三種，如果每種配置一條告警規則，對于后臺來說是會增加相應的計算量的。如果使用該包含value值配置，則可通過一條規則來實現配置邏輯。在這個示例中，如果指標字段busi_code的值是10，則滿足條件要求，如果是13則不滿足條件要求。包含value值規則是或的關系，即指標字段的值滿足該配置的多個value值中的一個即滿足該條件。3）不包含value值（多個值以逗號分隔）
判斷指標對象字段的值在判斷條件值的列表中是否不存在。該規則與上面的包含value值規則應用場景類似，用于判斷指標字段的值不在規則配置的value值列表范圍內。不包含value值規則中的多個值是與的關系，即指標字段的值與value值列表中的任一個都不相等。4）大于等于value值
判斷指標對象字段的值是否大于等于判斷條件值，是常見的判斷場景。例如判斷某個主機的cpu使用率大于95%時需要告警，通過條件判斷該指標的value值是否大于等于95%即可。5）小于等于value值
判斷指標對象字段的值是否小于等于判斷條件值，是常見的判斷場景。例如判斷某個主機目錄的磁盤空閑容量小于等于30MB時需要告警，通過條件判斷該指標的value值是否小于等于30MB即可。6）不等于value值
判斷指標對象字段的值是否不等于判斷條件值，是常見的判斷場景。例如判斷某個應用的接口調用結果存在1，-1，-2，-3等不同的值，只有為1時才代表接口正常，如果要在該接口調用結果不正常時告警，則可選擇該規則，判斷該指標的value值是否不等于1即可。7）時間范圍內
判斷指標對象字段（必須是時間格式）的值是否在某幾個時間范圍內。該規則常用于對業務上的高峰時段、工作時段、非工作時段之類的限制。例如在非工作時間和工作時間需要設置不同閾值的告警類型，則可通過該規則將時段進行劃分，按時間段做不同的告警條件判斷。需要說明的是，時間范圍內的判斷是可能存在多個時段的，例如非工作時間的判斷，可能是晚上20點到早上8點，但實際配置時是需要配置為20:00:00-23:59:59，0:00:00-08:00:00這兩段的。另外也可根據提示以小時范圍或只到分鐘范圍的精度來進行配置。當存在多段時間時是或的關系，即指標中的時間字段符合其中一個時間段條件即代表該規則項條件成立。8）時間范圍外
判斷指標對象字段（必須是時間格式）的值是否不在某幾個時間范圍內。該規則常用于對業務上的高峰時段、工作時段、非工作時段之類的限制。需要注意的是，當規則中存在多個時間段時，各段時間是與的關系，即指標的時間字段必須全都不滿足這些時間范圍，該規則項才條件成立。9）以…字符串開始
判斷指標對象字段（必須是字符串）的值是否以某個字符串開始的。該判斷條件場景比較少見，是對日志類數據進行指標化后，對其中某段信息進行判斷的一種邏輯，屬于偏項目化的場景。例如日志中的oracle數據庫報錯（或某個應用的業務報錯），同一個大類的報錯類型往往是以相同的字符串開頭的，但后面的內容不一樣，在日志分段分詞時會把該報錯類型作為一個字段，如果要對所有相同類型的報錯都進行告警（或用于指標計算統計中的過濾條件規則），則可使用這種規則邏輯。10）非以…字符串開始
判斷指標對象字段（必須是字符串）的值是否不是以某個字符串開始的。使用場景與上述的“以…字符串開始”類似，不再贅述。11）以…字符串結束
判斷指標對象字段（必須是字符串）的值是否是以某個字符串結束的。使用場景與上述的“以…字符串開始”類似，不再贅述。12）非以…字符串結束
判斷指標對象字段（必須是字符串）的值是否不是以某個字符串結束的。使用場景與上述的“以…字符串開始”類似，不再贅述。2.3 計算任務管理
對于已納管的FLINK集群，支持在平臺上創建計算任務、選擇任務類型（主函數入口）、設定任務參數、輸入輸出流配置、數據存儲組件配置等。FLINK的任務配置中有允許延時時間的配置，即當前任務在時間窗口統計時，允許延后多長時間來關閉窗口來等待延遲的數據，這個配置一般在指標計算中使用，減少因前端數據延遲對統計準確性帶來的影響。但配置延遲時間又會造成指標延時輸出，影響指標應用的實時性，因此延時是把雙刃劍，需要根據不同場景的需要以及資源的情況來酌情調整。FLINK的任務支持在前臺界面控制任務的啟停，以及對任務所加載的計算規則的加載或下線等操作，保障在不中斷任務運行的前提下上線或下線規則，或變更計算規則。在任務執行過程中，可以進入組件規則詳情頁查看當前任務所加載的規則列表，并可通過是否加載、規則刷新時間、指標最后生成時間（針對指標計算任務）等信息來了解規則的運行狀態。點擊規則列表操作欄中的“加載（下線）”按鈕可控制任務是否執行該規則計算。對于指標計算類的任務規則，點擊規則列表操作欄中的“詳情”按鈕，可查看當前規則計算所生成的最近指標數據，并可通過規則的關鍵屬性信息進行檢索。2.3.1 實時計算任務類型
目前DOMP支持的主要數據加工（分析）處理任務類型包括：1）日志數據分割分詞任務
日志數據分割分詞任務是針對現場自有的日志管理平臺所配置采集（文件、syslog等方式）的日志數據的分詞處理。一個任務中可以加載多個分詞模板的的處理，對于一個企業中所含的成百上千種類型的日志，可以按照重要程度或流量大小拆分到不同的分詞任務中執行，使運維管理更加有方便。下圖為一個分詞模板的示例：2）第三方數據分割分詞任務
第三方數據分割分詞任務的功能與日志數據分割分詞任務基本相同，是對其他平臺通過kafka-topic傳遞的第三方平臺吐出的數據做分割分詞處理。與自有平臺采集日志數據的處理邏輯不同的是，自采集的日志數據會帶有基于flume采集終端附加的日志屬性信息，而第三方平臺是沒有這些信息的。所以在任務處理環節前部會有一個預處理環節，對數據做格式化轉換，使其適配后續的分詞加工流程。3）數據加工計算任務
數據加工計算功能針對需要對源數據做加工處理的場景，實現數據的實時加工，并輸出加工后的數據。數據加工支持的規則已在“計算規則管理”一節中介紹，這里不做贅述。與分詞任務相同，數據加工計算同樣支持多任務執行，每個任務可以按分組管理的需要加載不同的加工規則。以下其它任務也具備相同的多任務管理和任務中多規則加載處理的能力，不再逐一說明。4）簡單指標計算任務
數據加工計算功能針對需要對某一數據類型的源數據做分組統計的場景，實現數據的過濾及分組統計。簡單指標計算支持的規則已在“計算規則管理”一節中介紹。5）復合指標計算任務
數據加工計算功能適用于需要對一種源數據指標或多種源數據指標，或基于指標的告警數據做復合統計的場景，實現數據的過濾、統計、四則運算等處理。復合指標計算支持的規則已在“計算規則管理”一節中介紹。6）指標加工計算任務
數據加工計算功能適用于需要源數據指標進行加工處理的場景，實現指標中關鍵字段信息、值信息的轉換處理。指標加工計算支持的規則已在“計算規則管理”一節中介紹。7）復合指標關聯計算任務
復合指標關聯計算功能是多指標計算中的一類特定場景，基于兩類不同的指標數據中的某一個屬性字段相同的特性，實現對兩條指標數據的組合生成一條新指標數據。復合指標關聯計算支持的規則已在“計算規則管理”一節中介紹。8）告警計算任務
告警計算功能針對指標數據的值做閾值判斷、動態基線判斷、同環比判斷等規則計算，并輸出判斷結果告警信息。告警計算支持的規則已在“計算規則配置”一節中介紹。2.3.2 實時計算任務運維支撐
在任務執行過程中，平臺提供了一些方便運維的細節功能，在此說明其使用場景。1）上下游kafka主題
在任務管理界面中，各記錄中會展示該任務的上游kafka和下游kafka的topic名稱，通過該名稱可以清晰的看出數據的流向。當運維需要檢查任務是否正常運行時，可以通過對下游kafka數據的檢查或監控來實現。如果某個實時計算任務沒有按預期在下游的kafka獲取到相應的輸出時，除了檢查任務是否正在運行，也可以通過到上游的kafka-topic按關鍵字撈取源數據來確認是否有符合條件的數據流入。2）規則更新
在任務管理界面中，每條記錄的操作欄中有“規則更新”按鈕，這個的作用是在任務不中斷的狀態下動態重新加載規則內容。由于一個任務中往往加載了多個計算規則（例如多個指標的計算、多個日志分詞等等）。如果任意一個規則需要修改都要啟停任務的話，會影響其他跑在同一個任務中的規則執行。所以，通過這個規則更新按鈕，可以將規則重新加載到緩存中，使更新上線的規則或新增的規則生效，也可使下線規則失效，不再起作用。3）規則刷新時間
從任務管理界面，選擇一條記錄，點擊“組件規則”按鈕進入規則列表頁時，可以看到每條規則都有個規則刷新時間。這個時間是指該規則重新被加載到緩存的時間。由于實時計算的后臺程序是定時到緩存中獲取規則的更新（5分鐘一次），所以根據該刷新時間可以推導出該規則是否已在后臺生效，并結合下游kafka-topic的數據輸出、指標最后生成時間等信息來判斷該規則是否已正常執行。4）指標上下線
在指標規則列表頁中，每條規則都有“是否加載”的字段，以及在操作列中有“上線”、“下線”的按鈕。這個功能用于實現將同一個任務中的部分規則暫時下線或重新上線的操作。運維過程中，如果需要對某個指標的配置規則進行修改，則需要先將該規則下線，修改后再重新上線生效。另外，在任務執行壓力大的時候，也可以將部分規則先暫時下線，以保障更重要的規則執行的，降低時延。5）指標最后生成時間
與規則刷新時間一樣，指標最后生成時間也在規則列表頁中的每一條規則記錄中展示。與規則刷新時間不同的是，只有指標計算類的任務（簡單指標計算、復合指標計算、加工指標計算）才有該字段展示，用于標識該規則的最后一條生成指標數據的時間戳。結合這個字段中的時間，與本地時間的偏差，即可快速發現該指標計算規則是否存在延時現象。特別是對于配置為1分鐘統計周期的指標，由于對實時性要求很高，所以一旦出現該字段與當前時間偏差稍大，就要快速介入運維。此處需要注意的是，不同的指標有統計周期的區別，例如30分鐘統計周期的指標，在每個半小時的整點進行統計，如果時間偏差在30分鐘內都是正常的。6）指標數據詳情查詢
如果是指標類的任務（簡單指標計算、復合指標計算、指標加工計算），在規則列表頁中，點擊規則記錄后面的“詳情”按鈕，會在下方展示該規則最近生成的指標數據。由于指標規則模板在一個統計周期中可能生成的實際指標數據量會非常龐大，所以展示所有數據是不現實的，也不應該展示所有數據，所以前臺限制了只會查詢展示200個指標實例的數據。可以通過對指標中不同關鍵字段的條件限制來對指標實例進行過濾，只展示運維需要檢查的數據即可。通過查看指標生成的數據詳情，可以對指標規則中特定目標數據的運行結果進行檢查和監測。由于實時指標數據往往用于實時大屏的展示，當大屏中相應的指標數據未正常展示時，可以通過該功能檢查相應的指標數據是否正常生成。當然，這個功能不是檢查指標數據的唯一方法。如果指標規則在定義時選擇了入庫的配置，則可以通過在相應的指標數據表中進行查找并確認（但該方法只能在事后檢查出是否生成了指標數據，無法在盡可能實時的時間里進行檢測）。2.3.3 計算任務實施注意事項
在項目實施過程中，無論是日志分詞任務，還是指標計算任務，最開始由于沒考慮任務的劃分問題，所有的規則都混在一起。這就導致出現高數據流量的規則拖累其他規則一起延時的狀況。后來通過將開發任務分組功能，按不同的管理需要劃分開，才較好的解決該問題。經過前期多個項目實施，我們積累了一些使用DOMP模塊來滿足現場運維數據應用場景的經驗，供其他項目團隊或后續使用該模塊的同學參考。在做規則分組時，可以按同類歸并原則，重點保障原則、數據分流原則來處理劃分邏輯，盡量減少后期的調整。1）同類歸并原則
運維場景所包含的數據加工需求是可能由不同的發起方（科室、項目、對口客戶）提出的。建議能將規則做一定原則的劃分，將同類（相同項目、相同客戶、相同科室等）規則合并到同一個任務或一組任務執行。通過將場景規則分組后通過不同任務執行，并且以任務為單位來分配計算資源，實現較好的管理。2）重點保障原則
運維數據應用場景中有部分指標的需求對實時性要求非常高，例如用于實時大屏展示的需求，或用于實時監控告警的需求。這類數據計算需求應該盡量多帶帶任務通道執行，或將具有同樣計算輸出場景的規則合并到一組任務來執行，避免被其他計算規則的數據量影響造成延時。3）數據分流原則
劃分到同一組任務的源端數據，可能存在數據量過大，在一個任務中仍會處理不及時的情況，這時候需要使用數據分流方式來處理。通過將源端數據在采集時就分配到不同的kafka-topic中，可以按不同源端數據源的流量規劃各個通道的數據流量大小，并以對應的任務分配資源來處理數據，以保證數據處理的及時性。DOMP自采集的日志數據可以通過采集客戶端、采集服務端的分組功能來實現數據分流場景，如果是對接外部系統的kafka-topic數據，也可以使用DOMP的第三方數據采集功能，將同一個topic中的數據按不同的采集口徑做二次采集分流后，再對接到下游的指標計算任務。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129096.html
