- 幫助定位故障: 在發生故障時，我們可以通過檢視監控系統的各項名額資料，輔助故障分析和定位。
- 預警減少故障率: 對于即将可能産生的故障能夠及時發出預警資訊，做好提前預防處理。
- 輔助容量規劃: 為伺服器、中間件以及應用叢集的容量規劃提供資料支撐。
- 輔助性能調優: JVM垃圾回收次數、接口響應時間、慢SQL等等都可以監控優化。
常見的監控對象和名額都有哪些？
- 伺服器監控: CPU使用率、記憶體使用率、磁盤使用率、磁盤讀寫的吞吐量、網絡出入流量等等。
- MySQL監控: TPS、QPS、資料庫連接配接數、慢SQL、InnoDB緩沖池命中率等等。
- Redis監控: 記憶體使用率、緩存命中率、key值總數、Redis響應請求時間、用戶端連接配接數、持久性名額等等。
- MQ監控: 連接配接數、隊列數、生産速率、消費速率、消息堆積量等等。
- 應用監控:
- HTTP接口：URL存活、請求量、耗時、異常量
- JVM ：GC次數、GC耗時、各個記憶體區域的大小、目前線程數、死鎖線程數
- 線程池：活躍線程數、任務隊列大小、任務執行耗時、拒絕任務數
- 資料采集：采集的方式有很多種，包括日志埋點進行采集，JMX标準接口輸出監控名額，被監控對象提供REST API進行資料采集（如Hadoop、ES），系統指令行，統一的SDK進行侵入式的埋點和上報等。
- 資料傳輸：将采集的資料以TCP、UDP或者HTTP協定的形式上報給監控系統，有主動Push模式，也有被動Pull模式。
- 資料存儲：有使用MySQL、Oracle等關系資料庫存儲的，也有使用時序資料庫RRDTool、OpentTSDB、InfluxDB存儲的，還有使用HBase存儲的。
- 資料展示：資料名額的圖形化展示。
- 監控告警：靈活的告警設定，以及支援郵件、短信、IM等多種通知通道。
Zabbix介紹
Zabbix 1998年誕生，核心元件采用C語言開發，Web端采用PHP開發。它屬于老牌監控系統中的優秀代表，監控功能很全面，使用也很廣泛，差不多有70%左右的網際網路公司都曾使用過 Zabbix 作為監控解決方案。
Zabbix架構設計
- Zabbix Server：核心元件，C語言編寫，負責接收Agent、Proxy發送的監控資料。同時，它還負責資料的彙總存儲以及告警觸發等。
- Zabbix Proxy：可選元件，對于被監控機器較多的情況下，可使用Proxy進行分布式監控，它能代理Server收集部分監控資料，以減輕Server的壓力。
- Zabbix Agentd：部署在被監控主機上，用于采集本機的資料并發送給Proxy或者Server。資料收集方式同時支援主動Push和被動Pull 兩種模式。
- Database：用于存儲配置資訊以及采集到的資料，支援MySQL、Oracle等關系型資料庫。同時，最新版本的Zabbix已經開始支援時序資料庫，不過成熟度還不高。
- Web Server：Zabbix的GUI元件，PHP編寫，提供監控資料的展現和告警配置。
OPen-Falcon
Open-falcon 是小米2015年開源的企業級監控工具，采用Go和Python語言開發，這是一款靈活、高性能且易擴充的新一代監控方案，目前小米、美團、滴滴等超過200家公司在使用它。
小米初期也使用的Zabbix進行監控，但是機器量和業務量上來後，Zabbix就有些力不從心了。是以，後來自主研發了Open-Falcon，在架構設計上吸取了Zabbix的經驗，同時很好地解決了Zabbix的諸多痛點。
架構看去比Zabbix複雜多了，其實它也是基于Server---Agent的模式，隻不過Server又給他劃分了好幾個元件，這個耦合性和擴充性都得到了明顯提高。
- Falcon-agent：資料采集器和收集器，Go開發，部署在被監控的機器上。就相當于Agent，用于采集機器負載監控名額資料如：CPU、記憶體、磁盤、IO、網絡、端口等等大概有200多個這些都可以自定是否收集。
- Transfer：資料分發元件，接收用戶端發送的資料，分别發送給資料存儲元件Graph和告警判定元件Judge，Graph和Judge均采用一緻性hash做資料分片，以提高橫向擴充能力。同時Transfer還支援将資料分發到OpenTSDB，用于曆史歸檔。
- Graph：資料存儲元件，底層使用RRDTool（時序資料庫）做單個名額的存儲，并通過緩存、分批寫入磁盤等方式進行了優化。據說一個graph執行個體能夠處理8W+每秒的寫入速率。
- Judge和Alarm：告警元件，Judge對Transfer元件上報的資料進行實時計算，判斷是否要産生告警事件，Alarm元件對告警事件進行收斂處理後，将告警消息推送給各個消息通道。
- API：面向終端使用者，收到查詢請求後會去Graph中查詢名額資料，彙總結果後統一傳回給使用者，屏蔽了存儲叢集的分片細節
Open-Falcon優勢 - 自動采集能力：Falcon-agent 能自動采集伺服器的200多個基礎名額（比如CPU、記憶體等），無需在server上做任何配置，這一點可以秒殺Zabbix.
- 強大的存儲能力：底層采用RRDTool，并且通過一緻性hash進行資料分片，建構了一個分布式的時序資料存儲系統，可擴充性強。
- 靈活的資料模型：借鑒OpenTSDB，資料模型中引入了tag，這樣能支援多元度的聚合統計以及告警規則設定，大大提高了使用效率。
- 插件統一管理：Open-Falcon的插件機制實作了對使用者自定義腳本的統一化管理，可通過HeartBeat Server分發給agent，減輕了使用者自主維護腳本的成本。
- 個性化監控支援：基于Proxy-gateway，很容易通過自主埋點實作應用層的監控（比如監控接口的通路量和耗時）和其他個性化監控需求，內建友善。
Open-Falcon缺點 - 監控類型較少: 不支援常用應用伺服器如tomcat、apache、jetty等的監控。
- 整體發展一般，社群活躍度低: 沒有專門的運維支援，代碼更新較少，沒有一個較大的社群來維護，後續想要有什麼新的能力基本隻能指望自己擴充。
Prometheus（号稱下一代監控系統）
我們知道 zabbix 在監控界占有不可撼動的地位，功能強大。但是對容器監控顯得力不從心。為解決監控容器的問題，引入了 Prometheus 技術