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

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

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

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

針對(duì)大數(shù)據(jù)集群，監(jiān)控報(bào)警的特點(diǎn)

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

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

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

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

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

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

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

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

首先是背景，我們先來談?wù)勡浖こ?。在很早以前，軟件開發(fā)的技術(shù)團(tuán)隊(duì)在做迭代開發(fā)時(shí)，一般是要經(jīng)歷這樣的開發(fā)流程：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在往后的內(nèi)容，我們把“自動(dòng)化周期性線上測試”系統(tǒng)，稱為“監(jiān)控報(bào)警”系統(tǒng)。因?yàn)樗媪巳巳?ldquo;監(jiān)控”，代替了測試工程師去“報(bào)告問題”。

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

監(jiān)控報(bào)警我認(rèn)為分為四大塊：

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

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

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

監(jiān)控報(bào)警系統(tǒng)細(xì)節(jié)分析

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

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

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

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

• 網(wǎng)絡(luò)數(shù)據(jù)，包括骨干交換機(jī)，核心交換機(jī)等硬件設(shè)備。
• 服務(wù)器數(shù)據(jù)，包括服務(wù)器的 CPU、內(nèi)存、硬盤的各項(xiàng)使用數(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ù)的收集也會(huì)變化。

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

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

在這里我也簡單提一下：

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

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

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

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

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

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

Map< METRIC_KEY , sortedMap<timestamp, METRIC_VALUE >>

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

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

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

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

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

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

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

Metrics 是否會(huì)無限增加，保留時(shí)長

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

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

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

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

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

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

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

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

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

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

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

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

任何時(shí)候，監(jiān)控報(bào)警系統(tǒng)都必須可用，必須可以容忍一部分機(jī)器掛掉。其不能因?yàn)槟撑_(tái)機(jī)器、某個(gè)進(jìn)程掛掉而導(dǎo)致整個(gè)監(jiān)控報(bào)警體系都宕掉。

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

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

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

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

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

wiki : Time series database

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

報(bào)警規(guī)則

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

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

我們看看看報(bào)警規(guī)則有哪些通用的技術(shù)點(diǎn)：

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

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

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

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

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

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

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

報(bào)警規(guī)則定義

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

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

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

比如當(dāng)某一、二個(gè)觀測指標(biāo)到達(dá)閾值時(shí)觸發(fā)，如下圖：

Prometheus：Alerting rules | Prometheus 

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

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

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

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

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

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

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

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

想快速修改報(bào)警規(guī)則時(shí)，流程會(huì)相對(duì)慢，因?yàn)橐?jīng)過代碼的修改，Merge，最后 Submit。

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

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

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

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

報(bào)警行為

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

作者：汪涉洋

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