建站
咨詢
售后
建站咨詢
新聞中心
對于監(jiān)控報警這一塊內容我想過很多次要從哪個方面講，因為監(jiān)控報警在現(xiàn)在已經是互聯(lián)網公司一個通用的產品。
創(chuàng)新互聯(lián)秉承實現(xiàn)全網價值營銷的理念，以專業(yè)定制企業(yè)官網，成都做網站、成都網站建設，微信小程序開發(fā)，網頁設計制作，手機網站制作，營銷型網站幫助傳統(tǒng)企業(yè)實現(xiàn)“互聯(lián)網+”轉型升級專業(yè)定制企業(yè)官網,公司注重人才、技術和管理，匯聚了一批優(yōu)秀的互聯(lián)網技術人才,對客戶都以感恩的心態(tài)奉獻自己的專業(yè)和所長。
而大數(shù)據(jù)的監(jiān)控報警只是其中的一系列報警規(guī)則子集，雖然這個子集很復雜。
有趣的是，報警系統(tǒng)的下層數(shù)據(jù)存儲引擎，也是歸類于大數(shù)據(jù)存儲的范疇。所以我打算從這樣的大綱來展開本文：
- 針對大數(shù)據(jù)集群，監(jiān)控報警的特點
- 監(jiān)控報警系統(tǒng)發(fā)展的歷史及業(yè)務背景
- 監(jiān)控報警系統(tǒng)的通用架構
- 監(jiān)控報警系統(tǒng)細節(jié)分析
- 總結
針對大數(shù)據(jù)集群，監(jiān)控報警的特點
圖 1：針對大數(shù)據(jù)集群的不同特性，監(jiān)控報警的特點
像大數(shù)據(jù)基礎設施這種部門，不可能配制專門的測試工程師，那么這么多的機器、服務以及應用要如何很好地運轉下去呢？
這就需要一套強大的“自動化監(jiān)控報警系統(tǒng)”。監(jiān)控報警這一塊，不同的公司應對方案是不同的。
對于大公司、小公司、創(chuàng)業(yè)公司，它們根據(jù)自己的實際情況選擇對于自己合理的解決方案。
監(jiān)控報警系統(tǒng)發(fā)展歷史及業(yè)務背景
市面上的監(jiān)控報警系統(tǒng)多種多樣，但越是眼花繚亂的市場，越要睜大眼睛，看其本質，剝其筋骨，找一款適合自己的解決方案。
網上有很多講述公司內部監(jiān)控報警系統(tǒng)的文章，都提到了自家監(jiān)控系統(tǒng)的實現(xiàn)，但都是直接講解了實現(xiàn)的細節(jié)，沒有講骨架、背景。
我感覺對于新入行的程序員來說會略顯生硬，對于想了解監(jiān)控報警系統(tǒng)內部運作原理的人來說，架構邏輯也不夠清晰。所以，我寫了這篇既講背景，又講骨架的文章。
首先是背景，我們先來談談軟件工程。在很早以前，軟件開發(fā)的技術團隊在做迭代開發(fā)時，一般是要經歷這樣的開發(fā)流程：
- 需求分析
- 原型／功能設計
- 測試用例設計（Tdd 測試驅動的開發(fā)）
- 開發(fā)人員完成功能，部署測試環(huán)境
- 測試按照測試用例做測試
- 如果在測試時，發(fā)現(xiàn) Bug，則回滾給開發(fā)重新 Fix
- 如果測試沒測試出 Bug，則上線生產環(huán)境
- 等線上真正有用戶發(fā)現(xiàn)了 Bug，好心的用戶會匯報 Bug，聯(lián)系客服人員
這種流程會導致什么問題呢？一般簡單的“顯式”Bug，比如“網站關鍵頁面打不開了”、“網站下單支付功能一直失敗”等等這類錯誤。
用戶和公司都能在相對的一段時間內發(fā)現(xiàn)問題，然后問題被重新整理報修為 Bug，修復、回滾。
而一些“隱式”Bug，比如“網站越來越慢了”、“支付功能要 30 秒才能成功”、“有時成功，有時失敗”、“短信驗證碼在產品上線了一周后，變得要 25 秒才能發(fā)送到客戶手機上”。
這類問題，有時并不影響業(yè)務邏輯的正常運轉，但系統(tǒng)內部肯定是已經出現(xiàn)問題了。
有時長期積累下去，會慢慢暴露出更多問題，最后導致核心業(yè)務的宕機；有時甚至就是產品性能上線后本身就很差，由于某次上線的“代碼/配置”變更導致。這種“隱式”的 Bug 也會影響用戶體驗。
測試發(fā)現(xiàn)顯式 Bug，what abou the 隱式 Bug？隨著互聯(lián)網的發(fā)展，各大互聯(lián)網公司對業(yè)務穩(wěn)定、可靠性的要求越來越高。
但公司的業(yè)務線是越來越多的，測試工程師不可能人肉去干無窮盡的手工測試，每天 24 小時一直盯著產品。
作為公司，更是希望這種隱式的 Bug 不要由用戶報告出來，最好是在內部 “快速”發(fā)現(xiàn)問題、“自動”發(fā)現(xiàn)問題、要比“用戶”早發(fā)現(xiàn)問題。這就逼迫開創(chuàng)了了“自動化周期性線上測試”。
“早期的自動化測試”，只發(fā)生在軟件上線之前。比如開發(fā)提交了新的功能之后，公司內會有 Jenkins 這種持續(xù)集成工具自動觸發(fā)去跑測試用例。
用例包括開發(fā)人員的“單元（白盒）測試”，以及測試人員寫的“腳本（黑盒）測試”。要求全部通過之后，方能部署到“生產”環(huán)境。
這種方式，能發(fā)現(xiàn)大部分的“顯示”Bug，但是很難發(fā)現(xiàn)“隱式”Bug。倘若有些程序有內存泄漏，并不會第一時間馬上崩潰，可能是跑了一個星期，甚至一個月才產生問題。
“自動化周期性線上測試”，解決隱式的 Bug，在產品上線后，持續(xù)地針對線上環(huán)境的多種指標，進行長期觀測，進行規(guī)律判斷來發(fā)現(xiàn)異常。
如果有潛在的異常，那么某些監(jiān)控指標會出現(xiàn)問題。還有一些異常指標在暴露時，如果能第一時間聯(lián)系到對應產品的“負責人”，馬上進行補救，從長期來看，對產品的口碑會有一個很大的提升。
比如：一個電商網站的支付頁面，響應速度持續(xù)地超過 5s，遠大于長期的平均值（2s），在這種現(xiàn)象連續(xù)出現(xiàn) 5 次時，報警給這一塊的研發(fā)人員，其發(fā)現(xiàn)程序有資源泄漏導致機器變慢，然后先重啟了部分服務，保證用戶速度提上來，之后馬上組織對此功能進行 Hotfix，最終解決問題。
監(jiān)控報警系統(tǒng)的通用架構
之前講了“自動化周期性線上測試”的產生歷史原因及背景?？雌饋?，這是時代的發(fā)展倒逼技術界而產生的“技術更替”。
在往后的內容，我們把“自動化周期性線上測試”系統(tǒng)，稱為“監(jiān)控報警”系統(tǒng)。因為它代替了人去“監(jiān)控”，代替了測試工程師去“報告問題”。
圖 2：監(jiān)控報警信息流
監(jiān)控報警我認為分為四大塊：
- 收集數(shù)據(jù)
- 存儲數(shù)據(jù)（時間序列的存儲）
- 報警規(guī)則
- 報警行為
下圖監(jiān)控系統(tǒng)是基本骨架，再細化一下，整個架構圖會變成下面這個樣子：
圖 3：監(jiān)控報警系統(tǒng)架構圖
監(jiān)控報警系統(tǒng)細節(jié)分析
收集數(shù)據(jù)
收集數(shù)據(jù)，我想這篇經典的《Measure Anything，Measure Everything》（https://www.tuicool.com/articles/A3AFvu6），是開啟了新時代“數(shù)據(jù)驅動”的監(jiān)控運維思想的一篇博文，大家可以讀一讀。
這里面講到的思想，也符合我這一系列文章的主旨：讓一切人的決策基于數(shù)據(jù)。
文章中提到，企業(yè)級的監(jiān)控數(shù)據(jù)，通常包括如下三類：
- 網絡數(shù)據(jù)，包括骨干交換機，核心交換機等硬件設備。
- 服務器數(shù)據(jù)，包括服務器的 CPU、內存、硬盤的各項使用數(shù)據(jù)。
- 應用數(shù)據(jù)。
應用數(shù)據(jù)是這三者中最難的，但也是最重要的。應用數(shù)據(jù)是和業(yè)務邏輯緊密相關的數(shù)據(jù)，業(yè)務邏輯變了，應用數(shù)據(jù)的收集也會變化。
在應用數(shù)據(jù)這一塊，有一個開源項目叫 Statsd，它催生了“應用數(shù)據(jù)收集標準”
https://github.com/etsy/statsd/blob/master/docs/metric_types.md
在這里我也簡單提一下：
- 累加值(Counting) gorets：1 | c
- 服務耗時(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)控指標的值隨時間變化的趨勢”這一目標而設計的。每一項監(jiān)控指標數(shù)據(jù)序列都是天然的按“時間排序”的，這是其特點。
業(yè)界管存儲這種數(shù)據(jù)結構的工具叫“時間序列數(shù)據(jù)庫”。這是一種專有數(shù)據(jù)庫，并非像 RDBMS（關系型數(shù)據(jù)庫）是一種通用的 SQL-LIKE 的數(shù)據(jù)庫。
市面上有很多很多的基于時間序列的數(shù)據(jù)庫，不論其底層的數(shù)據(jù)結構實現(xiàn)是什么樣子，時間序列存儲的本質數(shù)據(jù)結構永遠都是：
Map< METRIC_KEY , sortedMap
不同的底層實現(xiàn)都是在上面這個數(shù)據(jù)結構的一些點上有不同的擴展，比如：
- s1.在 METRIC_KEY 的分片邏輯，實現(xiàn)上不同：選取的分片是一致性哈希，還是求余哈希。
- s2.SortedMap 的實現(xiàn)不同，本質上是一個按 Timestamp 排序的序列。
- s3.讀寫的偏好略有不同。
在這里我不會著重去講具體的每一個時間序列的數(shù)據(jù)庫以及其底層數(shù)據(jù)結構的實現(xiàn)。
在技術選型時既要考慮技術的痛點，也需要考慮業(yè)務上的痛點，業(yè)務場景定下來了，技術選型才能定。
那么根據(jù)業(yè)務場景，又有了其他幾個選型點：
- s4.Metrics 是否會無限增加？
- s5.Metrics 保留的時間跨度有多長？
- s6.上層的業(yè)務報警，有多重要？
為了解決技術選型 SELECT，s1-s6，我拿一些例子來說明：
Metrics 是否會無限增加，保留時長
專有系統(tǒng)，即解決某一特定領域問題的時間序列存儲，Metric key 不會無限增長。
比如我們管理 Hadoop 的套件 Cloudera-Manager 或 Hortonworks 的 Ambari，都有自帶的監(jiān)控報警系統(tǒng)。
他們都是把數(shù)據(jù)存儲在本地的磁盤上，相當于是一個本地的數(shù)據(jù)庫。單機版數(shù)據(jù)庫的問題就是受單機硬盤的物理上限限制。
好在 Hadoop 技術棧的監(jiān)控指標是有限的、收斂的，且這些數(shù)據(jù)也大多只需要保留 1 個月。因此“Hadoop 監(jiān)控系統(tǒng)們”的單機存儲空間是可控的。
專有系統(tǒng)，一定是服務于一個成熟的“內聚產品”。通用監(jiān)控報警系統(tǒng)，Metric key 會無限增長。
如《Measure Anything，Measure Everything》提到，公司每個業(yè)務線 Team 都會把自己的應用數(shù)據(jù)發(fā)送到統(tǒng)一的指標數(shù)據(jù)存儲中。
隨著業(yè)務線、監(jiān)控指標的增長，時間序列存儲的壓力是無限增加的，且數(shù)據(jù)的保留時長不定，很有可能是無限長（每個應用都有其特殊性，不可估量）。這就要求底層的數(shù)據(jù)存儲必須支持“無限水平擴展”。
SortedMap 實現(xiàn)和讀寫偏好
SortedMap 即全局排序的映射表，它的實現(xiàn)更要由報警監(jiān)控的實際需求出發(fā)了。
專有系統(tǒng)，由于是有限的指標，且搜集數(shù)據(jù)的頻率也不會特別變態(tài)的高，那么同一時刻寫入的數(shù)據(jù)量應該是可控的。此時 B＋Tree、SkipList 都是很好的實現(xiàn)方式。
而通用系統(tǒng)，監(jiān)控指標會無限增加，有些指標采集需求的頻率可達幾十毫秒。這么高頻的并發(fā)寫入需求，一般使用 lSM Tree 來實現(xiàn)。
上層的業(yè)務報警，有多重要（HA & 高可用性）
任何時候，監(jiān)控報警系統(tǒng)都必須可用，必須可以容忍一部分機器掛掉。其不能因為某臺機器、某個進程掛掉而導致整個監(jiān)控報警體系都宕掉。
SPOF :https://en.wikipedia.org/wiki/Single_point_of_failure
監(jiān)控報警系統(tǒng)是用來“觀測公司內部的所有業(yè)務是否正常運轉”的，所有產品的第一時間救命稻草也就都壓在了“監(jiān)控報警”系統(tǒng)上了。
它掛了，公司所有產品出問題都反映不出來了。所以像基于單機版本數(shù)據(jù)存儲的時間序列是不能滿足企業(yè)級要求的。一定要選擇高可用 HA（High Available）的數(shù)據(jù)存儲解決方案。
而對于小型創(chuàng)業(yè)公司，可以在業(yè)務初期和高速增長前期暫時放棄過高的可靠可用性，先使用諸如“磁盤 Raid、定期備份、做數(shù)據(jù)庫級別的主從切換”等簡單易實施的技術來快速滿足輕量級的業(yè)務需求。
最后，附上一些時間序列數(shù)據(jù)庫總結引用的論文及文章：
wiki : Time series database
https://blog.outlyer.com/top10-open-source-time-series-databases
報警規(guī)則
報警規(guī)則模塊，首先，是天然個性的。為什么呢？按什么規(guī)則報警，顯然是和每個公司的具體業(yè)務綁定的。
而規(guī)則是基于對歷史數(shù)據(jù)的分析、度量。這牽扯到公司業(yè)務的個性化，本篇文章對個性化的業(yè)務細節(jié)不做過多的贅述。
我們看看看報警規(guī)則有哪些通用的技術點：
High-Available 的規(guī)則周期檢查
企業(yè)級的應用，最強調的就是高可用 HA，必須避免單點故障 SPOF。“報警規(guī)則模塊”發(fā)生問題了，仍然會導致“監(jiān)控報警”系統(tǒng)失效。
一般來說，報警規(guī)則都是周期性觸發(fā)的。因此需要有一個“類Cron Job”的調度器。
這類調度系統(tǒng)的 HA 設計可以參考“Azkaban” 和 “Quartz”：
- Azkaban：https://azkaban.github.io/
- Quartz：http://www.quartz-scheduler.org/
調度系統(tǒng)的 HA 設計主要分為“規(guī)則數(shù)據(jù)庫的高可用”和“調度 Sever 的高可用”兩方面：
- 數(shù)據(jù)庫高可用通過 Master-Slave 的主從實現(xiàn)。
- 調度 Server 的高可用，如果有狀態(tài)，則使用 zk／etcd 來做高可用；如果無狀態(tài)，那就啟動多個調度服務器好了。根據(jù)調度規(guī)則，制定一定的分片策略，不算困難。
報警規(guī)則定義
在我觀察了一系列的監(jiān)控報警產品后，大致歸納出兩種“報警規(guī)則”的定義實現(xiàn)方式：
- 基于“規(guī)則表達式的”。
- 基于直接“腳本&編程”的。
基于規(guī)則表達式的：在熟悉了表達式語言后，比較容易編寫，但靈活性差。在實現(xiàn)復雜的報警規(guī)則時比較難，一般適用于簡單的報警規(guī)則。
比如當某一、二個觀測指標到達閾值時觸發(fā)，如下圖：
Prometheus：Alerting rules | Prometheus
圖 4：Promethus 基于規(guī)則設定報警的例子
還有基于可視化配置規(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，一般為公司內部的代碼管理使用 Github／Gitlab。
想快速修改報警規(guī)則時，流程會相對慢，因為要經過代碼的修改，Merge，最后 Submit。
報警規(guī)則“腳本”定義的例子： 收集兩個數(shù)據(jù)源的數(shù)據(jù)，根據(jù)自定義規(guī)則，判斷指標是否異常，如果有異常，先進行“重啟”行為，緩解線上壓力，再發(fā)出報警給相關工程師，追查真正原因。
這種稍微復雜的報警規(guī)則，用編程腳本的方式實現(xiàn)起來毫無壓力，而如果要用基于規(guī)則語言的報警，則比較困難，甚至是不可能實現(xiàn)的。
圖 8：基于“腳本”的報警規(guī)則，定義函數(shù)
圖 9：基于“腳本&編程”的報警規(guī)則例子
報警行為
大家可能會問，報警行為有什么好講的呢？ 不外乎就是在報警規(guī)則觸發(fā)后，通過電話、微信、短信、郵件等媒介找到正確的負責人，這聽起來很簡單啊。
好，我們繼續(xù)把應用場景想的豐富一些：比如我們的 Hadoop 架構組，有 HDFS、Yarn、Hive、HBase、Zookeeper、Spark、Presto、Impala、Hue、Cloudera Manager……OK，不要再講了。
這么多組件，一個人能運維的過來嗎？是否需要組內的多個人分工呢？每個人一個星期？
檢測 Hadoop Namenode 健康的報警每 5 分鐘一次，是否每一次檢測失敗了都要報警？會不會有誤報？
第一次異常報警后，工程師已經在排查問題了，這時連續(xù)的第二次、第三次檢測異常，是否需要連續(xù)的打電話去打擾工程師？ 那么，連續(xù)幾次抑制報警呢？
哪些報警是非常重要的，白天晚上都必須打電話通知；哪些是相對重要的，白天打電話，晚上可以發(fā)一封郵件、短信先通知問題；哪些是次要的，可以只發(fā)一封郵件的。
有時候檢測程序也會因為一些“噪音”產生抖動，比如檢測網頁打開速度限制在 2ms，但是有一次訪問就是因為網絡鏈路的抖動達到了 50ms，那是否就應該直接報警呢？ 是不是連續(xù) 3-5 次的數(shù)據(jù)全部超標，確認問題之后再報警呢？
報警行為軟件，分為“自研”和“第三方”兩條路：
- 自研開發(fā)，這條路適合有強大復雜報警行為規(guī)則的大公司。包括報警行為規(guī)則的復雜和報警媒介的復雜兩方面。
每一家公司使用的內網辦公聊天軟件、郵件系統(tǒng)可能都不一樣，都會有獨特的場景需要集成。
每一家公司、每一個組的報警行為可能也不一樣，有的要 7*24 小時，有的只需要白天發(fā)封郵件，有的甚至只需要在工作日的白天發(fā)封郵件。
- 第三方軟件，中小型公司，創(chuàng)業(yè)公司，更適合使用第三方軟件。目前據(jù)我了解，灣區(qū)的公司，大多使用 Pagerduty，可參考鏈接了解詳情：https://www.pagerduty.com/。
而這款產品并沒有做中文的本地化，本土的軟件，還沒有一款殺手級的存在于市場。我找了一圈，找到了 Oneapm 公司的 One-Alert（http://www.110monitor.com/），試了試 Demo 還不錯。
個人意見：這一塊的需求會越來越大，希望國內能有靠譜像樣的公司做起來，共同推進國內的“監(jiān)控報警”市場發(fā)展。
總結
我整理了一張表，描述常見的“監(jiān)控報警”領域的開源產品，落在哪個區(qū)間：
大家在做技術選型時，一定要看的長遠，多想想未來的需求，不能只著眼于快速交付。同時，也希望國內能有專注于“報警行為”的公司出現(xiàn)。
作者：汪涉洋
簡介：來自美國視頻網站 hulu 的工程師，畢業(yè)于北京理工大學計算機專業(yè)，目前從事大數(shù)據(jù)基礎架構方面的工作，個人知乎專欄“大數(shù)據(jù)SRE的總結”：http://dwz.cn/7ygSgc。
網站標題：新手也能看懂的監(jiān)控報警系統(tǒng)架構設計
本文鏈接：http://www.dlmjj.cn/article/dphdigp.html
