百萬級報警平台的架構設計與實現

本文根據肖雙2018年10月19日在【第十屆中國系統架構師大會】上的演講內容整理而成。

講師介紹：

肖雙，去哪兒網高級運維開發，目前負責去哪兒網監控系統的設計、開發和運維工作，對DevOps理念有深入理解，深入實踐自動化運維。

文章摘要：

監控是每個公司基礎架構中不可缺少的一部分，如何構建適用於公司不同階段不同需求的監控系統需要技術團隊不停的探索和嘗試。本次分享主要以去哪兒網百萬級監控報警設計與實現為核心，討論去哪兒網Ops團隊在建設監控系統期間遇到的問題和解決的方法。

演講大綱：

• Watcher監控系統的介紹及架構展示;
• 報警系統的設計和演進;
• 報警遇到的痛點和解決辦法。

正文演講：

一.Watcher監控系統的介紹以及架構展示

去哪兒網早期用的是Cacti+Nagios的監控方式，同時這也是當時比較常用的一種監控架構，Cacti用作展示，Nagios用作報警。

我們早期的架構和上圖類似，當時每個部門做了一套Cacti+Nagios，這樣做的好處是分散了壓力，每個部門之間的報警互不影響。但是隨著業務量和報警量的增長，這種架構的缺點就被愈加放大了。

當時存在很多問題，首先就是Cacti的單機部署不能橫向擴展，性能差，非高可用。其次，各部門都需要維護一套甚至多套的Cacti+Nagios，隨著報警量的增加，我們不得不不斷增加Cacti+Nagios的部署，這樣一來，運維成本也在不斷增高。第三，報警配置由專人負責，不能由開發人員定製，效率低。如果開發人員想要加一個報警，那麼它就需要去和專門負責報警的同事溝通，溝通成本非常高。最後是各個監控系統之間的數據不通，數據不通會給之後的自動化以及報警統計分析等等帶來障礙。

為了解決上述問題，2014年，去哪兒網開始自主研發監控系統，也就是我們現在一直在用的監控系統— Watcher，它是企業級統一的監控報警平台。

Watcher是基於開源項目Graphite+Grafana深度開發，支持主機基礎監控報警和業務監控報警，並提供了統一的管理展示界面，即統一的入口，所有報警都通過入口進行展示、查看和配置。

當前Watcher在去哪兒網的應用規模是這樣一個量級：監控的應用有1500+，監控的指標數是4000萬+，每周的報警量是100萬+。

Watcher有四大特性，首先是用戶自定義報警以及個性化報警。用戶自定義報警指的是當數據打入到Watcher之後，Watcher會給這個數據直接生成指標圖，點擊指標圖進行報警配置。個性化報警指的是在報警時只顯示自己想要展示的內容，這是通過Watcher提供自定義的欄位支持來實現的。

自定義報警級別、報警升級和值班排班。服務肯定是有不同級別的，比如內網共享服務掛了和線上下不了單的重要級別肯定是不一樣的。目前，我們支持P1到P4 4個級別，其中P1是最高級別，P4是最低級別。如果P1級別服務出現故障，直接打電話，而P4級別出現故障，他只會發簡訊進行報警通知。報警升級，目前我們P2和P3級別的報警比較多，這一類服務故障之後，首先會發簡訊進行通知，如果一段時間沒有人去處理，就會升級為打電話通知，如果還沒有人處理，就會通知更高級別的負責人。排班值班，當一個報警設置了很多聯繫人時，如果服務發生故障，可能所有的人都會在同一時間收到報警並進行處理，這樣無形之中就增加了人力時間成本。而值班排班可以將這一組人定為一個組，設置每周或每天由一個人去值班，服務發生故障只會通知當前的值班人員。

樹形結構的指標和視圖展示，樹形結構對於指標的展示和管理是非常方便的。

橫向擴展能力強，數據高可用，理論上來講，Watcher任意一層，比如展示層、報警層和存儲層等都是可以很平滑地進行橫向擴展，並且數據是高可用的，每一個指標的數據在每個集群中都會至少存兩份，如果有任何一台機器掛了，不會影響當前的使用。

這是Watcher的Web頁面截圖，即數據打入到Watcher之後，生成的指標圖，直接點擊編輯這個圖就可以添加報警，比如設置報警名稱、報警聯繫人等等。如果想要設置個性化報警，可以直接使用欄位，而且還支持對報警做操作，例如設置Downtime或者添加回調等等。

如圖所示，我們可以把多個指標融合在一張圖中，也可以把多個圖放在一起，這樣方便對比。

上圖是Watcher的邏輯架構，當然只是一個機房的。目前我們的數據打入方式分為兩種，主機技術監控和業務監控。技術監控其實就是在遠程主機上換一個agent，業務打入是在代碼裡面埋點，數據會首先打入Relay中，Relay起到的是路由負載均衡的作用，然後根據一致性哈希將指標數據匯入到後端存儲層，同時Relay會利用Mirror去更新指標DB，指標DB中存儲的是這個指標的元數據信息，例如指標當前存儲在哪個集群的機器上。另外，指標DB是提供給Graphite-api使用的，Graphite-api取數據的時候會首先會去查詢指標DB的元數據信息，拿元數據信息之後，去存儲集群獲取相應的數據。

存儲用的是Graphite的一個原生組件—Carbon+whisper。Graphite-api拿到數據直接提供給Dashboard和報警使用。

上圖是主機收集數據的流程，主機部署了一個agent即Collected，硬體管理平台會同步Collected配置文件，Collected定時收集數據，然後將這些信息打入到Watcher當中提供給Dashboard和報警來使用。

上圖是業務層收集數據的邏輯，我們用的是Qmonitor組件。Qmonitor分為server端和client端，client端就是在代碼里埋點，server端會定期以Appcode為單位去拉取數據，並在自己的server端進行聚合，同時將聚合之後的數據打到Watcher當中。這樣，Dashboard和報警都可以使用這個數據。

二.報警系統的設計和演進

去哪兒網早期的報警系統是根據Nagios開發的。熟悉Nagios的人都知道它是一個開源的監控軟體，我們主要用的功能是狀態檢查，根據不同的狀態及策略去發送報警。Nagios目前支持的監控方式比較多，我們使用的是NRPE。

這是當時使用NRPE的基本原理，它分為nrpe daemon和check_nrpe插件。nrpe其實就相當於一個agent，部署在遠程主機上。Nagios通過check_nrpe插件和NRPE進行通信，獲取到遠端主機的信息。

早期單台Nagios支撐的報警數量是30萬+，監控服務10萬+。

這是當時單台Nagios的架構，監控系統會下發配置到Nagios，Nagios定期檢測所負責的主機上的服務狀態。一旦狀態發生改變，就立馬發送通知，並且Watcher系統會通過NagiosAPI組件對Nagios做一些簡單的操作，比如開關報警、設置Dowmtime等等。

因為Nagios是單點，所以當報警量上來之後，會引發很多問題，例如單台Nagios Load非常高，長期處於一個高負載狀態，而且響應慢，各個API耗時比較長。Nagios底層的操作實現其實是通過追加狀態文件，如果這個文件比較大的話，那麼它的操作時間就會越來越長。

基於此，我們當時做了一次改進，改進方式非常簡單就是直接加機器。然後，監控系統在下發配置的時候會進行一個哈希操作，將不同的配置哈希到不同的Nagios機器上，相當於達到了負載均衡的作用。

在這種架構下，報警的支持達到了一個新的量級，報警數量達到了100萬，監控服務達到了70萬+。當時的通知方式包括簡訊、電話和qtalk。

上述方式解決了前面提到的單點問題，但是還有很多其它問題等著我們解決。

首先是無高可用，恢復時間長。如果任何一台Nagios掛掉的話，那麼這個集群中的Nagios是沒有辦法平滑的去接管這台Nagios的配置，而且也無法去接管它的服務檢測。

其次是橫向擴展難。因為我們做了一些哈希操作，所以如果你要想加一台機器的話，首先要改代碼，然後配置肯定會有一個重新哈希的過程，比如本來被Nagios 1控制的服務，哈希之後可能就跑到了Nagios 3機器上。如果當時你對服務做了一些類似設置Downtime的操作，那麼是沒有辦法平移到Nagios 3上的。

第三是Web管理界面多。當時每台機器都有一個自己的管理界面，很多時候你根本不知道這個服務是被哈希到了哪台機器，所以在查找時需要一個一個去Nagios機器中找，很麻煩。

最後是Reload時間長，不實時。因為當時Nagios沒有提供相應的API去增刪配置，所以我們做了一個簡單的操作就是直接刷配置。但是刷配置會有Reload的過程，所以我們就做了一個硬限制——每次Reload的時間不能低於五分鐘。在硬限制的情況下，就導致了一個報警可能要等5分鐘之後才能生效。

後來我們調研了Icinga服務，它也是一個開源的監控系統，而且還是Nagios開發者開發的，這也是我們決定用Icinga替換Nagios的重要原因，Icinga完全兼容Nagios配置，且兼容NRPE監控方式。

上圖是Nagios和Icinga的對比情況。Icinga是分散式高可用的，天生就是集群形式，橫向擴展能力比較強。這樣在集群當中下線或者上線一台機器，代碼是完全無感知的。web管理界面統一，一個Icinga集群只有一個web管理界面。豐富的API，所有的操作幾乎都可以通過API來進行完成，而且無需Reload，操作基本上都是實時的。最重要的一點是兼容Nagios和NRPE，這樣我們的切換成本就會非常低。

這是我們當前一個機房的Icinga邏輯架構。最上面一層是HA，對外暴露介面; HA下面是兩個Master和Checker，在這個集群中，假如Master1掛掉了會自動平滑切換到Master2，如果Checker1掛了也會切換到Checker2。

另外，集群中不同的區域也可以有不同的分工，比如Master區域只做報警通知， Checker區域只做狀態檢查。

這是我們當時在測試Icinga和Nagios時的負載對比，在同等量級下的監控報警，Icinga比Nagios表現得更好。

上圖是操作對比，當報警比較多時，Nagios平均開關報警操作時間為15秒左右，而且如果Reload的話，我們有一個五分鐘的限制。而Icinga的操作都是毫秒級，且是實時的。

三. 報警遇到的痛點和解決辦法

第一個痛點就是報警細節太分散，歷史記錄晦澀難查。當你收到一個報警時，這個報警之前發給過誰、都有誰查看了報警或對報警做了操作……這些信息我們都是不知道的，如果開發人員想要知道，那麼就只能求助於運維人員，然後運維人員登錄報警平台去查看log，且我們的log也是有時效性的，隔段時間就自動歸檔了，所以查日誌這個操作是非常耗時的，無形之中增加了開發人員和運維人員的工作成本。

我們的解決方式是將所有的報警通知收集在一起做一條時間線。時間線是什麼?就是從一開始故障到服務恢復這期間，它都發了哪些通知，通知給了誰，誰在什麼時間對報警做了哪些操作…..這個時間線其實和快遞系統很類似，記錄了服務從故障到恢復各個時間點的操作。

報警分為事件和通知兩個部分。於Icinga來說，如果服務從OK狀態變成了Error狀態，就是一個報警事件。一旦報警事件發生了，就會進行報警通知，且通知可能會有很多次。所以事件和通知是一對多的關係，但是它倆太分散了，如果能夠把它們串聯起來，那麼時間線就比較清晰了。

所以我們做了一個全局的事件ID。當服務發生狀態改變時，會出現改變時間，記錄下這個時間，再根據監控項目的哈希和當前報警狀態，生成全局唯一的事件ID。

有了事件ID之後，我們就可以把這些東西都串聯在一起。因為我們有多個機房，所有需要把所有機房的事件和通知都收集在一起。

上圖是當時時間線的架構，一旦發生狀態改變，Icinga會生成一個事件ID，直接到達消息隊列里，然後存儲到DB當中。而且在發通知時會帶著事件ID到各個通知平台，然後通過平台到達用戶。這時如果通知平台收到了返回的消息也會進入到隊列中，並存儲到DB當中。

這樣的話，用戶端就有了事件ID，可以直接點擊事件ID看到當前事件處於什麼狀態。

這是Web端截圖，表格當中的每一條都是一個事件，記錄了這個事件當前的狀態或者最終狀態以及報警開始的時間。另外，我們還可以對它進行一些操作，比如說直接點擊跳到Watcher系統上查看報警當時的設置配置或者進入到詳情頁。

這是詳情頁，這裡可以看到報警的開始時間，幾分幾秒撥打了電話，電話打給了誰，誰接到了電話並關閉了報警，之後通知了誰，報警何時恢復了……一眼看過去就可以全部了解到，而且還可以在這裡做一些報警操作。

這是我們手機版APP的截圖，如果你在qtalk上收到了報警之後，可以直接點開看到報警的詳細信息。

第二個痛點是重要報警被淹沒。基於部門業務性能的不同，每天可能會收到很多報警，尤其是在早期沒有進行分級的時候，可能所有的報警就一下子全都湧進來了，很難去分辨哪些是重要的，哪些是可以等待的，而且重要信息很容易就被其它信息刷屏過去了。

基於此，我們做了報警分級，即將不同的服務分成不同的級別，很重要的服務就設成P1級別，其它服務按照重要程度設置成其它級別。一旦發生故障，你只需優先處理電話通知的故障，而qtalk或簡訊通知的故障可以延遲再去查看。

第三是收報警體驗差。有時一個報警設置了很多接收人，一旦報警來了，大家的手機都在不停響，浪費開發人員的時間。

針對這個痛點，我們做了報警排班的優化，我們可以給開發組設置一個組，每周設一個值班人員，一旦有了報警先發給值班人員去處理查看，假設值班人員沒有處理報警，過一段時間報警還會繼續發送給開發B，依次循環直至有人去處理報警。

第四個痛點是無主服務，持續報警。這是我們最近遇到的一個問題。由於一些歷史原因，報警或服務可能處於無人管的狀態，又或者是原來添加報警的員工離職之後，新來的員工並不了解該報警，不敢隨便去關報警。這樣就可能造成報警不停的去發，形成了報警騷擾或者淹沒掉重要信息。

我們做的優化就是報警下沉，如果報警持續了一段時間還沒有人處理，那我們就會降低報警間隔。比如剛開始服務故障，它會一分鐘發一次報警，如果持續了一個小時還沒有人去處理，那就會變成五分鐘發一次， 如果兩小時了沒人處理就變成十分鐘……報警間隔越來越大，大大降低了無效報警的情況。

分享到這裡，其實基礎的報警系統已經完成了，但我認為這只是完成了報警的初期功能，未來報警中應該具有更多智能化的模塊或元素，承擔更多的責任。

分類降噪，如果發生了稍微大的故障，可能會一下子湧進來大堆的故障，信息看不過來，電話也接不過來，很容易遺漏重要信息。分類降噪就是在出現這種情況時，將報警做聚類、聚合、收斂等操作。再根據報警的不同類別和重要程度以及不同的策略去進行發送。

多維關聯，就是當服務故障時，它會自動的去觸達到其他周邊，比如上下游的服務或者日誌信息，並反饋給用戶，幫助開發人員或運維人員快速定位問題。

智能分級，剛才的報警下沉其實也算智能分級的一個嘗試，報警下沉是針對不怎麼重要的服務，而智能分級是針對比較重要、優先順序比較高的服務，這時我們要做的不是下沉，而是報警擴散，在聯繫到了聯繫人之後還沒有去處理報警的話，我們就應該對報警進行擴散，讓更多的人或資源參與進來，快速解決問題。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！