最近兩周時間裡,一直都在學習監控軟體的開發,雖然是簡版的,可是在這個過程當中,對于要開發一個監控軟體的大概架構和流程還真的學習了很多東西,而且也想,這些知識實在是很難通過看文章或者是書籍能學習得到,隻有自己親自去實踐過,我想才可以慢慢體會到這中間的不易吧。而通過這樣一個過程,發現自己在這方面的思想枷鎖也慢慢地打開,也才慢慢體會到那種樂趣吧。這裡,真的是非常感謝Alex老師非常精彩的講解。
監控軟體的大概流程如下:
我剛開始看到上面的監控軟體示意圖時,感覺應該也不會太難的,但當我跟着一步一步去做時,才實作這中間要考慮和解決的問題實在是太多太多,總結起來,要解決的問題,或者說基本的實作流程與思想,簡單的總結可以如下:
對于用戶端:
1.如何獲得需要監控的名額項目
例如如果我要監控的是CPU的情況,我該如何去獲得CPU的相關名額資訊,通過什麼方式或者說什麼指令,這一步實作之後,其實得到的就是一個監控CPU的插件,這個插件應該盡量獨立,即不受其它程式的影響,與其它程式之間的耦合度要低,總之,這個插件的功能,就是可以得到我想要的監控名額資訊。
2.如何處理獲得的監控名額資訊
主要是指用戶端對這些監控名額資訊資料的處理,這裡應該涉及到的問題,獲得監控的名額資訊後,應該是基于一個監控項目來儲存,還是要基于一台被監控的主機來儲存名額資訊。比如我監控了一台主機的CPU、記憶體、load後,我是應該把這三者分别儲存為三個資料結構,還是把這三者直接儲存為一個資料結構?這就要看需求了,而基于CPU、記憶體、load的監控頻率可以調整,考慮到軟體以後的擴充性,應該要把三者獲得的資料分開儲存,用Python開發時,就可以把這三者儲存到三個不同的字典中去了。是以,從這一步來看,這裡重要的是要知道監控的頻率從何而來,繼續看下面的内容。
3.監控項目的配置資訊擷取方式
比如我要監控CPU,具體我要監控CPU的什麼資訊,什麼名額,如idle、nice等,我應該去哪裡找這些配置資訊?多長時間監控一次,即監控的頻率是多少?有想法是可以直接在用戶端上自己設定,但如果這樣做的話,依然是考慮到軟體的擴充問題,如果以後要監控的伺服器主機很多,那不是要在每一台用戶端主機上進行設定?既然是監控,那倒不如考慮在伺服器端設定用戶端的資訊,即配置檔案,然後可以由用戶端直接從伺服器端擷取,這樣當監控多台主機時,隻要在伺服器端進行相應的設定,用戶端跑個用戶端程式就可以了,集中、統一管理的思想由此而展現出來。但問題的關鍵是,這些配置資訊,用戶端怎麼去伺服器端取?
4.如何從伺服器端獲得監控項目的配置資訊
如果用的是3中的方法政策,那麼用戶端如何從伺服器端去取?這時就可以借助Redis資料庫的訂閱服務功能了,基于Redis資料庫的特性,隻要在伺服器端和用戶端都安裝并運作了Redis資料庫,問題就很好解決了。當然,這裡需要擷取的重要配置資訊應該是:這台主機監控的項目是什麼?監控頻率是多少?
5.通過什麼方式将擷取的監控資訊發送給伺服器端
有了4的經驗,那使用Redis的訂閱服務那是最簡單不過了。這時其實我們要采取的監控方式是被動監控方式,即伺服器端不會主動向用戶端擷取監控資訊,而是由用戶端主動向伺服器端發送監控資訊,然後伺服器端再根據已經設定好的監控政策來進行判斷用戶端主機是否出現異常,然後再實作報警功能。
對于伺服器端:
伺服器端要考慮的則更多了,在這裡,面向對象的程式設計思想就顯得猶為重要了,當然,監控資料的接收與整理、處理、報警也不容易。
1.用面向對象的程式設計思想實作不同主機監控項目的模闆定制
用戶端的監控配置資訊都是從伺服器端獲得的,由于不同的用戶端主機監控的項目、監控的頻率都有可能不一樣(這很正常,不同的伺服器對于不同的性能名額要求都不一樣),是以通過面向對象的程式設計思想,把每個監控項目的基本配置資訊模闆寫好,基于這些模闆,根據需要被監控的伺服器主機的不同,定制不同的監控配置資訊,然後儲存到Redis資料庫中,讓用戶端主機去取,這裡對應用戶端解決問題中的第3點。
2.監控資料如何接收與整理
前面其實已經說過,依然是通過Redis資料庫的訂閱服務功能來進行接收,如果這個方式要改變,那麼在用戶端主機中也應該進行相應的更改,這裡對應用戶端解決問題中的第5點。這裡,可以單獨寫一個程式來跑一個程序,把接收到的資料,根據後面處理資料時的需求,再添加相關的資訊來重新整合接收到的監控資料,再儲存到Redis資料庫中去,再由監控資料處理程式去進行處理,即handle程式,之是以要這樣做,是為了要降低程式之間的耦合度,以友善以後對監控軟體進行功能上的擴充。
3.監控資料如何處理
這裡單獨寫一個程式跑一個程序,從Redis資料庫中讀取不同主機不同監控項目的監控資訊,然後将這些監控資訊與第1步定制的模闆中的名額閥值進行比對(是以第一步寫的内容資訊不僅僅是監控項目配置資訊模闆,也應該還有不同名額和閥值的相關設定),如果發現有異常情況的,即将異常情況資訊儲存下來,寫入到Redis資料庫中,等待報警程式進行相關處理以實作報警功能,這樣分開來做的目的依然是為了降低程式之間的耦合度。另外這裡需要注意的是,監控資料的處理也應該是基于不同的監控項目的(對應用戶端中的第2點),而不是基于不同的主機,因為不同的主機的不同監控項目的監控頻率可以是不一樣的。
4.如何進行報警
這裡也應該單獨寫一個程式來進行報警功能的實作,從Redis資料庫中讀取報警資訊後,如何将這些資訊進行報警,是直接在螢幕輸出?還是郵件?還是短信?還是電話?以及将這些資訊發給哪個相關負責人?基于上面的這些不同需求,要構思的應該又不少了。
是以對于上面的一個流程的概述,可以更進一步總結如下:
用戶端:讀取監控配置資訊-->開始監控-->獲得監控資料-->發送給伺服器端
伺服器端:讀取監控資料-->監控資料處理-->儲存異常資訊-->實施自動報警
知道監控軟體的思想流程有何作用?
不管怎麼說,監控軟體的大緻開發過程或者說是開發的流程與思想應該是跟上面說的類似的,隻是基于不同的功能、不同的需求、不同的方式,在實際開發的過程當中又有太多細節的不一樣,總的來說,流程看起來不會太難,但具體到每一個細節的實施,需要花費的精力,我想是非常非常多的,而這,應該是需要一定的經驗的。但無論如何,因為知道了大概的開發流程,并且自己動手實踐過,是以以後在自己需要開發相關監控軟體時,根據自己的需求,再按照上面的思想流程去做,我想,從最基本的開始做起,是一定可以開發出一套适合實際生産環境的監控軟體的。
為什麼要學習Python自動化運維開發?
今年5月份,接手了學校600多台交換機的管理,發現對交換機的監控實在是太弱,600台交換機,上萬的使用者,竟隻有一個隻能通過螢幕界面來進行檢視的監控平台,是以,更不用說自動報警功能了,迫于這種無奈,我上網找了很多相關的監控軟體,要麼都是收費的,要麼是使用不了,要麼就是操作起來非常非常複雜的,是以,很難下手。其實我的需求很簡單,隻是希望可以看到交換機有沒有挂掉,然後如果挂掉了,可以給我打個資訊或者打個電話,是這樣一種輕量級的監控軟體就好了。
到了今年9月,實在是無奈,隻能自己去學開發,那種求人不如求己的感覺越來越強烈。
不管怎麼說,在學習了這方面的知識後,發現其實要開發具有我上面所說功能的交換機功能的監控軟體,在流程上面就要比前面說的那個要簡單很多,是以我想,這是不難實作的。
繼續Python開發的學習,在後面學習了Web開發相關的知識後,我是希望通過自己的能力可以開發一個較為完善的基于自己實際需要的交換機監控系統。
當然,以後要用Python做的事情,就真的是太多太多了。
不管如何,往後要學習的知識或者說技術,真的是太多太多,希望自己不要放棄,繼續努力下去吧!
本文轉自 xpleaf 51CTO部落格,原文連結:http://blog.51cto.com/xpleaf/1705623,如需轉載請自行聯系原作者