用 Python 開發一個企業級的監控平臺
作者簡介：
郭巨集澤，現任為勝科技技術總監，高階諮詢師，IT解決方案專家。擁有12年IT行業工作經驗，其中有8年一線運維經驗，4年運維開發經驗，曾就職於易車網、電信雲端計算、跟誰學等公司。開發過日誌分析系統、CDN流量計費結算系統，自動化容器管理平臺等。精通Linux相關技術及Python、Shell、JavaScript等語言。現任多家大型公司諮詢顧問，已幫助IBM、惠普、朗訊等多家跨國公司進行容器化及DevOps轉型。
AdminSet開源運維平臺建立者，DevOps Master，全球運維大會金牌講師，高效運維社群核心成員。
Python是一個浩瀚如煙的曠闊領域，有著豐富的應用場景，業務系統、雲端計算、大資料、人工智慧都有Python的身影。
Python是一個易於學習的語言，是一個以簡潔實用為宗旨的語言，我在以前的工作中接觸過PHP、C#、Java等語言，但當我第一次看到Python的時候，有一種相見恨晚的感覺，心裡冒出一句話“就它了”。
Python的興起是由於雲端計算時代的來臨，當IaaS逐漸成熟、PaaS百花齊放的時代到來時，Python終於迎來了它的黃金時代。
由於入門簡單、語法精煉、功能庫豐富，Python在計算機領域漸漸成為了一種通用語言，無論是應用、平臺還是工具，哪個沒有Python的API介面或是SDK呢？這正說明了Python的實力。正因為這些原因，Python在DevOps領域成為一種標準，而且不可替代。
如何選擇Python版本
Python目前有兩個主流版本，Python 2和Python 3，而且都在維護更新，且這兩個版本互不相容。
Python 2和Python 3的區別
我們先來看看Python 2和Python 3 之間的主要區別，參見下表。更多新特性請參考：https://docs.python.org/3/whatsnew/3.0.html。
Python 2 | Python 3 | |
Print 變函式 | Print“abc” | Print("abc") |
類 | 舊式類和新式類 | 只有新式類 |
運算 | 1/2=0 | 1/2=0.5 |
字串格式化 | %,Format | Format,% |
xrange | xrange | Range |
long重新命名為int | Long,int | Int |
包匯入 | 相對匯入 | 絕對匯入 |
原始檔編碼 | Ascii | utf8 |
從Python社群官方態度來看，官方強烈建議直接學習Python 3，因為Python 2只會維護到2020年。那麼看到這兒，可能你會覺得應該直接學習Python 3了，但實際上不是這樣，我們必須從Python 2開始。
如果我們對一件事舉棋不定，那麼最好看看別人是怎麼做的，下圖是Python各版本在2016年7月和8月的下載量統計圖。
通過資料換算（Y軸是指數），Python 2.6和Python 2.7的下載量佔比超過90%。資料不會說謊，事實就是當前仍然是Python 2主導的世界，Python 2作為大部分應用和工具的基礎，還會在相當長的時間記憶體在。
為什麼會出現這樣的情況呢？原因有三：
技術的發展是快的，但是在生產中落地是非常緩慢的。
如果Python 2就能用，為什麼非得升級到Python 3呢。
Python 3不是所有作業系統的預設直譯器，在系統環境中使用Python 3會消耗巨大的成本。
出於實用主義考慮，如果能用螺絲刀解決的問題絕不會用一個電鑽來解決。使用Python的人大多數是實用主義者，所以出現了在Python3出現多年以後仍然無法普及的現象。
如何學習Python
Python 2和Python 3還有一種平衡的方法，可以同時相容兩個版本，那就是在Python 2中引用Python的__future__庫。__future__庫裡面包含了Python 3的大多特性。
從Python 2開始學習，向Python 3演進，使用Python 2.7版本，利用Python 2.7的語法相容性，儘量使用Python 2版本和Python 3版本都能相容的語法，這樣既保證了在現有系統中的相容性，又為將來全面向Python 3遷移做好了準備。
事實上Python 2的最新版本Python 2.7和Python 3的差異不超過10%，可以說是比較小的，另外Python 2.7已經儘可能地彌合了Python 2與Python 3之間的差異，做到了儘可能多地相容Python 3。
比如在Python 2.7中使用print “hello world”和 print(“hello world”) 兩者都是可以的，但我們應該使用後者，以便全面向Python 3版本遷移。
最後給出幾條學習建議：
從Python 2.7開始學習，不要使用Python 2.7以前的版本。
瞭解Python 3棄用的語法和包，在書寫程式碼過程中儘量避免。
不要使有Python 3.5之前的Python 3.x版本。
儘量多地使用Python 2與Python 3相相容的語法。
熟悉__future__庫。
DevOps工程師應主要使用Python 2.7。
業務開發工程師可以直接使用Python 3.5。
開發一個簡單的監控平臺
監控對運維的重要性
“ 因為你是我的眼，讓我看見這世界就在我眼前”，這是一首耳熟能詳的歌曲《你是我的眼》。監控，對於運維工程師來說就是眼睛，如果沒有監控，運維工作就無從談起；如果沒有監控，運維工程師就成了盲人。
一個良好的監控系統可以快速地發現並定位問題，減少宕機時間，提高故障處理速度，減輕運維工作壓力，甚至可以促進家庭和諧。
但是對於這麼重要的系統，我發現很多公司都做的都不好：要麼監控不到位，很多盲區；要麼監控過多，太多無效條目導致報警麻木；要麼監控系統五花八門，工具琳琅滿目，重複監控，條理不清，等等。
我認為產生這些問題的原因主要有兩點。其一，人的問題，是我們的運維工作人員對監控沒有深刻的認識，經驗不足；其二，工具的問題，沒有得心應手的工具，開源、閉源，五花八門，難以統籌高效利用及整合。
以前我們習慣於拿來主義，有問題需要用工具，上網查查別人都在用什麼，我也下載一個試一試，差不多就行了。
但是現在時代變了，IaaS、PaaS、SaaS的結構越來越複雜，對於運維工程師說來，必須對監控有深度定製或二次開發的能力才能滿足當下的需要。
所以我的建議是，可以考慮自研一套監控系統，這固然有壓力，但是一旦成功，收益巨大。俗話說萬事開頭難，開了頭其實就不難。我以自己的經驗來說說自寫一套監控系統的套路。
伺服器端
前端開發主要會用到大量的頁面元素，我建議使用目前開源的adminlte，這個前端框架元素非常豐富，頁面簡潔，比較適合作為監控系統的基礎頁面框架。
adminlte本身是基於Bootstrap開發的，對於我們將來進行深度頁面定製是非常友好的。圖表庫內建了font awesome和iconic，表單整合了Select2，adminlte幾乎能滿足你的任何要求。
在圖形展示上，建議使用Echarts監控圖表（參見下圖），它由百度團隊開發維護，資料文件非常豐富，在圖形質量、非同步獲取和載入方面都比較成熟，要把它嵌入到系統中，只需要引入一個JavaScript包發即可。
後臺開發使用Django，主要是快，無論是Model、FORM、Auth等系統，還是在外掛中介軟體的豐富程度、文件的完善度上，Django都具有絕對優勢。通過將平臺微服務化，Django本身的速度劣勢將被彌補。
在監控資料的設計方面，對資產資訊、使用者關係等的監控肯定要使MySQL這種關係性資料庫，但是對於監控條目的處理就得三思而後行了，我見過很多專案都是把監控條目直接丟到MySQL裡，導致後期擴充套件困難，資料庫成了監控平臺的巨大瓶頸。
我的方法是將所有監控資訊全部寫入MongoDB這樣的NoSQL資料庫，無論是在可擴充套件性還是效能上，它們都能應對當前海量的監控資料需求。
然後在服務端寫一個獨立的微服務介面，負責接收客戶端上傳的監控資訊，然後將資料進行處理後插入MongoDB，以供前端進行資料呼叫，下面程式碼截圖是一個API插入的示例。
這個API通過HTTP Server的方式啟動，然後監聽客戶端的POST資料，接收到資料後以伺服器本地時間為基準，打上監控資料的時間戳後存入MongoDB，並以主機名為依據，直接進行分表。
客戶端
客戶端的開發相對來說比較簡單，主要引入了requests 進行HTTP動作的處理，引入了Schedule進行定時上報和計劃任務，引入了Psutil進行效能資訊採集。
客戶端的效能資料主要依靠Psutil採集，Psutil有非常豐富的監控介面，能夠輕鬆實現對CPU、記憶體、網路、磁碟的監控。
獲取磁碟資訊的函式截圖如下：
通過Psutil提供的介面採集效能資訊，然後將結果封裝成一個Json資料，使用Requests Post提交到伺服器的API介面中去——一次監控過程就完成了。
監控平臺的通道也就打開了，以後監控任意條目的套路不過如此。NPM、中介軟體監控、APM，不都是這樣嗎？採集資料、上報、存檔並展現。
開發規劃
服務端、客戶端，資料庫和圖表展現完成之後，一個簡單的監控平臺雛形就完成了。這只是一個開始，DevOps的核心思想是持續學習、持續迭代，在這個過程中不斷完善。有了平臺和架子，我們就可以不斷地添磚加瓦。
對於硬體監控，可以通過Linux系統命令（比如smartctl、dmidecode等）來獲取相關資訊。
對於NPM、CPU、記憶體、磁碟、網路和程序，可使用Psutil來完成。
對於中介軟體監控，比如MySQL、Nginx，可以通過命令列或是中介軟體的監控介面來採集資料。
對於某些自定義監控，比如監控某個檔案大小、某個目錄的檔案數、某個檔案的屬性，可以用Shell來完成。
對於APM、應用程式指標、函式呼叫、響應時間、業務資料等，我們可以通過埋點、API或是JVM嗅探來完成。
對於報警系統，可以使用郵件、微信等形式，這個可以根據企業自身的需要來設定，都是十幾行程式碼即可搞定。
如果我們使用開源軟體Cacti Zabbix，在實現和整合上都會比較麻煩，很多時候會受制於軟體原有的結構，二次開發比較麻煩。
所以，我們何不自己寫一個，將所有的控制權都放在自己手上呢？況且又不是特別難，在開發平臺的過程中，你的Python技術、軟體工程能力都會有很大的提升，你將能夠快速實現企業的需求，而不是跑到社群去哭訴“給我加個功能吧”。
Python 開發三十六計：
如果您對其中內容表示質疑，歡迎指出並發表意見，一經採納，您將成為內測版讀者，《DevOps三十六計》在年末的第一批印刷將在第一時間送到您的手中。
想與郭巨集澤老師直接交流？請加入 DevOps 三十六計交流群
入群請加微信：gaoxiaoyunweiliuce
關注 DevOps 三十六計公眾號
我們將長期釋出 DevOps 三十六計完整內容
更多相關文章閱讀
騰訊 SNG 團隊首次系統性披露其運維體系：
第九屆GOPS全球運維大會將於2018年4月13日-14日在深圳召開。大會為期2天，側重方向包括AIOps、運維自動化和 DevOps。
為期兩天的大會將涵蓋眾多先進的技術與理念：
點選閱讀原文，進入大會官網