站點監控 | 外科醫生的實戰

640?wx_fmt=gif

作者簡介

梁飛    百度高級研發工程師

640?wx_fmt=png

負責百度雲監控(BCM)系統的研發和可用性建設相關工作,在雲監控、系統可用性方面有廣泛的實踐經驗。

網站無法訪問、網站內容返回錯誤、網站響應慢等場景。針對以上場景,本文將從技術角度探究如何實現站點監控

根據之前文章的介紹,設計一個站點監控系統,需要滿足以下兩個方面需求:

  • 支持多種站點監控需求

    • 支持多種協議類型,比如HTTP、HTTPS等;

    • 支持站點可用性監控,比如域名是否被劫持,接口返回錯誤碼、接口返回語義是否符合預期等;

    • 支持站點性能的監控,比如接口整體響應時間,服務端和網絡傳輸的分階段時間等;

    • 支持不同域/運營商/網絡制式多種探測方式,便於多維度分析和故障定位。

  • 保障探測任務的高可用

做爲一個監控系統,站點監控需要保障7*24小時服務穩定運行。通常單個探測點Agent故障是無法避免的,這就需要系統能夠進行探測點故障容災,以保證單個探測點故障的情況下,採集任務仍然能夠正常的被執行。

我們需要根據站點的服務類型和服務對外暴露的接口提供包括應用層、傳輸層協議在內的多種探測協議支持,常見的協議有HTTP(S) 、FTP、SMTP、DNS、PING、TCP、UDP。

一個站點探測任務通常輸出多個指標,來表示目標站點的可用性和性能狀態。如圖1所示,我們通過一個網站從瀏覽器輸入網址開始到瀏覽器返回內容的過程,來說明一次HTTP探測任務輸出的可用性和性能的指標有哪些。

640?wx_fmt=png

圖1  一個網址從輸入到頁面加載完畢的流程

  • 網站連通性

網站連通性主要反應網站是否可以成功建立連接,指標包括DNS解析返回值,TCP連接是否建立,探測任務是否探測成功。

  • 網站語義

網站語義用來探測網站的返回內容是否符合預期,指標包括HTTP響應狀態碼,HTTP內容校驗結果返回值(校驗的內容需用戶自己配置)。

  • 網站性能

網站性能反應網站的響應速度,指標包括DNS解析時間,TCP建連時間, HTTP內容下載時間,探測任務整體響應時間。

上述過程整理了HTTP探測任務的執行過程和輸出的監控項。不同的協議類型會有不同的監控指標產生,如表1所示。

表1  站點監控探測任務說明

640?wx_fmt=png

一個網站通常會被不同省份的用戶通過不同運營商和網絡制式進行訪問,當一個用戶反饋網站異常了,我們期望能夠快速的發現和定位故障的範圍,常見場景如下:

  • 查詢在江蘇移動4G網絡下訪問站點的平均響應時間

  • 查詢在北京聯通網絡下訪問站點的平均響應時間

  • 查詢網站在全網的平均響應時間

通過在全國各省份部署多個探測點,並且探測點接入不同的運營商/不同的網絡制式來實現對目標網站的探測。用戶在配置站點監控任務時,可以指定具體的省份和運營商,系統根據用戶配置進行探測任務的分配,各個探測點執行具體的探測任務,並且把數據回傳到監控系統。如圖2所示爲部署在北京的探測點列表;如圖3所示爲回傳數據模型。

640?wx_fmt=png

圖2  北京市探測點分佈示意圖

640?wx_fmt=png

圖3  站點監控數據模型示意圖

站點監控的架構如圖4所示,分爲業務端、數據通路和採集通路三個部分。其中,業務端負責任務管理和採集指標查看;數據通路負責採集指標數據的轉發、存儲、計算以及對指標的異常檢測;採集通路中任務調度模塊負責管理當前所有的探測點及探測Agent信息,並將站點監控業務端下發的監控任務分配到具體的Agent執行;探測Agent執行具體的監控任務並將數據回傳至站點監控系統。

640?wx_fmt=png

圖4  站點監控架構圖

系統的高可用,主要體現在系統可單實例故障容災,系統可動態擴展上(參看:https://en.wikipedia.org/wiki/High_availability)。

在站點監控系統中,業務端爲無狀態服務,以集羣方式

採集通路中任務調度模塊爲有狀態服務,以主備方式部署滿足系統的高可用;探測點和探測Agent作爲探測任務的執行單元,對保障站點監控任務的高可用至關重要:

  • 一方面需要考慮一個探測點下單個探測Agent的容量問題,當單個探測Agent執行的任務數量已超過該Agent最大容量負載時,需要能夠將多出的任務負載均衡到其他的Agent;

  • 另一方面,需要考慮單個探測Agent故障情況,單個Agent故障時,需要將任務遷移到屬於同一探測點的其他Agent上。

我們會在每個探測點(即每個省份、運營商、網絡制式)下部署多個探測Agent,用於支持探測點的高可用保障需求,具體方案如下:

  • 任務均衡分配&容量可擴展

任務分配採用哈希環算法,利用一致性哈希的平衡性、分散性、平滑性的特點可保證任務均衡分配。針對每個探測點(屬於同一個省份+運營商+網絡制式下的探測Agent屬於同一個探測點)下所屬的Agent構建一個哈希環,使用AgentID(每個Agent分配的全局唯一的ID)作爲節點的Key,將任務按照“一致性哈希”的方式平均分配到每個探測Agent上,如圖5所示。

640?wx_fmt=png

圖5  基於一致性哈希的任務分配

  • 探測Agent故障容災

Agent通過定期心跳信息來上報健康狀態。任務調度模塊定期檢查每個探測Agent上報的心跳時間戳,當心跳時間戳與當前時間差值超過一定閾值,則判定該Agent宕機。

當Agent被判定爲宕機後,任務調度模塊會將Agent從所屬的探測點哈希環中摘除,並根據一致性哈希策略將此宕機Agent上的任務分配至其他探測Agent。

本文從技術角度介紹了站點監控的實現方案,其中,以HTTP探測爲例說明如何支持多種探測任務(協議)、多種監控指標採集;在系統高可用方面重點介紹如何解決探測任務均衡分配和探測點故障容災兩個問題。站點監控通過從探測點發送模擬真實用戶訪問的探測請求,實時獲取監控目標的響應時間、DNS解析時間、可用性等信息,爲網站的穩定運行保駕護航。

大家對站點監控如有任何疑問,可以直接後臺聯繫我們,歡迎各位一起交流探討~

640?wx_fmt=jpeg

640?wx_fmt=gif

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章