为什么说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事务“套路”面试