1)報(bào)警配置信息的錄入 
這部分比較簡單，就是一個(gè)簡單的管理系統(tǒng)
架構(gòu)如下所示：

配置信息具體要存什么，看你自己需要，每個(gè)人有自己的想法
我之前的思路是：
(0)定義本配置所屬的服務(wù)，比如web服務(wù)，rpc服務(wù)，cache緩存服務(wù)，mq服務(wù)，sql服務(wù)。
(1)定義一個(gè)采樣次數(shù)的總數(shù)，比如10次采樣樣本為一次計(jì)算單位。
(2)定義一個(gè)采樣樣本不過關(guān)的次數(shù)，比如4次，也就是10次里面有4次樣本不過關(guān)就報(bào)警。
(2.1)單個(gè)樣本里的成功率必須>=某個(gè)閥值
(2.2)單個(gè)樣本里的平均耗時(shí)必須<=某個(gè)閥值
(2.3)單個(gè)樣本里的***耗時(shí)必須<=某個(gè)閥值(可選)
(2.4)單個(gè)樣本里的最小耗時(shí)必須<=某個(gè)閥值(可選)
(2.5)單個(gè)樣本里的TP99數(shù)值必須<=某個(gè)閥值(可選)
(2.6)其它，你想怎么做就怎么做，規(guī)則你自己定，你就是規(guī)則之王。
(3)報(bào)警周期，就是后面如果報(bào)警，多少時(shí)間之內(nèi)同種類型的不再報(bào)警，如果你不需要就設(shè)置為0，那么有多少報(bào)警都會(huì)發(fā)出去，造成報(bào)警短信洪災(zāi)。

單個(gè)樣本到底是啥意思？ 客戶端調(diào)用埋點(diǎn)jar包里的API,會(huì)調(diào)用很多次，然后如果你定義了6秒鐘收割一次進(jìn)行數(shù)據(jù)采樣匯總，上傳到服務(wù)器，那就是一個(gè)采樣樣本。
PS:如果在這6秒鐘某個(gè)API被調(diào)用1萬次，成功6000次，那么只會(huì)上報(bào)一條數(shù)據(jù)給遠(yuǎn)程服務(wù)器，
類似于{key,10000,6000,...其它信息},要弄清楚這個(gè)概念，絕對(duì)不會(huì)上報(bào)1萬條數(shù)據(jù)給遠(yuǎn)程服務(wù)器。

好，到此，針對(duì)每種服務(wù)的報(bào)警標(biāo)準(zhǔn)都已經(jīng)存在mysql數(shù)據(jù)庫了。
有的時(shí)候，用戶(單位內(nèi)部各個(gè)業(yè)務(wù)系統(tǒng))會(huì)說，我需要每種服務(wù)的參數(shù)都要定制，那么你需要自己擴(kuò)充這些達(dá)到定制的需求，
還有說我針對(duì)時(shí)間段的需求要定制，我針對(duì)每個(gè)URL的參數(shù)要定制，這個(gè)你自己舉一反三就可以了。

2)業(yè)務(wù)統(tǒng)計(jì)信息上報(bào) 

這部分代碼在client_metrics里已經(jīng)實(shí)現(xiàn)了，花時(shí)間看一下就知道設(shè)計(jì)思路。
上報(bào)的時(shí)候要包含以下一些信息
{產(chǎn)品，所屬服務(wù)，機(jī)器ID,key,total調(diào)用次數(shù)，成功次數(shù),平均耗時(shí),***耗時(shí)，最小耗時(shí)，TP99...等其它你想要的信息}
這里解釋一下前4個(gè)字段的意思。
舉個(gè)例子：
產(chǎn)品:公司金融產(chǎn)品
服務(wù):因?yàn)檫@個(gè)產(chǎn)品會(huì)包含一些http服務(wù)啊，rpc服務(wù)啊，緩存服務(wù)啊，sql服務(wù)啊，所以你要標(biāo)記出來。
機(jī)器ID:就算你指定了rpc服務(wù)，你不會(huì)只部署一臺(tái)吧，你肯定有多臺(tái)，那你得指定是哪一臺(tái)啊，不然不知道發(fā)生在哪臺(tái)機(jī)器上啊，這個(gè)你可以寫一個(gè)
靜態(tài)函數(shù)獲取，比如我們采用了發(fā)送時(shí)獲取{ip：本進(jìn)程監(jiān)聽端口}這樣，以后就不再重新獲取，復(fù)用這個(gè)值。
key:針對(duì)http服務(wù)，就是你的url; 針對(duì)redis服務(wù)，就是你的命令；以http服務(wù)為例，你的url如果有變化的參數(shù)，你要寫成模板類型的值，不然key的個(gè)數(shù)
發(fā)生爆炸，比如http://ip:port/a/1/b 這樣的，里面的1會(huì)發(fā)生變化，你不能直接把這個(gè)作為key,你得寫成http://ip:port/a/xxx/b,大概就這個(gè)意思。
有的人說埋點(diǎn)你不能影響我的業(yè)務(wù)速度，不能影響我的內(nèi)存，這個(gè)在設(shè)計(jì)時(shí)候都要考慮
還有如果監(jiān)控的數(shù)據(jù)接收服務(wù)器全部宕機(jī)了，也不能影響業(yè)務(wù)，這個(gè)請(qǐng)自己看client_metrics,看完了就知道大體思路了，如果你覺得可以優(yōu)化得更好你自己優(yōu)化吧。核心思想是異步上傳，容許一段時(shí)間的數(shù)據(jù)不是100%準(zhǔn)確（發(fā)生在所有遠(yuǎn)程數(shù)據(jù)接收服務(wù)器全部宕機(jī)的前提下）

另外我們當(dāng)時(shí)做數(shù)據(jù)匯總時(shí)，以web為例，web可能會(huì)有幾十個(gè)URL的數(shù)據(jù)，我們上傳時(shí)就已經(jīng)做了所有數(shù)據(jù)的一個(gè)綜合統(tǒng)計(jì)，比如所有url的調(diào)用次數(shù)，平均耗時(shí)，這樣后面如果你要看這些數(shù)據(jù)，直接用這些數(shù)據(jù)作為計(jì)算基礎(chǔ)就可以了。

然后我們還做了一個(gè)掉0檢測，就是如果某個(gè)新的key***次出現(xiàn)時(shí)，我們?cè)趦?nèi)存中記住了它，如果它在某個(gè)采樣周期內(nèi)沒有出現(xiàn)，我們就會(huì)上報(bào)這個(gè)key的數(shù)據(jù)為0，有些場合可以用來做掉零檢測。

另外如果你不是java語言的程序，怎么埋點(diǎn)?一個(gè)可行的是你用Netty寫一個(gè)UDP服務(wù)器，內(nèi)部嵌套上面的java jar包，本質(zhì)上是做了一個(gè)代理
然后所有程序發(fā)送UDP數(shù)據(jù)給你，這里可以優(yōu)化，思路你自己想，(maybe QUIC協(xié)議你可以調(diào)研一下)

好，數(shù)據(jù)到了Netty服務(wù)器之后，這里是HTTP協(xié)議上報(bào)的哈，為什么要一份為2，一式2份呢？
目的是為了數(shù)據(jù)上傳入HBase和數(shù)據(jù)入MQ互相不干擾，也就是說，hbase全部宕機(jī)不影響數(shù)據(jù)進(jìn)MQ,MQ全部宕機(jī)不影響數(shù)據(jù)入hbase.

hbase：用來存儲(chǔ)海量歷史數(shù)據(jù)，這樣如果你收到了報(bào)警信息，你可以查啊，調(diào)出那個(gè)時(shí)候的數(shù)據(jù)看是不是真的有問題，用于歷史回溯。
mq: 用于存數(shù)據(jù)，作為實(shí)時(shí)計(jì)算的數(shù)據(jù)源啊，不然誰來發(fā)送報(bào)警短信和郵件呢？

然后hbase那里有一個(gè)redis.這個(gè)是干嘛的？因?yàn)槊總€(gè)數(shù)據(jù)里面的產(chǎn)品我可以實(shí)現(xiàn)定義在配置庫里，但是服務(wù)，機(jī)器ID,key這些是完全動(dòng)態(tài)的啊
所以每一條數(shù)據(jù)來了后，要需要先查redis是否存在，不存在的話，要相應(yīng)的維護(hù)到hbase里的表里，這樣慢慢構(gòu)建好這個(gè)產(chǎn)品的這些信息，回頭在界面上才可以調(diào)出來。所以redis就是起加速作用，不然每一條信息來了，你也不知道服務(wù)和機(jī)器id,key是不是已經(jīng)存在了的，然后插入到hbase,很慢啊，量大了你肯定扛不住。

3)報(bào)警信息實(shí)時(shí)計(jì)算 

具體的技術(shù)很多，storm,flink,heron都可以的，你熟悉哪個(gè)用哪個(gè)。
保證同一個(gè)[產(chǎn)品，服務(wù),機(jī)器ID]的數(shù)據(jù)肯定是到同一個(gè)bolt就行，這樣才好做計(jì)算，否則如果分散了，那就不好計(jì)算了。
計(jì)算的標(biāo)準(zhǔn)怎么拿？從步驟1的報(bào)警配置信息庫里拿啊，所以每個(gè)bolt啟動(dòng)時(shí)從sql庫里拿，
建議在1)的架構(gòu)里開一個(gè)HTTP API接口，這樣bolt每次啟動(dòng)前初始化先拿取相關(guān)的配置信息，然后后面定時(shí)拉取更新本地配置
這樣你如果修改了配置信息，自然會(huì)更新到bolt里，不用重啟storm程序。
實(shí)際上有很多需要注意的細(xì)節(jié)
比如如果HTTP接口調(diào)用失敗怎么辦，那就繼續(xù)保持原有的配置信息不需要替換。
如果新的配置跟老的配置有沖突怎么辦，比如老的是10條數(shù)據(jù)有6次失敗就報(bào)警，目前已經(jīng)有了8條數(shù)據(jù)，還差2條，然后刷新了新的報(bào)警配置是6條數(shù)據(jù)3次失敗就報(bào)警
，你怎么解決就看你自己了，合理就行。

我們當(dāng)時(shí)做報(bào)警郵件的時(shí)候，郵件內(nèi)容一部分是用戶定的報(bào)警標(biāo)準(zhǔn)，下面是每一條信息的具體數(shù)值，然后告訴你這條數(shù)據(jù)是否達(dá)標(biāo)。
(死也得讓你知道為啥死的 :)

這里報(bào)警的時(shí)候，就用到了你的參數(shù)里的報(bào)警周期，這個(gè)參數(shù)怎么用？比如你定義[產(chǎn)品，服務(wù)，機(jī)器ID]這個(gè)組合1分鐘只能報(bào)警1次，假設(shè)服務(wù)是web的話，就算有很多個(gè)URL都報(bào)警了，我也只會(huì)在這1分鐘內(nèi)報(bào)警1次，具體怎么玩你自己定，否則業(yè)務(wù)一下子收到幾十個(gè)報(bào)警短信，他會(huì)覺得很無助，其實(shí)也沒必要發(fā)這么多條，你懂我的意思就好。游戲規(guī)則自己定吧。

注意每一個(gè)細(xì)節(jié)，力求***。

4）最終的架構(gòu)圖

最終完整的架構(gòu)圖如上所示。

5）細(xì)節(jié)和性能分析

有人會(huì)問，如果業(yè)務(wù)越來越多，我怎么知道我的監(jiān)控系統(tǒng)是否要擴(kuò)容？
很簡單，你把2）步驟里面的netty服務(wù)器里面的2個(gè)內(nèi)存隊(duì)列的size做監(jiān)控信息采集，同樣上報(bào)給后端，同時(shí)在1）里面設(shè)置好報(bào)警參數(shù)
也就是你做了一個(gè)自監(jiān)控，一旦內(nèi)存隊(duì)列的size超過了閥值，說明輸入的速度>輸出的速度啊，嗯，跟老板申請(qǐng)擴(kuò)容吧
可以是加web服務(wù)器，也可以是提高后面的處理速度，自己分析吧。

招一個(gè)好一點(diǎn)的大數(shù)據(jù)人員，維護(hù)好hbase,storm這些，這套系統(tǒng)就可以水平擴(kuò)展了，
不管你一天有多少T的數(shù)據(jù)量，照單全收，毫無壓力。

另外附上我們之前生產(chǎn)環(huán)境的數(shù)值：每天300G數(shù)據(jù)，沒辦法，不是大公司，沒這么多的產(chǎn)品，而且很多中臺(tái)產(chǎn)品都是1分鐘上報(bào)1次，頻率有點(diǎn)低，其實(shí)幾秒鐘上報(bào)1次都是可以的，這樣很快可以發(fā)現(xiàn)哪個(gè)業(yè)務(wù)出了問題，也可以做到秒級(jí)感知啊 :) 。

PS:因?yàn)闀r(shí)間有限，最近在研究別的東西，這個(gè)項(xiàng)目的代碼不會(huì)經(jīng)常更新，附上架構(gòu)圖給各位網(wǎng)友，
以此為藍(lán)本，加上你的自由發(fā)揮的能力，沒問題。

另外有興趣做HDFS數(shù)據(jù)入庫的可以看看我的另外一個(gè)項(xiàng)目MyHDFS,從前同事得知***的數(shù)據(jù)是 5000萬條數(shù)據(jù)/單日(其實(shí)寫幾個(gè)億絲毫沒有問題)

附錄:

http://git.oschina.net/qiangzigege/MyEye 里面談到了每種技術(shù)具體可以用的技術(shù)選型，就看你熟悉哪個(gè)了

http://git.oschina.net/qiangzigege/MyHDFS

大牛很多，只敢拋磚引玉，肯定有設(shè)計(jì)不當(dāng)和不周的地方，還請(qǐng)各位大牛輕噴，謝謝！

MyEye官方討論群 120734278  想做監(jiān)控的可以內(nèi)部自由討論。

另外最近看到阿里的監(jiān)控，除了常規(guī)數(shù)據(jù)統(tǒng)計(jì)和報(bào)警外，給我印象最深的是智能監(jiān)控，我只能說阿里人才就是多啊 :)

這套系統(tǒng)是15年9月份開始寫的***行代碼，15年10月中旬第1版上線使用，只花了1個(gè)半月。

我做總體架構(gòu)設(shè)計(jì)和API設(shè)計(jì)，物理庫設(shè)計(jì),code review，只有1個(gè)小弟負(fù)責(zé)代碼編寫.

當(dāng)時(shí)2個(gè)人沒有任何雜念的全身心投入到這個(gè)產(chǎn)品中，經(jīng)?；丶叶荚谒伎及滋斓拇a有沒有問題。這段時(shí)間也是很懷念的。其實(shí)在做這個(gè)監(jiān)控系統(tǒng)之前我從來沒有做過監(jiān)控，當(dāng)時(shí)領(lǐng)導(dǎo)讓我設(shè)計(jì)監(jiān)控的時(shí)候我真是一臉懵逼，到處問人有沒有經(jīng)驗(yàn)可以借鑒，問了一圈發(fā)生公司沒有任何一個(gè)人可以幫到我，于是定下心來自己完全琢磨每個(gè)細(xì)節(jié)該怎么設(shè)計(jì)，開發(fā)過程中小弟也提出來一些很好的建議，后來發(fā)現(xiàn)一些想法在別的開源軟件中也是存在的，所以說這個(gè)系統(tǒng)沒有參考任何一款軟件，***開發(fā)出來并且非常平穩(wěn)的運(yùn)行了1年半時(shí)間我還是挺高興的。

實(shí)際上，公司內(nèi)部任何需要監(jiān)控的信息點(diǎn)，只要稍微轉(zhuǎn)換下，都可以用同一個(gè)API來上報(bào)信息

所以我們當(dāng)時(shí)也做了平臺(tái)部門MQ消息中間件的負(fù)載監(jiān)控，大數(shù)據(jù)部門的信息采集指標(biāo)健康監(jiān)控。

https://my.oschina.net/qiangzigege/blog/600441

是當(dāng)時(shí)給公司上面匯報(bào)用的PPT。

后記: 當(dāng)時(shí)做完這套監(jiān)控系統(tǒng)的時(shí)候，壓根還不知道有調(diào)用鏈這個(gè)東西的存在，也沒有領(lǐng)導(dǎo)和同事提出這個(gè)需求，否則當(dāng)時(shí)肯定也直接給加上去了，后來把zipkin的源碼翻完之后才發(fā)現(xiàn)調(diào)用鏈比做監(jiān)控更簡單，以后有時(shí)間再講講調(diào)用鏈的本質(zhì)以及以 zipkin為例子如何上報(bào)調(diào)用信息。