無監控、不運維。運維繫統架構設計附帶思惟導圖

無監控、不運維


運維行業有句話:「無監控、不運維」。

是的,一點也不誇張,監控俗稱「第三隻眼」。沒了監控,什麼基礎運維,業務運維都是「瞎子」。**


ios

開篇

因此說監控是運維這個職業的第一步。尤爲是在如今DevOps這麼火的時候,用監控數據給本身撐腰,這顯得更加必要。


有人說運維是背鍋俠,那麼,有了監控,有了充足的數據,一切以數聽說話,運維還須要背鍋嗎,因此做爲一個運維工程師,如何構建一套監控系統是你的第一件工做。

數據庫

統一運維監控平臺設計思路


運維監控平臺不是簡單的下載一個開源工具,而後搭建起來就好了,
它須要根據監控的環境和特色進行各類整合和二次開發,以達到與本身的需求徹底吻合的程度。**


那麼下面就談談運維監控平臺的設計思路。


構建一個智能的運維監控平臺,必須以運行監控故障報警這兩個方面爲重點,將全部業務系統中所涉及的
網絡資源、硬件資源、軟件資源、數據庫資源等歸入統一的運維監控平臺中,並經過消除管理軟件的差異。


據採集手段的差異,對各類不一樣的數據來源實現統一管理、統一規範、統一處理、統一展示、統一用戶登陸、統一權限控制,最終實現運維規範化、自動化、智能化的大運維管理。網絡

架構設計

智能的運維監控平臺,設計架構從低到高能夠分爲6層,三大模塊,以下圖:架構

clipboard.png

設計架構從低到高能夠分爲6層


數據收集層:位於最底層,主要收集網絡數據、業務系統數據、數據庫數據、操做系統數據等,而後將收集到的數據進行規範化並進行存儲。


數據展現層:位於第二層,是一個Web展現界面,主要是將數據收集層獲取到的數據進行統一展現,展現的方式能夠是曲線圖、柱狀圖、餅狀態等,經過將數據圖形化,能夠幫助運維人員瞭解一段時間內主機或網絡的運行狀態和運行趨勢,並做爲運維人員排查問題或解決問題的依據。


數據提取層:位於第三層,主要是對從數據收集層獲取到的數據進行規格化和過濾處理,提取須要的數據到監控報警模塊,這個部分是監控和報警兩個模塊的銜接點。


報警規則配置層:位於第四層,主要是根據第三層獲取到的數據進行報警規則設置、報警閥值設置、報警聯繫人設置和報警方式設置等。


報警事件生成層:位於第五層,主要是對報警事件進行實時記錄,將報警結果存入數據庫以備調用,並將報警結果造成分析報表,以統計一段時間內的故障率和故障發生趨勢。


用戶展現管理層:**位於最頂層,是一個Web展現界面,主要是將監控統計結果、報警故障結果進行統一展現,並實現多用戶、多權限管理,實現統一用戶和統一權限控制。

運維

功能實現劃分3大模塊

在這6層中,從功能實現劃分,又分爲三個模塊,分別是數據收集模塊、數據提取模塊和監控報警模塊,每一個模塊完成的功能以下:工具

數據收集模塊:此模塊主要完成基礎數據的收集與圖形展現。數據收集的方式有不少種,能夠經過SNMP實現,也能夠經過代理模塊實現,還能夠經過自定義腳本實現。經常使用的數據收集工具備Cacti、Ganglia等。


數據提取模塊:此模板主要完成數據的篩選過濾和採集,將須要的數據從數據收集模塊提取到監控報警模塊中。能夠經過數據收集模塊提供的接口或自定義腳本實現數據的提取。


監控報警模塊:此模塊主要完成監控腳本的設置、報警規則設置,報警閥值設置、報警聯繫人設置等,並將報警結果進行集中展示和歷史記錄。常見的監控報警工具備Nagios、Centreon等。

spa

思惟導圖

image.png

相關文章
相關標籤/搜索