本文轉自微訊號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！

前言

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

上篇文章《建設DevOps統一運維監控平臺，先從日誌監控說起》主要從日誌監控的方面進行了分享，本篇文章則是重點在系統監控層面進行分享。
目錄：
一、統一監控平臺架構解析
二、系統監控的技術棧
三、開源系統監控軟體 Zabbix VS Nagios VS Open-Falcon
四、基於k8s容器雲背景下的系統監控實踐：cAdvisor+Heapster+Influxdb
五、容器時代的監控利器： Prometheus

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

監控源：
從層次上來分，大致可以分為三層，業務應用層、中介軟體層、基礎設施層。業務應用層主要包括應用軟體、企業訊息匯流排等，中介軟體層包括資料庫、快取、配置中心、等各種系統軟體，基礎設施層主要有物理機、虛擬機器、容器、網路裝置、儲存裝置等等。
資料採集：
資料來源如此多樣，資料採集的任務自然輕鬆不了。資料採集從指標上劃分可以分為業務指標、應用指標、系統軟體監控指標、系統指標。應用監控指標如：可用性、異常、吞吐量、響應時間、當前等待筆數、資源佔用率、請求量、日誌大小、效能、佇列深度、執行緒數、服務呼叫次數、訪問量、服務可用性等，業務監控指標如大額流水、流水區域、流水明細、請求筆數、響應時間、響應筆數等，系統監控指標如：CPU負載、記憶體負載、磁碟負載、網路IO、磁碟IO、tcp連線數、程序數等。
從採集方式來說通常可以分為介面採集、客戶端agent採集、通過網路協議主動抓取（http、snmp等）
資料儲存：
採集到的資料一般都會儲存到檔案系統（如HDFS）、索引系統（如elasticsearch）、指標庫（如influxdb）、訊息佇列（如kafka，做訊息臨時儲存或者緩衝）、資料庫（如mysql）
資料分析：
針對採集到的資料，進行資料的處理。處理分兩類：實時處理和批處理。技術包括Map/Reduce計算、全日誌檢索、流式計算、指標計算等，重點是根據不同的場景需求選擇不同的計算方式。
資料展現：
將處理的結果進行圖表展現，在多屏時代，跨裝置的支援必不可少。
預警：
如果在資料處理過程發現了問題，則需要進行異常的分析、風險的預估以及事件的觸發或告警。
CMDB(企業軟硬體資產管理):
CMDB在統一監控平臺中是很重要的一環，監控源雖然種類繁多，但是他們大都有著關係，如應用執行在執行環境中，應用的正常執行又依賴網路和儲存裝置，一個應用也會依賴於其他的應用（業務依賴），一旦其中任何一個環節出了問題，都會導致應用的不可用。CMDB除了儲存軟硬體資產外，還要儲存這樣一份資產間的關聯關係，一個資產發生了故障，要能根據這個關係迅速得知哪些其他的資產會被影響，然後逐一解決問題。

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

二、系統監控的技術棧

系統監控的部分技術棧如下圖所示，監控技術眾多，這裡自然不可能列出所有的技術，選擇了部分比較經典、受歡迎的開源技術。

系統監控不同於日誌監控，有很多開源軟體把資料庫採集、資料儲存、資料展現、事件告警的任務都完成了，所以對於系統監控的技術棧中，將這些開源軟體暫且排除，待後面章節再進行講解。此處主要關注於如何自建一個統一系統監控平臺。
資料採集：
系統監控資料採集一般分為兩種方式：主動採集、客戶端採集。主動採集一般是通過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中的事件資料，進行解析並根據事件處理策略進行告警通知等處理。

三、開源系統監控軟體
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、POP3、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的整體對比如下：

四、基於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就可以採集到這些主機的效能資料了。

五、容器時代的監控利器： 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會越來越火熱。

六、總結

系統監控的方案有很多，甚至優秀的開源相容軟體也有很多，如果需求不高，也許zabbix就很合適，如果想要帶上容器監控，那麼Prometheus也許是個較好的方案。總之，適合自己的才是最好的。

關於作者
王海龍

現任普元資訊高階研發工程師，畢業於華東師範大學，曾參與和負責銀聯Paas雲平臺專案、興業銀行CAP4J專案、交通銀行信用卡中心統一監控平臺專案、神華災備雲平臺、萬達DevOps平臺等專案。

代表作品：
《建設DevOps統一運維監控平臺，先從日誌監控說起》

關於EAWorld
微服務，DevOps，元資料，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公眾號。

掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微訊號：EAWorld。

全新形態的PWorld2017盛大開啟，首四場定於7月1日在北京、上海、廣州、成都四城同步舉行。CSDN專項報名通道可獲得現場伴手禮個性T恤一件！