建設DevOps統一運維監控平臺，全面的系統監控 Zabbix VS Nagios VS Open-Falcon OR Prometheus

前言

隨着Devops、雲計算、微服務、容器等理念的逐步落地和大力發展，機器愈來愈多，應用愈來愈多，服務愈來愈微，應用運行基礎環境越來多樣化，容器、虛擬機、物理機不一而足。面對動輒幾百上千個虛擬機、容器，數十種要監控的對象，現有的監控系統還可否支撐的住？來自於容器、虛擬機、物理機、網絡設備、中間件的指標數據如何採用同一套方案快速、完整的收集和分析告警？怎樣的架構、技術方案才更適合如此龐大繁雜的監控需求呢？

上篇文章《建設DevOps統一運維監控平臺，先從日誌監控提及》主要從日誌監控的方面進行了分享，本篇文章則是重點在系統監控層面進行分享。

目錄：

1、統一監控平臺架構解析

2、系統監控的技術棧

3、開源系統監控軟件 Zabbix VS Nagios VS Open-Falcon

4、基於k8s容器雲背景下的系統監控實踐：cAdvisor+Heapster+Influxdb

5、容器時代的監控利器： Prometheus

1、統一監控平臺架構解析

先作一下回顧，統一監控平臺由七大角色構成：監控源、數據採集、數據存儲、數據分析、數據展示、預警中心、CMDB(企業軟硬件資產管理)。

• 監控源：

從層次上來分，大體能夠分爲三層，業務應用層、中間件層、基礎設施層。業務應用層主要包括應用軟件、企業消息總線等，中間件層包括數據庫、緩存、配置中心、等各類系統軟件，基礎設施層主要有物理機、虛擬機、容器、網絡設備、存儲設備等等。

• 數據採集：

數據源如此多樣，數據採集的任務天然輕鬆不了。數據採集從指標上劃分能夠分爲業務指標、應用指標、系統軟件監控指標、系統指標。應用監控指標如：可用性、異常、吞吐量、響應時間、當前等待筆數、資源佔用率、請求量、日誌大小、性能、隊列深度、線程數、服務調用次數、訪問量、服務可用性等，業務監控指標如大額流水、流水區域、流水明細、請求筆數、響應時間、響應筆數等，系統監控指標如：CPU負載、內存負載、磁盤負載、網絡IO、磁盤IO、tcp鏈接數、進程數等。

從採集方式來講一般能夠分爲接口採集、客戶端agent採集、經過網絡協議主動抓取（http、snmp等）

• 數據存儲：

採集到的數據通常都會存儲到文件系統（如HDFS）、索引系統（如elasticsearch）、指標庫（如influxdb）、消息隊列（如kafka，作消息臨時存儲或者緩衝）、數據庫（如mysql）

• 數據分析：

針對採集到的數據，進行數據的處理。處理分兩類：實時處理和批處理。技術包括Map/Reduce計算、全日誌檢索、流式計算、指標計算等，重點是根據不一樣的場景需求選擇不一樣的計算方式。

• 數據展示：

將處理的結果進行圖表展示，在多屏時代，跨設備的支持必不可少。

• 預警：

若是在數據處理過程發現了問題，則須要進行異常的分析、風險的預估以及事件的觸發或告警。

• CMDB(企業軟硬件資產管理):

CMDB在統一監控平臺中是很重要的一環，監控源雖然種類繁多，可是他們大都有着關係，如應用運行在運行環境中，應用的正常運行又依賴網絡和存儲設備，一個應用也會依賴於其餘的應用（業務依賴），一旦其中任何一個環節出了問題，都會致使應用的不可用。CMDB除了存儲軟硬件資產外，還要存儲這樣一份資產間的關聯關係，一個資產發生了故障，要能根據這個關係迅速得知哪些其餘的資產會被影響，而後逐一解決問題。

OK，回顧到此爲止，進入正題，系統監控。

2、系統監控的技術棧

系統監控的部分技術棧以下圖所示，監控技術衆多，這裏天然不可能列出全部的技術，選擇了部分比較經典、受歡迎的開源技術。

系統監控不一樣於日誌監控，有不少開源軟件把數據庫採集、數據存儲、數據展示、事件告警的任務都完成了，因此對於系統監控的技術棧中，將這些開源軟件暫且排除，待後面章節再進行講解。此處主要關注於如何自建一個統一系統監控平臺。

• 數據採集：

系統監控數據採集通常分爲兩種方式：主動採集、客戶端採集。主動採集通常是經過SNMP、SSH、Telnet、IPMI、JMX等手段進行遠程採集，客戶端採集則是須要在每個要監控的主機中部署一個客戶端進行數據採集併發送到遠程服務端進行接收。

• 數據緩衝：

和日誌監控同樣，在面臨海量監控時，考慮到網絡的壓力和數據處理的瓶頸，能夠在數據存儲前先通過一層數據緩衝，將採集到的數據先放置到消息隊列中，而後再從分佈式隊列中讀取數據並存儲。若是數據量不大的話，則能夠不考慮此層。

• 數據存儲：

對於系統監控數據，一般採用時序數據庫來存儲，時序數據庫全稱爲時間序列數據庫。時間序列數據庫主要用於指處理帶時間標籤（按照時間的順序變化，即時間序列化）的數據，帶時間標籤的數據也稱爲時間序列數據。如influxdb和opentsdb，是其中翹楚。

OpenTSDB是用hbase存儲全部的時序（無須採樣）來構建的一個分佈式、可伸縮的時間序列數據庫，能夠從大規模的集羣（包括集羣中的網絡設備、操做系統、應用程序）中獲取相應的metrics並進行存儲、索引以及服務，從而使得這些數據更容易讓人理解，如web化，圖形化等。用JAVA語言實現，對於JAVA系的同窗們是一個福音,不過其依賴hbase也許會讓一部分同窗望而卻步，畢竟還要先去維護hbase。

Influxdb是新興的一個時序數據庫，用go語言編寫，無需外部依賴，發展很快，最新版本已經到了1.2。提供類sql的查詢語法，安裝方便，單點便可使用，雖然有集羣的能力，不過該特性是非開源的（不過單點性能基本也都能知足企業需求了）。提供Http API，便於調用和封裝。對於想基於influxdb自行進行數據處理和展示的同窗們而言非常友好。

• 數據展示：

說到時序數據的圖形化展示，Grafana是一個不得不提的利器。Grafana是一個開源的時序數據的查詢和展示軟件，提供了靈活豐富的圖形化選項；能夠混合多種風格，有着功能齊全的度量儀表盤和圖形編輯器。支持與Graphite、Elasticsearch、CloudWatch、Prometheus、InfluxdbDB等衆多數據存儲對接，進行數據的查詢和圖表展示。一些開源的監控軟件如zabbix、Graphite、Prometheus也都有着本身的數據圖形化展示能力，可是通常也都是建議使用

Grafana來代替它們的頁面。可想而知Grafana的優秀。

固然，Grafana的數據源都是來自時序數據庫，在實際場景中，可能你想要查看的報表的一部分數據還來自於業務系統，這就是Grafana或者其餘的監控軟件作不到的了，去擴展是一種方式，另一種方式就是結合本身的需求實現圖表展示,經過對時序數據的計算分析以及結合業務數據，使用如echarts等開源圖表前端框架進行展示。這時候Influxdb的優點就體現出來了，對外提供http api很是適合自主封裝圖形化頁面。

• 告警：

在日誌監控的分享中，確實沒有對告警進行說明。像Zabbix、Nagios、Open-Falcon、Prometheus等開源監控軟件，都是有些本身的告警能力的。若是你採用了他們做爲監控平臺，實際上告警能力就已經有了。若是是純自建統一監控平臺的話，也能夠本身實現告警中心。咱們本身的作法是，在數據處理時，根據配置的事件觸發規則，生成相應事件扔到kafka中，事件處理引擎監聽kafka中的事件數據，進行解析並根據事件處理策略進行告警通知等處理。

3、開源系統監控軟件

Zabbix VS Nagios VS Open-Falcon

上面大體介紹了運維監控的技術棧，可是實際上已經有些開源監控軟件功能都很全面，從數據採集到數據展示都提供了支持，若是是小團隊，不想自建監控平臺的話，選擇這些開源軟件實際上是一個很好的選擇。

Zabbix

Zabbix是一個企業級的開源分佈式監控解決方案，支持實施從數以萬計的服務器、虛擬機、網絡設備等收集百萬的指標數據，具有常見的商業監控軟件所具有的功能（主機的性能監控、網絡設備性能監控、數據庫性能監控、FTP等通用協議監控、多種告警方式、詳細的報表圖表繪製）支持自動發現網絡設備和服務器；支持分佈式，能集中展現、管理分佈式的監控點；擴展性強，server提供通用接口，能夠本身開發完善各種監控。

Zabbix重要組件說明：

• zabbix server：負責接收agent發送的報告信息的核心組件，全部配置、統計數據及操做數據都由它組織進行；
• database storage：專用於存儲全部配置信息，以及由zabbix收集的數據；
• web interface：zabbix的GUI接口；
• proxy：可選組件，經常使用於監控節點不少的分佈式環境中，代理server收集部分數據轉發到server，能夠減輕server的壓力；
• agent：部署在被監控的主機上，負責收集主機本地數據如cpu、內存、數據庫等數據發往server端或proxy端；

優勢：

• All in One：部署至關便捷
• Server對宿主機性能要求很低。
• 自動發現服務器與網絡設備
• 分佈式監控，以及WEB集中管理功能
• 同時支持agent採集和無agent採集，主機經過agent 或者ipmi採集數據，網絡設備、存儲設備等經過 SNMP 客戶端採集數據，agent支持經常使用的UNIX和Windows操做系統
• 功能全面，數據採集、數據存儲、數據展示、事件告警。
• 開放式接口，擴展性強，插件編寫容易

不足：

• 數據庫瓶頸，使用mysql做爲底層存儲，大數據讀寫的時候，對於數據庫的壓力很是大
• 須要在主機中安裝agent
• 對容器監控支持很差，須要本身擴展。

Nagios

Nagios 全名爲（Nagios Ain’t Goona Insist on Saintood），最初項目名字是 NetSaint。它是一款免費的開源 IT 基礎設施監控系統，其功能強大，靈活性強，能有效監控 Windows 、Linux、VMware 和 Unix 主機狀態，交換機、路由器等網絡設置等。Nagios核心功能是監控報警，告警能力很不錯，可是圖形展現效果不好。同時nagios更加靈活，不少功能都要經過插件化來實現，對於技術能力沒那麼強的同窗，上手會有些困難。固然，對於運維老手，上手會很快。

Nagios 的功能特性以下：

• 監控網絡服務（SMTP、POP三、HTTP、NNTP、PING等）；
• 監控主機資源（處理器負荷、磁盤利用率等）；
• 簡單地插件設計使得用戶能夠方便地擴展本身服務的檢測方法；
• 並行服務檢查機制；
• 具有定義網絡分層結構的能力，用"parent"主機定義來表達網絡主機間的關係，這種關係可被用來發現和明晰主機宕機或不可達狀態；
• 當服務或主機問題產生與解決時將告警發送給聯繫人（經過EMail、短信、用戶定義方式）；
• 能夠定義一些處理程序，使之可以在服務或者主機發生故障時起到預防做用；
• 自動的日誌滾動功能；
• 能夠支持並實現對主機的冗餘監控；
• 可選的WEB界面用於查看當前的網絡狀態、通知和故障歷史、日誌文件等；

Open-Falcon

Open-Falcon是小米運維部門開源出來的互聯網企業級監控系統，目前包括小米、金山雲、美團、京東金融、趕集網等都在使用Open-Falcon。Open-Falcon 總體能夠分爲兩部分，即繪圖組件、告警組件。「繪圖組件」負責數據的採集、收集、存儲、歸檔、採樣、查詢、展現（Dashboard/Screen）等功能，能夠單獨工做，做爲time-series data的一種存儲展現方案。「告警組件」負責告警策略配置（portal）、告警斷定（judge）、告警處理（alarm/sender）、用戶組管理（uic）等，能夠單獨工做。架構以下：

關鍵特性有：

• 數據採集免配置：agent自發現、支持Plugin、主動推送模式
• 容量水平擴展：生產環境每秒50萬次數據收集、告警、存儲、繪圖，可持續水平擴展。
• 告警策略自發現：Web界面、支持策略模板、模板繼承和覆蓋、多種告警方式、支持回調動做。
• 告警設置人性化：支持最大告警次數、告警級別設置、告警恢復通知、告警暫停、不一樣時段不一樣閾值、支持維護週期，支持告警合併。
• 歷史數據高效查詢：秒級返回上百個指標一年的歷史數據。
• Dashboard人性化：多維度的數據展現，用戶自定義Dashboard等功能。
• 架構設計高可用：整個系統無核心單點，易運維，易部署。

缺點：

• 支持的監控類型較少，不支持經常使用應用服務器如tomcat、apache、jetty等的監控。
• 沒有專門的運維支持，代碼更新較少，沒有一個較大的社區來維護，後續想要有什麼新的能力基本只能期望本身擴展。

Zabbix、Nagios、Open-Falcon的總體對好比下：

4、基於k8s容器雲背景下的系統監控實踐：

cAdvisor+Heapster+Influxdb

上面介紹的都是比較傳統的系統監控架構，在容器時代到來後，對於容器的支持就顯得差強人意了。下面介紹下咱們基於k8s容器雲背景下的系統監控方案，首先仍是介紹下咱們的DevOps平臺架構，平臺運行在由kubernetes+docker構建的容器雲中，kubernetes、docker等服務運行在IaaS平臺上（咱們的生產環境是阿里雲）。

咱們的統一監控平臺，在系統監控上，採用了cAdvisor+Heapster+Influxdb的方案。架構以下：

爲何採用這種方案呢？先來了解下這三個工具。

cAdvisor 是谷歌公司用來分析運行中的Docker容器的資源佔用以及性能特性的工具, cAdvisor部署爲一個運行中的daemon，它會收集、彙集、處理並導出運行中容器的信息。這些信息可以包含容器級別的資源隔離參數、資源的歷史使用情況、反映資源使用和網絡統計數據完整歷史情況。對docker的監控能力很是強大。同時還提供了本身的web頁面，用戶能夠經過web頁面直接查看該宿主機上全部容器的監控數據。cAdvior功能已經被集成到了kubelet組件中，也就是說，安裝好kubernetes後，cAdvisor就已經安裝到了每個計算節點上。在每個計算節點上均可以經過IP+端口（默認爲4194）訪問cAdvisor的頁面了。

Heapster一樣是Google提供的，用於對k8s集羣的監控。Heapster能夠經過容器啓動，傳入kubernetes master的地址，heapster會經過調用kubernetes api獲取全部kubernetes計算節點，而後經過kubelet的外部調用端口號（默認爲10250）調用kubelet的http api，kubelet會進行調用cAdvisor接口獲取當前計算節點上的容器數據以及當前主機的性能數據，返回給heapter。這樣heapster就收集到了kubernetes集羣的全部容器數據以及主機數據。Heapster支持數據傳輸到Influxdb中進行存儲。數據展示咱們就是本身調用influxdb的api獲取數據，結合咱們的業務相關數據進行計算，用echarts進行前端圖表展示。

可能有的同窗會問，這樣只是監控到了全部計算節點的容器數據和主機性能數據，這樣有些非計算節點的主機監控該怎麼辦？確實，由於Heapster只是針對於kubernetes集羣去監控，非kubelet節點確實是拿不到數據的，而咱們又不想再用另一種方式去單獨監控主機，那樣獲得的數據格式也不同。因而咱們採起了折中的辦法，在每一個非k8s集羣節點上，也安裝kubelet，而且加入到kubernetes集羣中，可是配置成不參與集羣調度，也就是容器不會被部署到這些機器上。這樣，heapster就能夠採集到這些主機的性能數據了。

5、容器時代的監控利器： Prometheus

除了咱們實踐的cAdvisor+Heapster+Influxdb方案能夠作到容器和主機性能數據同時監控外，其實還有一個相對而言更好的方案，那就是Prometheus。Prometheus是一套開源的監控&報警&時間序列數據庫的組合，由社交音樂平臺SoundCloud在2012年開發。隨着發展，愈來愈多公司和組織接受採用Prometheus，社區也十分活躍，他們便將其獨立成開源項目，而且不依賴於任何公司。Prometheus最初是參照google內部監控系統BorgMon開發的，如今最多見的Kubernetes容器管理系統中，一般會搭配Prometheus進行監控。

2016年Prometheus正式成爲Cloud Native Computing Foundation的孵化項目，該基金會是在Google的支持下由一羣IT行業巨頭建立並指導Kubernetes容器管理系統的開發。在CNCF的主導下，Prometheus成爲該開放平臺棧的第二個正式的組件。特性以下：

• 高維度數據模型
• 高效的時序數據存儲能力
• 查詢語言靈活
• 具體時序數據圖形化展示的能力
• 易於運維
• 提供豐富的客戶端開發庫
• 告警中心功能全面

Prometheus的架構圖以下：

• Prometheus Server : Prometheus主服務器，用來收集和存儲時間序列數據
• client libraries : 客戶端庫
• push gateway : 短時jobs的中介網關
• GUI-based dashboard builder : 基於Rails/SQL的GUI dashboard
• Exporters ： 數據採集探針，支持包括數據庫、主機、消息隊列、存儲、應用服務器、github等軟件、其餘監控系統等多種類的探針。
• Alertmanager ：告警中心

Prometheus 是google力捧的監控方案，社區很是活躍，發展非常迅速，功能在不斷的飛速補充和完善。一個監控範圍覆蓋容器、主機、存儲、數據庫、各類中間件，同時還具體完善的時序數據存儲、告警中心等能力，發展又很迅速，相信Prometheus會愈來愈火熱。

6、總結

系統監控的方案有不少，甚至優秀的開源兼容軟件也有不少，若是需求不高，也許zabbix就很合適，若是想要帶上容器監控，那麼Prometheus也許是個較好的方案。總之，適合本身的纔是最好的。

 

關於做者

王海龍