1.9 其他開源監控工具

除了市場上提供的很多SaaS商業工具如監控寶、監控易、聽云等，還有一些開源監控工具如 Zabbix、Open-Falcon等。

1.9.1 Zabbix

Zabbix是由Alexei Vladishev開源的分布式監控系統，支持多種采集方式和采集客戶端，同時支持SNMP、IPMI、JMX、Telnet、SSH等多種協議，它將采集到的數據存放到數據庫中，然后對其進行分析整理，如果符合告警規則，則觸發相應的告警。

Zabbix主要有以下幾個核心概念。

◎ 主機（Host）：是Zabbix監控的對象抽象，每個監控對象都有一個IP地址，這里的主機不僅限于物理服務器，可能是虛擬機容器或者某個網絡設備。

◎ 主機組（Host Group）：是一組主機的集合，主要用于多用戶之間的資源隔離，將主機組和用戶關聯，這樣 Zabbix 的不同用戶便只對自己管理的資源可見。

◎ 條目（Item）：是一個指標的相關監控數據，每個條目都有一個key去標識，以區分不同的指標。

◎ 應用（Application）：是一組條目的集合，一個條目可以屬于一個或多個應用。

◎ 模板（Template）：是 Zabbix里快速配置的利器，用于快速定義被監控主機的預設條目集合，通常包含條目、觸發器、視圖、應用及服務發現規則，通過將主機關聯模板來避免重復配置主機。

◎ 觸發器（Trigger）：是Zabbix的告警規則，用于評估某監控對象在某特定條目內接收到的數據是否匹配閾值，如果匹配，則觸發器狀態將從OK轉變為Problem，當數據量再次回到合理范圍時，觸發器狀態又將從 Problem 轉變為OK。

◎ 動作（Action）：是Zabbix在某個事件發生后執行的動作。事件主要指告警事件、網絡發現新主機加入事件、自動注冊（代理）事件和內部事件（監控項不支持）；行為主要包括發送郵件通知、執行遠程命令或者執行 Zabbix的附加動作。

Zabbix的組件圖如圖1-12所示。

如圖1-12所示，Zabbix由以下幾個組件構成。

1.Zabbix Server

Zabbix的核心組件，由C語言編寫而成，主要負責接收Agent發送的監控信息，并進行匯總存儲。Zabbix Server需要完成以下三個主要工作。

◎ 設備注冊。有兩種方式可以將監控對象注冊到設備中：一種是手動配置Agent地址，但如果需要將機房中的幾百臺機器一次性加入，則將是很大的工作量；另一種是采用自動發現機制，可以配置整個網段，Server會檢測整個網段的主機，并且可以自動配置模板、觸發器等一系列相關配置。

◎ 數據收集。這里既包括主動采集，也包括被動接收，采集到的數據首先會被放置在內存中，然后被批量保存在數據庫中。

◎ 定期的數據清理及告警觸發。通過配置的觸發器匹配采集數據，如果滿足條件，則發出告警。

2.Zabbix Database

用于存儲所有配置信息，以及由 Zabbix 收集的監控數據。后端數據庫支持MySQL、PostgreSQL、Oracle等，通常用到的是MySQL，并提供Zabbix Web頁面的數據查詢方式。由于采用了關系型數據庫存儲時序數據，所以Zabbix在監控大規模集群時常常在數據存儲方面捉襟見肘。

3.Zabbix Web

Zabbix的 GUI組件，由 PHP編寫而成，通常與 Server運行在同一臺主機上，提供監控數據的展現和系統配置，主要配置包括監控模板、告警等。

4.Proxy

可選組件，常用于分布式監控環境中，代理Server收集部分被監控端的監控數據并按照一定的頻率統一發往Server端。

Proxy有自己的數據庫，引入Proxy主要是為了解決以下兩個問題。

◎ Server和Agent之間網絡不連通，這種情況在跨網絡、跨機房的場景中經常出現。

◎ 在大規模部署時減輕Server的壓力，畢竟在同時連接這么多Agent時，Server需要維護更多的連接。以Proxy模式進行部署時，Agent配置的上游地址是Proxy，而Proxy配置的是Server。

5.Agent

部署在被監控主機上，負責收集本地數據并發往 Server 端或 Proxy 端，Agent會啟動一個名為 Agentd的守護進程。

Agent 分為兩種模式：主動和被動。主動是指 Agent 主動采集數據并將數據發送到Server/Proxy；被動是指Server每次都主動調用Agent獲取數據。Agent還能執行用戶的自定義腳本，從而完成一些原生 Agent不具備的功能。

這里補充講解 Zabbix 的一個工具，即 Zabbix_sender。Zabbix_sender 是一個命令行工具，可用于主動向Zabbix服務端發送監控數據，這樣可避免 Agent一直等待監控任務完成。有意思的是，Zabbix 本身由一個商業團隊維護，該團隊免費提供Zabbix軟件，但收取支持和維護費用。這和Red Hat的思路如出一轍，在系統軟件日趨成熟的未來，軟件的商業模式將逐步從出售許可證轉變為收取服務費用，這也是大勢所趨。

1.9.2 Nagios

Nagios原名為NetSaint，由Ethan Galstad開發并維護。Nagios是一個老牌監控工具，由C語言編寫而成，主要針對主機監控（CPU、內存、磁盤等）和網絡監控（SMTP、POP3、HTTP和NNTP等），當然也支持用戶自定義的監控腳本，如圖1-13所示。

Nagios的整體架構非常清晰，它通過Plugin采集各種監控數據，例如針對SNMP監控時，通過SNMP plugin和在監控對象上運行的snmpd通信獲取網絡信息；它還支持一種更加通用和安全的采集方式NRPE（Nagios Remote Plugin Executor），它首先在遠端啟動一個NRPE守護進程，用于在遠端主機上面運行檢測命令，在Nagios服務端用check nrep的plugin插件通過SSL對接到NRPE守護進程，執行相應的監控行為。相比SSH遠程執行命令的方式，這種方式更加安全。當然，Nagios也支持SSH的Plugin。

Nagios數據被保存在RDD（Round Robin Database，環形數據庫）中，RDD適用于存儲時序數據，支持以下4種監控數據。

◎ gauge：儀表盤數據。

◎ counter：計數器。

◎ absolute：不同時間段的變化率，為正數。

◎ driver：變化率，指當前值和前一個監控數值的比值，有正有負。

RDD的存儲原理比較簡單，它把整個數據存儲空間構建成圓環，指針指向最新的數據位置并且會隨著數據讀寫移動，如果此時沒有獲取監控數據，RDD就會使用默認的unknown填充，保證數據對齊。每個數據庫文件都以.rdd結尾，大小是固定的，如圖1-14所示。

1.9.3 Open-Falcon

Open-Falcon 是小米開源的企業級監控工具，由 Go 語言開發而成，包括小米、滴滴、美團等在內的互聯網公司都在使用它，是一款靈活、可擴展并且高性能的監控方案，整體架構如圖1-15所示。

下面對如圖1-15所示的組件進行簡單介紹。

◎ Falcon-agent：用Go語言開發的Daemon程序，運行在每臺Linux服務器上，用于采集主機上的各種指標數據，主要包括CPU、內存、磁盤、文件系統、內核參數、Socket連接等，目前已經支持200多項監控指標。并且，Agent支持用戶自定義的監控腳本，腳本必須返回 Agent 指定的數組格式。Agent采集的數據會通過RPC方式上報到Transfer。為了避免單個Transfer發生故障，Agent支持配置多個Transfer地址，還可以忽略多余的監控指標。Agent本身也可以成為一個 Proxy-gateway代理網關，接收第三方 HTTP請求并將其轉發到Transfer中。

◎ Hearthbeat server：簡稱 HBS（心跳服務），每個 Agent 都會周期性地通過RPC 方式將自己的狀態上報給 HBS，主要包括主機名、主機 IP、Agent 版本和插件版本，Agent 還會從 HBS 獲取自己需要執行的采集任務和自定義插件。

◎ Transfer：負責接收 Agent 發送的監控數據，并對數據進行整理，在過濾后通過一致性 Hash 算法將數據發送到 Judge 或者 Graph。為了支持存儲大量的歷史數據，Transfer 還支持 OpenTSDB。Transfer 本身沒有狀態，可以隨意擴展。

◎ Judge：告警模塊，Transfer轉發到Judge的數據會觸發用戶設定的告警規則，如果滿足，則會觸發郵件、微信或者回調接口。這里為了避免重復告警，引入了Redis暫存告警，從而完成告警合并和抑制。

◎ Graph:RRD數據上報、歸檔、存儲的組件。Graph在收到數據以后，會以RRDtool的數據歸檔方式存儲數據，同時提供RPC方式的監控查詢接口。

◎ API：主要提供查詢接口，不但可以從Graph里讀取監控數據，還可以對接MySQL，用于保存告警、用戶等信息。

◎ Dashboard：由 Python開發而成，提供 Open-Falcon的數據和告警展現，監控數據來自Graph,Dashboard允許用戶自定義監控面板。

◎ Aggregator：聚合組件，聚合某集群下所有機器的某個指標的值，提供一種集群視角的監控體驗。通過定時從Graph獲取數據，按照集群聚合產生新的監控數據并將監控數據發送到Transfer。