雲計算時代的到來給人們帶來了不少便利，同時也帶來了挑戰。好比，硬件環境更加複雜、設備多樣、處理難度大，運行的平臺系統更加多樣化，須要更廣的知識面，對運維安全要求也更高，因此在雲環境下，咱們須要對雲運維平臺進行可視化管理。前端
運維可視化核心是將所運維的服務、資源、設備的狀態和正在發生的事件經過可視化的手段呈現出來，指導運維人員或者產品研發人員作出正確的運維決策。某種程度上，雲平臺的運維與可視化相輔相成，可視化程度越高，運維就越簡單，運維效率也就越高。web
在雲運維的工做範疇中，實時監控對故障的發現和診斷起到相當重要的做用。今天，咱們以私有云監控中的一個重點場景——內網監控爲例，來介紹可視化的重要做用（內網指的是一個企業的內部網絡，包括機房內部網絡和機房間的網絡）。前端工程化
異常事件可視化
瀏覽器
當運維工程師發現本身負責的系統出現故障時，檢查網絡鏈接是否有異常，是故障排查流程當中的標準步驟。在這個場景中，工程師須要知道本身的系統所在的機房以及所依賴的網絡通路是否存在故障，因此但願內網監控系統提供一個網絡故障概覽，展現給定的時間段中相關機房的異常事件。安全
最簡單的方式是將全部的網絡故障展現在表格當中。微信
如上表所示，每一行表明一個故障事件。網絡
第一列表示故障關聯的機房app
第二列表示故障的起止時間框架
第三列表示故障的嚴重程度運維
這種展示方式存在如下三個問題：
不能第一眼看出哪些故障嚴重，哪些故障輕微。
不能直觀感覺到每一個故障的持續時長。
很難知道在某一時刻哪幾個機房同時存在故障。
當時間段很長，篩選出的故障事件不少時，表格會變得很長，就更加不利於工程師瞭解網絡情況。
爲解決以上問題，咱們須要在機房、時間、 程度三個維度上都能直觀的展現故障事件。從時間跨度來想，有點像事件流的感受，彷佛能夠用事件流圖來展現。
圖1 事件流圖
如圖1所示，事件流圖用一條事件河流來表示事件。河流被橫向切分爲若干條色帶，每條色帶表明一個類別的事件。色帶的高度（河流的寬度）表明在某個時刻，各種別包含事件的個數。事件越多，河流越寬，反之越窄。
這種事件流圖適合展現在一段時間內事件羣體的統計變化，而咱們須要可以展現每一個事件的個體信息。所以，咱們對事件流圖做了幾個修改：
每一個故障事件用一個矩形條表示，矩形條左右兩邊的位置對應事件的起止時間。
矩形條的顏色用來區分事件的嚴重程度，而不是事件的類別。
關聯到某一個機房的故障事件矩形條放在河流的同一個高度位置。若是事件在時間上能徹底錯開，則將矩形條左右放置。若是事件在時間上有重疊，則拓寬機房所佔河流的寬度，將矩形條上下放置。
圖2 異常事件流圖
圖2展現了咱們的事件流圖方案。
圖中展現了三個機房的異常，其中機房一有1個嚴重的異常事件（用紅色來標識），這個異常事件是一個時間跨度比較長的嚴重異常事件。機房二有4個輕度的異常事件（用黃色標識），這4個異常是時間跨度比較短的輕度異常事件，機房三有12個輕度的異常事件（用黃色標識），這12個異常事件中也有三個時間跨度比較長的時間。若是鼠標放置在異常事件矩形塊上，就能查看哪一個機房出現異常。
經過這個圖，工程師能夠很方便地看到每一個機房的每一個故障事件的詳細信息，比表格的方式直觀得多。
總 結
事件流圖，從機房、時間、異常程度三個維度都能直觀的展現故障事件，幫助工程師快速查看異常狀況。其實，事件流圖還能夠用於展現變動事件，甚至能夠將變動事件與異常事件組合，讓工程師能一眼查看異常事件多是由哪些變動事件引發的。
咱們從智能運維場景中抽象出一些可視化組件，好比這裏的事件流圖組件，再經過前端工程化工具把這些子元素串聯起來，構建出前端統一展示層框架，後面咱們會逐一介紹這些可視化組件與框架其餘細節。
有問題可後臺留言，咱們隨時解答。關於智能運維的後續文章，還請持續關注百度雲微信公衆號。
莫莫 百度資深前端研發工程師
負責百度智能運維（Noah）相關產品的前端設計和研發，在運維數據可視化方向有着豐富的實踐經驗。
本文分享自微信公衆號 - 百度智能雲（baidu_cloud）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。