为什么说Prometheus是足以取代Zabbix的监控神器?
點擊上方“朱小廝的博客”,選擇“設為星標”
回復”666“獲取公眾號專屬資料
一、簡介
Kubernetes自從2012年開源以來便以不可阻擋之勢成為容器領域調度和編排的領頭羊,Kubernetes是Google Borg系統的開源實現,于此對應Prometheus則是Google BorgMon的開源實現。Prometheus是由SoundCloud開發的開源監控報警系統和時序列數據庫。從字面上理解,Prometheus由兩個部分組成,一個是監控報警系統,另一個是自帶的時序數據庫(TSDB)。
2016年,由Google發起的Linux基金會旗下的原生云基金會(Cloud Native Computing Foundation)將Prometheus納入其第二大開源項目。Prometheus在開源社區也十分活躍,在GitHub上擁有兩萬多Star,并且系統每隔一兩周就會有一個小版本的更新。
二、各種監控工具對比
其實,在Prometheus之前市面已經出現了很多的監控系統,如Zabbix、Open-Falcon、Nagios等。那么Prometheus和這些監控系統有啥異同呢?我們先簡單回顧一下這些監控系統。
1、ZabbixZabbix是由Alexei Vladishev開源的分布式監控系統,支持多種采集方式和采集客戶端,同時支持SNMP、IPMI、JMX、Telnet、SSH等多種協議,它將采集到的數據存放到數據庫中,然后對其進行分析整理,如果符合告警規則,則觸發相應的告警。
Zabbix核心組件主要是Agent和Server,其中Agent主要負責采集數據并通過主動或者被動的方式采集數據發送到Server/Proxy,除此之外,為了擴展監控項,Agent還支持執行自定義腳本。Server主要負責接收Agent發送的監控信息,并進行匯總存儲,觸發告警等。
Zabbix Server將收集的監控數據存儲到Zabbix ?Database中。Zabbix ? Database支持常用的關系型數據庫,如果MySQL、PostgreSQL、Oracle等,默認是MySQL,并提供Zabbix Web頁面(PHP編寫)數據查詢。
Zabbix由于使用了關系型數據存儲時序數據,所以在監控大規模集群時常常在數據存儲方面捉襟見肘。所以從Zabbix 4.2版本后開始支持TimescaleDB時序數據庫,不過目前成熟度還不高。
2、Open-FalconOpen-Falcon是小米開源的企業級監控工具,用Go語言開發而成,包括小米、滴滴、美團等在內的互聯網公司都在使用它,是一款靈活、可擴展并且高性能的監控方案,主要組件包括了:
1)Falcon-agent是用Go語言開發的Daemon程序,運行在每臺Linux服務器上,用于采集主機上的各種指標數據,主要包括CPU、內存、磁盤、文件系統、內核參數、Socket連接等,目前已經支持200多項監控指標。并且,Agent支持用戶自定義的監控腳本。
2)Hearthbeat server簡稱HBS心跳服務,每個Agent都會周期性地通過RPC方式將自己的狀態上報給HBS,主要包括主機名、主機IP、Agent版本和插件版本,Agent還會從HBS獲取自己需要執行的采集任務和自定義插件。
3)Transfer負責接收Agent發送的監控數據,并對數據進行整理,在過濾后通過一致性Hash算法發送到Judge或者Graph。
4)Graph是基于RRD的數據上報、歸檔、存儲組件。Graph在收到數據以后,會以rrdtool的數據歸檔方式來存儲,同時提供RPC方式的監控查詢接口。
5)Judge告警模塊,Transfer轉發到Judge的數據會觸發用戶設定的告警規則,如果滿足,則會觸發郵件、微信或者回調接口。這里為了避免重復告警引入了Redis暫存告警,從而完成告警的合并和抑制。
6)Dashboard是面向用戶的監控數據查詢和告警配置界面。
3、NagiosNagios原名為NetSaint,由Ethan Galstad開發并維護。Nagios是一個老牌監控工具,由C語言編寫而成,主要針對主機監控(CPU、內存、磁盤等)和網絡監控(SMTP、POP3、HTTP和NNTP等),當然也支持用戶自定義的監控腳本。
它還支持一種更加通用和安全的采集方式NREP(Nagios Remote Plugin Executor),它首先在遠端啟動一個NREP守護進程,用于在遠端主機上面運行檢測命令,在Nagios服務端用check nrep的plugin插件通過SSL對接到NREP守護進程執行相應的監控行為。相比SSH遠程執行命令的方式,這種方式更加安全。
4、PrometheusPrometheus是由SoundCloud開發的開源監控報警系統和時序列數據庫。Prometheus的基本原理是通過HTTP周期性抓取被監控組件的狀態,任意組件只要提供對應的HTTP接口并且符合Prometheus定義的數據格式,就可以接入Prometheus監控。
Prometheus Server負責定時在目標上抓取metrics(指標)數據并保存到本地存儲里面。Prometheus采用了一種Pull(拉)的方式獲取數據,不僅降低客戶端的復雜度,客戶端只需要采集數據,無需了解服務端情況,而且服務端可以更加方便的水平擴展。
如果監控數據達到告警閾值Prometheus Server會通過HTTP將告警發送到告警模塊alertmanger,通過告警的抑制后觸發郵件或者webhook。Prometheus支持PromQL提供多維度數據模型和靈活的查詢,通過監控指標關聯多個tag的方式,將監控數據進行任意維度的組合以及聚合。
5、綜合對比1)綜合對比如上面的表格,從開發語言上看,為了應對高并發和快速迭代的需求,監控系統的開發語言已經慢慢從C語言轉移到Go。不得不說,Go憑借簡潔的語法和優雅的并發,在Java占據業務開發,C占領底層開發的情況下,準確定位中間件開發需求,在當前開源中間件產品中被廣泛應用。
2)從系統成熟度上看,Zabbix和Nagios都是老牌的監控系統:Nagios是在1999年出現的,Zabbix是在1998年出現的,系統功能比較穩定,成熟度較高。而Prometheus和Open-Falcon都是最近幾年才誕生的,雖然功能還在不斷迭代更新,但站在巨人的肩膀之上,在架構設計上借鑒了很多老牌監控系統的經驗;
3)從系統擴展性方面看,Zabbix和Open-Falcon都可以自定義各種監控腳本,并且Zabbix不僅可以做到主動推送,還可以做到被動拉取,Prometheus則定義了一套監控數據規范,并通過各種exporter擴展系統采集能力。
4)從數據存儲方面來看,Zabbix采用關系數據庫保存,這極大限制了Zabbix采集的性能,Nagios和Open-Falcon都采用RDD數據存儲,Open-Falcon還加入了一致性hash算法分片數據,并且可以對接到OpenTSDB,而Prometheus自研一套高性能的時序數據庫,在V3版本可以達到每秒千萬級別的數據存儲,通過對接第三方時序數據庫擴展歷史數據的存儲;
5)從配置復雜度上看,Prometheus只有一個核心server組件,一條命令便可以啟動,相比而言,其他系統配置相對麻煩,尤其是Open-Falcon。
6)從社區活躍度上看,目前Zabbix和Nagios的社區活躍度比較低,尤其是Nagios,Open-Falcon雖然也比較活躍,但基本都是國內的公司參與,Prometheus在這方面占據絕對優勢,社區活躍度最高,并且受到CNCF的支持,后期的發展值得期待;
7)從容器支持角度看,由于Zabbix和Nagios出現得比較早,當時容器還沒有誕生,自然對容器的支持也比較差。Open-Falcon雖然提供了容器的監控,但支持力度有限。Prometheus的動態發現機制,不僅可以支持swarm原生集群,還支持Kubernetes容器集群的監控,是目前容器監控最好解決方案。Zabbix在傳統監控系統中,尤其是在服務器相關監控方面,占據絕對優勢。而Nagios則在網絡監控方面有廣泛應用,伴隨著容器的發展,Prometheus開始成為主導及容器監控方面的標配,并且在未來可見的時間內被廣泛應用。
總體來說,對比各種監控系統的優劣,Prometheus可以說是目前監控領域最鋒利的“瑞士軍刀”了。
三、Prometheus功能介紹
下圖是Prometheus整體架構圖。左側是各種數據源主要是各種符合Prometheus數據格式的exporter,除此之外為了支持推送數據的Agent,可以通過Pushgateway組件,將Push轉化為Pull。Prometheus甚至可以從其它的Prometheus獲取數據,后面介紹聯邦的時候詳細介紹。
圖片的上側是服務發現,Prometheus支持監控對象的自動發現機制,從而可以動態獲取監控對象,雖然Zabbix和Open-Falcon也支持動態發現機制,但Prometheus支持最完善。
圖片中間是核心,通過Retrieval模塊定時拉取數據,通過Storage模塊保存數據。PromQL是Prometheus提供的查詢語法,PromQL通過解析語法樹,查詢Storage模塊獲取監控數據。圖片右側是告警和頁面展現,頁面查看除了Prometheus自帶的webui,還可以通過grafana等組件查詢Prometheus監控數據。
Prometheus指標格式分為兩個部分:一是指標名稱,另一個是指標標簽。格式如下:
<metric name>{<label name>=<label value>, ...}
標簽可體現指標的維度特征,例如,對于指標http_request_total,可以有{status="200", method="POST"}和{status="200", method="GET"}這兩個標簽。在需要分別獲取GET和POST返回200的請求時,可分別使用上述兩種指標;在需要獲取所有返回200的請求時,可以通過http_request_total{status="200"}完成數據的聚合,非常便捷和通用。
Prometheus指標類型有四種:
1)Counter(計數器):計數統計,累計多長或者累計多少次等。它的特點是只增不減,譬如HTTP訪問總量;
2)Gauge(儀表盤):數據是一個瞬時值,如果當前內存用量,它隨著時間變化忽高忽低。
如果需要了解某個時間段內請求的響應時間,通常做法是使用平均響應時間,但這樣做無法體現數據的長尾效應。例如,一個HTTP服務器的正常響應時間是30ms,但有很少幾次請求耗時3s,通過平均響應時間很難甄別長尾效應,所以Prometheus引入了Histogram和Summary。
3)Histogram(直方圖):服務端分位,不同區間內樣本的個數,譬如班級成績,低于60分的9個,低于70分的10個,低于80分的50個。
4)Summary(摘要):客戶端分位,直接在客戶端通過分位情況,還是用班級成績舉例:0.8分位的是,80分,0.9分為85分,0.99分為的是98分。
Prometheus通過HTTP接口的方式從各種客戶端獲取數據,這些客戶端必須符合Prometheus監控數據格式,通常由兩種方式,一直是侵入式埋點監控,通過在客戶端集成如果Kubernetes API直接通過引入Prometheus go client,提供/metrics接口查詢kubernetes API各種指標。
另一種是通過exporter方式,在外部將原來各種中間件的監控支持轉化為Prometheus的監控數據格式,如redis exporter將reids指標轉化為Prometheus能夠識別的HTTP請求。
Prometheus并沒有采用json的數據格式,而是采用 text/plain 純文本的方式 ,這是它的特殊之處。
HTTP返回Header和Body如上圖所示,指標前面兩行#是注釋,標識指標的含義和類型。指標和指標的值通過空格分割,開發者通常不需要自己拼接這種個數的數據, Prometheus提供了各種語言的SDK支持。
Prometheus為了支持各種中間件以及第三方的監控提供了exporter,大家可以把它理解成監控適配器,將不同指標類型和格式的數據統一轉化為Prometheus能夠識別的指標類型。
譬如Node exporter主要通過讀取linux的/proc以及/sys目錄下的系統文件獲取操作系統運行狀態,reids exporter通過reids命令行獲取指標,mysql exporter通過讀取數據庫監控表獲取mysql的性能數據。他們將這些異構的數據轉化為標準的Prometheus格式,并提供HTTP查詢接口。
Prometheus提供了兩種數據持久化方式:一種是本地存儲,通過Prometheus自帶的tsdb(時序數據庫),將數據保存到本地磁盤,為了性能考慮,建議使用SSD。但本地存儲的容量畢竟有限,建議不要保存超過一個月的數據。Prometheus本地存儲經過多年改進,自Prometheus 2.0后提供的V3版本tsdb性能已經非常高,可以支持單機每秒1000w個指標的收集。
另一種是遠端存儲,適用于大量歷史監控數據的存儲和查詢。通過中間層的適配器的轉化,Prometheus將數據保存到遠端存儲。適配器實現Prometheus存儲的remote write和remote read接口并把數據轉化為遠端存儲支持的數據格式。目前,遠端存儲主要包括OpenTSDB、InfluxDB、Elasticsearch、M3db、Kafka等,其中M3db是目前非常受歡迎的后端存儲。
和關系型數據庫的SQL類似,Prometheus也內置了數據查詢語言PromQL,它提供對時間序列數據豐富的查詢,聚合以及邏輯運算的能力。一條PromQL主要包括了指標名稱、過濾器以及函數和參數。指標可以進行數據運算,包括+ (加法)、- (減法)、* (乘法)、/ (除法)、% (求余)、^ (冪運算),聚合函數包括了:sum (求和)、min (最小值)、max (最大值)、avg (平均值)、stddev (標準差)、count (計數)、topk (前n條)、quantile (分布統計)等。查詢數據通過HTTP GET請求發送PromQL查詢語句。形式如:
curl 'http://Prometheus:9090/api/v1/query?query=up&time=2015-07-01T20:10:51.781Z'
其中query參數就是一條PromQL表達式。除此之外還支持范圍查詢query_range,需要額外添加start(起始時間)、end(結束時間)、step(查詢步長)這三個參數。無論是Prometheus自帶的webui還可以通過grafana,他們本質上都是通過HTTP發送PromQL的方式查詢Prometheus數據。整個解析流程如下所示:
當Prometheus接收請求后,通過PromQL引擎解析PromQL,確定查詢時間序列和查詢時間范圍,通過tsdb接口獲取對應數據塊,最后根據聚合函數處理監控數據并返回。
Prometheus告警配置也是通過yaml文件配置,核心是上面的expr參數(告警規則)和查詢一樣也是一個PromQL表達式。for代表持續時間,如果在for時間內持續觸發,Prometheus才發出告警至alertmanger。
告警組件alertmanger地址是在Prometheus的配置文件中指定,告警經過alertmanger去重、抑制等操作,最后執行告警動作,目前支持郵件、slack、微信和webhook,如果是對接釘釘,便可以通過webhook方式觸發釘釘的客戶端發送告警。
Prometheus配置監控對象有兩種方式,一種是通過靜態文件配置,另一種是動態發現機制,自動注冊監控對象。
Prometheus動態發現目前已經支持Kubernetes、etcd、Consul等多種服務發現機制,動態發現機制可以減少運維人員手動配置,在容器運行環境中尤為重要,容器集群通常在幾千甚至幾萬的規模,如果每個容器都需要單獨配置監控項不僅需要大量工作量,而且容器經常變動,后續維護更是異常麻煩。針對Kubernetes環境的動態發現,Prometheus通過watch kubernetes api動態獲取當前集群所有服務和容器情況,從而動態調整監控對象。
為了擴展單個Prometheus的采集能力和存儲能力,Prometheus引入了“聯邦”的概念。
多個Prometheus節點組成兩層聯邦結構,如圖所示,上面一層是聯邦節點,負責定時從下面的Prometheus節點獲取數據并匯總,部署多個聯邦節點是為了實現高可用。下層的Prometheus節點又分別負責不同區域的數據采集,在多機房的事件部署中,下層的每個Prometheus節點可以被部署到單獨的一個機房,充當代理。
四、Prometheus落地實踐
首先先簡單介紹一下宜信容器這個產品,它是宜信內部基于Kubernetes搭建的容器管理平臺,用戶可以通過平臺一鍵部署自己的服務。平臺主要功能包括了服務管理(灰度發布、自動伸縮、多集群部署等)、鏡像管理、監控告警、CICD、Nginx管理、Ceph存儲等多個功能。
其中監控和告警和自動伸縮都是基于Prometheus構建。
Prometheus采集的數據包括了主機性能監控、容器性能監控、nginx訪問流量、Kubernetes狀態以及平臺各個自研組件的性能指標。
Prometheus一方面為頁面提供性能指標查詢,如果nginx qps、容器cpu利用率,另一方便提供基于這些指標的性能告警,告警發送至alertmanger中,并通過alertmanger的webhook觸發后續的告警處理。
為了支持容器的多指標、多集群自動伸縮,平臺開發一套自動伸縮模塊,通過定時獲取Prometheus監控指標,通過上面的公式(指標和除以目標值)計算出目標的容器副本數,最后通過調用Kubernetes接口擴展容器副本。
最后我想表達,Prometheus也并非銀彈。
首先,Prometheus只針對性能和可用性監控,并不具備日志監控等功能,并不能通過Prometheus解決所有監控問題。
其次,Prometheus認為只有最近的監控數據才有查詢的需要,所有Prometheus本地存儲的設計初衷只是保持短期(一個月)的數據,并非針對大量的歷史數據的存儲。如果需要報表之類的歷史數據,則建議使用Prometheus的遠端存儲如OpenTSDB、m3db等。
Prometheus還有一個小瑕疵是沒有定義單位,這里需要使用者自己去區分或者事先定義好所有監控數據單位,避免數據缺少單位問題。
作者:陳曉宇
來源:DBAplus社群
想知道更多?掃描下面的二維碼關注我
怎么加群?:
怎么免費加入知識星球:
免費資料入口:后臺回復“666”
朕已閱?
總結
以上是生活随笔為你收集整理的为什么说Prometheus是足以取代Zabbix的监控神器?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 忘掉Java并发,先听完这个故事...
- 下一篇: Spring事务“套路”面试