之前，寫過幾篇有關(guān)線上問題排查的文章，文中附帶了一些監(jiān)控圖，有些讀者對(duì)此很感興趣，問我監(jiān)控系統(tǒng)選型上有沒有好的建議?

[[337149]]

 

圖片來自 Pexels

目前我所經(jīng)歷的幾家公司，監(jiān)控系統(tǒng)都是自研的。其實(shí)業(yè)界有很多優(yōu)秀的開源產(chǎn)品可供選擇，能滿足絕大部分的監(jiān)控需求，如果能從中選擇一款滿足企業(yè)當(dāng)下的訴求，顯然最省時(shí)省力。

 

這篇文章，我將對(duì)監(jiān)控體系的基礎(chǔ)知識(shí)、原理和架構(gòu)做一次系統(tǒng)性整理，同時(shí)還會(huì)對(duì)幾款最常用的開源監(jiān)控產(chǎn)品做下介紹，以便大家選型時(shí)參考。

內(nèi)容包括如下三部分：

• 必知必會(huì)的監(jiān)控基礎(chǔ)知識(shí)
• 主流監(jiān)控系統(tǒng)介紹
• 監(jiān)控系統(tǒng)的選型建議

必知必會(huì)的監(jiān)控基礎(chǔ)知識(shí)

監(jiān)控系統(tǒng)俗稱“第三只眼”，幾乎是我們每天都會(huì)打交道的系統(tǒng)，下面四項(xiàng)基礎(chǔ)知識(shí)我認(rèn)為是必須要了解的。

監(jiān)控系統(tǒng)的 7 大作用

正所謂“無監(jiān)控，不運(yùn)維”，監(jiān)控系統(tǒng)的地位不言而喻。不管你是監(jiān)控系統(tǒng)的開發(fā)者還是使用者，首先肯定要清楚：監(jiān)控系統(tǒng)的目標(biāo)是什么?它能發(fā)揮什么作用?

 

監(jiān)控系統(tǒng)有如下七大作用：

• 實(shí)時(shí)采集監(jiān)控?cái)?shù)據(jù)：包括硬件、操作系統(tǒng)、中間件、應(yīng)用程序等各個(gè)維度的數(shù)據(jù)。
• 實(shí)時(shí)反饋監(jiān)控狀態(tài)：通過對(duì)采集的數(shù)據(jù)進(jìn)行多維度統(tǒng)計(jì)和可視化展示，能實(shí)時(shí)體現(xiàn)監(jiān)控對(duì)象的狀態(tài)是正常還是異常。
• 預(yù)知故障和告警：能夠提前預(yù)知故障風(fēng)險(xiǎn)，并及時(shí)發(fā)出告警信息。
• 輔助定位故障：提供故障發(fā)生時(shí)的各項(xiàng)指標(biāo)數(shù)據(jù)，輔助故障分析和定位。
• 輔助性能調(diào)優(yōu)：為性能調(diào)優(yōu)提供數(shù)據(jù)支持，比如慢 SQL，接口響應(yīng)時(shí)間等。
• 輔助容量規(guī)劃：為服務(wù)器、中間件以及應(yīng)用集群的容量規(guī)劃提供數(shù)據(jù)支撐。
• 輔助自動(dòng)化運(yùn)維：為自動(dòng)擴(kuò)容或者根據(jù)配置的 SLA 進(jìn)行服務(wù)降級(jí)等智能運(yùn)維提供數(shù)據(jù)支撐。

使用監(jiān)控系統(tǒng)的正確姿勢(shì)

出任何線上事故，先不說其他地方有問題，監(jiān)控部分一定是有問題的。聽著很甩鍋的一句話，仔細(xì)思考好像有一定道理。

我們?cè)谑鹿蕪?fù)盤時(shí)，通常會(huì)思考這三個(gè)和監(jiān)控有關(guān)的問題：

• 有沒有做監(jiān)控?
• 監(jiān)控是否及時(shí)?
• 監(jiān)控信息是否有助于快速定位問題?

可見光有一套好的監(jiān)控系統(tǒng)還不夠，還必須知道如何用好它。一個(gè)成熟的研發(fā)團(tuán)隊(duì)通常會(huì)定一個(gè)監(jiān)控規(guī)范，用來統(tǒng)一監(jiān)控系統(tǒng)的使用方法。

 

如何使用監(jiān)控系統(tǒng)?總結(jié)如下四個(gè)方面：

• 了解監(jiān)控對(duì)象的工作原理：要做到對(duì)監(jiān)控對(duì)象有基本的了解，清楚它的工作原理。比如想對(duì) JVM 進(jìn)行監(jiān)控，你必須清楚 JVM 的堆內(nèi)存結(jié)構(gòu)和垃圾回收機(jī)制。
• 確定監(jiān)控對(duì)象的指標(biāo)：清楚使用哪些指標(biāo)來刻畫監(jiān)控對(duì)象的狀態(tài)?比如想對(duì)某個(gè)接口進(jìn)行監(jiān)控，可以采用請(qǐng)求量、耗時(shí)、超時(shí)量、異常量等指標(biāo)來衡量。
• 定義合理的報(bào)警閾值和等級(jí)：達(dá)到什么閾值需要告警?對(duì)應(yīng)的故障等級(jí)是多少?不需要處理的告警不是好告警，可見定義合理的閾值有多重要，否則只會(huì)降低運(yùn)維效率或者讓監(jiān)控系統(tǒng)失去它的作用。
• 建立完善的故障處理流程：收到故障告警后，一定要有相應(yīng)的處理流程和 oncall 機(jī)制，讓故障及時(shí)被跟進(jìn)處理。

監(jiān)控的對(duì)象和指標(biāo)都有哪些

監(jiān)控已然成為了整個(gè)產(chǎn)品生命周期非常重要的一環(huán)，運(yùn)維關(guān)注硬件和基礎(chǔ)監(jiān)控，研發(fā)關(guān)注各類中間件和應(yīng)用層的監(jiān)控，產(chǎn)品關(guān)注核心業(yè)務(wù)指標(biāo)的監(jiān)控?？梢?，監(jiān)控的對(duì)象已經(jīng)越來越立體化。

這里，我對(duì)常用的監(jiān)控對(duì)象以及監(jiān)控指標(biāo)做了分類整理，供大家參考：

①硬件監(jiān)控

 

包括：電源狀態(tài)、CPU 狀態(tài)、機(jī)器溫度、風(fēng)扇狀態(tài)、物理磁盤、raid 狀態(tài)、內(nèi)存狀態(tài)、網(wǎng)卡狀態(tài)。

②服務(wù)器基礎(chǔ)監(jiān)控

包括：

• CPU：?jiǎn)蝹€(gè) CPU 以及整體的使用情況。
• 內(nèi)存：已用內(nèi)存、可用內(nèi)存。
• 磁盤：磁盤使用率、磁盤讀寫的吞吐量。
• 網(wǎng)絡(luò)：出口流量、入口流量、TCP 連接狀態(tài)。

③數(shù)據(jù)庫(kù)監(jiān)控

包括：數(shù)據(jù)庫(kù)連接數(shù)、QPS、TPS、并行處理的會(huì)話數(shù)、緩存命中率、主從延時(shí)、鎖狀態(tài)、慢查詢。

④中間件監(jiān)控

包括：

• Nginx：活躍連接數(shù)、等待連接數(shù)、丟棄連接數(shù)、請(qǐng)求量、耗時(shí)、5XX 錯(cuò)誤率。
• Tomcat：最大線程數(shù)、當(dāng)前線程數(shù)、請(qǐng)求量、耗時(shí)、錯(cuò)誤量、堆內(nèi)存使用情況、GC 次數(shù)和耗時(shí)。
• 緩存：成功連接數(shù)、阻塞連接數(shù)、已使用內(nèi)存、內(nèi)存碎片率、請(qǐng)求量、耗時(shí)、緩存命中率。
• 消息隊(duì)列：連接數(shù)、隊(duì)列數(shù)、生產(chǎn)速率、消費(fèi)速率、消息堆積量。

⑤應(yīng)用監(jiān)控

包括：

• HTTP 接口：URL 存活、請(qǐng)求量、耗時(shí)、異常量。
• RPC 接口：請(qǐng)求量、耗時(shí)、超時(shí)量、拒絕量。
• JVM：GC 次數(shù)、GC 耗時(shí)、各個(gè)內(nèi)存區(qū)域的大小、當(dāng)前線程數(shù)、死鎖線程數(shù)。
• 線程池：活躍線程數(shù)、任務(wù)隊(duì)列大小、任務(wù)執(zhí)行耗時(shí)、拒絕任務(wù)數(shù)。
• 連接池：總連接數(shù)、活躍連接數(shù)。
• 日志監(jiān)控：訪問日志、錯(cuò)誤日志。
• 業(yè)務(wù)指標(biāo)：視業(yè)務(wù)來定，比如 PV、訂單量等。

監(jiān)控系統(tǒng)的基本流程

無論是開源的監(jiān)控系統(tǒng)還是自研的監(jiān)控系統(tǒng)，監(jiān)控的整個(gè)流程大同小異。

 

一般都包括以下模塊：

• 數(shù)據(jù)采集：采集的方式有很多種，包括日志埋點(diǎn)進(jìn)行采集(通過 Logstash、Filebeat 等進(jìn)行上報(bào)和解析)，JMX 標(biāo)準(zhǔn)接口輸出監(jiān)控指標(biāo)，被監(jiān)控對(duì)象提供 REST API 進(jìn)行數(shù)據(jù)采集(如 Hadoop、ES)，系統(tǒng)命令行，統(tǒng)一的 SDK 進(jìn)行侵入式的埋點(diǎn)和上報(bào)等。
• 數(shù)據(jù)傳輸：將采集的數(shù)據(jù)以 TCP、UDP 或者 HTTP 協(xié)議的形式上報(bào)給監(jiān)控系統(tǒng)，有主動(dòng) Push 模式，也有被動(dòng) Pull 模式。
• 數(shù)據(jù)存儲(chǔ)：有使用 MySQL、Oracle 等 RDBMS 存儲(chǔ)的，也有使用時(shí)序數(shù)據(jù)庫(kù) RRDTool、OpentTSDB、InfluxDB 存儲(chǔ)的，還有使用 HBase 存儲(chǔ)的。
• 數(shù)據(jù)展示：數(shù)據(jù)指標(biāo)的圖形化展示。
• 監(jiān)控告警：靈活的告警設(shè)置，以及支持郵件、短信、IM 等多種通知通道。

主流監(jiān)控系統(tǒng)介紹

下面再來認(rèn)識(shí)下主流的開源監(jiān)控系統(tǒng)，由于篇幅有限，我挑選了 3 款使用最廣泛的監(jiān)控系統(tǒng)：Zabbix、Open-Falcon、Prometheus，會(huì)對(duì)它們的架構(gòu)進(jìn)行介紹，同時(shí)總結(jié)下各自的優(yōu)劣勢(shì)。

Zabbix(老牌監(jiān)控的優(yōu)秀代表)

Zabbix 于 1998 年誕生，核心組件采用 C 語(yǔ)言開發(fā)，Web 端采用 PHP 開發(fā)。

 

它屬于老牌監(jiān)控系統(tǒng)中的優(yōu)秀代表，監(jiān)控功能很全面，使用也很廣泛，差不多有 70% 左右的互聯(lián)網(wǎng)公司都曾使用過 Zabbix 作為監(jiān)控解決方案。

先來了解下 Zabbix 的架構(gòu)設(shè)計(jì)：

Zabbix 架構(gòu)圖如上：

 

• Zabbix Server：核心組件，C 語(yǔ)言編寫，負(fù)責(zé)接收 Agent、Proxy 發(fā)送的監(jiān)控?cái)?shù)據(jù)，也支持 JMX、SNMP 等多種協(xié)議直接采集數(shù)據(jù)。同時(shí)，它還負(fù)責(zé)數(shù)據(jù)的匯總存儲(chǔ)以及告警觸發(fā)等。
• Zabbix Proxy：可選組件，對(duì)于被監(jiān)控機(jī)器較多的情況下，可使用 Proxy 進(jìn)行分布式監(jiān)控，它能代理 Server 收集部分監(jiān)控?cái)?shù)據(jù)，以減輕 Server 的壓力。
• Zabbix Agentd：部署在被監(jiān)控主機(jī)上，用于采集本機(jī)的數(shù)據(jù)并發(fā)送給 Proxy 或者 Server，它的插件機(jī)制支持用戶自定義數(shù)據(jù)采集腳本。
• Agent 可在 Server 端手動(dòng)配置，也可以通過自動(dòng)發(fā)現(xiàn)機(jī)制被識(shí)別。數(shù)據(jù)收集方式同時(shí)支持主動(dòng) Push 和被動(dòng) Pull 兩種模式。
• Database：用于存儲(chǔ)配置信息以及采集到的數(shù)據(jù)，支持 MySQL、Oracle 等關(guān)系型數(shù)據(jù)庫(kù)。同時(shí)，最新版本的 Zabbix 已經(jīng)開始支持時(shí)序數(shù)據(jù)庫(kù)，不過成熟度還不高。
• Web Server：Zabbix 的 GUI 組件，PHP 編寫，提供監(jiān)控?cái)?shù)據(jù)的展現(xiàn)和告警配置。

下面是 Zabbix 的優(yōu)勢(shì)：

• 產(chǎn)品成熟：由于誕生時(shí)間長(zhǎng)且使用廣泛，擁有豐富的文檔資料以及各種開源的數(shù)據(jù)采集插件，能覆蓋絕大部分監(jiān)控場(chǎng)景。
• 采集方式豐富：支持 Agent、SNMP、JMX、SSH 等多種采集方式，以及主動(dòng)和被動(dòng)的數(shù)據(jù)傳輸方式。
• 較強(qiáng)的擴(kuò)展性：支持 Proxy 分布式監(jiān)控，有 Agent 自動(dòng)發(fā)現(xiàn)功能，插件式架構(gòu)支持用戶自定義數(shù)據(jù)采集腳本。
• 配置管理方便：能通過 Web 界面進(jìn)行監(jiān)控和告警配置，操作方便，上手簡(jiǎn)單。

下面是 Zabbix 的劣勢(shì)：

• 性能瓶頸：機(jī)器量或者業(yè)務(wù)量大了后，關(guān)系型數(shù)據(jù)庫(kù)的寫入一定是瓶頸，官方給出的單機(jī)上限是 5000 臺(tái)，個(gè)人感覺達(dá)不到，尤其現(xiàn)在應(yīng)用層的指標(biāo)越來越多。雖然最新版已經(jīng)開始支持時(shí)序數(shù)據(jù)庫(kù)，不過成熟度還不高。
• 應(yīng)用層監(jiān)控支持有限：如果想對(duì)應(yīng)用程序做侵入式的埋點(diǎn)和采集(比如監(jiān)控線程池或者接口性能)，Zabbix 沒有提供對(duì)應(yīng)的 SDK，通過插件式的腳本也能曲線實(shí)現(xiàn)此功能，個(gè)人感覺 Zabbix 就不是做這個(gè)事的。
• 數(shù)據(jù)模型不強(qiáng)大：不支持 Tag，因此沒法按多維度進(jìn)行聚合統(tǒng)計(jì)和告警配置，使用起來不靈活。
• 方便二次開發(fā)難度大：Zabbix 采用的是 C 語(yǔ)言，二次開發(fā)往往需要熟悉它的數(shù)據(jù)表結(jié)構(gòu)，基于它提供的 API 更多只能做展示層的定制。

Open-Falcon(小米出品，國(guó)內(nèi)流行)

Open-falcon 是小米 2015 年開源的企業(yè)級(jí)監(jiān)控工具，采用 Go 和 Python 語(yǔ)言開發(fā)，這是一款靈活、高性能且易擴(kuò)展的新一代監(jiān)控方案，目前小米、美團(tuán)、滴滴等超過 200 家公司在使用它。

 

小米初期也使用的 Zabbix 進(jìn)行監(jiān)控，但是機(jī)器量和業(yè)務(wù)量上來后，Zabbix 就有些力不從心了。

因此，后來自主研發(fā)了 Open-Falcon，在架構(gòu)設(shè)計(jì)上吸取了 Zabbix 的經(jīng)驗(yàn)，同時(shí)很好地解決了 Zabbix 的諸多痛點(diǎn)。

先來了解下 Open-Falcon 的架構(gòu)設(shè)計(jì)：

Open-Falcon 架構(gòu)圖如上：

 

• Falcon-agent：數(shù)據(jù)采集器和收集器，Go 開發(fā)，部署在被監(jiān)控的機(jī)器上，支持3種數(shù)據(jù)采集方式。
• 首先它能自動(dòng)采集單機(jī) 200 多個(gè)基礎(chǔ)監(jiān)控指標(biāo)，無需做任何配置;同時(shí)支持用戶自定義的 Plugin 獲取監(jiān)控?cái)?shù)據(jù);此外，用戶可通過 HTTP 接口，自主 Push 數(shù)據(jù)到本機(jī)的 proxy-gateway，由 Gateway 轉(zhuǎn)發(fā)到 Server。
• Transfer：數(shù)據(jù)分發(fā)組件，接收客戶端發(fā)送的數(shù)據(jù)，分別發(fā)送給數(shù)據(jù)存儲(chǔ)組件 Graph 和告警判定組件 Judge，Graph 和 Judge 均采用一致性 Hash 做數(shù)據(jù)分片，以提高橫向擴(kuò)展能力。同時(shí) Transfer 還支持將數(shù)據(jù)分發(fā)到 OpenTSDB，用于歷史歸檔。
• Graph：數(shù)據(jù)存儲(chǔ)組件，底層使用 RRDTool(時(shí)序數(shù)據(jù)庫(kù))做單個(gè)指標(biāo)的存儲(chǔ)，并通過緩存、分批寫入磁盤等方式進(jìn)行了優(yōu)化。據(jù)說一個(gè) Graph 實(shí)例能夠處理 8W+ 每秒的寫入速率。
• Judge 和 Alarm：告警組件，Judge 對(duì) Transfer 組件上報(bào)的數(shù)據(jù)進(jìn)行實(shí)時(shí)計(jì)算，判斷是否要產(chǎn)生告警事件，Alarm 組件對(duì)告警事件進(jìn)行收斂處理后，將告警消息推送給各個(gè)消息通道。
• API：面向終端用戶，收到查詢請(qǐng)求后會(huì)去 Graph 中查詢指標(biāo)數(shù)據(jù)，匯總結(jié)果后統(tǒng)一返回給用戶，屏蔽了存儲(chǔ)集群的分片細(xì)節(jié)。

下面是 Open-Falcon 的優(yōu)勢(shì)：

• 自動(dòng)采集能力：Falcon-agent 能自動(dòng)采集服務(wù)器的 200 多個(gè)基礎(chǔ)指標(biāo)(比如 CPU、內(nèi)存等)，無需在 Server 上做任何配置，這一點(diǎn)可以秒殺 Zabbix。
• 強(qiáng)大的存儲(chǔ)能力：底層采用 RRDTool，并且通過一致性 Hash 進(jìn)行數(shù)據(jù)分片，構(gòu)建了一個(gè)分布式的時(shí)序數(shù)據(jù)存儲(chǔ)系統(tǒng)，可擴(kuò)展性強(qiáng)。
• 靈活的數(shù)據(jù)模型：借鑒 OpenTSDB，數(shù)據(jù)模型中引入了 Tag，這樣能支持多維度的聚合統(tǒng)計(jì)以及告警規(guī)則設(shè)置，大大提高了使用效率。
• 插件統(tǒng)一管理：Open-Falcon 的插件機(jī)制實(shí)現(xiàn)了對(duì)用戶自定義腳本的統(tǒng)一化管理，可通過 HeartBeat Server 分發(fā)給 Agent，減輕了使用者自主維護(hù)腳本的成本。
• 個(gè)性化監(jiān)控支持：基于 Proxy-gateway，很容易通過自主埋點(diǎn)實(shí)現(xiàn)應(yīng)用層的監(jiān)控(比如監(jiān)控接口的訪問量和耗時(shí))和其他個(gè)性化監(jiān)控需求，集成方便。

下面是 Open-Falcon 的劣勢(shì)：

• 整體發(fā)展一般：社區(qū)活躍度不算高，同時(shí)版本更新慢，有些大廠是基于它的穩(wěn)定版本直接做二次開發(fā)的，關(guān)于以后的前景其實(shí)有點(diǎn)擔(dān)憂。
• UI 不夠友好：對(duì)于業(yè)務(wù)線的研發(fā)來說，可能只想便捷地完成告警配置和業(yè)務(wù)監(jiān)控，但是它把機(jī)器分組、策略模板、模板繼承等概念全部暴露在 UI 上，感覺在圍繞這幾個(gè)概念設(shè)計(jì) UI，理解有點(diǎn)費(fèi)勁。
• 安裝比較復(fù)雜：個(gè)人的親身感受，由于它是從小米內(nèi)部衍生出來的，雖然去掉了對(duì)小米內(nèi)部系統(tǒng)的依賴，但是組件還是比較多，如果對(duì)整個(gè)架構(gòu)不熟悉，安裝很難一蹴而就。

Prometheus(號(hào)稱下一代監(jiān)控系統(tǒng))

Prometheus(普羅米修斯)是由前 Google 員工 2015 年正式發(fā)布的開源監(jiān)控系統(tǒng)，采用 Go 語(yǔ)言開發(fā)。

 

它不僅有一個(gè)很酷的名字，同時(shí)它有 Google 與 K8s 的強(qiáng)力支持，開源社區(qū)異?；鸨?。

Prometheus 于 2016 年加入云原生基金會(huì)，是繼 K8s 后托管的第二個(gè)項(xiàng)目，未來前景被相當(dāng)看好。

它和 Open-Falcon 最大不同在于：數(shù)據(jù)采集是基于 Pull 模式的，而不是 Push 模式，并且架構(gòu)非常簡(jiǎn)單。

先來了解下 Prometheus 的架構(gòu)設(shè)計(jì)：

 

Prometheus 架構(gòu)圖如上：

• Prometheus Server：核心組件，用于收集、存儲(chǔ)監(jiān)控?cái)?shù)據(jù)。它同時(shí)支持靜態(tài)配置和通過 Service Discovery 動(dòng)態(tài)發(fā)現(xiàn)來管理監(jiān)控目標(biāo)，并從監(jiān)控目標(biāo)中獲取數(shù)據(jù)。

此外，Prometheus Server 也是一個(gè)時(shí)序數(shù)據(jù)庫(kù)，它將監(jiān)控?cái)?shù)據(jù)保存在本地磁盤中，并對(duì)外提供自定義的 PromQL 語(yǔ)言實(shí)現(xiàn)對(duì)數(shù)據(jù)的查詢和分析。

• Exporter：用來采集數(shù)據(jù)，作用類似于 Agent，區(qū)別在于 Prometheus 是基于 Pull 方式拉取采集數(shù)據(jù)的。

因此，Exporter 通過 HTTP 服務(wù)的形式將監(jiān)控?cái)?shù)據(jù)按照標(biāo)準(zhǔn)格式暴露給 Prometheus Server，社區(qū)中已經(jīng)有大量現(xiàn)成的 Exporter 可以直接使用，用戶也可以使用各種語(yǔ)言的 client library 自定義實(shí)現(xiàn)。

• Push gateway：主要用于瞬時(shí)任務(wù)的場(chǎng)景，防止 Prometheus Server 來 Pull 數(shù)據(jù)之前此類 Short-lived jobs 就已經(jīng)執(zhí)行完畢了，因此 Job 可以采用 Push 的方式將監(jiān)控?cái)?shù)據(jù)主動(dòng)匯報(bào)給 Push gateway 緩存起來進(jìn)行中轉(zhuǎn)。
• Alert Manager：當(dāng)告警產(chǎn)生時(shí)，Prometheus Server 將告警信息推送給 Alert Manager，由它發(fā)送告警信息給接收方。
• Web UI：Prometheus 內(nèi)置了一個(gè)簡(jiǎn)單的 Web 控制臺(tái)，可以查詢配置信息和指標(biāo)等，而實(shí)際應(yīng)用中我們通常會(huì)將 Prometheus 作為 Grafana 的數(shù)據(jù)源，創(chuàng)建儀表盤以及查看指標(biāo)。

下面是 Prometheus 的優(yōu)勢(shì)：

• 輕量管理：架構(gòu)簡(jiǎn)單，不依賴外部存儲(chǔ)，單個(gè)服務(wù)器節(jié)點(diǎn)可直接工作，二進(jìn)制文件啟動(dòng)即可，屬于輕量級(jí)的 Server，便于遷移和維護(hù)。
• 較強(qiáng)的處理能力：監(jiān)控?cái)?shù)據(jù)直接存儲(chǔ)在 Prometheus Server 本地的時(shí)序數(shù)據(jù)庫(kù)中，單個(gè)實(shí)例可以處理數(shù)百萬的 Metrics。
• 靈活的數(shù)據(jù)模型：同 Open-Falcon，引入了 Tag，屬于多維數(shù)據(jù)模型，聚合統(tǒng)計(jì)更方便。
• 強(qiáng)大的查詢語(yǔ)句：PromQL 允許在同一個(gè)查詢語(yǔ)句中，對(duì)多個(gè) Metrics 進(jìn)行加法、連接和取分位值等操作。
• 很好地支持云環(huán)境：能自動(dòng)發(fā)現(xiàn)容器，同時(shí) K8s 和 Etcd 等項(xiàng)目都提供了對(duì) Prometheus 的原生支持，是目前容器監(jiān)控最流行的方案。

下面是 Prometheus 的劣勢(shì)：

• 功能不夠完善：Prometheus 從一開始的架構(gòu)設(shè)計(jì)就是要做到簡(jiǎn)單，不提供集群化方案，長(zhǎng)期的持久化存儲(chǔ)和用戶管理，而這些是企業(yè)變大后所必須的特性，目前要做到這些只能在 Prometheus 之上進(jìn)行擴(kuò)展。
• 網(wǎng)絡(luò)規(guī)劃變復(fù)雜：由于 Prometheus 采用的是 Pull 模型拉取數(shù)據(jù)，意味著所有被監(jiān)控的 Endpoint 必須是可達(dá)的，需要合理規(guī)劃網(wǎng)絡(luò)的安全配置。

監(jiān)控系統(tǒng)的選型建議

通過上面的介紹，大家對(duì)主流的監(jiān)控系統(tǒng)應(yīng)該有了一定的認(rèn)識(shí)。

面對(duì)選型問題，我的建議是：

• 先明確清楚你的監(jiān)控需求：要監(jiān)控的對(duì)象有哪些?機(jī)器數(shù)量和監(jiān)控指標(biāo)有多少?需要具備什么樣的告警功能?
• 監(jiān)控是一項(xiàng)長(zhǎng)期建設(shè)的事情，一開始就想做一個(gè) All In One 的監(jiān)控解決方案，我覺得沒有必要。從成本角度考慮，在初期直接使用開源的監(jiān)控方案即可，先解決有無問題。
• 從系統(tǒng)成熟度上看，Zabbix 屬于老牌的監(jiān)控系統(tǒng)，資料多，功能全面且穩(wěn)定，如果機(jī)器數(shù)量在幾百臺(tái)以內(nèi)，不用太擔(dān)心性能問題，另外，采用數(shù)據(jù)庫(kù)分區(qū)、SSD 硬盤、Proxy 架構(gòu)、Push 采集模式都可以提高監(jiān)控性能。
• Zabbix 在服務(wù)器監(jiān)控方面占絕對(duì)優(yōu)勢(shì)，可以滿足 90% 以上的監(jiān)控場(chǎng)景，但是應(yīng)用層的監(jiān)控似乎并不擅長(zhǎng)，比如要監(jiān)控線程池的狀態(tài)、某個(gè)內(nèi)部接口的執(zhí)行時(shí)間等，這種通常都要做侵入式埋點(diǎn)。相反，新一代的監(jiān)控系統(tǒng) Open-Falcon 和 Prometheus 在這一點(diǎn)做得很好。
• 從整體表現(xiàn)上來看，新一代監(jiān)控系統(tǒng)也有明顯的優(yōu)勢(shì)，比如：靈活的數(shù)據(jù)模型、更成熟的時(shí)序數(shù)據(jù)庫(kù)、強(qiáng)大的告警功能，如果之前對(duì) Zabbix 這種傳統(tǒng)監(jiān)控沒有技術(shù)積累，建議使用 Open-Falcon 或者 Prometheus。
• Open-Falcon 的核心優(yōu)勢(shì)在于數(shù)據(jù)分片功能，能支撐更多的機(jī)器和監(jiān)控項(xiàng);Prometheus 則是容器監(jiān)控方面的標(biāo)配，有 Google 和 K8s 加持。
• Zabbix、Open-Falcon 和 Prometheus 都支持和 Grafana 做快速集成，想要美觀且強(qiáng)大的可視化體驗(yàn)，可以和 Grafana 進(jìn)行組合。
• 用合適的監(jiān)控系統(tǒng)解決相應(yīng)的問題即可，可以多套監(jiān)控同時(shí)使用，這種在企業(yè)初期很常見。
• 到中后期，隨著機(jī)器數(shù)據(jù)增加和個(gè)性化需求增多(比如希望統(tǒng)一監(jiān)控平臺(tái)、打通公司的 CMDB 和組織架構(gòu)關(guān)系)，往往需要二次開發(fā)或者通過監(jiān)控系統(tǒng)提供的 API 做集成，從這點(diǎn)來看，Open-Falcon 或者 Prometheus 更合適。
• 如果非要自研，可以多研究下主流監(jiān)控系統(tǒng)的架構(gòu)方案，借鑒它們的優(yōu)勢(shì)。

最后的話

本文對(duì)監(jiān)控體系的基礎(chǔ)知識(shí)、原理和主流架構(gòu)做了詳細(xì)梳理，希望有助于大家對(duì)監(jiān)控系統(tǒng)的認(rèn)識(shí)，以及在技術(shù)選型時(shí)做出更合適的選擇。

由于篇幅問題，本文的內(nèi)容并未涉及到全鏈路監(jiān)控、日志監(jiān)控、以及 Web 前端和客戶端的監(jiān)控，可見監(jiān)控真的是一個(gè)龐大且復(fù)雜的體系，如果想理解透徹，必須理論結(jié)合實(shí)踐再做深入。

 

對(duì)于運(yùn)維監(jiān)控體系，如果你們也有自己的經(jīng)驗(yàn)和體會(huì)，歡迎留言討論。

作者：駱俊武

簡(jiǎn)介：前亞馬遜工程師，現(xiàn) 58 轉(zhuǎn)轉(zhuǎn)技術(shù)總監(jiān)，持續(xù)分享個(gè)人的成長(zhǎng)經(jīng)歷，希望為你的職場(chǎng)發(fā)展帶來些新思路。

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號(hào) IT 人的職場(chǎng)進(jìn)階