監控的意義
監控是整個運維乃至整個產品生命周期中最重要的一環，事前及時預警發現故障，事后提供詳實的數據用于追查定位問題。
嚴格意義上來說，線上的服務器沒有監控，是不允許上線的。
常用的開源監控
- 老牌監控:
MRTG（Multi Route Trffic Grapher）是一套可用來繪制網絡流量圖的軟件，由瑞士奧爾滕的Tobias Oetiker與Dave Rand所開發，以GPL授權。 MRTG最好的版本是1995年推出的，用perl語言寫成，可跨平臺使用，數據采集用SNMP協議，MRTG將手機到的數據通過Web頁面以GIF或者PNG格式繪制出圖像。
Grnglia是一個跨平臺的、可擴展的、高性能的分布式監控系統，如集群和網格。它基于分層設計，使用廣泛的技術，用RRDtool存儲數據。具有可視化界面，適合對集群系統的自動化監控。其精心設計的數據結構和算法使得監控端到被監控端的連接開銷非常低。目前已經有成千上萬的集群正在使用這個監控系統，可以輕松的處理2000個節點的集群環境。
Cacti（英文含義為仙人掌）是一套基于PHP、MySQL、SNMP和RRDtool開發的網絡流量監測圖形分析工具，它通過snmpget來獲取數據使用RRDtool繪圖，但使用者無須了解RRDtool復雜的參數。提供了非常強大的數據和用戶管理功能，可以指定每一個用戶能查看樹狀結構、主機設備以及任何一張圖，還可以與LDAP結合進行用戶認證，同時也能自定義模板。在歷史數據展示監控方面，其功能相當不錯。 Cacti通過添加模板，使不同設備的監控添加具有可復用性，并且具備可自定義繪圖的功能，具有強大的運算能力（數據的疊加功能）
Nagios是一個企業級監控系統，可監控服務的運行狀態和網絡信息等，并能監視所指定的本地或遠程主機狀態以及服務，同時提供異常告警通知功能等。 Nagios可運行在Linux和UNIX平臺上。同時提供Web界面，以方便系統管理人員查看網絡狀態、各種系統問題、以及系統相關日志等 Nagios的功能側重于監控服務的可用性，能根據監控指標狀態觸發告警。目前Nagios也占領了一定的市場份額，不過Nagios并沒有與時俱進，已經不能滿足于多變的監控需求，架構的擴展性和使用的便捷性有待增強，其高級功能集成在商業版Nagios XI中。
Smokeping主要用于監視網絡性能，包括常規的ping、www服務器性能、DNS查詢性能、SSH性能等。底層也是用RRDtool做支持，特點是繪制圖非常漂亮，網絡丟包和延遲用顏色和陰影來標示，支持將多張圖疊放在一起，其作者還開發了MRTG和RRDtll等工具。
Smokeping的站點為：http://tobi.oetiker.cn/hp
開源監控系統OpenTSDB用Hbase存儲所有時序（無須采樣）的數據，來構建一個分布式、可伸縮的時間序列數據庫。它支持秒級數據采集，支持永久存儲，可以做容量規劃，并很容易地接入到現有的告警系統里。 OpenTSDB可以從大規模的集群（包括集群中的網絡設備、操作系統、應用程序）中獲取相應的采集指標，并進行存儲、索引和服務，從而使這些數據更容易讓人理解，如Web化、圖形化等。
- 王牌監控
Zabbix是一個分布式監控系統，支持多種采集方式和采集客戶端，有專用的Agent代理，也支持SNMP、IPMI、JMX、Telnet、SSH等多種協議，它將采集到的數據存放到數據庫，然后對其進行分析整理，達到條件觸發告警。其靈活的擴展性和豐富的功能是其他監控系統所不能比的。相對來說，它的總體功能做的非常優秀。
從以上各種監控系統的對比來看，Zabbix都是具有優勢的，其豐富的功能、可擴展的能力、二次開發的能力和簡單易用的特點，讀者只要稍加學習，即可構建自己的監控系統。
小米的監控系統：open-falcon。open-falcon的目標是做最開放、最好用的互聯網企業級監控產品。
OWL是TalkingData公司推出的一款開源分布式監控系統OWLgithub地址
- 三方監控
現在市場上有很多不錯的第三方監控，比如：監控寶、監控易、聽云、還有很多云廠商自帶監控，但是在這里我們不打算著重介紹，如果想了解三方監控可自行上官網咨詢。
Zabbix的功能和特性
- 安裝配置簡單。
- 可視化web管理界面
- 免費開源
- 支持中文
- 自動發現
- 分布式監控
- 實時繪圖
Zabbix架構及工作流程
zabbix架構 如圖所示：
Zabbix工作流程
1.數據采集: Zabbix通過SNMP、Agent、ICMP、SSH、IPMI等對系統進行數據采集
2.數據存儲: Zabbix存儲在MySQL上，也可以存儲在其他數據庫服務
3.數據分析: 當我們事后需要復盤分析故障時，zabbix能給我們提供圖形以及時間等相關信息，方面我們確定故障所在。
4.數據展示: web界面展示、(移動APP、java_php開發一個web界面也可以)
5.監控報警:電話報警、郵件報警、微信報警、短信報警、報警升級機制等（無論什么報警都可以）
6.報警處理:當接收到報警，我們需要根據故障的級別進行處理，比如:重要緊急、重要不緊急，等。根據故障的級別，配合相關的人員進行快速處理。
Zabbix的軟件組成
默認情況下zabbix包含5個程序：zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server，另外一個zabbix_java_gateway是可選，這個需要另外安裝。下面來分別介紹下他們各自的作用。
-
zabbix_agentd：客戶端守護進程，此進程收集客戶端數據，例如cpu負載、內存、硬盤使用情況等。 -
zabbix_get：zabbix工具，單獨使用的命令，通常在server或者proxy端執行獲取遠程客戶端信息的命令。通常用戶排錯。例如在server端獲取不到客戶端的內存數據，我們可以使用zabbix_get獲取客戶端的內容的方式來做故障排查。 -
zabbix_sender：zabbix工具，用于發送數據給server或者proxy，通常用于耗時比較長的檢查。很多檢查非常耗時間，導致zabbix超時。于是我們在腳本執行完畢之后，使用sender主動提交數據。 -
zabbix_server：zabbix服務端守護進程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的數據最終都是提交到server
備注：當然不是數據都是主動提交給zabbix_server,也有的是server主動去取數據。
-
zabbix_proxy：zabbix代理守護進程。功能類似server，唯一不同的是它只是一個中轉站，它需要把收集到的數據提交/被提交到server里。 -
zabbix_java_gateway：zabbix2.0之后引入的一個功能。顧名思義：Java網關，類似agentd，但是只用于Java方面。需要特別注意的是，它只能主動去獲取數據，而不能被動獲取數據。它的數據最終會給到server或者proxy。
Zabbix的邏輯關系圖
Zabbix監控環境中相關術語
1、主機（host）：要監控的網絡設備，可由IP或DNS名稱指定；
2、主機組（host group）：主機的邏輯容器，可以包含主機和模板，但同一個組織內的主機和模板不能互相鏈接；主機組通常在給用戶或用戶組指派監控權限時使用；
3、監控項（item）：一個特定監控指標的相關的數據；這些數據來自于被監控對象；item是zabbix進行數據收集的核心，相對某個監控對象，每個item都由”key”標識；
4、觸發器（trigger）：一個表達式，用于評估某監控對象的特定item內接收到的數據是否在合理范圍內，也就是閾值；接收的數據量大于閾值時，觸發器狀態將從”OK”轉變為”Problem”，當數據再次恢復到合理范圍，又轉變為”OK”；
5、事件（event）：觸發一個值得關注的事情，比如觸發器狀態轉變，新的agent或重新上線的agent的自動注冊等；
6、動作（action）：指對于特定事件事先定義的處理方法，如發送通知，何時執行操作；
7、報警升級（escalation）：發送警報或者執行遠程命令的自定義方案，如每隔5分鐘發送一次警報，共發送5次等；
8、媒介（media）：發送通知的手段或者通道，如Email、Jabber或者SMS等；
9、通知（notification）：通過選定的媒介向用戶發送的有關某事件的信息；
10、遠程命令（remote command）：預定義的命令，可在被監控主機處于某特定條件下時自動執行；
11、模板（template）：用于快速定義被監控主機的預設條目集合，通常包含了item、trigger、graph、screen、application以及low-level discovery rule；模板可以直接鏈接至某個主機；
12、應用（application）：一組item的集合；
13、web場景（web scennario）：用于檢測web站點可用性的一個活多個HTTP請求；
14、前端（frontend）：Zabbix的web接口；
Zabbix各邏輯組件關系圖
Zabbix的生產監控架構
常用的監控架構平臺
-
server-agentd模式
由zabbix server向zabbix agent發出指令獲取數據，即zabbix agent被動的去獲取數據并返回給zabbix server，zabbix server周期性的向agent 索取數據，這總模式的最大問題就是會加大zabbix server的工作量，在數百臺服務器的環境下zabbix server不能及時獲取到最新數據，但這也是默認的工作方式。這個是最簡單的架構了，常用于監控主機比較少的情況下。
server-proxy-agentd模式:
這個常用于比較多的機器，使用proxy進行分布式監控，有效的減輕server端的壓力。
