【原創(chuàng)】 2018-01-22 郭宏澤 高效運維

作者簡介：

郭宏澤，現(xiàn)任為勝科技技術總監(jiān)，高級咨詢師，IT解決方案專家。擁有12年IT行業(yè)工作經(jīng)驗，其中有8年一線運維經(jīng)驗，4年運維開發(fā)經(jīng)驗，曾就職于易車網(wǎng)、電信云計算、跟誰學等公司。開發(fā)過日志分析系統(tǒng)、CDN流量計費結算系統(tǒng)，自動化容器管理平臺等。精通Linux相關技術及Python、Shell、JavaScript等語言?，F(xiàn)任多家大型公司咨詢顧問，已幫助IBM、惠普、朗訊等多家跨國公司進行容器化及DevOps轉(zhuǎn)型。

AdminSet開源運維平臺創(chuàng)建者，DevOps Master，全球運維大會金牌講師，高效運維社區(qū)核心成員。

Python是一個浩瀚如煙的曠闊領域，有著豐富的應用場景，業(yè)務系統(tǒng)、云計算、大數(shù)據(jù)、人工智能都有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的區(qū)別

我們先來看看Python 2和Python 3 之間的主要區(qū)別，參見下表。更多新特性請參考：https://docs.python.org/3/whatsnew/3.0.html。

從Python社區(qū)官方態(tài)度來看，官方強烈建議直接學習Python 3，因為Python 2只會維護到2020年。那么看到這兒，可能你會覺得應該直接學習Python 3了，但實際上不是這樣，我們必須從Python 2開始。

如果我們對一件事舉棋不定，那么最好看看別人是怎么做的，下圖是Python各版本在2016年7月和8月的下載量統(tǒng)計圖。

通過數(shù)據(jù)換算（Y軸是指數(shù)），Python 2.6和Python 2.7的下載量占比超過90%。數(shù)據(jù)不會說謊，事實就是當前仍然是Python 2主導的世界，Python 2作為大部分應用和工具的基礎，還會在相當長的時間內(nèi)存在。

為什么會出現(xiàn)這樣的情況呢？原因有三：

• 技術的發(fā)展是快的，但是在生產(chǎn)中落地是非常緩慢的。

• 如果Python 2就能用，為什么非得升級到Python 3呢。

• Python 3不是所有操作系統(tǒng)的默認解釋器，在系統(tǒng)環(huán)境中使用Python 3會消耗巨大的成本。

出于實用主義考慮，如果能用螺絲刀解決的問題絕不會用一個電鉆來解決。使用Python的人大多數(shù)是實用主義者，所以出現(xiàn)了在Python3出現(xiàn)多年以后仍然無法普及的現(xiàn)象。

如何學習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版本都能兼容的語法，這樣既保證了在現(xiàn)有系統(tǒng)中的兼容性，又為將來全面向Python 3遷移做好了準備。

事實上Python 2的最新版本Python 2.7和Python 3的差異不超過10%，可以說是比較小的，另外Python 2.7已經(jīng)盡可能地彌合了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。

• 業(yè)務開發(fā)工程師可以直接使用Python 3.5。

開發(fā)一個簡單的監(jiān)控平臺

監(jiān)控對運維的重要性

“ 因為你是我的眼，讓我看見這世界就在我眼前”，這是一首耳熟能詳?shù)母枨赌闶俏业难邸?。監(jiān)控，對于運維工程師來說就是眼睛，如果沒有監(jiān)控，運維工作就無從談起；如果沒有監(jiān)控，運維工程師就成了盲人。

一個良好的監(jiān)控系統(tǒng)可以快速地發(fā)現(xiàn)并定位問題，減少宕機時間，提高故障處理速度，減輕運維工作壓力，甚至可以促進家庭和諧。

但是對于這么重要的系統(tǒng)，我發(fā)現(xiàn)很多公司都做的都不好：要么監(jiān)控不到位，很多盲區(qū)；要么監(jiān)控過多，太多無效條目導致報警麻木；要么監(jiān)控系統(tǒng)五花八門，工具琳瑯滿目，重復監(jiān)控，條理不清，等等。

我認為產(chǎn)生這些問題的原因主要有兩點。其一，人的問題，是我們的運維工作人員對監(jiān)控沒有深刻的認識，經(jīng)驗不足；其二，工具的問題，沒有得心應手的工具，開源、閉源，五花八門，難以統(tǒng)籌高效利用及整合。

以前我們習慣于拿來主義，有問題需要用工具，上網(wǎng)查查別人都在用什么，我也下載一個試一試，差不多就行了。

但是現(xiàn)在時代變了，IaaS、PaaS、SaaS的結構越來越復雜，對于運維工程師說來，必須對監(jiān)控有深度定制或二次開發(fā)的能力才能滿足當下的需要。

所以我的建議是，可以考慮自研一套監(jiān)控系統(tǒng)，這固然有壓力，但是一旦成功，收益巨大。俗話說萬事開頭難，開了頭其實就不難。我以自己的經(jīng)驗來說說自寫一套監(jiān)控系統(tǒng)的套路。

服務器端

前端開發(fā)主要會用到大量的頁面元素，我建議使用目前開源的adminlte，這個前端框架元素非常豐富，頁面簡潔，比較適合作為監(jiān)控系統(tǒng)的基礎頁面框架。

adminlte本身是基于Bootstrap開發(fā)的，對于我們將來進行深度頁面定制是非常友好的。圖表庫內(nèi)置了font awesome和iconic，表單整合了Select2，adminlte幾乎能滿足你的任何要求。

在圖形展示上，建議使用Echarts監(jiān)控圖表（參見下圖），它由百度團隊開發(fā)維護，資料文檔非常豐富，在圖形質(zhì)量、異步獲取和加載方面都比較成熟，要把它嵌入到系統(tǒng)中，只需要引入一個JavaScript包發(fā)即可。

后臺開發(fā)使用Django，主要是快，無論是Model、FORM、Auth等系統(tǒng)，還是在插件中間件的豐富程度、文檔的完善度上，Django都具有絕對優(yōu)勢。通過將平臺微服務化，Django本身的速度劣勢將被彌補。

在監(jiān)控數(shù)據(jù)的設計方面，對資產(chǎn)信息、用戶關系等的監(jiān)控肯定要使MySQL這種關系性數(shù)據(jù)庫，但是對于監(jiān)控條目的處理就得三思而后行了，我見過很多項目都是把監(jiān)控條目直接丟到MySQL里，導致后期擴展困難，數(shù)據(jù)庫成了監(jiān)控平臺的巨大瓶頸。

我的方法是將所有監(jiān)控信息全部寫入MongoDB這樣的NoSQL數(shù)據(jù)庫，無論是在可擴展性還是性能上，它們都能應對當前海量的監(jiān)控數(shù)據(jù)需求。

然后在服務端寫一個獨立的微服務接口，負責接收客戶端上傳的監(jiān)控信息，然后將數(shù)據(jù)進行處理后插入MongoDB，以供前端進行數(shù)據(jù)調(diào)用，下面代碼截圖是一個API插入的示例。

這個API通過HTTP Server的方式啟動，然后監(jiān)聽客戶端的POST數(shù)據(jù)，接收到數(shù)據(jù)后以服務器本地時間為基準，打上監(jiān)控數(shù)據(jù)的時間戳后存入MongoDB，并以主機名為依據(jù)，直接進行分表。

客戶端

客戶端的開發(fā)相對來說比較簡單，主要引入了requests 進行HTTP動作的處理，引入了Schedule進行定時上報和計劃任務，引入了Psutil進行性能信息采集。

客戶端的性能數(shù)據(jù)主要依靠Psutil采集，Psutil有非常豐富的監(jiān)控接口，能夠輕松實現(xiàn)對CPU、內(nèi)存、網(wǎng)絡、磁盤的監(jiān)控。

獲取磁盤信息的函數(shù)截圖如下：

通過Psutil提供的接口采集性能信息，然后將結果封裝成一個Json數(shù)據(jù)，使用Requests Post提交到服務器的API接口中去——一次監(jiān)控過程就完成了。

監(jiān)控平臺的通道也就打開了，以后監(jiān)控任意條目的套路不過如此。NPM、中間件監(jiān)控、APM，不都是這樣嗎？采集數(shù)據(jù)、上報、存盤并展現(xiàn)。

開發(fā)規(guī)劃

服務端、客戶端，數(shù)據(jù)庫和圖表展現(xiàn)完成之后，一個簡單的監(jiān)控平臺雛形就完成了。這只是一個開始，DevOps的核心思想是持續(xù)學習、持續(xù)迭代，在這個過程中不斷完善。有了平臺和架子，我們就可以不斷地添磚加瓦。

• 對于硬件監(jiān)控，可以通過Linux系統(tǒng)命令（比如smartctl、dmidecode等）來獲取相關信息。

• 對于NPM、CPU、內(nèi)存、磁盤、網(wǎng)絡和進程，可使用Psutil來完成。

• 對于中間件監(jiān)控，比如MySQL、Nginx，可以通過命令行或是中間件的監(jiān)控接口來采集數(shù)據(jù)。

• 對于某些自定義監(jiān)控，比如監(jiān)控某個文件大小、某個目錄的文件數(shù)、某個文件的屬性，可以用Shell來完成。

• 對于APM、應用程序指標、函數(shù)調(diào)用、響應時間、業(yè)務數(shù)據(jù)等，我們可以通過埋點、API或是JVM嗅探來完成。

• 對于報警系統(tǒng)，可以使用郵件、微信等形式，這個可以根據(jù)企業(yè)自身的需要來設置，都是十幾行代碼即可搞定。

如果我們使用開源軟件Cacti Zabbix，在實現(xiàn)和整合上都會比較麻煩，很多時候會受制于軟件原有的結構，二次開發(fā)比較麻煩。

所以，我們何不自己寫一個，將所有的控制權都放在自己手上呢？況且又不是特別難，在開發(fā)平臺的過程中，你的Python技術、軟件工程能力都會有很大的提升，你將能夠快速實現(xiàn)企業(yè)的需求，而不是跑到社區(qū)去哭訴“給我加個功能吧”。

Python 開發(fā)三十六計：

如果您對其中內(nèi)容表示質(zhì)疑，歡迎指出并發(fā)表意見，一經(jīng)采納，您將成為內(nèi)測版讀者，《DevOps三十六計》在年末的第一批印刷將在第一時間送到您的手中。