業務流程監控：讓多維度監控有了靈魂

需求

《視覺化業務流程監控，是解決方案更是運維之道!》一文讓我們知道可以藉助Grafana 兩個外掛：Diagram、FlowCharting，滿足我們對於圖形+資料+業務流程的視覺化監控，但是在使用前需要我們做好以下兩點工作：

源資料的完整性 這意味著我們仍要持續的進行多維度的監控指標的收集，不斷豐富業務流程對關鍵指標的依賴。

多資料來源無法集中合併展示 受限於Grafana的Dashboard的資料來源單一性，即無法在一個Dashboard中關聯多個資料來源進行集中展示。

以上第一點是一個長期性的工作，也是一個非常重要的基礎性工作;而第二點我們可透過使用mix資料來源，實現資料來源合併展示。

有了多維度監控的資料，我們可以進一步讓業務流程監控逐漸豐滿起來，更好的為業務服務!

圖形化展示

相對於Diagram，FlowCharting透過draw.io進行圖形化編排，結合各個資料來源提供實時資料，並在流程圖中定義資料與圖表進行多樣性互動：

監視狀態和效能

與圖表互動

根據資料或狀態改變顯示的物件

向物件新增連結

充分利用變數來修改形狀，顏色，連結，下載路徑等。

支援用於匹配和替換的正規表示式

以下是透過FlowCharting編排的幾個DEMO：

1.網路拓撲圖

2.擴充套件和伸縮圖

3.架構圖

4.告警事件和動畫

透過以上幾個DEMO的展示，可以看出FlowCharting豐富的圖形化和資料展示功能。當然運維還是要落地的，因此我們透過一個自定義流程來進行具體展示。

業務審批流程

現在我們有一個業務審批流程需要進行監控，之前總是出現卡審批的現象，需要業務運維拉開發人員來進一步定位，這無疑大大延長了故障修復時間。後來經過覆盤，原因主要集中在以下幾方面：

1、Rabbitmq 佇列生產速度>消費速度，導致訊息積壓;

2、Kafka topic 生產速度>消費速度，導致訊息積壓;

3、業務應用發生異常導致無法消費;

4、等等

1.業務審批流程圖

業務審批流程大致為：收單-->Rabbitmq 相關佇列 --> 信貸系統 --> 全面風險管理系統 --> Kafka 相關topic --> 其他業務自子系統

整個業務流程，我們透過監控Rabbitmq、Kafka相關佇列的消費情況，來比運營人員更早的發現問題，甚至是提前將問題解決。

2.資料來源設定metric

圖中綠色部分是我們透過以下資料來源與其關聯的：

Zabbix資料來源

ELK資料來源

由於粒度比較粗，我們還可以新增prometheus、mysql等資料來源來進行更好的補充。

3.資料關聯

以上是我們對Rabbitmq其中的一個佇列“cmis_rule_loan”進行資料關聯，根據配置我們可以得到：

綠色：正常，即佇列積壓低於50;

橙色：佇列積壓超50;

紅色：佇列積壓超80;

比較有趣的是，當告警時可以在圖中設定動畫，如：反轉、傾斜、閃動等，以便我們更好的發現問題。

總結

圖形化的業務流程監控給我們運維開啟了另一個維度的監控思路，之前我們的監控維度主要為：

硬體監控

伺服器基礎狀態監控

應用狀態監控

流量監控

這些監控可以幫助我們解決80%的問題，但總感覺缺少一點靈魂。透過業務流程監控正好可以補齊這個短板，以上各個維度的資料都可為業務流程監控提供資料支撐，這讓我們的思維更進一個臺階。