背景

過去很長一段時間，我們在監控平臺的建設之路上不斷的探索與實踐，同時監控需求也在隨著技術架構、業務規模不斷的演變：

• 從Nagios、Zabbix到Prometheus；
• 從關係型資料庫、非關係型資料庫到時序資料庫；
• 從伺服器硬體、基礎執行狀態到應用可用性；
• 從伺服器、網路、中介軟體、資料庫到應用訪問鏈路；
• 從傳統架構到雲原生架構；

但最終無論怎樣發展，我們運維的核心目標卻始終如一，即為業務服務。

問題

監控平臺的執行過程中，我們通常面臨著以下幾個問題：

• 告警集中氾濫
• 告警資料分散在各監控子系統
• 監控和業務分離

其中監控和業務分離一直是我們所忽略的問題，隨著架構和業務規模不斷髮展，一般情況下的多維度監控雖然可以在業務應用可用性方面發揮重要的作用，但是無法做到和業務流程進行有效關聯。此時就需要更懂或者更瞭解業務的相關人員進一步判斷，這無疑大大延長了故障時間，嚴重影響了我們的SLA。

需求

對於上述問題，我們雖然一直踐行著多維度監控的理念，從業務架構中收集各種維度的監控指標資料約達20多萬條，但都是離散的，無法有效的串聯起來幫我們更精準的定位問題。

因此我們對於監控平臺又提出了幾個新的需求：

• 監控面向業務流程，讓業務流程更好的發揮串聯作用；
• 從無序的監控中，提取不同的業務監控場景；
• 透過圖形+資料+業務流程，為場景提供視覺化監控；

總之，我們想要監控更貼近業務流程，透過圖形化資料展示能夠更直觀的定位業務流程中出問題的節點。

解決方案

由於監控平臺資料可能存放在各種資料庫、ES、Prometheus、Zabbix等多個監控子系統中，因此我們利用Grafana多資料來源及豐富的外掛等特性來滿足圖形視覺化的需求。既然圖形和資料我們都有了，現在只缺少一套完整的業務流程來將它們結合起來，來完成圖形化展示的最後一步。

基於以上現狀的分析，形成了我們最終的兩種解決方案：

• Grafana + Diagram
• Grafana + FlowCharting

其中Grafana對接各種監控子系統，而外掛Diagram 或 FlowCharting 則可以根據業務流程生成圖形，透過正則匹配從各種資料來源中提取資料，從而在圖形展示。

Diagram

Diagram透過利用 mermaid.js 庫來建立流程圖、序列圖和甘特圖的方法。

• 可以使用 Mermaid JS 語法定義圖表；
• 公制系列用於為形狀/節點的文字或背景著色；
• 系列的目標或“別名”與圖表節點的 ID；
• 進行比較以找到匹配項，然後將樣式應用於形狀；
• 組合可用於聚合單個節點的多個系列，每個系列都有自定義閾值；

其中組合是Diagram比較亮眼的功能，透過聚合多個metric，可以很清晰的展示出哪個節點出現問題。

根據我們的實際業務流程，我們可以透過mermaid進行繪圖

graph LR
      LB[Load Balancer] -- route1 --> web1
      LB[Load Balancer] --> web2
      web1 --> app1(fa:fa-check app1)
      web1 ==> app2
      web2 ==> app2(fa:fa-ban app2)
      web2 --> app1
      app1 --> D[(database)]

根據定義的mermaid語法，可生成以下圖形：

如圖，我們app2是我們定義的一個組合，在業務流程圖中作為一個後端服務，其聚合的是app2_1、app2_2、app2_3 三個metric，透過組合可直觀的展示此時是app2_1應用超閾值，從而很快的定位問題。

但是透過實際使用，Diagram雖然在功能上滿足了我們的需求，但是在細節方面還是有不足：

• Diagram對於簡單圖形展示比較友好，一旦我們的業務流程複雜，隨著關鍵業務節點增多，會導致圖形無法放大展示，導致整個圖形無法檢視；
• mermaid 雖然繪圖簡單，一旦業務發生變更，還是有一定維護工作量的且非常不友好；
• 閾值是全域性的，無法針對每個metric設定單獨的閾值；

FlowCharting

FlowCharting可顯示覆雜的圖表，需藉助線上圖形庫 draw.io 來建立多種型別的圖表：

• 技術架構架構（Legacy、Cloud、Azure、AWS、GCP、Kubernetes、Terraform）
• 圖表（網路、電力、流量）
• 工業過程
• 有機計劃
• 平面圖
• UML 計劃
• 工作流（Jenkins、Ansible Tower、OpenShift）

FlowChating可提供實時資料並在流程圖中定義資料與圖形進行互動，具體功能如下：

• 監控狀態和效能；
• 與圖表互動；
• 根據資料或狀態更改顯示的物件；
• 新增指向物件的連結；
• 充分利用變數來修改形狀、顏色、連結、下載路徑等；
• 支援匹配和替換的正規表示式；

透過Draw繪出的網路拓撲圖，結合FlowCharting的資料互動，進行下圖展示：

與Diagram相比，Draw能夠更方面的按業務流程進行繪圖並方便維護，而FlowCharting則能夠靈活的對各個metric設定閾值。

遺憾

Diagram、FlowCharting都可以非常全面的滿足我們對於圖形+資料+業務流程的視覺化監控，但是在使用前需要我們做好以下兩點工作：

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

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

以上第一點是一個長期性的工作，也是一個非常重要的基礎性工作；而第二點還需要我們持續探索，找到突破點。

總結

有了這套解決方案後，剩下的問題就在於我們要了解、熟悉業務流程，這可不是一件簡單的事情，需要我們在日常工作中與業務、開發、測試多溝通、多總結，還要兼顧到業務流程變更等各個環節。只有瞭解業務，才能更好的為業務服務。

透過不斷的梳理和完成，我們就可以圖形化展示各種業務流程，不僅能夠更快的定位問題，其直觀的視覺化展示更可以幫助團隊相關人員更快的上手並適應工作，對團隊的發展進步非常有幫助。

想到此，我不禁覺得視覺化業務流程監控，不僅是解決方案，更是我們最終的運維之道！