編輯
高浩淼（整理）
做者介紹
趙舜東
江湖人稱趙班長，曾在武警某部負責指揮自動化的架構和運維工做，2008年退役後一直從事互聯網運維工做。曾帶團隊負責國內某食品電商的運維工做，即將出版的《saltstack入門與實踐》做者之一。
主題簡介
咱們今天的話題是《中小企業監控體系構建實戰》，前期分享了《中小企業自動化部署實戰》尚未看到的朋友能夠先閱讀下，這樣也能明白爲什麼要定位中小企業。監控這個話題實在太大，因此本文的正肯定位應該是如何構建一個「相對」完善的監控體系。
從面試開始
在以前的招聘面試中，我必問的一個問題就是「大家以前公司的監控體系是怎麼作的？你認爲怎麼作效果比較好？」
常常獲得這樣相似的答案：「咱們公司用的Nagios、Cacti作監控，或者說咱們公司用Zabbix作監控」，再繼續追問每每獲得的也是如何使用這些工具的細節的回答。
這樣的回答當然沒錯，但卻反映出來運維人員常常會被工具迷惑雙眼，從而忘記了最初的出發點。本文就以一個剛入職的運維工程師小王的故事來闡述監控體系，因此這個故事的名字叫作《小王特煩惱》。
1. 肯定目標、統一思想
咱們直接跳過什麼是監控和監控的重要性等大段描述，先仔細的想想，監控的目標是什麼？
每一個人的答案都不一樣，個人回答是：終極目標就是爲了保證業務的持續和穩定運行。如此偏激的回答就是讓讀者從如今開始要站在業務的角度的開始規劃監控體系，而不是某個技術範疇。
注意：本文不涉及性能測試、性能優化中的監控，全部文字的出發點都是平常運維監控。
在開始以前，咱們仍是先統一下認識：要監控一個對象，須要掌握哪些東西呢？
監控對象的理解：要監控的對象你是否瞭解呢？好比CPU究竟是如何工做的？
監控對象的指標：咱們要監控這個東西的什麼屬性？好比CPU的CPU使用率、負載、上下文切換。
肯定報警基準線：怎麼樣纔算是故障，要報警呢？好比CPU的負載到底多少算高？
若是上述的條件不知足，那就先不要開始實施監控了，由於等作完了，你會發現，然並卵？
2. 故事開始
王小明（化名）剛剛畢業，到了一家剛剛起步的電商公司任職：運維工程師，剛上班第一天，小王收到領導安排的光榮任務:把咱們公司的監控搞起來！
小王想了很久，沒想明白，索性不想了，從手頭接觸到的慢慢開始吧,因而小王決定先去機房看看。
2.1 硬件監控
到了機房，小王看着公司的各類品牌的服務器，想到的第一件事情就是，這些硬件設備，我要監控起來。
硬件設備監控是最基礎的監控手段，好比按期的的機房巡檢。
一般咱們的服務器上都會有遠程控制卡，如Dell的iDRAC,HP的ILO和IBM的IMM等，能夠經過Web界面來進行硬件的監控和管理工做，若是購買企業級的受權，還可使用控制檯進行管理。
在Linux下，一般咱們使用IPMI來完成物理設備的監控工做。一般必需要監控的就是溫度、硬盤故障等。
小王編寫了本身職業生涯的第一個腳本，就是使用ipmi工具獲取溫度傳感器的數據，大於50就發一份郵件給他，雖然感受不高端，但總算是有一個開始。
故障回想：以前我司託管在北京某機房的設備就出現過，由於恰好所在機櫃區域的空調壞了，致使服務器溫度太高，而後系統宕機。
2.2 系統監控
小王下一個想到的就是系統監控，公司全是Linux的服務器，系統資源的使用狀況，確定是要監控起來的。
系統監控是監控體系的基礎，系統監控主要的對象有：
CPU
Memory
IO
CPU：關於CPU，有3個重要的概念：上下文切換（context switchs），運行隊列（Run queue）和使用率（utilization）。
這也是咱們CPU監控的三個重點。一般狀況下，每一個處理器的運行隊列要小於等於3，CPU 利用率中user/system比例維持在70/30，上下文切換要根據系統繁忙程度來綜合考量。
經常使用的監控工具備：top vmstat mpstat
內存：Linux虛擬內存是一個龐大的東東，一般咱們須要監控內存的使用率、SWAP使用率、同時能夠經過內存的使用率曲線來發現某些服務的內存溢出等。
監控工具備：free vmstat
IO：IO分爲磁盤IO和網絡IO。除了在作性能調優咱們要監控更詳細的數據外，那麼平常監控，只關注磁盤使用率、io wait便可，網絡也是監控網卡流量便可。工具備iostat iotop iftop。
TCP監控：在不少狀況下有必要監控TCP的狀態，可使用netstat或者ss來獲取全部的TCP鏈接，來展示11種不一樣的TCP鏈接狀態的數量，能夠在大併發中及時發現TCP的相關故障。
其它的系統監控還有運行的進程數、登錄用戶、Open File等。
2.3 應用服務監控
小王把硬件監控和系統監控研究明白後，登錄到服務器上繼續研究，偶然間一個ps aux，小王發現，咱們服務器上運行了這麼多的服務，那都須要監控起來啊。
應用服務監控也是監控體系中比較重要的內容，例如：
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就能夠進行遠程監控。
因而小王，將線上的各類服務，都一個一個的進行了監控，這樣這些服務的詳細的運行狀態就瞭如指掌了。
同時，還須要將全部的API接口狀態進行監控，好比經過curl檢查返回的HTTP狀態碼。有條件的用戶，能夠作一個URL監控平臺，專門用來作這個事情。
2.4 引入Zabbix
自從小王接收到監控的任務後，這Shell編程能力是愈來愈強了，可是天天一打開郵箱就被各類報警所淹沒，腳本多而雜亂。
小王想，我須要一個什麼監控工具來幹這些事，不能這麼寫腳本下去了。因而在網上進行各類搜索，發現了不少的監控工具如Nagios、Cacti、Zabbix，原來本身以前費那麼大勁，這些工具早就實現了。
通過相關的對比，小王選擇了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的自動發現功能實現上線一臺服務器後，自動添加監控。
使用Zabbix Proxy實現了多機房的分佈式監控，這簡直太棒了。
對於告警通知：郵件、微信、短信、釘釘等，均可以與Zabbix快速的集成，網上有不少此類文檔。
同時，針對某些能夠進行直接處理的報警，Zabbix能夠觸發Action來輕鬆幫你實現，故障的自動處理。
因而小王準備向經理彙報工做，此處省略300字，可是不到10分鐘小王垂直頭回來了。由於經理問了一個問題，小王回答不上來：小王，今天我們網站的總體PV是多少？如今訪問最多的頁面是哪一個？
2.5 流量分析
小王首先想到的是把訪問日誌拿出來各類awk而後sort一下，可是此次他沒有急於開始，難道就沒有作這些統計和分析的工具嗎？
因而小王發現了google分析、百度統計、站長工具等等一堆統計的東西，只須要在頁面嵌入一個js便可。
可是呢？這個數據始終是在對方那裏，並且功能定製起來也不方便，因而google幫助了他，一個叫作piwik的開源項目映入眼簾。
網站流量分析對於運維人員來講，更是一門必須掌握的知識了。好比對於一家電商公司來講，經過對訂單來源的統計和分析，能夠了解咱們在某個網站上的廣告投入有沒有收到預期的效果。能夠區分不一樣地區的訪問人數、甚至商品交易額等。
並且，流量分析是運維向運營拓展的必經之路，做爲一名運維工程師頗有必要掌握公司站點的各類訪問詳情。
2.6 網絡監控
做爲一個針對全國用戶的電商網站，時刻掌握各地到機房的網絡狀態是小王的下一個監控目標。
網絡監控是咱們構建監控平臺是必需要考慮的，尤爲是針對有多個機房的場景，各個機房之間的網絡狀態，機房和全國各地的網絡狀態都是咱們須要重點關注的對象，那麼如何掌握這些狀態信息呢？咱們須要藉助於網絡監控工具Smokeping。
Smokeping 是rrdtool的做者Tobi Oetiker的做品，是用Perl寫的，主要是監視網絡性能，www 服務器性能，dns查詢性能等，使用rrdtool繪圖，並且支持分佈式，直接從多個agent進行數據的彙總。
同時，因爲本身監控點比較少，還能夠藉助不少商業的監控工具，好比監控寶、基調、博瑞等。同時這些服務提供商還能夠幫助你監控CDN的狀態。
2.7 安全監控
雖然iptables幫助小王完成了四層的安全防禦，可是針對七層的Web層面怎麼辦呢？
因而小王使用Nginx + Lua編寫了一個WAF，而後把相關的日誌記錄到了Elasticsearch中，經過kibana能夠圖形化的展現不一樣的攻擊類型的統計。
同時小王學習使用python還寫了一個爬蟲按期掃描github，有沒有公司相關的關鍵字，以避免同事分享代碼時，不當心涉及到敏感的內容。
（圖片來源https://github.com/loveshell/ngx_lua_waf）
2.8 業務監控
小王再去向經理彙報，剛走到門口被總經理碰上了，張總說：小王啊，大家經理彙報你最近監控工做乾的不錯，你給我說下，我們如今10點的時候總訂單是多少，每分鐘平均訂單有多少？
小王又蒙了，我本身也曾經就是那個小王！
沒有業務指標監控的監控平臺是一個不完善的監控平臺，一般在咱們作監控系統中，必須將咱們重要的業務指標進行監控，並設置閾值進行告警通知。
好比每分鐘的訂單、每分鐘註冊、日活用戶、短信使用量等重要的業務指標均可以加入到Zabbix上。
注：因爲業務監控圖表，涉及到隱私的數據太多，就不截圖了。
2.9 日誌監控
一般狀況下，系統會產生系統日誌、應用程序會有應用的訪問日誌、錯誤日誌，服務有運行日誌等，可使用ELK來進行日誌監控。
對於日誌來講，最多見的需求就是收集、存儲、查詢、展現，開源社區正好有相對應的開源項目：
logstash（收集）
elasticsearch（存儲+搜索）
kibana（展現）
咱們將這三個組合起來的技術稱之爲ELK Stack，因此說ELK Stack指的是Elasticsearch、Logstash、Kibana技術棧的結合。
若是收集了錯誤日誌，那麼若是部署更新有異常出現，能夠當即在kibana上看到。固然也可使用Zabbix來進行錯誤日誌的過濾來進行告警。
2.10 自動化
通過努力，小王完成從監控菜鳥到頭腦中有一個相對完整的監控體系的逆襲，可是在大規模的環境中，若是沒法作到自動化監控，那麼手動添加監控不只僅是一個恐怖的工做，並且也沒法保證完整性。
自動化的方案有不少，一般有主動和被動不一樣的形式，這裏相對Zabbix來講。
主動形式：
好比使用Zabbix的自動發現，主動的對全網進行掃描，而後自動添加相關的監控服務器和引用監控模板。
被動形式：
也可使用Zabbix API進行被動的監控的添加。好比以CMDB爲核心，若是檢測到某服務器增長了Nginx服務，那麼自動調用Zabbix API添加上Nginx的監控模板。
真正想作到更完整的監控體系，目前的開源軟件，確實沒法很好的知足，有條件的公司都開始本身開發本身的監控系統，好比小米開源的Open-Falcon。
也有比較好的開源的監控框架如Sensu等，再加上influxdb grafana能夠用來定製符合本身企業的監控平臺。
2.11 可視化
通過小王的各類努力，終於一個相對完善的監控平臺使用Zabbix構建起來了，小王爲此還作一個漂亮的screen，來進行展現，可是有一天忽然訂單量特別少，張總又一次到了運維部，但失望而歸，由於整個監控體系並不能反映出來訂單量爲何減小了？
運維的重要目標之一就是數據的可視化，一個監控平臺不能很好的反映出來業務的波動，就是耍流氓。以前的一切努力在業務部門的領導中變得一文不值！！！
咱們能作的有如下幾點：
面向傳統運維：
儘量的完善業務監控，若是有專門的業務分析系統，要想辦法和運維的監控平臺進行結合。
梳理清楚各個子系統之間和業務的關係，好比若是忽然間流量增長了50M，可以快速的知道這50M流量到了那個業務系統上，訪問的哪些URL，以及這個業務系統的相關狀態。
面向DevOps：
將全部的監控項和業務之間創建關係樹，好比業務、網絡、系統、數據庫、流量、推廣活動（流量分析）之間能夠造成一個龐大的關係鏈。這是一個比較龐大的工程，業務是多變的，如何讓監控平臺能儘量的適應多變的業務是一個艱鉅的任務。
（圖來源於http://echarts.baidu.com/index.html）
到面試結束
該結束了，由於我不管怎麼努力增長，仍是以爲總有漏下的。
監控的話題還有不少不少，好比還有和運維相關的頁面性能監控（頁面資源數量、DNS解析時間、首屏時間、加載最慢的資源、產生阻塞的JS等）、代碼監控、與運維無關的輿論監控等，先這麼多吧！
好的，咱們是從面試開始引入的監控的話題，那麼就從面試結束吧！下次再遇到相似的面試題，我相信讀者內心必定有了本身的答案，這裏就不在詳述，一個相對完善的運維監控體系是否已經在你腦海中造成了呢？
小貼士：面試中，若是你遇到一個有很強的責任心，連洗澡都要帶上手機，以避免錯過報警的人，不要猶豫，先招進來再慢慢培養吧。責任心是運維工程師的第一要素！
後記：小王的故事結束了，小王目前被監控的關係樹鍛鍊的連王菲、李亞鵬的關係都能搞明白了。但是你呢？
若是你是一名運維工程師，動手幹吧，監控會是一個不斷完善的工程，這就是運維（運營）和項目的本質區別。
若是你是一名Devops，那麼開始編程吧！
若是你是一名老闆，給公司的運維工程師一個轉變的機會和一些時間，人老是不斷進步的！
FAQ：
故障自動處理有沒有相關的思路？
不一樣業務形態、不一樣架構、不一樣服務可能採用的方式都不一樣，這個沒有一個固定的東西分享。能夠參考以前騰訊藍鯨的分享，他們實現了故障自愈的功能。
運維須要懂業務嗎？
我我的的觀點是懂業務能讓運維走的更遠，運維服務的對象不必定是其它部門，爲何不能是終端用戶呢？
能夠站在終端用戶的視角來作運維，好比有用戶反映訪問慢，爲何慢，是架構的緣由，Nginx配置的緣由，仍是數據庫的緣由。
不要等着領導來安排，運維能帶來的價值是須要運維本身作出來的，思想有多遠，運維就能走多遠！
那麼監控在這裏發揮的做用就是：讓數聽說話！
作監控也須要CMDB嗎？
我認爲CMDB是基礎，尤爲是在自動化運維的模式下，你須要有一個地方能準確的提供一臺服務器放在哪一個位置、配置是什麼？何時購買的？何時過保？都運行了哪些服務、開放了什麼端口、版本是什麼（升級時使用）。
有了這些數據，就能夠輕鬆和配置管理系統、部署系統、監控系統有效的結合起來。總結起來就是：以業務爲導向、以CMDB爲中心、以API爲基礎來進行運維體系的建設。
有了CMDB的數據支撐，那些看着高大上的自動繪出架構圖和機櫃圖就不是難事了。