PAAS云平臺監控實現與探討

張鳳麗

天津工業職業學院 天津 300400

1 Prometheus介紹

1.1 簡介

Prometheus是一種應用十分廣泛的性能監控平臺，是一個開源的記錄和處理數字時間序列的監控平臺，由Matt T.Proud和Julius Volz最初合作開發，開始開發的大部分費用由SoundCloud贊助，使用Go語言編寫，現在是一個獨立的開源項目，獨立于任何公司維護，并于2016年加入云原生基金會，成為繼Kubernetes之后的第二個托管項目。其工作基本原理是通過HTTP協議周期性的抓取被監控組件的狀態，任何組件只要提供HTTP接口就可以接入監控系統而不需要任何SDK[1]。

1.2 工作流程、架構

Prometheus的工作流程如下。

Prometheus Server負責對監控數據的獲取、存儲、查詢與監測Job的調度，以既定的輪詢頻率抓取監控目標數據并實現數據持久化到時序數據庫。與其他依靠代理或嵌入式設備收集數據并“推送”指標到監控后臺思路不同，Prometheus Exporter負責將監控數據采集的端點(Endpoint)通過HTTP服務暴露，之后Prometheus Server通過訪問該端點獲取需要采集的監控數據。如果目標網絡不可達，可以通過PushGateway間接實現目標指標項抓取。另外Prometheus提供客戶端庫，選擇適合的語言，可以方便地在應用程序上為需要監控的服務生成相應的metric并暴露給Prometheus server，當Prometheus server來pull時，直接返回實時狀態的metric。Prometheus Alertmanager報警組件用于處理收到的警報以及Grafana數據展示組件用于可視化展示收集的數據。

Prometheus整體架構如圖1所示。

圖1 Prometheus架構圖

1.3 特點

Prometheus的主要特點如下：

(1)提供多維數據模型，時間序列由metric名稱和k/v的labels組成。

(2)提供一個靈活的查詢語句PromQL，可以利用多維數據完成復雜查詢。

(3)不依賴于分布式存儲的獨立的Prometheus服務器。

(4)基于HTTP的pull模式收集時間序列數據，同時采用PushGateway組件收集數據。

(5)通過服務發現或者靜態配置去獲取監控對象，自動完成數據采集。

(7)支持作為數據源接入Grafana，有多種可視化圖形界面，易于伸縮[2-3]。

2 Prometheus與其他監控工具的比較

隨著云計算平臺的快速發展，云平臺服務因具有虛擬性、通用性、部署便捷、個性化服務和廉價性等優點被廣泛應用到生產和生活的各個方面，然而面對不管是大量的硬件設備或者是海量的軟件應用服務，如何對整個資源進行有效監控就顯得尤為重要了。越來越多的公司順勢推出了自己相應的監控工具，如Zabbix、Caati、InfluxDB、OpenTSDB、Nagios、Prometheus等。其中Zabbix是一個企業級、開源分布式的監控工具，主要用于物理主機，交換機和網絡監控等，支持agent、snmp、JMX、telnet等多種數據采集方式并擁有豐富的插件，具有高可用性，支持多種告警方式，如基于郵件、短信和微信等，支持圖形化展示，但是存在性能瓶頸，存在單機的上線并且采用的是C和PHP語言，運行速度會比Prometheus稍慢一些[4]。Cacti是基于PHP語言開發的網絡流量監測工具，但缺點比較明顯如圖像效果不佳、不支持分布式等。InfluxDB是一個開源的時序數據庫，主要用于存儲數據，如果想搭建監控報警系統，則需要依賴于其他的系統，如數據采集器、報警模塊等。OpenTSDB是基于Hadoop和HBase的分布式時間序列數據庫，如果對時間序列數據有長期的存儲需要，并且對Hadoop十分熟悉則可以選用。Nagios是比較適合小集群或者靜態系統的監控，是一個輕量化的監控系統，相對于目前的監控系統工具來說比較古老，很多性能都沒有，不方便擴展，需要增加很多插件[5]。

本文中所要探討的Prometheuss屬于一站式監控報警平臺；具有靈活的數據模型，同時支持在數據采集階段對監控數據的標簽進行修改；提供了十分靈活的豐富的查詢語句，能夠支持多維數據的復雜查詢；支持對云或者容器的監控；具有豐富的組件支持；成熟的社區和豐富的參考文檔，以便于快速搭建監控系統，是目前應用最多的云平臺的監控工具[6]。

3 基于Prometheus的Paas云平臺監控的探討

3.1 Exporter分類合并

Prometheus官網提供很多Exporter鏈接，用來實現不同產品指標數據抽取，有些標注為官方維護如MySQL server exporter，Node/system metrics exporter等，有些由Prometheus社區開發，還有一些第三提供，供大家參考或使用。但開源Exporter的指標數量通常遠遠多于具體項目監控指標需求，無需周期獲取這些相應指標數據。如果依然周期獲取不使用指標，不僅增加Exporter接口響應時間，也會給Prometheus及對應后端時序存儲帶來一定的壓力。抑或Exporter依然全量抽取，通過Prometheus配置實現指標過濾，都會增添額外的計算負擔。因此，考慮Exporter基于全量指標基礎上，提供指標分類，指標簡單分為2類Enabled和Disabled，決定是否參與數據抽取，做到依據項目需求，指標頁面可配置，每次請求時進行指標分類處理，并加載Enabled指標，進行抽取。

Prometheus通過Pull方式周期的從目標端(Exporter)抽取數據。該種松耦合的架構方式，只要Exporter在運行，可以在任何地方，查看監控目標實例的健康狀態，并且可以快速定位故障。在PAAS平臺中，通常需要將Exporter部署到監控目標虛擬機內，對目標入侵性較高，同時監控不同種類指標可能需要不同Exporter，導致目標端內需要維護多個Exporter，使目標端Agent泛濫，帶來更多的資源消耗，維護起來更棘手。后續如果發現BUG或是版本升級，需要依次升級所有Exporter，風險很高。如果將Exporter從目標端移出，作為Kubernates集群獨立服務部署，可以避免上述談到的諸多問題。Exporter作為獨立服務部署，不同的Exporter既可以分開獨立部署或按類別合并相近的Exporter如將數據庫相關的Exporter合并，形成新的DB-Exporter，對外提供指標抽取服務。實際開發工程項目中，將Prometheus官網數據庫Redis Exporter，MySQL Server Exporter(official)，MongoDB Exporter的開源代碼進行修改合并，并成功實現數據庫引擎指標抽取工作，整體結構如圖2所示。Exporter Db提供數據庫引擎指標抓取，Exporter vm實現類似Node exporter指標數據抓取。數據渲染部分并沒有采用官方的Grafana作為解決方案，而是通過elm組件進行個性化實現。UI效果呈現，如圖2所示。

圖2

圖3

3.2 目標發現機制的探討

Prometheus目標發現機制，在實際項目中的應用。Prometheus提供兩種目標發現機制。基于文件的目標發現，可以結合共享存儲或是Etcd組件，如kubernates提供掛載共享存儲卷，Prometheus服務只需部署一份，可以充分利用kubernates服務高可用機制，在不同Node間秒級拉起新的Prometheus提供服務，監控目標集合始終沒有變化。抑或通過Etcd保證Prometheus多個Node節點目標配置文件一致性，Prometheus服務仍然部署一份。假設由于監控實例目標數量增長，需要多個Prometheus服務分擔監控目標，且避免同一個目標被重復拉取，就要分Node下發不同監控目標文件，也就失去Kubernates高可用的意義。基于Consule服務發現機制，發現的是服務，依然無法監控不同產品實例目標如數據庫，中間件實例等。但可模擬Consule服務接口/agent/self、/catalog/services、/health/service/：id來實現程序掃描數據庫中監控目標的記錄，從而實現表中記錄的變化，及時被Prometheus服務感知。該種方案，亦可以通過計算表中監控目標記錄數，動態增加Prometheus服務Replica數量，分擔Prometheus服務壓力，整體結構如圖4所示。

圖4

結語

依據探討點進行的設計具有可行性及用戶友好型，不僅可以實現指標項靈活修改、減少exporter數量依賴，升級便捷，最重要的通過模擬Consule后，可以動態擴展Prometheus Repica數量，分擔負載。