• 先看監(jiān)控的需求來源，即監(jiān)控系統(tǒng)可做什么
• 再跳出監(jiān)控，從可觀測性，看監(jiān)控與日志、鏈路間的關(guān)系及它們各自的作用
• 最后介紹開源社區(qū)幾個有代表性的方案以及它們各自的優(yōu)缺點(diǎn)，便于你之后做技術(shù)選型。

1 監(jiān)控需求來源

系統(tǒng)出問題我們能及時感知。隨時代發(fā)展，對監(jiān)控系統(tǒng)提出更多訴求：

• 通過監(jiān)控了解數(shù)據(jù)趨勢，知道系統(tǒng)在未來的某個時刻可能出問題，預(yù)知問題
• 通過監(jiān)控了解系統(tǒng)的水位情況，為服務(wù)擴(kuò)縮容提供數(shù)據(jù)支撐
• 通過監(jiān)控來給系統(tǒng)把脈，感知到哪里需要優(yōu)化，比如一些中間件參數(shù)的調(diào)優(yōu)
• 通過監(jiān)控來洞察業(yè)務(wù)，提供業(yè)務(wù)決策的數(shù)據(jù)依據(jù)，及時感知業(yè)務(wù)異常

目前監(jiān)控系統(tǒng)越來越重要，同時也越來越完備。不但能很好地解決上面這幾點(diǎn)訴求，還沉淀很多監(jiān)控系統(tǒng)中的穩(wěn)定性相關(guān)的知識。當(dāng)然，這得益于對監(jiān)控體系的持續(xù)運(yùn)營，特別是一些資深工程師的持續(xù)運(yùn)營的成果。

2 可觀測性三大支柱

監(jiān)控系統(tǒng)，其實(shí)只是指標(biāo)監(jiān)控，通常使用折線圖形態(tài)呈現(xiàn)在圖表上，如某機(jī)器的CPU利用率、某個數(shù)據(jù)庫實(shí)例的流量或者網(wǎng)站的在線人數(shù)，都可體現(xiàn)為隨著時間而變化的趨勢圖。

指標(biāo)監(jiān)控 只能處理數(shù)字，但它的歷史數(shù)據(jù)存儲成本較低，實(shí)時性好，生態(tài)龐大，是可觀測性領(lǐng)域里最重要的一根支柱。聚焦在指標(biāo)監(jiān)控領(lǐng)域的開源產(chǎn)品有Zabbix、Open-Falcon、Prometheus、Nightingale等。

除了指標(biāo)監(jiān)控，另一個重要的可觀測性支柱是 日志。從日志中可以得到很多信息，對于了解軟件的運(yùn)行情況、業(yè)務(wù)的運(yùn)營情況都很關(guān)鍵。比如操作系統(tǒng)的日志、接入層的日志、服務(wù)運(yùn)行日志，都是重要的數(shù)據(jù)源。

從操作系統(tǒng)的日志中，可以得知很多系統(tǒng)級事件的發(fā)生；從接入層的日志中，可以得知有哪些域名、IP、URL 收到了訪問，是否成功以及延遲情況等；從服務(wù)日志中可以查到 Exception 的信息，調(diào)用堆棧等，對于排查問題來說非常關(guān)鍵。但是日志數(shù)據(jù)通常量比較大，不夠結(jié)構(gòu)化，存儲成本較高。

處理日志這個場景，也有很多專門的系統(tǒng)，比如開源產(chǎn)品ELK和Loki，商業(yè)產(chǎn)品Splunk和Datadog，下面是在 Kibana 中查詢?nèi)罩镜囊粋€頁面。

可觀測性最后一大支柱 鏈路追蹤。微服務(wù)一個問題具體是哪個模塊導(dǎo)致的，排查非常困難。

鏈路追蹤思路

以請求串聯(lián)上下游模塊，為每個請求生成一個隨機(jī)字符串作為請求ID。服務(wù)之間互相調(diào)用時，把該ID逐層往下傳遞，每層分別耗費(fèi)多久，是否正常處理，都可收集附到該請求ID。后面追查問題時，拿著請求ID就可將串聯(lián)的所有信息提取。鏈路追蹤這個領(lǐng)域也有很多產(chǎn)品，如 Skywalking、Jaeger、Zipkin都是翹楚。

雖把可觀測性領(lǐng)域劃分3大支柱，但它們之間有很強(qiáng)關(guān)聯(lián)關(guān)系。如經(jīng)常會從日志提取指標(biāo)，轉(zhuǎn)存到指標(biāo)監(jiān)控系統(tǒng)，或者從日志中提取鏈路信息來做分析，業(yè)界都有實(shí)踐。

本專欄聚焦指標(biāo)監(jiān)控領(lǐng)域，把這領(lǐng)域講透，助你在工作中快速落地實(shí)踐。

3 解決方案橫評

了解業(yè)界方案優(yōu)缺點(diǎn)，對選型有大助。這里主要評價開源方案。

3.1 老代整體方案代表Zabbix

企業(yè)級開源解決方案，擅長設(shè)備、網(wǎng)絡(luò)、中間件監(jiān)控。因?yàn)榍皫啄晔褂帽O(jiān)控系統(tǒng)主要就是用來監(jiān)控設(shè)備和中間件，所以Zabbix在國內(nèi)應(yīng)用非常廣泛。

核心構(gòu)成

Zabbix Server與可選組件Zabbix Agent。Zabbix Server可通過SNMP、Zabbix Agent、JMX、IPMI等多種方式采集數(shù)據(jù)，它可以運(yùn)行在Linux、Solaris、HP-UX、AIX、Free BSD、Open BSD、OS X等平臺。

配套組件，Zabbix Proxy、Zabbix Java Gateway、Zabbix Get、Zabbix WEB等，共同組成Zabbix整體架構(gòu)：

優(yōu)點(diǎn)

• 對各種設(shè)備的兼容性較好，Agentd不但可以在Windows、Linux上運(yùn)行，也可在Aix運(yùn)行
• 架構(gòu)簡單，使用數(shù)據(jù)庫做時序數(shù)據(jù)存儲，易于維護(hù)，備份和轉(zhuǎn)儲都較易
• 社區(qū)龐大，資料多。Zabbix大概是2012年開源的，因?yàn)榘l(fā)展的時間比較久，在網(wǎng)上可以找到海量資源

缺點(diǎn)

• 使用數(shù)據(jù)庫做存儲，無法水平擴(kuò)展，容量有限。如采集頻率較高，比如10秒采集一次，上限大約可監(jiān)控600臺設(shè)備，還要把數(shù)據(jù)庫部署在一個高配機(jī)器，如SSD或NVMe的盤
• Zabbix面向資產(chǎn)的管理邏輯，監(jiān)控指標(biāo)的數(shù)據(jù)結(jié)構(gòu)較為固化，沒有靈活的標(biāo)簽設(shè)計(jì)，面對云原生架構(gòu)下動態(tài)多變的環(huán)境，顯得力不從心

老國產(chǎn)代表 Open-Falcon

Open-Falcon在Zabbix后，開發(fā)初衷就是解決Zabbix容量問題。Open-Falcon最初來自小米，14年開源，當(dāng)時小米有3套Zabbix，1套業(yè)務(wù)性能監(jiān)控系統(tǒng)perfcounter。Open-Falcon初衷想做大一統(tǒng)方案，來解決這亂局。Open-Falcon架構(gòu)圖：

Open-Falcon基于RRDtool做了一個分布式時序存儲組件Graph。這可將多臺機(jī)器組成一個集群，大幅提升海量數(shù)據(jù)處理能力。前面負(fù)責(zé)轉(zhuǎn)發(fā)的組件是Transfer，Transfer對監(jiān)控數(shù)據(jù)求取一個唯一ID，再對ID做哈希，就可生成監(jiān)控數(shù)據(jù)和Graph實(shí)例的對應(yīng)關(guān)系，這就是Open-Falcon架構(gòu)中最核心的分片邏輯。

告警部分用Judge模塊，發(fā)送告警事件Alarm模塊，采集數(shù)據(jù)Agent，心跳模塊HBS，聚合監(jiān)控數(shù)據(jù)的模塊是Aggregator，負(fù)責(zé)處理數(shù)據(jù)缺失的模塊是Nodata。和用戶交互的Portal/Dashboard模塊。

Open-Falcon把組件拆散，組件較多，部署較麻煩。不過每個組件的職能單一，二次開發(fā)較容易，很多互聯(lián)網(wǎng)公司都是基于Open-Falcon二開，如美團(tuán)、快網(wǎng)、360、金山云、新浪微博、愛奇藝、京東、SEA等。

優(yōu)點(diǎn)

• 可以處理大規(guī)模監(jiān)控場景，比Zabbix的容量要大得多，不僅可以處理設(shè)備、中間件層面的監(jiān)控，也可以處理應(yīng)用層面的監(jiān)控，最終替換掉了小米內(nèi)部的perfcounter和三套Zabbix。
• 組件拆分得比較散，大都是用Go語言開發(fā)的，Web部分是用Python，易于做二次開發(fā)。

缺點(diǎn)

• 生態(tài)不大，是小米公司在主導(dǎo)，很多公司二開，但都沒回饋社區(qū)，貢獻(xiàn)者數(shù)量較少
• 開源軟件治理架構(gòu)不夠優(yōu)秀，小米公司核心開發(fā)人員離職，項(xiàng)目就停滯，小米公司后續(xù)也沒有大的治理投入，相比托管在基金會的項(xiàng)目，缺少生命力

新一代整體方案代表 Prometheus

Prometheus設(shè)計(jì)思路來自Google的Borgmon，師出名門，就像Borgmon為Borg而生，Prometheus就是為Kubernetes而生。它針對Kubernetes直接支持，提供多種服務(wù)發(fā)現(xiàn)機(jī)制，大幅簡化Kubernetes的監(jiān)控。

在Kubernetes環(huán)境下，Pod創(chuàng)建和銷毀非常頻繁，監(jiān)控指標(biāo)生命周期大幅縮短，導(dǎo)致類似Zabbix這種面向資產(chǎn)的監(jiān)控系統(tǒng)力不從心，而且云原生環(huán)境下大都是微服務(wù)設(shè)計(jì)，服務(wù)數(shù)量變多，指標(biāo)量也呈爆炸態(tài)勢，對時序數(shù)據(jù)存儲提出高要求。

Prometheus 1.0設(shè)計(jì)較差，但2.0重新設(shè)計(jì)時序庫，性能、可靠性都大幅提升，社區(qū)涌現(xiàn)越來越多的Exporter采集器，非常繁榮。

Prometheus架構(gòu)圖：

Prometheus優(yōu)點(diǎn)：

• 對Kubernetes支持很好，目前看，Prometheus就是Kubernetes監(jiān)控標(biāo)配
• 生態(tài)龐大，有各種各樣Exporter，支持各種時序庫作為后端存儲，也很好支持多種不同語言SDK，供業(yè)務(wù)代碼嵌入埋點(diǎn)

缺點(diǎn)

• 易用性差些，如告警策略需要修改配置文件，協(xié)同起來比較麻煩。當(dāng)然了，對于IaC落地較好的公司，反而認(rèn)為這樣更好，不過在國內(nèi)當(dāng)下的環(huán)境來看，還無法走得這么靠前，大家還是更喜歡用Web界面來查看監(jiān)控數(shù)據(jù)、管理告警規(guī)則。
• Exporter參差不齊，通常是一個監(jiān)控目標(biāo)一個Exporter，管理起來成本比較高。
• 容量問題，Prometheus默認(rèn)只提供單機(jī)時序庫，集群方案需要依賴其他的時序庫。

新一代國產(chǎn)代表 Nightingale

Nightingale 可看做 Open-Falcon 的一個延續(xù)，因?yàn)殚_發(fā)人員是一撥人，不過兩個軟件的定位截然不同，Open-Falcon 類似 Zabbix，更多的是面向機(jī)器設(shè)備，而Nightingale 不止解決設(shè)備和中間件的監(jiān)控，也希望能一并解決云原生環(huán)境下的監(jiān)控問題。

但 Kubernetes 環(huán)境下，Prometheus 已大行其道，再重復(fù)造輪意義不大，所以 Nightingale 是和 Prometheus 做良好的整合，打造更完備方案。當(dāng)下的架構(gòu)，主要是把 Prometheus 當(dāng)成一個時序庫，作為 Nightingale 的一個數(shù)據(jù)源。如果不使用 Prometheus 也沒問題，如用 VictoriaMetrics 時序庫。

優(yōu)點(diǎn)

• 有比較完備的UI，有權(quán)限控制，產(chǎn)品功能比較完備，可以作為公司級統(tǒng)一的監(jiān)控產(chǎn)品讓所有團(tuán)隊(duì)共同使用。Prometheus一般是每個團(tuán)隊(duì)自己用自己的，比較方便。如果一個公司用同一套Prometheus系統(tǒng)來解決監(jiān)控需求會比較麻煩，容易出現(xiàn)我們上面說的協(xié)同問題，而Nightingale在協(xié)同方面做得相對好一些。
• 兼容并包，設(shè)計(jì)上比較開放，支持對接 Categraf、Telegraf、Grafana-Agent、Datadog-Agent 等采集器，還有Prometheus生態(tài)的各種Exporter，時序庫支持對接 Prometheus、VictoriaMetrics、M3DB、Thanos 等。

缺點(diǎn)

• 考慮到機(jī)房網(wǎng)絡(luò)割裂問題，告警引擎單獨(dú)拆出一個模塊下沉部署到各機(jī)房，但很多中小公司無需這么復(fù)雜架構(gòu)，部署維護(hù)起來較麻煩
• 告警事件發(fā)送缺少聚合降噪收斂邏輯，官方解釋是未來會單獨(dú)做一個事件中心的產(chǎn)品，支持Nightingale、Zabbix、Prometheus等多種數(shù)據(jù)源的告警事件，但目前還沒放出

如主要需求是監(jiān)控設(shè)備，推薦Zabbix；如主要需求是監(jiān)控Kubernetes，可選Prometheus+Grafana；如既兼顧傳統(tǒng)設(shè)備、中間件監(jiān)控場景，又兼顧Kubernetes做成公司級方案，推薦Nightingale。

4 總結(jié)

監(jiān)控產(chǎn)品的需求來源，即監(jiān)控問題域，從及時感知系統(tǒng)出現(xiàn)的問題，到現(xiàn)在希望預(yù)知問題，并可洞察業(yè)務(wù)經(jīng)營數(shù)據(jù)，越來越多訴求讓我們意識到監(jiān)控重要性。

指標(biāo)監(jiān)控是可觀測性三大支柱產(chǎn)品之一，日志監(jiān)控和鏈路追蹤三者聯(lián)系緊密，共同輔助我們衡量系統(tǒng)內(nèi)外部健康狀況。指標(biāo)監(jiān)控因歷史數(shù)據(jù)存儲成本較低，實(shí)時性好，生態(tài)龐大，是可觀測性領(lǐng)域里最重要的一根支柱，也是我們關(guān)注的重點(diǎn)。

最后對指標(biāo)監(jiān)控領(lǐng)域的多個開源解決方案橫評對比，助技術(shù)方案選型。針對指標(biāo)監(jiān)控的幾個開源方案的優(yōu)缺點(diǎn)比較思維導(dǎo)圖：

關(guān)注我，緊跟本系列專欄文章，咱們下篇再續(xù)！

作者簡介：魔都國企技術(shù)專家兼架構(gòu)，多家大廠后臺研發(fā)和架構(gòu)經(jīng)驗(yàn)，負(fù)責(zé)復(fù)雜度極高業(yè)務(wù)系統(tǒng)的模塊化、服務(wù)化、平臺化研發(fā)工作。具有豐富帶團(tuán)隊(duì)經(jīng)驗(yàn)，深厚人才識別和培養(yǎng)的積累。

參考：文章來源地址http://www.zghlxwxcb.cn/news/detail-813912.html

• 編程嚴(yán)選網(wǎng)

到了這里，關(guān)于監(jiān)控場景及開源監(jiān)控方案選型的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！