對于監(jiān)控報警這一塊內(nèi)容我想過很多次要從哪個方面講，因為監(jiān)控報警在現(xiàn)在已經(jīng)是互聯(lián)網(wǎng)公司一個通用的產(chǎn)品。

而大數(shù)據(jù)的監(jiān)控報警只是其中的一系列報警規(guī)則子集，雖然這個子集很復(fù)雜。

有趣的是，報警系統(tǒng)的下層數(shù)據(jù)存儲引擎，也是歸類于大數(shù)據(jù)存儲的范疇。所以我打算從這樣的大綱來展開本文：

• 針對大數(shù)據(jù)集群，監(jiān)控報警的特點
• 監(jiān)控報警系統(tǒng)發(fā)展的歷史及業(yè)務(wù)背景
• 監(jiān)控報警系統(tǒng)的通用架構(gòu)
• 監(jiān)控報警系統(tǒng)細節(jié)分析
• 總結(jié)

針對大數(shù)據(jù)集群，監(jiān)控報警的特點

圖 1：針對大數(shù)據(jù)集群的不同特性，監(jiān)控報警的特點

像大數(shù)據(jù)基礎(chǔ)設(shè)施這種部門，不可能配制專門的測試工程師，那么這么多的機器、服務(wù)以及應(yīng)用要如何很好地運轉(zhuǎn)下去呢？

這就需要一套強大的“自動化監(jiān)控報警系統(tǒng)”。監(jiān)控報警這一塊，不同的公司應(yīng)對方案是不同的。

對于大公司、小公司、創(chuàng)業(yè)公司，它們根據(jù)自己的實際情況選擇對于自己合理的解決方案。

監(jiān)控報警系統(tǒng)發(fā)展歷史及業(yè)務(wù)背景

市面上的監(jiān)控報警系統(tǒng)多種多樣，但越是眼花繚亂的市場，越要睜大眼睛，看其本質(zhì)，剝其筋骨，找一款適合自己的解決方案。

網(wǎng)上有很多講述公司內(nèi)部監(jiān)控報警系統(tǒng)的文章，都提到了自家監(jiān)控系統(tǒng)的實現(xiàn)，但都是直接講解了實現(xiàn)的細節(jié)，沒有講骨架、背景。

我感覺對于新入行的程序員來說會略顯生硬，對于想了解監(jiān)控報警系統(tǒng)內(nèi)部運作原理的人來說，架構(gòu)邏輯也不夠清晰。所以，我寫了這篇既講背景，又講骨架的文章。

首先是背景，我們先來談?wù)勡浖こ獭Ｔ诤茉缫郧?，軟件開發(fā)的技術(shù)團隊在做迭代開發(fā)時，一般是要經(jīng)歷這樣的開發(fā)流程：

• 需求分析
• 原型／功能設(shè)計
• 測試用例設(shè)計（Tdd 測試驅(qū)動的開發(fā)）
• 開發(fā)人員完成功能，部署測試環(huán)境 
• 測試按照測試用例做測試 
• 如果在測試時，發(fā)現(xiàn) Bug，則回滾給開發(fā)重新 Fix
• 如果測試沒測試出 Bug，則上線生產(chǎn)環(huán)境
• 等線上真正有用戶發(fā)現(xiàn)了 Bug，好心的用戶會匯報 Bug，聯(lián)系客服人員

這種流程會導(dǎo)致什么問題呢？一般簡單的“顯式”Bug，比如“網(wǎng)站關(guān)鍵頁面打不開了”、“網(wǎng)站下單支付功能一直失敗”等等這類錯誤。

用戶和公司都能在相對的一段時間內(nèi)發(fā)現(xiàn)問題，然后問題被重新整理報修為 Bug，修復(fù)、回滾。

而一些“隱式”Bug，比如“網(wǎng)站越來越慢了”、“支付功能要 30 秒才能成功”、“有時成功，有時失敗”、“短信驗證碼在產(chǎn)品上線了一周后，變得要 25 秒才能發(fā)送到客戶手機上”。 

這類問題，有時并不影響業(yè)務(wù)邏輯的正常運轉(zhuǎn)，但系統(tǒng)內(nèi)部肯定是已經(jīng)出現(xiàn)問題了。

有時長期積累下去，會慢慢暴露出更多問題，最后導(dǎo)致核心業(yè)務(wù)的宕機；有時甚至就是產(chǎn)品性能上線后本身就很差，由于某次上線的“代碼/配置”變更導(dǎo)致。這種“隱式”的 Bug 也會影響用戶體驗。

測試發(fā)現(xiàn)顯式 Bug，what abou the 隱式 Bug？隨著互聯(lián)網(wǎng)的發(fā)展，各大互聯(lián)網(wǎng)公司對業(yè)務(wù)穩(wěn)定、可靠性的要求越來越高。

但公司的業(yè)務(wù)線是越來越多的，測試工程師不可能人肉去干無窮盡的手工測試，每天 24 小時一直盯著產(chǎn)品。

作為公司，更是希望這種隱式的 Bug 不要由用戶報告出來，最好是在內(nèi)部 “快速”發(fā)現(xiàn)問題、“自動”發(fā)現(xiàn)問題、要比“用戶”早發(fā)現(xiàn)問題。這就逼迫開創(chuàng)了了“自動化周期性線上測試”。

“早期的自動化測試”，只發(fā)生在軟件上線之前。比如開發(fā)提交了新的功能之后，公司內(nèi)會有 Jenkins 這種持續(xù)集成工具自動觸發(fā)去跑測試用例。

用例包括開發(fā)人員的“單元（白盒）測試”，以及測試人員寫的“腳本（黑盒）測試”。要求全部通過之后，方能部署到“生產(chǎn)”環(huán)境。

這種方式，能發(fā)現(xiàn)大部分的“顯示”Bug，但是很難發(fā)現(xiàn)“隱式”Bug。倘若有些程序有內(nèi)存泄漏，并不會第一時間馬上崩潰，可能是跑了一個星期，甚至一個月才產(chǎn)生問題。

“自動化周期性線上測試”，解決隱式的 Bug，在產(chǎn)品上線后，持續(xù)地針對線上環(huán)境的多種指標，進行長期觀測，進行規(guī)律判斷來發(fā)現(xiàn)異常。

如果有潛在的異常，那么某些監(jiān)控指標會出現(xiàn)問題。還有一些異常指標在暴露時，如果能第一時間聯(lián)系到對應(yīng)產(chǎn)品的“負責人”，馬上進行補救，從長期來看，對產(chǎn)品的口碑會有一個很大的提升。

比如：一個電商網(wǎng)站的支付頁面，響應(yīng)速度持續(xù)地超過 5s，遠大于長期的平均值（2s），在這種現(xiàn)象連續(xù)出現(xiàn) 5 次時，報警給這一塊的研發(fā)人員，其發(fā)現(xiàn)程序有資源泄漏導(dǎo)致機器變慢，然后先重啟了部分服務(wù)，保證用戶速度提上來，之后馬上組織對此功能進行 Hotfix，最終解決問題。

監(jiān)控報警系統(tǒng)的通用架構(gòu)

之前講了“自動化周期性線上測試”的產(chǎn)生歷史原因及背景?？雌饋恚@是時代的發(fā)展倒逼技術(shù)界而產(chǎn)生的“技術(shù)更替”。

在往后的內(nèi)容，我們把“自動化周期性線上測試”系統(tǒng)，稱為“監(jiān)控報警”系統(tǒng)。因為它代替了人去“監(jiān)控”，代替了測試工程師去“報告問題”。

圖 2：監(jiān)控報警信息流

監(jiān)控報警我認為分為四大塊：

• 收集數(shù)據(jù)
• 存儲數(shù)據(jù)（時間序列的存儲）
• 報警規(guī)則
• 報警行為

下圖監(jiān)控系統(tǒng)是基本骨架，再細化一下，整個架構(gòu)圖會變成下面這個樣子：

圖 3：監(jiān)控報警系統(tǒng)架構(gòu)圖

監(jiān)控報警系統(tǒng)細節(jié)分析

收集數(shù)據(jù)

收集數(shù)據(jù)，我想這篇經(jīng)典的《Measure Anything，Measure Everything》（https://www.tuicool.com/articles/A3AFvu6），是開啟了新時代“數(shù)據(jù)驅(qū)動”的監(jiān)控運維思想的一篇博文，大家可以讀一讀。

這里面講到的思想，也符合我這一系列文章的主旨：讓一切人的決策基于數(shù)據(jù)。

文章中提到，企業(yè)級的監(jiān)控數(shù)據(jù)，通常包括如下三類：

• 網(wǎng)絡(luò)數(shù)據(jù)，包括骨干交換機，核心交換機等硬件設(shè)備。
• 服務(wù)器數(shù)據(jù)，包括服務(wù)器的 CPU、內(nèi)存、硬盤的各項使用數(shù)據(jù)。
• 應(yīng)用數(shù)據(jù)。

應(yīng)用數(shù)據(jù)是這三者中最難的，但也是最重要的。應(yīng)用數(shù)據(jù)是和業(yè)務(wù)邏輯緊密相關(guān)的數(shù)據(jù)，業(yè)務(wù)邏輯變了，應(yīng)用數(shù)據(jù)的收集也會變化。

在應(yīng)用數(shù)據(jù)這一塊，有一個開源項目叫 Statsd，它催生了“應(yīng)用數(shù)據(jù)收集標準” <github-statsd 應(yīng)用數(shù)據(jù)收集標準>。

https://github.com/etsy/statsd/blob/master/docs/metric_types.md

在這里我也簡單提一下：

• 累加值(Counting) gorets：1 | c
• 服務(wù)耗時(Timing) glork：320 | ms | @0.1
• 指標值(Gauges) gaugor：333 | g

字符串的第一部分，就是 "METRIC"，用冒號隔開的左邊是“METRIC_KEY”，右邊是“METRIC_VALUE”，豎線右邊的部分是“數(shù)據(jù)類型”。

存儲數(shù)據(jù)

監(jiān)控報警的數(shù)據(jù)，全部都是圍繞“監(jiān)控指標的值隨時間變化的趨勢”這一目標而設(shè)計的。每一項監(jiān)控指標數(shù)據(jù)序列都是天然的按“時間排序”的，這是其特點。

業(yè)界管存儲這種數(shù)據(jù)結(jié)構(gòu)的工具叫“時間序列數(shù)據(jù)庫”。這是一種專有數(shù)據(jù)庫，并非像 RDBMS（關(guān)系型數(shù)據(jù)庫）是一種通用的 SQL-LIKE 的數(shù)據(jù)庫。

市面上有很多很多的基于時間序列的數(shù)據(jù)庫，不論其底層的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)是什么樣子，時間序列存儲的本質(zhì)數(shù)據(jù)結(jié)構(gòu)永遠都是：

Map< METRIC_KEY , sortedMap<timestamp, METRIC_VALUE >>

不同的底層實現(xiàn)都是在上面這個數(shù)據(jù)結(jié)構(gòu)的一些點上有不同的擴展，比如：

• s1.在 METRIC_KEY 的分片邏輯，實現(xiàn)上不同：選取的分片是一致性哈希，還是求余哈希。
• s2.SortedMap 的實現(xiàn)不同，本質(zhì)上是一個按 Timestamp 排序的序列。
• s3.讀寫的偏好略有不同。

在這里我不會著重去講具體的每一個時間序列的數(shù)據(jù)庫以及其底層數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)。

在技術(shù)選型時既要考慮技術(shù)的痛點，也需要考慮業(yè)務(wù)上的痛點，業(yè)務(wù)場景定下來了，技術(shù)選型才能定。

那么根據(jù)業(yè)務(wù)場景，又有了其他幾個選型點：

• s4.Metrics 是否會無限增加？
• s5.Metrics 保留的時間跨度有多長？
• s6.上層的業(yè)務(wù)報警，有多重要？

為了解決技術(shù)選型 SELECT，s1-s6，我拿一些例子來說明：

Metrics 是否會無限增加，保留時長

專有系統(tǒng)，即解決某一特定領(lǐng)域問題的時間序列存儲，Metric key 不會無限增長。

比如我們管理 Hadoop 的套件 Cloudera-Manager 或 Hortonworks 的 Ambari，都有自帶的監(jiān)控報警系統(tǒng)。

他們都是把數(shù)據(jù)存儲在本地的磁盤上，相當于是一個本地的數(shù)據(jù)庫。單機版數(shù)據(jù)庫的問題就是受單機硬盤的物理上限限制。

好在 Hadoop 技術(shù)棧的監(jiān)控指標是有限的、收斂的，且這些數(shù)據(jù)也大多只需要保留 1 個月。因此“Hadoop 監(jiān)控系統(tǒng)們”的單機存儲空間是可控的。

專有系統(tǒng)，一定是服務(wù)于一個成熟的“內(nèi)聚產(chǎn)品”。通用監(jiān)控報警系統(tǒng)，Metric key 會無限增長。

如《Measure Anything，Measure Everything》提到，公司每個業(yè)務(wù)線 Team 都會把自己的應(yīng)用數(shù)據(jù)發(fā)送到統(tǒng)一的指標數(shù)據(jù)存儲中。

隨著業(yè)務(wù)線、監(jiān)控指標的增長，時間序列存儲的壓力是無限增加的，且數(shù)據(jù)的保留時長不定，很有可能是無限長（每個應(yīng)用都有其特殊性，不可估量）。這就要求底層的數(shù)據(jù)存儲必須支持“無限水平擴展”。

SortedMap 實現(xiàn)和讀寫偏好

SortedMap 即全局排序的映射表，它的實現(xiàn)更要由報警監(jiān)控的實際需求出發(fā)了。

專有系統(tǒng)，由于是有限的指標，且搜集數(shù)據(jù)的頻率也不會特別變態(tài)的高，那么同一時刻寫入的數(shù)據(jù)量應(yīng)該是可控的。此時 B＋Tree、SkipList 都是很好的實現(xiàn)方式。

而通用系統(tǒng)，監(jiān)控指標會無限增加，有些指標采集需求的頻率可達幾十毫秒。這么高頻的并發(fā)寫入需求，一般使用 lSM Tree 來實現(xiàn)。

上層的業(yè)務(wù)報警，有多重要（HA & 高可用性）

任何時候，監(jiān)控報警系統(tǒng)都必須可用，必須可以容忍一部分機器掛掉。其不能因為某臺機器、某個進程掛掉而導(dǎo)致整個監(jiān)控報警體系都宕掉。

SPOF :https://en.wikipedia.org/wiki/Single_point_of_failure

監(jiān)控報警系統(tǒng)是用來“觀測公司內(nèi)部的所有業(yè)務(wù)是否正常運轉(zhuǎn)”的，所有產(chǎn)品的第一時間救命稻草也就都壓在了“監(jiān)控報警”系統(tǒng)上了。

它掛了，公司所有產(chǎn)品出問題都反映不出來了。所以像基于單機版本數(shù)據(jù)存儲的時間序列是不能滿足企業(yè)級要求的。一定要選擇高可用 HA（High Available）的數(shù)據(jù)存儲解決方案。

而對于小型創(chuàng)業(yè)公司，可以在業(yè)務(wù)初期和高速增長前期暫時放棄過高的可靠可用性，先使用諸如“磁盤 Raid、定期備份、做數(shù)據(jù)庫級別的主從切換”等簡單易實施的技術(shù)來快速滿足輕量級的業(yè)務(wù)需求。

最后，附上一些時間序列數(shù)據(jù)庫總結(jié)引用的論文及文章：

wiki : Time series database

https://blog.outlyer.com/top10-open-source-time-series-databases

報警規(guī)則

報警規(guī)則模塊，首先，是天然個性的。為什么呢？按什么規(guī)則報警，顯然是和每個公司的具體業(yè)務(wù)綁定的。

而規(guī)則是基于對歷史數(shù)據(jù)的分析、度量。這牽扯到公司業(yè)務(wù)的個性化，本篇文章對個性化的業(yè)務(wù)細節(jié)不做過多的贅述。

我們看看看報警規(guī)則有哪些通用的技術(shù)點：

High-Available 的規(guī)則周期檢查

企業(yè)級的應(yīng)用，最強調(diào)的就是高可用 HA，必須避免單點故障 SPOF。“報警規(guī)則模塊”發(fā)生問題了，仍然會導(dǎo)致“監(jiān)控報警”系統(tǒng)失效。

一般來說，報警規(guī)則都是周期性觸發(fā)的。因此需要有一個“類Cron Job”的調(diào)度器。

這類調(diào)度系統(tǒng)的 HA 設(shè)計可以參考“Azkaban” 和 “Quartz”：

• Azkaban：https://azkaban.github.io/
• Quartz：http://www.quartz-scheduler.org/

調(diào)度系統(tǒng)的 HA 設(shè)計主要分為“規(guī)則數(shù)據(jù)庫的高可用”和“調(diào)度 Sever 的高可用”兩方面：

• 數(shù)據(jù)庫高可用通過 Master-Slave 的主從實現(xiàn)。
• 調(diào)度 Server 的高可用，如果有狀態(tài)，則使用 zk／etcd 來做高可用；如果無狀態(tài)，那就啟動多個調(diào)度服務(wù)器好了。根據(jù)調(diào)度規(guī)則，制定一定的分片策略，不算困難。

報警規(guī)則定義

在我觀察了一系列的監(jiān)控報警產(chǎn)品后，大致歸納出兩種“報警規(guī)則”的定義實現(xiàn)方式：

• 基于“規(guī)則表達式的”。
• 基于直接“腳本&編程”的。

基于規(guī)則表達式的：在熟悉了表達式語言后，比較容易編寫，但靈活性差。在實現(xiàn)復(fù)雜的報警規(guī)則時比較難，一般適用于簡單的報警規(guī)則。

比如當某一、二個觀測指標到達閾值時觸發(fā)，如下圖：

Prometheus：Alerting rules | Prometheus 

圖 4：Promethus 基于規(guī)則設(shè)定報警的例子

還有基于可視化配置規(guī)則的，比如 Zabbix 的 Trigger 配置：Zabbix Documentation 3.2。

圖 5：Zabbix 的可視化規(guī)則配置

Grafana 在 4.0 之后，也有了基于規(guī)則的簡單報警功能：Alerting Engine & Rules Guide，如下圖：

圖 6：Grafana4.0 基于規(guī)則的報警 UI .1

圖 7：Grafana4.0 基于規(guī)則的報警 UI .2

基于“腳本／編程”的，這種類型的規(guī)則定義，提供了無限的靈活性。因為“可編程”，就等于可以“do everything”。

但也有一些壞處，比如：又多引入了一個外部依賴：代碼管理庫，且意味著又要為另一套系統(tǒng)做高可用 HA，一般為公司內(nèi)部的代碼管理使用 Github／Gitlab。

想快速修改報警規(guī)則時，流程會相對慢，因為要經(jīng)過代碼的修改，Merge，最后 Submit。

報警規(guī)則“腳本”定義的例子： 收集兩個數(shù)據(jù)源的數(shù)據(jù)，根據(jù)自定義規(guī)則，判斷指標是否異常，如果有異常，先進行“重啟”行為，緩解線上壓力，再發(fā)出報警給相關(guān)工程師，追查真正原因。

這種稍微復(fù)雜的報警規(guī)則，用編程腳本的方式實現(xiàn)起來毫無壓力，而如果要用基于規(guī)則語言的報警，則比較困難，甚至是不可能實現(xiàn)的。

圖 8：基于“腳本”的報警規(guī)則，定義函數(shù)

圖 9：基于“腳本&編程”的報警規(guī)則例子

報警行為

大家可能會問，報警行為有什么好講的呢？ 不外乎就是在報警規(guī)則觸發(fā)后，通過電話、微信、短信、郵件等媒介找到正確的負責人，這聽起來很簡單啊。

好，我們繼續(xù)把應(yīng)用場景想的豐富一些：比如我們的 Hadoop 架構(gòu)組，有 HDFS、Yarn、Hive、HBase、Zookeeper、Spark、Presto、Impala、Hue、Cloudera Manager……OK，不要再講了。

這么多組件，一個人能運維的過來嗎？是否需要組內(nèi)的多個人分工呢？每個人一個星期？

檢測 Hadoop Namenode 健康的報警每 5 分鐘一次，是否每一次檢測失敗了都要報警？會不會有誤報？

第一次異常報警后，工程師已經(jīng)在排查問題了，這時連續(xù)的第二次、第三次檢測異常，是否需要連續(xù)的打電話去打擾工程師？ 那么，連續(xù)幾次抑制報警呢？

哪些報警是非常重要的，白天晚上都必須打電話通知；哪些是相對重要的，白天打電話，晚上可以發(fā)一封郵件、短信先通知問題；哪些是次要的，可以只發(fā)一封郵件的。

有時候檢測程序也會因為一些“噪音”產(chǎn)生抖動，比如檢測網(wǎng)頁打開速度限制在 2ms，但是有一次訪問就是因為網(wǎng)絡(luò)鏈路的抖動達到了 50ms，那是否就應(yīng)該直接報警呢？ 是不是連續(xù) 3-5 次的數(shù)據(jù)全部超標，確認問題之后再報警呢？

報警行為軟件，分為“自研”和“第三方”兩條路：

• 自研開發(fā)，這條路適合有強大復(fù)雜報警行為規(guī)則的大公司。包括報警行為規(guī)則的復(fù)雜和報警媒介的復(fù)雜兩方面。

每一家公司使用的內(nèi)網(wǎng)辦公聊天軟件、郵件系統(tǒng)可能都不一樣，都會有獨特的場景需要集成。

每一家公司、每一個組的報警行為可能也不一樣，有的要 7*24 小時，有的只需要白天發(fā)封郵件，有的甚至只需要在工作日的白天發(fā)封郵件。

• 第三方軟件，中小型公司，創(chuàng)業(yè)公司，更適合使用第三方軟件。目前據(jù)我了解，灣區(qū)的公司，大多使用 Pagerduty，可參考鏈接了解詳情：https://www.pagerduty.com/。

而這款產(chǎn)品并沒有做中文的本地化，本土的軟件，還沒有一款殺手級的存在于市場。我找了一圈，找到了 Oneapm 公司的 One-Alert（http://www.110monitor.com/），試了試 Demo 還不錯。

個人意見：這一塊的需求會越來越大，希望國內(nèi)能有靠譜像樣的公司做起來，共同推進國內(nèi)的“監(jiān)控報警”市場發(fā)展。

總結(jié)

我整理了一張表，描述常見的“監(jiān)控報警”領(lǐng)域的開源產(chǎn)品，落在哪個區(qū)間：

大家在做技術(shù)選型時，一定要看的長遠，多想想未來的需求，不能只著眼于快速交付。同時，也希望國內(nèi)能有專注于“報警行為”的公司出現(xiàn)。

作者：汪涉洋

簡介：來自美國視頻網(wǎng)站 hulu 的工程師，畢業(yè)于北京理工大學(xué)計算機專業(yè)，目前從事大數(shù)據(jù)基礎(chǔ)架構(gòu)方面的工作，個人知乎專欄“大數(shù)據(jù)SRE的總結(jié)”：http://dwz.cn/7ygSgc。