最近兩週時間裏，一直都在學習監控軟件的開發，雖然是簡版的，可是在這個過程當中，對於要開發一個監控軟件的大概框架和流程還真的學習了很多東西，而且也想，這些知識實在是很難通過看文章或者是書籍能學習得到，只有自己親自去實踐過，我想纔可以慢慢體會到這中間的不易吧。而通過這樣一個過程，發現自己在這方面的思想枷鎖也慢慢地打開，也才慢慢體會到那種樂趣吧。這裏，真的是非常感謝Alex老師非常精彩的講解。
監控軟件的大概流程如下：
當然，實際中學習的過程中並沒有去監控MySQL或者是ngnix，而只是監控Linux服務器的CPU、內存、load的各項相關指標，不過我覺得這倒沒什麼問題，因爲思想和框架出來了，後面要監控什麼，自然而然也就很輕鬆了，把插件寫好，然後添加到監控項裏面去就OK了。
我剛開始看到上面的監控軟件示意圖時，感覺應該也不會太難的，但當我跟着一步一步去做時，才實現這中間要考慮和解決的問題實在是太多太多，總結起來，要解決的問題，或者說基本的實現流程與思想，簡單的總結可以如下：
對於客戶端：
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做的事情，就真的是太多太多了。
不管如何，往後要學習的知識或者說技術，真的是太多太多，希望自己不要放棄，繼續努力下去吧！