背景

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

但是最終不管我們怎么發展，我們運維的核心目標還是一樣的，就是為業務服務。

問題

在監控平臺運行過程中，我們一般會面臨以下問題：

其中，監控與業務的分離一直是我們忽略的一個問題。 隨著架構和業務規模的不斷發展，多維監控通常看起來對業務應用的可用性起著重要作用服務器運維技術，難以與業務流程實現有效結合。 聯系。 這時候需要對業務比較了解或者比較了解的相關人員做進一步的判斷，這無疑大大延長了宕機時間，嚴重影響了我們的SLA。

需要

針對以上問題，我們其實還是提倡多維監控的概念。 我們從業務結構上收集了超過20萬條各個維度的監控指標數據，但是它們都是離散的，很難有效串聯起來幫助我們更精準的進行監控。 定位問題。

為此，我們對監控平臺提出了幾個新的要求：

事實上，我們希望更貼近業務流程進行監控服務器運維技術，只有通過圖形化的數據展示，才能更直觀地定位到業務流程中的問題節點。

解決方案

由于監控平臺數據可能存儲在各種數據庫、ES等多個監控子系統中，我們采用多數據源和豐富的插件來滿足圖形可視化的需求。 現在我們既有圖形又有數據，現在只缺一套完整的業務流程把它們結合起來完成最后一步的圖形展示。

基于以上對現狀的分析，我們最終的解決方案有兩種：

其中，連接各個監控子系統，插件可以根據業務流程生成圖形，通過正則匹配從各個數據源中提取數據，以圖形方式展示。

在 .js 庫的幫助下創建流程圖、序列圖和甘特圖。

其中，組合是一個比較引人注目的功能。 通過聚合多個功能，它可以清楚地顯示哪個節點有問題。

根據我們實際的業務流程，我們可以通過

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)]

根據定義的句型，可以生成如下圖形：

如圖，我們的app2就是我們定義的一個組合。 作為業務流程圖中的前端服務，聚合了三、三、三。 通過組合可以直觀的看出應用此時超過了閾值，可以快速定位問題。

并且通過實際使用，即使在功能上滿足了我們的需求，但在細節上還是存在不足：

可以顯示復雜的圖表，需要使用在線圖形庫draw.io來創建各種類型的圖表：

可提供實時數據，并可在流程圖中定義數據與圖形交互。 具體功能如下：

通過Draw繪制的網絡拓撲圖，結合數據交互，如右圖所示：

與Draw相比，它可以更全面地根據業務流程進行繪制，方便維護，并且可以靈活地為每個設置閾值。

遺憾

，完全可以滿足我們對圖形+數據+業務流程的可視化監控，使用前我們需要做以下兩件事：

以上第一點是常年工作，也是非常重要的基礎工作； 而第二點需要我們繼續探索，尋找突破口。

總結

有了這套解決方案，剩下的問題就是我們需要了解和熟悉業務流程。 這不是一件簡單的事情。 需要覆蓋業務流程變更等所有環節。 只有了解業務，才能更好地為業務服務。

通過不斷的排序和補全，我們可以圖形化的展示各種業務流程。 除了能夠更快地定位問題，其直觀的可視化展示可以幫助相關團隊成員更快上手和適應工作，有利于團隊的發展。 進步特別有幫助。