中小企業監控體系構建_知識分享【面試總結】

　　大名鼎鼎的中國運維社區的狼首趙瞬東相信你們都略有耳聞，江湖人稱趙班長，曾在武警某部負責指揮自動化的架構和運維工做，2008年退役後一直從事互聯網運維工做。曾帶團隊負責國內某食品電商的運維工做，同時帶領團隊建立了本身的運維社區，講本身多年經驗傳遞給衆多學者、運維人員，同時他也是即將出版的《saltstack入門與實踐》做者之一。

　　他的一篇博文對我頗有啓發，想要成功就是向有經驗的人學習因此我也在按照他的腳步再爬。廢話很少說請看正文之——詳解企業監控體系構建:

【內容借鑑思想！面試案例真實！】　　

　　在我以前的公司，招聘面試中，個人老大必問的一個問題就是「大家以前公司的監控體系是怎麼作的？你認爲怎麼作效果比較好？」

　　常常獲得這樣相似的答案：「咱們公司用的Nagios、Cacti作監控，或者說咱們公司用Zabbix作監控」，再繼續追問每每獲得的也是如何使用這些工具的細節的回答。

　　這樣的回答當然沒錯，但卻反映出來運維人員常常會被工具迷惑雙眼，從而忘記了最初的出發點。然而今天我被問到了。我答的並很差，特此總結：

1. 肯定目標、統一思想

　　咱們直接跳過什麼是監控和監控的重要性等大段描述，先仔細的想想，監控的目標是什麼？

　　每一個人的答案都不一樣，個人回答是：終極目標就是爲了保證業務的持續和穩定運行。如此偏激的回答就是讓讀者從如今開始要站在業務的角度的開始規劃監控體系，而不是某個技術範疇。

　　注意：本文不涉及性能測試、性能優化中的監控，全部文字的出發點都是平常運維監控。

　　在開始以前，咱們仍是先統一下認識：要監控一個對象，須要掌握哪些東西呢？

　　監控對象的理解：要監控的對象你是否瞭解呢？好比CPU究竟是如何工做的？

　　監控對象的指標：咱們要監控這個東西的什麼屬性？好比CPU的CPU使用率、負載、上下文切換。

　　肯定報警基準線：怎麼樣纔算是故障，要報警呢？好比CPU的負載到底多少算高？

　　若是上述的條件不知足，那就先不要開始實施監控了，由於等作完了，你會發現，然並卵？

二、監控實時過程

 

系統監控是監控體系的基礎，系統監控主要的對象有：

• CPU

• Memory

• IO

 

CPU：關於CPU，有3個重要的概念：上下文切換（context switchs），運行隊列（Run queue）和使用率（utilization）。

這也是咱們CPU監控的三個重點。一般狀況下，每一個處理器的運行隊列要小於等於3，CPU 利用率中user/system比例維持在70/30，上下文切換要根據系統繁忙程度來綜合考量。

經常使用的監控工具備：top vmstat mpstat

 

內存：Linux虛擬內存是一個龐大的東東，一般咱們須要監控內存的使用率、SWAP使用率、同時能夠經過內存的使用率曲線來發現某些服務的內存溢出等。可是，很巧的是阿里雲並無SWAP。此處咱們也作一下記錄

監控工具備：free vmstat

 

IO：IO分爲磁盤IO和網絡IO。除了在作性能調優咱們要監控更詳細的數據外，那麼平常監控，只關注磁盤使用率、io wait便可，網絡也是監控網卡流量便可。工具備iostat iotop iftop。

 

TCP監控：在不少狀況下有必要監控TCP的狀態，可使用netstat或者ss來獲取全部的TCP鏈接，來展示11種不一樣的TCP鏈接狀態的數量，能夠在大併發中及時發現TCP的相關故障。

 

其它的系統監控還有運行的進程數、登錄用戶、Open File等。

 

應用服務監控也是監控體系中比較重要的內容，例如：

• Apache：Apache提供了mod_status和mod_info模塊用來輸出Apache的狀態，各類grep和awk搞定。

• Nginx：一樣有狀態模塊，編譯的時候加上—with-http_stub_status_module，而後就可使用stub_status on來開啓了。

• Memcached：使用nc給memcached發送了一個stats命令就獲取到了全部想要的信息。

• Redis：使用nc給redis發送了一個info命令就獲取到了redis的相關狀態。

• JVM：使用jmconsole，或者jmx就能夠進行遠程監控。

三、引入Zabbix

固然，以上想要監控的內容，zabbix均可以實現

• 硬件監控：Zabbix IPMI Interface

• 系統監控：Zabbix Agent Interface

• Java監控：Zabbix JMX Interface

• 網絡設備監控：Zabbix SNMP Interface

• 應用服務監控：Zabbix Agent UserParameter

• MySQL數據庫監控：percona-monitoring-plulgins

• URL監控：Zabbix Web 監控

　　使用Zabbix Proxy能夠實現多機房的分佈式監控，對於告警通知：郵件、微信、短信、釘釘等，均可以與Zabbix快速的集成，網上有不少此類文檔。

　　同時，針對某些能夠進行直接處理的報警，Zabbix能夠觸發Action來輕鬆幫你實現，故障的自動處理。好比阿里的自我修復機制，一臺服務器宕機根據自身毀壞度進行自我修復自主上線。這個須要強大的開發能力，也能夠經過shell腳本進行判斷，此處不作過多解釋。

四、流量分析

　　萬事俱備只欠東風，基本監控都已經搭建完成，此時若是你的領導問，我們的PV是多少啊？此時你該如何應答？

　　netstat -ant | awk '/^tcp/{b[$NF]++}END{for(i in b)print i,b[i]}'

　　首先想到的是把訪問日誌拿出來各類awk而後sort一下，可是，難道就沒有作這些統計和分析的工具嗎？答案是有的。

　　google分析、百度統計、站長工具等等一堆統計的東西，只須要在頁面嵌入一個js便可。

　　可是呢？這個數據始終是在對方那裏，並且功能定製起來也不方便，因而google幫助了他，一個叫作piwik的開源項目映入眼簾。

　　網站流量分析對於運維人員來講，更是一門必須掌握的知識了。好比對於一家電商公司來講，經過對訂單來源的統計和分析，能夠了解咱們在某個網站上的廣告投入有沒有收到預期的效果。能夠區分不一樣地區的訪問人數、甚至商品交易額等。

　　並且，流量分析是運維向運營拓展的必經之路，做爲一名運維工程師頗有必要掌握公司站點的各類訪問詳情。

五、網絡監控

　　網絡監控是咱們構建監控平臺是必需要考慮的，尤爲是針對有多個機房的場景，各個機房之間的網絡狀態，機房和全國各地的網絡狀態都是咱們須要重點關注的對象，那麼如何掌握這些狀態信息呢？咱們須要藉助於網絡監控工具Smokeping。

　　Smokeping 是rrdtool的做者Tobi Oetiker的做品，是用Perl寫的，主要是監視網絡性能，www 服務器性能，dns查詢性能等，使用rrdtool繪圖，並且支持分佈式，直接從多個agent進行數據的彙總。

　　同時，因爲本身監控點比較少，還能夠藉助不少商業的監控工具，好比監控寶、基調、博瑞等。同時這些服務提供商還能夠幫助你監控CDN的狀態。

六、安全監控

雖然iptables能幫助完成四層的安全防禦，可是針對七層的Web層面怎麼辦呢？

那你說能夠用Nginx + Lua編寫了一個WAF，而後把相關的日誌記錄到了Elasticsearch中，經過kibana能夠圖形化的展現不一樣的攻擊類型的統計。

八、業務監控

那你的領導又問你，我們10點的時候總訂單是多少，每分鐘平均訂單有多少？這時候你又蒙了。（根據不一樣的公司不一樣的需求）

沒有業務指標監控的監控平臺是一個不完善的監控平臺，一般在咱們作監控系統中，必須將咱們重要的業務指標進行監控，並設置閾值進行告警通知。

好比每分鐘的訂單、每分鐘註冊、日活用戶、短信使用量等重要的業務指標均可以加入到Zabbix上。

注：因爲業務監控圖表，涉及到隱私的數據太多，就不截圖了。

九、日誌監控

一般狀況下，系統會產生系統日誌、應用程序會有應用的訪問日誌、錯誤日誌，服務有運行日誌等，可使用ELK來進行日誌監控。

對於日誌來講，最多見的需求就是收集、存儲、查詢、展現，開源社區正好有相對應的開源項目：

• logstash（收集）

• elasticsearch（存儲+搜索）

• kibana（展現）

咱們將這三個組合起來的技術稱之爲ELK Stack，因此說ELK Stack指的是Elasticsearch、Logstash、Kibana技術棧的結合。

若是收集了錯誤日誌，那麼若是部署更新有異常出現，能夠當即在kibana上看到。固然也可使用Zabbix來進行錯誤日誌的過濾來進行告警。

十、自動化

　　通過努力，終於從監控菜鳥到頭腦中有一個相對完整的監控體系的逆襲，可是在大規模的環境中，若是沒法作到自動化監控，那麼手動添加監控不只僅是一個恐怖的工做，並且也沒法保證完整性。

　　自動化的方案有不少，一般有主動和被動不一樣的形式，這裏相對Zabbix來講。

主動形式：

　　好比使用Zabbix的自動發現，主動的對全網進行掃描，而後自動添加相關的監控服務器和引用監控模板。

被動形式：

　　也可使用Zabbix API進行被動的監控的添加。好比以CMDB爲核心，若是檢測到某服務器增長了Nginx服務，那麼自動調用Zabbix API添加上Nginx的監控模板。

　　真正想作到更完整的監控體系，目前的開源軟件，確實沒法很好的知足，有條件的公司都開始本身開發本身的監控系統，好比小米開源的Open-Falcon。

　　也有比較好的開源的監控框架如Sensu等，再加上influxdb grafana能夠用來定製符合本身企業的監控平臺。

 

 

到面試結束

　　該結束了，由於我不管怎麼努力增長，仍是以爲總有漏下的，打死我也說不出來那麼多。

　　監控的話題還有不少不少，好比還有和運維相關的頁面性能監控（頁面資源數量、DNS解析時間、首屏時間、加載最慢的資源、產生阻塞的JS等）、代碼監控、與運維無關的輿論監控等，先這麼多吧！

　　好的，咱們是從面試開始引入的監控的話題，那麼就從面試結束吧！下次再遇到相似的面試題，我相信讀者內心必定有了本身的答案，這裏就不在詳述，一個相對完善的運維監控體系是否已經在你腦海中造成了呢？

 

FAQ：

故障自動處理有沒有相關的思路？

　　不一樣業務形態、不一樣架構、不一樣服務可能採用的方式都不一樣，這個沒有一個固定的東西分享。能夠參考以前騰訊藍鯨的分享，他們實現了故障自愈的功能。

運維須要懂業務嗎？

　　我我的的觀點是懂業務能讓運維走的更遠，運維服務的對象不必定是其它部門，爲何不能是終端用戶呢？

　　能夠站在終端用戶的視角來作運維，好比有用戶反映訪問慢，爲何慢，是架構的緣由，Nginx配置的緣由，仍是數據庫的緣由。

　　不要等着領導來安排，運維能帶來的價值是須要運維本身作出來的，思想有多遠，運維就能走多遠！

　　那麼監控在這裏發揮的做用就是：讓數聽說話！

 

若是你是一名運維工程師，動手幹吧，監控會是一個不斷完善的工程，這就是運維（運營）和項目的本質區別。