## 監控的必要性
> 在一個IT環境中會存在各種各樣的設備，比如：硬件設備，軟件設備，系統環境，運行服務。那麼在這麼複雜的環境下，尤其是大公司裏成千上萬的服務器我們如何去管理和維護呢？如何能保證公司資源的正常運轉？我們通過什麼手段去及時掌握基礎環境和業務應用的可用性？如何獲取到各組件的運行狀態（如：CPU使用率，內存的使用率，硬盤的使用率，服務是否運行正常，端口是否存在，帶寬流量以及網站訪問的狀態碼），公司業務擴展需要增加服務器又該如何操作呢？等等這些問題都需要有一個系統的工具來幫助我們實現--這就是監控系統。
## 監控體系的實現
> 一個監控系統的組成大體可以分爲兩部分:數據採集（客戶端Agent）和數據存儲分析告警展示（服務端Server）
> 數據採集又分爲主動模式（客戶端主動上報數據到服務器）和被動模式（服務器到客戶端去採集數據）
> 通常情況下，大多數監控系統都支持這兩種模式。被動模式對服務器的開銷大，只適合中小企業的監控環境；而主動模式對服務器的開銷小，更適合企業的大規模的監控環境。
> 採集數據的協議有兩種：專用的客戶端採集和共用的協議採集（SNMP、SSH、Telnet等）
> 對採集到的監控數據，可以將其存儲到數據庫或者文本或者其他方式，根據企業的需求來決定。
## 開源的監控軟件介紹
- MRTG
>> MRTG（Multi Route Trffic Grapher）是一套可用來繪製網絡流量圖的軟件，由瑞士奧爾滕的Tobias Oetilker與Dave Rand所開發，以GPL授權。MRTG最好的版本是1995年推出的，用perl語言寫成，可跨平臺使用，數據財局用SNMP協議，MRTG將收集到的數據通過Web頁面以PNG格式繪製出圖像。
- Cacti
>> （英文含義仙人掌）是一套基於PHP、MySQL和RRDtool開發的網絡流量檢測圖形分析工具，它通過snmpget來獲取數據使用RRDtool繪圖，但使用者無須瞭解RRDtool複雜的參數；它提供了非常強大的數據和用戶管理功能，可以指定每一個用戶能查看樹狀結構、主機設備以及任何一張圖，還可以與ADAP結合進行用戶認證，同時也能自定義模板。在歷史數據展示監控方面，起功能相當不錯。
>> Cacti通過添加模板，是不同設備的監控添加具有可複用性，並且具備可自定義繪圖功能，具有強大的運算能力（數據的疊加功能）。
>> Cacti的官方網站：http://www.cacti.net/
- Smokeping
>> Smokeping主要的功能是用於監控網絡性能，包括常規的ping、www服務器性能、DNS查詢性能、SSH性能等。底層也是RRDtool做的支持，特點是繪製展示圖特別漂亮，玩過丟包和延遲用顏色和陰影來標識，支持將多張圖疊加放在一起，起作者還開發了MRTG和RRDtll等工具
>> Smokeping的官方網站：http://tobi.oetiker.cn
- Graphite
>> Craphite是一個用於採集網站實時信息並驚醒統計的開源的項目。Graphite服務支持平均每分鐘4800次更新操作，採用簡單文本協議，具有繪圖你能，其即插即用的功能方便地用於任何需要監控的系統上。
>> 和其他監控工具不同的而是，Graphite本身並不收集具體的數據，這些數據收集的工作通常由第三方工具或插件完成，可以說，Graphite是一個繪圖工具。
>> Graphite的安裝網址：http://graphite.wikidot.com/
- Nagios
>> Nagios（Nagios Ain’t Goona Insist on Saintood）是一個企業級別的、免費的、開源IT基礎設施監控系統，可監控服務的運行狀態和網絡信息等，並能監視所指定的本地或遠程主機參數以及服務，同時提供異常告警通知功能等。
>> Nagios可運行在Linux和UNIX平臺上。能有效監控Windows、Linux、UNIX、VMware的主機狀態，交換機、路由器等網絡設備，同時提供一個可選的基於瀏覽器的web界面以方便系統管理人員查看系統的運行狀態、網絡狀態、服務狀態、日誌信息以及其他異常現象等。
>> Nagios的功能側重於監控服務的可用性，能及時根據觸發條件告警。
>> 目前Nagios也佔領了一定的市場份額，不過Nagios並沒有與時俱進，已經不能厚滿足於多變的監控市場需求，架構的擴展性和使用的便捷性有待增強，其告警功能集成在商業版Nagios XI中。
>> Nagios能實現的功能特性：
1. 監控網絡服務（SMTP、POP3、HTTP、FTP、PING等）
2. 監控本級以及遠程主機資源（CPU負載、磁盤利用率、進程等）；
3. 允許用戶編寫主機的插件來監控特定的服務，方便地擴展主機的服務的檢測方法，支持多種開發語言（Shell、Perl、Python、PHP等）
4. 具備定義網絡分層結構的能力，用“parent”主機定義來表達網絡主機間的關係，這種關係可被用來發現和明晰主機宕機或不可達狀態
5. 當服務或主機問題產生於解決時將告警發送給聯繫人（通過EMail、短信、用戶定義方式）
6. 可以支持並實現對主機的冗餘監控
7. 可用Web界面查看當前的網絡狀態、通知和故障歷史、日誌文件等
>> Nagios的官網地址：http://www.nagios.org/
安裝步驟可參考：http://os.51cto.com/art/201403/433062.htm
- Zenoss
>> Zenoss（Zenoss Core）是開源企業級IT管理軟件，它允許IT管理員依靠單一的Web控制檯來監控網絡架構的狀態和健康度。
>> Zenoss Core的強大功能來自深入的列表與配置管理數據庫，用於發現和管理公司IT環境的各類資產（包括服務器、網絡和其他結構設備）。Zenoss可以創建資產清單和對應的組件級別（接口、服務、進程、已安裝的軟件等）建立好模型後，Zenoss就可以監控和報告IT架構中各種資源都餓 狀態和性能狀況了。同時還提供與CMDB關聯的時間和錯誤管理系統，以協助提高各類事件和提醒的管理效率，以此提高IT管理人員的效率。
>> 使用代理收集和基於標準的管理協議：
WMI、PerfMon、SNMP、JMX、HTTP、Telnet、SSH、Syslog、CIMP、FTP、SMTP等
>> Zenoss的官方地址：http://www.zenoss.org/
- Ganglia
>> Ganglia是一個跨平臺的、可擴展的。高性能的分佈式監控系統，如集羣和網絡。它基於分層設計，使用廣泛的技術，用RRDtool存儲數據。具有可視化界面，適合對集羣系統的自動化監控。其精心設計的數據結構和算法使得監控端到被監控端的連接開銷非常低。目前已經有成千上萬的集羣正在使用這個監控系統，可以輕鬆的管理2000個節點的集羣環境。
>> Ganglia是UC Berkeley發起的一個開源集羣監視項目，核心包含gmond、gmetad以及一個web前端，主要用於監控系統性能，如：cpu、mem、硬盤利用率、I/O負載、網絡流量情況等，通過曲線很容易見到每個節點的工作狀態。
>> Ganglia的工作原理是，每臺服務器上運行一個收集和發送度量數據的名爲gmond的守護進程；gmetad可以部署在集羣內任一臺節點上或者通過網絡連接到集羣的獨立柱基，它通過單播路由的方式與gmond通信，收集區域內節點的狀態信息，並以XML數據的形式保存在數據庫中；有RRDtool工具處理數據，並生成相應的圖形顯示，以Web方式直觀的提供給客戶端。
>> Ganglia官方地址：http://ganglia.info/
- OpenTSDB
>> OpenTSDB是一款開源的監控系統，用Hbase存儲所有哦時序（無序採樣）的數據，來構建一個分佈式、可伸縮的時間序列數據庫。它支持妙計數據採集，支持永久存儲，可以做容量規劃，並很容易地接入到現有的告警系統裏。
>> OpenTSDB可以從大規模的集羣（包括集羣中的網絡設備、操作系統、應用程序）中獲取相應的而採集指標，並進行存儲、索引和服務，從而使這些數據更容易讓人理解，如Web花、圖形化等
>> OpenTSDB的官放網址：http://opentsdb.net/
- Zabbix
>> Zabbix是一個基於Web界面的提供分佈式系統監控以及網絡監控功能的而企業級的開源解決方案。
>> Zabbix能監視各種網絡參數，保證服務器系統的安全運營；並提供靈活的通知機制以讓系統管理員快速定位/解除存在的各種問題。
>> Zabbix由兩部分組成：zabbix server和可選組件zabbix agent
>> Zabbix server可以通過SNMP、zabbix agent、ping、端口監視等方法提供對遠程服務器/網絡狀態的監視，數據收集等功能，它可以運行在Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OSX等平臺上，將收集到的數據進行分析整理，達到條件觸發告警。
>> 從以上各種監控系統的對比來看，Zabbix都是具有優勢的，其豐富的功能、可擴展的能力、二次開發的能力和簡單易用，只要使用者稍加學習即可上手使用。
>> Zabbix的官方網站：http://www.zabbix.com/
## Zabbix簡介
1. Zabbix簡介
>> 隨着雲計算、虛擬化的大規模應用，以及未來移動互聯網、物聯網等的興起，Zabbix的使用將越來越廣泛，應用場合也越來越多。目前，不少互聯網公司、雲計算公司、需要繼承軟件公司、外包服務公司等，都有對Zabbix進行二次開發和大規模的使用。所以，可以斷言，Zabbix在未來將會引領監控軟件的浪潮，這也是爲什麼要學習Zabbix的原因之一。
>> Zabbix適合大中型，中小型企業，單個Server節點可以支持上萬臺設備，每秒可以處理1.5萬此請求，理論上可以支持5萬臺設備。Zabbix自身的定位是中小型企業和大型企業，如果在特大型環境中使用，需要解決大併發、大壓力的問題，這對使用者提出了更高的要求。Zabbi是真正的源代碼開源產品，用戶可以自由下載並使用。
2.Zabbix的功能特性
- 數據收集：可用、性能檢測；支持Agent、SNMP、IPMI、JMX、SSH、Telnet等；自定義的檢測；自定義收集數據的頻率；服務端/代理端和客戶端模式
- 靈活的觸發器：可以自定義非常靈活的閥值和多種相關聯的條件
- 高度可定製的告警：發送通知，可以定製包括告警級別、動作升級、收件人和媒體類型
- 實時的繪圖功能：監控項將數據實時繪製在圖形上
- Web監控能力：Zabbix可以monitor瀏覽器請求一個網站，並檢測返回值和響應時間
- 多種可視化的展示：可以自定義監控的展示圖。將多種監控數據集中展示到以張圖上；網絡拓撲圖；自定義Screens和Slide shows可以將多種圖形集中展示；報表功能；資源使用情況的監控展示
- 歷史數據的存儲：數據存儲在數據庫中；歷史數據的存放週期可配置；定期刪除國企的歷史數據
- 配置簡單易上手：配置比較簡單，只需要一下兩步即可-->添加設備和應用模板即可完成監控
- 使用模板：模板可以分組；模板具有可繼承性
- 網絡發現：支持自動發現網絡設備和服務器（可以通過自動發現服務規則實現）；Agent自動發現；支持自動發現實現動態監控的而批量監控（支持自定義）內置的自動發現包括文件系統、網絡接口、SNMP OLD，可定製自動發現。
- 快速的訪問接口：Web頁面基於PHP；遠程訪問；日誌審計
- API功能：應用API功能可以方便地和其他系統結合，包括手機客戶端的使用
- 系統權限：不同的用戶展示監控的資源不同
- 程序特性：用C語言編寫，其性能和內存開銷非常小
- 大型環境的支持：利用Zabbix-Proxy方式即可輕鬆構建遠程監控
3.選擇Zabbix七大理由
- Zabbix是一個自由開發源代碼的產品，用戶可以對源代碼進行任意修改和二次開發。Zabbix採用GNU General Public License (GPL) Version2開源協議
- 安裝和配置簡單，用戶僅僅需要一些簡單的學習，即可完成監控的搭建工作
- 搭建環境簡單，基於開源軟件構建平臺，僅需要Linux、Apache/Nginx、MySQL/PostgreSQL/Oracle、PHP即可，無須專用操作系統支持，也無須專用硬件
- Zabbix-Agent完全支持Linux、UNIX、Windows、AIX、BSD和Solaris的監控，Server和Agent都採用C語言編碼，對系統的資源佔用非常小，數據採集的性能和速度非常快
- 將數據採集持久存儲到數據庫，便於對監控數據的二次分析
- 非常豐富的擴展能力，很輕鬆地自定義監控項和實現數據採集，幾乎能監控所有的數據。例如：可以監控網站的訪問次數，監控UPS和天氣溫度等。毫不誇張地說，在Zabbix的世界裏，往往有想不到的事情，沒有辦不到的事情。
- 開源社區的運作模式，有各種論壇、郵件列表、IM及時溝通等。
## 進入正題，對監控的理解
1.確定目標、統一思想
- 我們直接跳過什麼是監控和監控的重要性等大段描述，先仔細的想一想，監控的目標是什麼？每個人的答案都不同，我的回答是：終極目標就是爲了保證業務的持續和穩定運行。如此偏激的回答就是讓讀者從現在開始要站在業務的角度的開始規劃監控體系，而不是某個技術範疇。
- 在開始之前，我們還是先統一下認識：要監控一個對象，需要掌握哪些東西呢？
- 監控對象的理解：要監控的對象你是否瞭解呢？比如CPU到底是如何工作的？
- 監控對象的指標：我們要監控這個東西的什麼屬性？比如CPU的CPU使用率、負載、上下文切換。
- 確定報警基準線：怎麼樣纔算是故障，要報警呢？比如CPU的負載到底多少算高？
2.如果你不知道從和入手，那麼 我們就慢慢一步一步來，最後做個總結
- 硬件監控
> 硬件設備監控是最基礎的監控手段，比如定期的的機房巡檢。
>> 通常我們的服務器上都會有遠程控制卡，如Dell的iDRAC,HP的ILO和IBM的IMM等，可以通過Web界面來進行硬件的監控和管理工作，如果購買企業級的授權，還可以使用控制檯進行管理。在Linux下，通常我們使用IPMI來完成物理設備的監控工作。通常必須要監控的就是溫度、硬盤故障等。
- 系統監控
> 首先考慮的就是服務器的系統資源的使用情況，這是監控體系的基礎，監控的多項包括:
>> CPU
>>> 關於CPU，有3個重要的概念：上下文切換（context switchs），運行隊列（Run queue）和使用率（utilization）。
>>> 這也是我們CPU監控的三個重點。通常情況下，每個處理器的運行隊列要小於等於3，CPU 利用率中user/system比例維持在70/30，上下文切換要根據系統繁忙程度來綜合考量。
>>> 常用的監控工具有：top vmstat mpstat
>> Memory
>>> Linux虛擬內存是一個龐大的東東，通常我們需要監控內存的使用率、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就可以進行遠程監控
>> 還需要將所有的API接口狀態進行監控，比如通過curl檢查返回的HTTP狀態碼。有條件的用戶，可以做一個URL監控平臺，專門用來做這個事情,這樣就會顯的一目瞭然.
3.那麼問題來了,最開始這些活用腳本都能實現,但是慢慢的發現,隨着公司的發展和業務的擴大,腳本越來越多,每天郵箱裏的郵件也越來越多,每天上班光郵件就得看好長時間,那麼就需要使用一個軟件類來實現這些功能了,於是乎,很熱門,很流行的監控軟件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還提供了Zabbix Proxy代理來實現跨機房的分佈式監控
> 對於告警通知：郵件、微信、短信、釘釘等，都可以與Zabbix快速的集成，網上有很多此類文檔。
> 針對某些可以進行直接處理的報警，Zabbix可以觸發Action來輕鬆幫你實現，故障的自動處理。
- 流量分析
>> 網上很多，比如google分析、百度統計、站長工具等等一堆統計的東西，只需要在頁面嵌入一個js即可，但是這些工具的數據都不在本地，於是一個叫做piwik的開源項目幫我們解決了這個問題。參考：https://www.oschina.net/question/17_1525
- 網絡監控
>> 網絡監控是我們構建監控平臺是必須要考慮的，尤其是針對有多個機房的場景，各個機房之間的網絡狀態，機房和全國各地的網絡狀態都是我們需要重點關注的對象，那麼如何掌握這些狀態信息呢？我們需要藉助於網絡監控工具Smokeping。
>> Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl寫的，主要是監視網絡性能，www 服務器性能，dns查詢性能等，使用rrdtool繪圖，而且支持分佈式，直接從多個agent進行數據的彙總。
>> 同時，由於自己監控點比較少，還可以藉助很多商業的監控工具，比如監控寶、基調、博瑞等。同時這些服務提供商還可以幫助你監控CDN的狀態。參考：***linux/shiyongsmokepingjiankongidcjifangwangluozhiliangqingkuang_556136_1375949500.html
- 安全監控
>> 雖然iptables完成了四層的安全防護，但是針對七層的Web層面怎麼辦呢？可以使用Nginx + Lua編寫了一個WAF，然後把相關的日誌記錄到了Elasticsearch中，通過kibana可以圖形化的展示不同的***類型的統計。參考：https://github.com/loveshell/ngx_lua_waf
- 業務監控
>> 沒有業務指標監控的監控平臺是一個不完善的監控平臺，通常在我們做監控系統中，必須將我們重要的業務指標進行監控，並設置閾值進行告警通知。
>> 比如每分鐘的訂單、每分鐘註冊、日活用戶、短信使用量等重要的業務指標都可以加入到Zabbix上。
- 日誌監控
> 通常情況下，系統會產生系統日誌、應用程序會有應用的訪問日誌、錯誤日誌，服務有運行日誌等，可以使用ELK來進行日誌監控。
> 對於日誌來說，最常見的需求就是收集、存儲、查詢、展示，開源社區正好有相對應的開源項目：
>> logstash（收集）
>> elasticsearch（存儲+搜索）
>> kibana（展示）
> 我們將這三個組合起來的技術稱之爲ELK Stack，所以說ELK Stack指的是Elasticsearch、Logstash、Kibana技術棧的結合。
> 如果收集了錯誤日誌，那麼如果部署更新有異常出現，可以立即在kibana上看到。當然也可以使用Zabbix來進行錯誤日誌的過濾來進行告警。
- 自動化
> 在大規模的環境中，如果無法做到自動化監控，那麼手動添加監控不僅僅是一個恐怖的工作，而且也無法保證完整性
>> 主動模式 比如使用Zabbix的自動發現，主動的對全網進行掃描，然後自動添加相關的監控服務器和引用監控模板
>> 被動模式 也可以使用Zabbix API進行被動的監控的添加。比如以CMDB爲核心，如果檢測到某服務器增加了Nginx服務，那麼自動調用Zabbix API添加上Nginx的監控模板
> 真正想做到更完整的監控體系，目前的開源軟件，確實無法很好的滿足，有條件的公司都開始自己開發自己的監控系統，比如小米開源的Open-Falcon。也有比較好的開源的監控框架如Sensu等，再加上influxdb grafana可以用來定製符合自己企業的監控平臺。
- 可視化
> 運維的重要目標之一就是數據的可視化，一個監控平臺不能很好的反映出來業務的波動，就是耍流氓。之前的一切努力在業務部門的領導中變得一文不值。
>> 面向傳統運維：
>>> 儘可能的完善業務監控，如果有專門的業務分析系統，要想辦法和運維的監控平臺進行結合
>>> 梳理清楚各個子系統之間和業務的關係，比如如果突然間流量增加了50M，能夠快速的知道這50M流量到了那個業務系統上，訪問的哪些URL，以及這個業務系統的相關狀態
>> 面向DevOps：
>>> 將所有的監控項和業務之間建立關係樹，比如業務、網絡、系統、數據庫、流量、推廣活動（流量分析）之間可以形成一個龐大的關係鏈。這是一個比較龐大的工程，業務是多變的，如何讓監控平臺能儘可能的適應多變的業務是一個艱鉅的任務。參考：http://echarts.baidu.com/index.html
4.還有和運維相關的頁面性能監控（頁面資源數量、DNS解析時間、首屏時間、加載最慢的資源、產生阻塞的JS等）、代碼監控、與運維無關的輿論監控等.