監(jiān)控告警-Prometheus

第一章：概述

本章將介紹監(jiān)控告警的一些基本概念。

1.1 什么是監(jiān)控告警秃症？

• 監(jiān)控是什么厂榛？

  說白了就是用一種形式去盯著、觀察服務(wù)器纽匙，把服務(wù)器的各種行為表現(xiàn)都顯示出來务蝠，用以發(fā)現(xiàn)問題和不足。

• 告警是什么烛缔？

  監(jiān)控和告警這兩個詞需要分開來理解馏段，監(jiān)控是監(jiān)控，告警是告警践瓷。監(jiān)控是把行為表現(xiàn)展現(xiàn)出來院喜，用來觀察的。告警則是當(dāng)監(jiān)控獲取的數(shù)據(jù)發(fā)生異常并且達(dá)到了某個臨界點(diǎn)的時候晕翠，采用各種途徑來通知用戶喷舀、管理員、運(yùn)維人員甚至是老板淋肾。

  告警系統(tǒng)中最重要的一個概念之一就是對告警閾值的理解硫麻。閾值(Trigger Value)是監(jiān)控系統(tǒng)中對數(shù)據(jù)達(dá)到某一個臨界值的定義。

在這里插入圖片描述

1.2 監(jiān)控都有哪些組成部分和流程樊卓？

監(jiān)控本身看的是數(shù)據(jù)拿愧，數(shù)據(jù)從哪里來？

數(shù)據(jù)不是憑空從天上掉下來的简识，也不是研發(fā)人員主動給的赶掖，只能是從運(yùn)維數(shù)據(jù)采集來感猛。

在這里插入圖片描述

1.3 監(jiān)控設(shè)計

• 評估系統(tǒng)的業(yè)務(wù)流程、業(yè)務(wù)種類奢赂、架構(gòu)體系

  各個企業(yè)的產(chǎn)品不同陪白，業(yè)務(wù)方向不同，程序代碼不同膳灶，系統(tǒng)架構(gòu)更不同

  對于各個地方的細(xì)節(jié)都需要有一定程度的認(rèn)知咱士，才可以開起設(shè)計的源頭

• 分類出所需的監(jiān)控項種類

  一般可以分為：業(yè)務(wù)級別監(jiān)控/系統(tǒng)級別監(jiān)控/網(wǎng)絡(luò)監(jiān)控/程序代碼監(jiān)控/日志監(jiān)控/用戶行為分析監(jiān)控/其他種類監(jiān)控

  • 業(yè)務(wù)監(jiān)控： 可以包含用戶訪問QPS，DAU日活轧钓，訪問狀態(tài)序厉，業(yè)務(wù)接口（登錄、注冊毕箍、上傳弛房、聊天、留言而柑、短信文捶、搜索等），產(chǎn)品轉(zhuǎn)化率媒咳，充值額度粹排，用戶投訴等等這些很宏觀的概念
  • 系統(tǒng)監(jiān)控：主要是跟操作系統(tǒng)相關(guān)的基本監(jiān)控項，CUP/內(nèi)存/硬盤/IO/TCP連接/流量等等
  • 網(wǎng)絡(luò)監(jiān)控：對網(wǎng)絡(luò)狀態(tài)的監(jiān)控（交換機(jī)涩澡、路由器顽耳、防火墻、vpn等妙同，應(yīng)用更多的是直接對主機(jī)的網(wǎng)絡(luò)監(jiān)控）射富，互聯(lián)網(wǎng)公司必不可少，但很多時候又被忽略渐溶，如：內(nèi)網(wǎng)之間（物理內(nèi)網(wǎng)辉浦、邏輯內(nèi)網(wǎng)、云平臺可用區(qū)等）茎辐、外網(wǎng)宪郊、丟包率、延遲等
  • 日志監(jiān)控：監(jiān)控中的重頭戲拖陆，往往單獨(dú)設(shè)計和搭建弛槐，全部種類的日志都需要有采集（syslog,soft,網(wǎng)絡(luò)設(shè)備,用戶行為）
  • 程序監(jiān)控：一般需要和開發(fā)人員配合，程序中嵌入各種接口依啰，直接獲取數(shù)據(jù)或者特質(zhì)的日志格式

第二章：Prometheus簡介

本章將介紹 Prometheus 的特點(diǎn)乎串、架構(gòu)以及與一些流行監(jiān)控工具的比較。

2.1 什么是Prometheus速警？

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Since its inception in 2012, many companies and organizations have adopted Prometheus, and the project has a very active developer and user community. It is now a standalone open source project and maintained independently of any company. To emphasize this, and to clarify the project's governance structure, Prometheus joined the Cloud Native Computing Foundation in 2016 as the second hosted project, after Kubernetes.

Prometheus受啟發(fā)于Google的Brogmon監(jiān)控系統(tǒng)（相似的Kubernetes是從Google的Brog系統(tǒng)演變而來）叹誉，從2012年開始由前Google工程師在Soundcloud以開源軟件的形式進(jìn)行研發(fā)鸯两，并且于2015年早期對外發(fā)布早期版本。2016年5月繼Kubernetes之后成為第二個正式加入CNCF基金會的項目长豁，同年6月正式發(fā)布1.0版本钧唐。2017年底發(fā)布了基于全新存儲層的2.0版本，能更好地與容器平臺匠襟、云平臺配合钝侠，2018年8月Prometheus正式從CNCF畢業(yè)，預(yù)示著Prometheus將走入企業(yè)酸舍，支撐著大大小小的公司帅韧，幫助他們完成新一代監(jiān)控系統(tǒng)的過渡。

2.2 Prometheus的特點(diǎn)

• 多維數(shù)據(jù)模型（時序由 metric 名字和 k/v 的 labels 構(gòu)成）啃勉。
• 靈活的查詢語句（PromQL）忽舟。
• 無依賴分布式存儲，支持 local 和 remote 不同模型璧亮，單個服務(wù)器節(jié)點(diǎn)是自主的秋秤。
• 通過基于http協(xié)議的pull方式采集時序數(shù)據(jù)各吨，簡單易懂豹芯。
• 可以通過中間網(wǎng)關(guān)進(jìn)行時序數(shù)據(jù)推送膀估。
• 可以通過服務(wù)發(fā)現(xiàn)或靜態(tài)配置的方式來發(fā)現(xiàn)目標(biāo)服務(wù)對象啊楚。
• 支持多種統(tǒng)計數(shù)據(jù)模型炮叶，圖形化友好哥遮。

2.3 Prometheus組織架構(gòu)

在這里插入圖片描述

2.3.1 基本原理

Prometheus的基本原理是通過HTTP協(xié)議周期性抓取被監(jiān)控組件的狀態(tài)笨使，任意組件只要提供對應(yīng)的HTTP接口就可以接入監(jiān)控镀裤。不需要任何SDK或者其他的集成過程竞阐。這樣做非常適合做虛擬化環(huán)境監(jiān)控系統(tǒng)，比如VM暑劝、Docker骆莹、Kubernetes等。輸出被監(jiān)控組件信息的HTTP接口被叫做exporter 担猛。目前互聯(lián)網(wǎng)公司常用的組件大部分都有exporter可以直接使用幕垦，比如Varnish、Haproxy傅联、Nginx先改、MySQL、Linux系統(tǒng)信息(包括磁盤蒸走、內(nèi)存仇奶、CPU、網(wǎng)絡(luò)等等)比驻。

2.3.2 核心組件

2.3.2.1 Prometheus server

• Prometheus Server是Prometheus組件中的核心部分该溯，負(fù)責(zé)實(shí)現(xiàn)對監(jiān)控數(shù)據(jù)的獲取岛抄，存儲以及查詢。 Prometheus Server可以通過靜態(tài)配置管理監(jiān)控目標(biāo)狈茉，也可以配合使用Service Discovery的方式動態(tài)管理監(jiān)控目標(biāo)弦撩，并從這些監(jiān)控目標(biāo)中獲取數(shù)據(jù)。其次Prometheus Server需要對采集到的監(jiān)控數(shù)據(jù)進(jìn)行存儲论皆，Prometheus Server本身就是一個時序數(shù)據(jù)庫益楼，將采集到的監(jiān)控數(shù)據(jù)按照時間序列的方式存儲在本地磁盤當(dāng)中。最后Prometheus Server對外提供了自定義的PromQL語言点晴，實(shí)現(xiàn)對數(shù)據(jù)的查詢以及分析感凤。

• Prometheus Server內(nèi)置的Express Browser UI，通過這個UI可以直接通過PromQL實(shí)現(xiàn)數(shù)據(jù)的查詢以及可視化粒督。

• Prometheus Server的聯(lián)邦集群能力可以使其從其他的Prometheus Server實(shí)例中獲取數(shù)據(jù)陪竿，因此在大規(guī)模監(jiān)控的情況下，可以通過聯(lián)邦集群以及功能分區(qū)的方式對Prometheus Server進(jìn)行擴(kuò)展屠橄。

2.3.2.2 Exporters

Exporter將監(jiān)控數(shù)據(jù)采集的端點(diǎn)通過HTTP服務(wù)的形式暴露給Prometheus Server族跛，Prometheus Server通過訪問該Exporter提供的Endpoint端點(diǎn)，即可獲取到需要采集的監(jiān)控數(shù)據(jù)锐墙。

一般來說可以將Exporter分為2類：

• 直接采集：這一類Exporter直接內(nèi)置了對Prometheus監(jiān)控的支持礁哄，比如cAdvisor，Kubernetes溪北，Etcd桐绒，Gokit等，都直接內(nèi)置了用于向Prometheus暴露監(jiān)控數(shù)據(jù)的端點(diǎn)之拨。

• 間接采集：間接采集茉继，原有監(jiān)控目標(biāo)并不直接支持Prometheus，因此我們需要通過Prometheus提供的Client Library編寫該監(jiān)控目標(biāo)的監(jiān)控采集程序蚀乔。例如： Mysql Exporter烁竭，JMX Exporter，Consul Exporter等吉挣。

2.3.2.3 AlertManager

在Prometheus Server中支持基于PromQL創(chuàng)建告警規(guī)則派撕，如果滿足PromQL定義的規(guī)則，則會產(chǎn)生一條告警听想，而告警的后續(xù)處理流程則由AlertManager進(jìn)行管理腥刹。在AlertManager中我們可以與郵件，Slack等等內(nèi)置的通知方式進(jìn)行集成汉买，也可以通過Webhook自定義告警處理方式衔峰。

2.3.2.4 PushGateway

由于Prometheus數(shù)據(jù)采集基于Pull模型進(jìn)行設(shè)計，因此在網(wǎng)絡(luò)環(huán)境的配置上必須要讓Prometheus Server能夠直接與Exporter進(jìn)行通信。 當(dāng)這種網(wǎng)絡(luò)需求無法直接滿足時垫卤，就可以利用PushGateway來進(jìn)行中轉(zhuǎn)威彰。可以通過PushGateway將內(nèi)部網(wǎng)絡(luò)的監(jiān)控數(shù)據(jù)主動Push到Gateway當(dāng)中穴肘。而Prometheus Server則可以采用同樣Pull的方式從PushGateway中獲取到監(jiān)控數(shù)據(jù)歇盼。

Pushgateway 是 Prometheus 生態(tài)中一個重要工具，使用它的原因主要是：

• Prometheus 采用 pull 模式评抚，可能由于不在一個子網(wǎng)或者防火墻原因豹缀，導(dǎo)致 Prometheus 無法直接拉取各個 target 數(shù)據(jù)。
• 在監(jiān)控業(yè)務(wù)數(shù)據(jù)的時候慨代，需要將不同數(shù)據(jù)匯總, 由 Prometheus統(tǒng)一收集邢笙。

由于以上原因，不得不使用 pushgateway侍匙，但在使用之前氮惯，有必要了解一下它的一些弊端：

• 將多個節(jié)點(diǎn)數(shù)據(jù)匯總到 pushgateway, 如果 pushgateway 掛了，受影響比多個 target 大想暗。
• Prometheus 拉取狀態(tài) up 只針對 pushgateway, 無法做到對每個節(jié)點(diǎn)有效妇汗。
• Pushgateway 可以持久化推送給它的所有監(jiān)控數(shù)據(jù)。

因此说莫，即使你的監(jiān)控已經(jīng)下線杨箭，prometheus 還會拉取到舊的監(jiān)控數(shù)據(jù)，需要手動清理 pushgateway 不要的數(shù)據(jù)唬滑。

2.3.2.5 Service Discovery

服務(wù)發(fā)現(xiàn)在Prometheus中是特別重要的一個部分告唆，基于Pull模型的抓取方式，需要在Prometheus中配置大量的抓取節(jié)點(diǎn)信息才可以進(jìn)行數(shù)據(jù)收集晶密。有了服務(wù)發(fā)現(xiàn)后，用戶通過服務(wù)發(fā)現(xiàn)和注冊的工具對成百上千的節(jié)點(diǎn)進(jìn)行服務(wù)注冊模她，并最終將注冊中心的地址配置在Prometheus的配置文件中稻艰，大大簡化了配置文件的復(fù)雜程度， 也可以更好的管理各種服務(wù)侈净。

• 在眾多云平臺中（AWS,OpenStack）尊勿，Prometheus可以 通過平臺自身的API直接自動發(fā)現(xiàn)運(yùn)行于平臺上的各種服務(wù)，并抓取他們的信息

• Kubernetes掌握并管理著所有的容器以及服務(wù)信息畜侦，那此時Prometheus只需要與Kubernetes打交道就可以找到所有需要監(jiān)控的容器以及服務(wù)對象

• Consul（官方推薦）等服務(wù)發(fā)現(xiàn)注冊軟件

• 通過DNS進(jìn)行服務(wù)發(fā)現(xiàn)

• 通過靜態(tài)配置文件（在服務(wù)節(jié)點(diǎn)規(guī)模不大的情況下）

2.3.2.6 Storage

Prometheus提供了兩種數(shù)據(jù)持久化方式：一種是本地存儲元扔，通過Prometheus自帶的TSDB（時序數(shù)據(jù)庫），將數(shù)據(jù)保存到本地磁盤旋膳，為了性能考慮澎语，建議使用SSD。但本地存儲的容量畢竟有限，建議不要保存超過一個月的數(shù)據(jù)擅羞。Prometheus本地存儲經(jīng)過多年改進(jìn)尸变，自Prometheus 2.0后提供的V3版本TSDB性能已經(jīng)非常高，可以支持單機(jī)每秒1000w個指標(biāo)的收集减俏。

Prometheus本地數(shù)據(jù)存儲能力一直為大家詬病召烂，但Prometheus本地存儲設(shè)計的初衷就是為了監(jiān)控數(shù)據(jù)的查詢，Facebook發(fā)現(xiàn)85％的查詢是針對26小時內(nèi)的數(shù)據(jù)娃承。所以Prometheus本地時序數(shù)據(jù)庫的設(shè)計更多考慮的是高性能而非分布式大容量奏夫。

另一種是遠(yuǎn)端存儲，適用于大量歷史監(jiān)控數(shù)據(jù)的存儲和查詢历筝。通過中間層的適配器的轉(zhuǎn)化酗昼，Prometheus將數(shù)據(jù)保存到遠(yuǎn)端存儲。適配器實(shí)現(xiàn)Prometheus存儲的remote write和remote read接口漫谷，并把數(shù)據(jù)轉(zhuǎn)化為遠(yuǎn)端存儲支持的數(shù)據(jù)格式仔雷。目前，遠(yuǎn)端存儲主要包括OpenTSDB舔示、InfluxDB碟婆、Elasticsearch、M3DB等惕稻，其中M3DB是目前非常受歡迎的后端存儲竖共。

運(yùn)維方面：

Prometheus has several flags that allow configuring the local storage. The most important ones are:

• --storage.tsdb.path: This determines where Prometheus writes its database. Defaults to data/.
• --storage.tsdb.retention.time: This determines when to remove old data. Defaults to 15d. Overrides storage.tsdb.retention if this flag is set to anything other than default.
• --storage.tsdb.retention.size: [EXPERIMENTAL] This determines the maximum number of bytes that storage blocks can use (note that this does not include the WAL size, which can be substantial). The oldest data will be removed first. Defaults to 0 or disabled. This flag is experimental and can be changed in future releases. Units supported: KB, MB, GB, PB. Ex: "512MB"
• --storage.tsdb.retention: This flag has been deprecated in favour of storage.tsdb.retention.time.
• --storage.tsdb.wal-compression: This flag enables compression of the write-ahead log (WAL). Depending on your data, you can expect the WAL size to be halved with little extra cpu load. Note that if you enable this flag and subsequently downgrade Prometheus to a version below 2.11.0 you will need to delete your WAL as it will be unreadable.

這幾個參數(shù)是設(shè)置本地存儲的配置，自行翻譯吧俺祠。

On average, Prometheus uses only around 1-2 bytes per sample. Thus, to plan the capacity of a Prometheus server, you can use the rough formula:

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

計算Prometheus服務(wù)器的容量 公给，關(guān)于采集時間間隔的設(shè)置可以參考文章規(guī)劃Prometheus的存儲用量。

To tune the rate of ingested samples per second, you can either reduce the number of time series you scrape (fewer targets or fewer series per target), or you can increase the scrape interval. However, reducing the number of series is likely more effective, due to compression of samples within a series.

If your local storage becomes corrupted for whatever reason, your best bet is to shut down Prometheus and remove the entire storage directory. Non POSIX compliant filesystems are not supported by Prometheus's local storage, corruptions may happen, without possibility to recover. NFS is only potentially POSIX, most implementations are not. You can try removing individual block directories to resolve the problem, this means losing a time window of around two hours worth of data per block directory. Again, Prometheus's local storage is not meant as durable long-term storage.

If both time and size retention policies are specified, whichever policy triggers first will be used at that instant.

Expired block cleanup happens on a background schedule. It may take up to two hours remove expired blocks. Expired blocks must be fully expired before they are cleaned up.

2.3.3 服務(wù)過程

• Prometheus server 定期從靜態(tài)配置的 targets 或者服務(wù)發(fā)現(xiàn)的 targets 拉取metrics(指標(biāo))數(shù)據(jù)蜘渣。

• Prometheus采用PULL的方式進(jìn)行監(jiān)控淌铐，即服務(wù)器可以直接通過目標(biāo)PULL數(shù)據(jù)或者間接地通過中間網(wǎng)關(guān)來Push數(shù)據(jù)。 PushGateway支持Client主動推送metrics到PushGateway蔫缸，而Prometheus只是定時去Gateway上抓取數(shù)據(jù)腿准。

• Prometheus是將采集過來的數(shù)據(jù)先存放在內(nèi)存之中的，并通過一定規(guī)則進(jìn)行清理和整理數(shù)據(jù)拾碌，把得到的結(jié)果存儲到新的時間序列中吐葱。當(dāng)新拉取的數(shù)據(jù)大于配置內(nèi)存緩存區(qū)的時候，Prometheus 會將數(shù)據(jù)持久化到磁盤（如果使用 remote storage 將持久化到云端）校翔。

• Prometheus 可以配置 rules弟跑，然后定時查詢數(shù)據(jù)，當(dāng)條件觸發(fā)的時候防症，會將 alert 推送到配置的 Alertmanager孟辑。

• Alertmanager 收到警告的時候哎甲，會根據(jù)配置，聚合扑浸，去重烧给，降噪，最后發(fā)送警告喝噪。

• Prometheus通過PromQL和其他API可視化地展示收集的數(shù)據(jù)础嫡。Prometheus支持很多方式的圖表可視化，例如Grafana酝惧、自帶的Promdash以及自身提供的模版引擎等等榴鼎。Prometheus還提供HTTP API的查詢方式，自定義所需要的輸出晚唇。

注意：

• Prometheus 的數(shù)據(jù)是基于時序的 float64 的值巫财，如果你的數(shù)據(jù)值有更多類型，無法滿足哩陕。

• Prometheus 不適合做審計計費(fèi)平项，因為它的數(shù)據(jù)是按一定時間采集的，關(guān)注的更多是系統(tǒng)的運(yùn)行瞬時狀態(tài)以及趨勢悍及，即使有少量數(shù)據(jù)沒有采集也能容忍闽瓢，但是審計計費(fèi)需要記錄每個請求，并且數(shù)據(jù)長期存儲心赶，這個Prometheus 無法滿足扣讼，可能需要采用專門的審計系統(tǒng)。

2.4 Prometheus的優(yōu)勢

優(yōu)勢和它的特點(diǎn)是分不開的：

• 基于time series時間序列模型（時序由 metric 名字和 k/v 的 labels 構(gòu)成）

  時間序列(time series (X,Y))是一系列有序的數(shù)據(jù)缨叫，通常是等時間間隔的采樣數(shù)據(jù)椭符。

• 采樣數(shù)據(jù)的查詢完全基于數(shù)學(xué)運(yùn)算，二不是其他的表達(dá)式耻姥，并提供專有的查詢輸入console销钝。

  這個特點(diǎn)很獨(dú)特，所有查詢都基于數(shù)學(xué)運(yùn)算公式琐簇，如（增量(A)+增量(B)）/ 總增量(C) > 固定百分比曙搬，則觸發(fā)告警。

• 采用http pull/push兩種對應(yīng)的數(shù)據(jù)采集傳輸方式

  所有的數(shù)據(jù)采集都基本采用http的形式鸽嫂，且分為pull/push拉和推兩種方式去采集程序，對數(shù)據(jù)操作很方便征讲。

• 開源据某，且有大量的社區(qū)成品插件

  很多prometheus社區(qū)開發(fā)的插件已經(jīng)異常強(qiáng)大和完善，如果對監(jiān)控要求不是特別高诗箍，默認(rèn)的幾個成品插件裝上就可以用到底了癣籽。監(jiān)控成型速度快。

• push的方法使用非常靈活

  push的這種采集方法靈活度超乎想象，幾乎任何形式的數(shù)據(jù)都可以實(shí)現(xiàn)筷狼。

• 本身自帶圖像調(diào)試

  prometheus本身自帶了現(xiàn)成的圖形成型界面瓶籽，雖然不能跟grafana的效果相比，但是這種自帶圖形成圖可以方便我們進(jìn)行調(diào)試埂材。

• 最精細(xì)的數(shù)據(jù)采樣

  大多數(shù)市面上的開源監(jiān)控采樣也就能精確到半分鐘塑顺、一分鐘的程度，商品化監(jiān)控產(chǎn)品就更別提了俏险，為了縮小數(shù)據(jù)存儲的成本严拒，有的甚至是5分鐘作為采樣最小間隔。

  prometheus理論上可以達(dá)到每秒采集竖独，而且可以自行定制頻率裤唠，可以自行衡量采樣時間和存儲成本的平衡。

prometheus一些不足的地方:

• 暫不支持集群莹痢。
• 如果集群數(shù)量過大种蘸，本身監(jiān)控有性能的瓶頸，如果是集群則可以解決這個問題竞膳。
• 偶爾發(fā)生數(shù)據(jù)丟失（2.0之前版本偶爾會發(fā)生航瞭，2.0之后已解決）。
• 學(xué)習(xí)成本太大顶猜，尤其是獨(dú)有的數(shù)學(xué)命令行沧奴，各種數(shù)學(xué)模型概念復(fù)雜，中文資料極少长窄。
• 對磁盤資源消耗較大滔吠，具體看監(jiān)控的集群量、監(jiān)控項的多少和保存時間的長短等挠日。

2.5 Prometheus的適用場景

在選擇Prometheus作為監(jiān)控工具前疮绷，要明確它的適用范圍，以及不適用的場景嚣潜。

• Prometheus在記錄純數(shù)值時間序列方面表現(xiàn)非常好冬骚。它既適用于以服務(wù)器為中心的監(jiān)控，也適用于高動態(tài)的面向服務(wù)架構(gòu)的監(jiān)控懂算。

• 在微服務(wù)的監(jiān)控上只冻，Prometheus對多維度數(shù)據(jù)采集及查詢的支持也是特殊的優(yōu)勢。

• Prometheus更強(qiáng)調(diào)可靠性计技，即使在故障的情況下也能查看系統(tǒng)的統(tǒng)計信息喜德。權(quán)衡利弊，以可能丟失少量數(shù)據(jù)為代價確保整個系統(tǒng)的可用性垮媒。因此舍悯，它不適用于對數(shù)據(jù)準(zhǔn)確率要求100%的系統(tǒng)航棱，比如實(shí)時計費(fèi)系統(tǒng)（涉及到錢）。

2.6 Why Prometheus?

Zabbix是由Alexei Vladishev開源的分布式監(jiān)控系統(tǒng)，支持多種采集方式和采集客戶端路召，同時支持SNMP勃刨、IPMI、JMX股淡、Telnet身隐、SSH等多種協(xié)議，它將采集到的數(shù)據(jù)存放到數(shù)據(jù)庫中唯灵，然后對其進(jìn)行分析整理贾铝，如果符合告警規(guī)則，則觸發(fā)相應(yīng)的告警埠帕。

Open-Falcon是小米開源的企業(yè)級監(jiān)控工具垢揩，用Go語言開發(fā)而成，包括小米敛瓷、滴滴叁巨、美團(tuán)等在內(nèi)的互聯(lián)網(wǎng)公司都在使用它，是一款靈活呐籽、可擴(kuò)展并且高性能的監(jiān)控方案锋勺。

從開發(fā)語言上看，為了應(yīng)對高并發(fā)和快速迭代的需求狡蝶，監(jiān)控系統(tǒng)的開發(fā)語言已經(jīng)慢慢從C語言轉(zhuǎn)移到Go庶橱。不得不說，Go憑借簡潔的語法和優(yōu)雅的并發(fā)贪惹，在Java占據(jù)業(yè)務(wù)開發(fā)苏章，C占領(lǐng)底層開發(fā)的情況下，準(zhǔn)確定位中間件開發(fā)需求奏瞬，在當(dāng)前開源中間件產(chǎn)品中被廣泛應(yīng)用枫绅。

從系統(tǒng)成熟度上看，Zabbix是老牌的監(jiān)控系統(tǒng)：Zabbix是在1998年出現(xiàn)的丝格，系統(tǒng)功能比較穩(wěn)定撑瞧，成熟度較高。而Prometheus和Open-Falcon都是最近幾年才誕生的显蝌，雖然功能還在不斷迭代更新预伺，但站在巨人的肩膀之上，在架構(gòu)設(shè)計上借鑒了很多老牌監(jiān)控系統(tǒng)的經(jīng)驗曼尊。

從系統(tǒng)擴(kuò)展性方面看酬诀，Zabbix和Open-Falcon都可以自定義各種監(jiān)控腳本，并且Zabbix不僅可以做到主動推送骆撇，還可以做到被動拉取瞒御，Prometheus則定義了一套監(jiān)控數(shù)據(jù)規(guī)范，并通過各種exporter擴(kuò)展系統(tǒng)采集能力神郊。

從數(shù)據(jù)存儲方面來看肴裙，Zabbix采用關(guān)系數(shù)據(jù)庫保存趾唱，這極大限制了Zabbix采集的性能，Open-Falcon采用RDD數(shù)據(jù)存儲蜻懦，并且可以對接到OpenTSDB甜癞，而Prometheus自研一套高性能的時序數(shù)據(jù)庫，在V3版本可以達(dá)到每秒千萬級別的數(shù)據(jù)存儲宛乃，通過對接第三方時序數(shù)據(jù)庫擴(kuò)展歷史數(shù)據(jù)的存儲悠咱。

從配置和維護(hù)的復(fù)雜度上看，Prometheus只有一個核心server組件征炼，一條命令便可以啟動析既，相比而言，其他系統(tǒng)配置相對麻煩谆奥，尤其是Open-Falcon眼坏。

從社區(qū)活躍度上看，目前Zabbix社區(qū)活躍度比較低雄右，Open-Falcon雖然也比較活躍空骚，但基本都是國內(nèi)的公司參與，Prometheus在這方面占據(jù)絕對優(yōu)勢擂仍，社區(qū)活躍度最高囤屹，并且受到CNCF的支持，后期的發(fā)展值得期待逢渔。

從容器支持角度看肋坚，由于Zabbix出現(xiàn)得比較早，當(dāng)時容器還沒有誕生肃廓，自然對容器的支持也比較差智厌。Open-Falcon雖然提供了容器的監(jiān)控，但支持力度有限盲赊。Prometheus的動態(tài)發(fā)現(xiàn)機(jī)制铣鹏，不僅可以支持Swarm原生集群官研，還支持Kubernetes容器集群的監(jiān)控狈定，是目前容器監(jiān)控最好解決方案。Zabbix在傳統(tǒng)監(jiān)控系統(tǒng)中圣拄，尤其是在服務(wù)器相關(guān)監(jiān)控方面绘迁，占據(jù)絕對優(yōu)勢合溺。伴隨著容器的發(fā)展，Prometheus開始成為主導(dǎo)及容器監(jiān)控方面的標(biāo)配缀台，并且在未來可見的時間內(nèi)被廣泛應(yīng)用棠赛。總體來說，對比各種監(jiān)控系統(tǒng)的優(yōu)劣睛约，Prometheus可以說是目前監(jiān)控領(lǐng)域最鋒利的“瑞士軍刀”了鼎俘。

總結(jié)：

• Prometheus 屬于一站式監(jiān)控告警平臺，依賴少痰腮，功能齊全而芥。

• Prometheus 支持對云的或容器的監(jiān)控，其他系統(tǒng)主要對主機(jī)監(jiān)控膀值。

• Prometheus 數(shù)據(jù)查詢語句表現(xiàn)力更強(qiáng)大，內(nèi)置更強(qiáng)大的統(tǒng)計函數(shù)误辑。

• Prometheus 在數(shù)據(jù)存儲擴(kuò)展性以及持久性上沒有 InfluxDB沧踏，OpenTSDB，Sensu 好巾钉。

參考文檔：http://www.sohu.com/a/342733264_198222