561
建設DevOps統一運維監控平台，全麵的係統監控你做好了嗎？
隨著Devops、雲計算、微服務、容器等理念的逐步落地和大力發展，機器越來越多，應用越來越多，服務越來越微，應用運行基礎環境越來多樣化，容器、虛擬機、物理機不一而足。麵對動輒幾百上千個虛擬機、容器，數十種要監控的對象，現有的監控係統還能否支撐的住？來自於容器、虛擬機、物理機、網絡設備、中間件的指標數據如何采用同一套方案快速、完整的收集和分析告警？怎樣的架構、技術方案才更適合如此龐大繁雜的監控需求呢
一、統一監控平台架構解析
先做一下回顧，統一監控平台由七大角色構成：監控源、數據采集、數據存儲、數據分析、數據展現、預警中心、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也許是個較好的方案。總之，適合自己的才是最好的。
最後更新：2017-06-22 17:32:43