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

監(jiān)控對it運維來說到底有多重要？“因為你是我的眼，讓我看見這世界就在我眼前”，這是一首耳熟能詳的歌曲《你是我的眼》。監(jiān)控，對于it運維工程師來說就是眼睛，如果沒有監(jiān)控，it運維工作就無從談起；如果沒有監(jiān)控，it運維工程師就成了盲人。

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

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

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

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

但是現在時代變了，IaaS、PaaS、SaaS的結構越來越復雜，對于it運維工程師說來，必須對監(jiān)控有深度定制或二次開發(fā)的能力才能滿足當下的需要。所以我建議可以考慮開發(fā)一個簡單的監(jiān)控平臺，這固然有壓力，但是一旦成功，收益巨大。俗話說萬事開頭難，開了頭其實就不難。

監(jiān)控系統方法：

服務器端

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

adminlte本身是基于Bootstrap開發(fā)的，幾乎能滿足你的任何要求；在圖形展示上，建議使用Echarts監(jiān)控圖表；后臺開發(fā)使用Django，Django具有絕對優(yōu)勢。

在it運維監(jiān)控數據的設計方面，對資產信息、用戶關系等的監(jiān)控肯定要使MySQL這種關系性數據庫，很多項目都是把監(jiān)控條目直接丟到MySQL里，導致后期擴展困難，避免這種情況的方法是將所有監(jiān)控信息全部寫入MongoDB這樣的NoSQL數據庫，無論是在可擴展性還是性能上，它們都能應對當前海量的監(jiān)控數據需求。

然后在服務端寫一個獨立的微服務接口，負責接收客戶端上傳的監(jiān)控信息，然后將數據進行處理后插入MongoDB，以供前端進行數據調用。

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

客戶端

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

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

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

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

總結：

所以，我們何不寫一個，讓所有的公司監(jiān)控都沒有后患呢？在這里我只是提出的一種方法，如果您自己不能解決，那同創(chuàng)雙子it運維將為您服務。