為了更好地幫助大家理解監控的維度，本文先從一個通用的網站架構開始談起，然后講一講 58 集團是怎么在橫向和縱向兩個維度覆蓋各種類型監控的。

主要分為兩個部分進行分享：

1. 網站的總體架構
2. 構建立體化的監控體系

網站的總體架構

業務集群

對于大多數的技術人員來說，最熟悉的就是業務集群，我們在業務集群上實現業務邏輯，由 Nginx 將流量分發到這些業務集群上。

如上圖所示，是相關的架構，這部分大家都比較熟悉，我們就不展開了。下面詳細說一下大型網站在機房外部和機房內部的流量接入端的架構。

機房外部

用戶訪問一個頁面，從瀏覽器的地址欄輸入網址，按下回車鍵，到頁面加載出來，經過哪些步驟呢。

拿一個典型頁面舉例，通過瀏覽器中的開發者工具，我們可以看到加載和渲染這個頁面需要加載很多頁面資源。

不但加載了很多文檔類型的資源，例如 HTML；也加載了很多靜態資源，例如 CSS、JS 和圖片文件。

我們將前一種劃分為動態內容，將后一種劃分為靜態資源。如果我們在全國只有一個機房，那么全國各地的用戶都需要跨越多個區域、多個運營商的網絡才能訪問到網站，如下圖所示，這樣訪問速度一定不是很快。

怎么解決這個問題呢？最簡單的方法就是讓用戶就近訪問頁面資源，在全國各區域、各運營商用戶數量比較多的網絡內建立節點，讓用戶就近訪問。

如下圖所示，不同顏色的圓圈代表不同的運營商，節點覆蓋了頁面數量大的區域。

頁面上加載的絕大多數資源都是靜態資源，通過這種方式可以非常顯著地提升頁面的加載速度。

這種技術就是 CDN 技術（Content Delivery Network，即內容分發網絡）。

對于動態請求的優化思路也是類似，前面提到的是只有一個機房提供動態請求響應的情況，南方用戶的動態請求響應速度是較慢的。

如下圖所示，如果在華東、華南等區域部署機房，可以更好地對華東、華南的用戶進行覆蓋，提升動態內容的訪問速度。

那 CDN 是如何實現靜態資源的就近訪問的呢？使用的就是 DNS 調度的方法。

我們都知道通過 HTTP 協議發起請求的幾個步驟如下：

• 域名解析
• 建立連接
• 發送請求
• 接收響應

如下圖所示，用戶在向域名解析服務器發起域名解析請求的時候，DNS 服務器返回了離該用戶最近的 CDN 節點的 IP，從而實現了用戶的就近訪問。

機房內部

如上圖，在經過域名解析階段后，動態的請求會直接訪問機房（也可以做動態內容的加速），靜態資源在無緩存時也會回源（去機房獲取資源文件），這兩種情況都會訪問機房的 VIP。

分別經過四層負載均衡和七層負載均衡集群后，流量被分發到業務集群。業務集群之間也會存在互相調用的情況。

對每一個關鍵集群來說都存在主備，主集群出現問題則切換到備集群；也可以主備集群同時提供服務，每個集群都預留承擔全部流量的資源。

每個集群內部都包含多臺服務器，少量服務器出現異常不影響集群提供服務。機房網絡出口提供備份鏈路，主鏈路出現問題可以自動切換到備鏈路。

當遇到極端情況，兩條鏈路都中斷的情況，可以切換域名的解析結果和 CDN 的回源 IP 到備份機房的 VIP，然后通過機房之間的專線將流量導入。如果有多個機房，那么直接將流量切到其他正常的機房即可。

構建立體化的監控體系

監控的定位和目標

監控的定位和目標如下：

• 線上服務的守護神，服務穩定性的重要保障
• 運維和研發、測試人員的眼睛，快速發現和排查故障
• 將運維數據進行量化和可視化，便于對網站進行優化

監控系統架構

監控系統的底層模塊基于 Open-Falcon，上層做了很多深度的二次開發，整體系統架構圖如下：

監控的應用規模

監控體系在 58 集團的應用規模如下：

• 覆蓋了近萬臺服務器，包括 58 集團下屬的各網站，如 58 同城、趕集網、中華英才網、安居客、轉轉。
• 監控的業務指標，監控系統中配置了超過 3000 個集群、近 3000 個監控模板、近 300 萬個監控指標、每天實時處理的數據量超過 2T。

立體化監控體系概述

參考網站的架構圖，立體化的監控體系包括縱向和橫向兩個方向。

縱向實現了自底向上各層級的監控，包括網絡、服務器、系統層、應用層、業務層，如下圖所示：

橫向實現了從外到內各層級的監控，包括用戶端、機房網絡出口端、流量接入端、業務端等，如下圖所示：

縱向各層級的監控指標

網絡監控

最基本的網絡監控包括：

• 機房出口 VIP 是否存活，從機房外對 VIP 進行 ping，如果連續多次發現 VIP 不通則發出告警。
• 流量是否正常，在四層網絡設備上監測出入流量和包量等關鍵指標。
• 機房間專線流量和質量是否正常，以及網絡設備及流量是否正常等。在機房之間的網絡設備上監控專線的流量和質量，例如：帶寬使用量，丟包率、ping 延時等。

服務器監控

服務器的監控包括服務器是否宕機，服務器硬件是否有異常等。

宕機監控，在每個機房都部署監控機，通過 ping 的方式對同機房的服務器進行宕機監控。

為了避免網絡抖動的影響，當連續多次發現 ping 不通則發出宕機告警。

在同機房進行部署是為了避免由于機房間網絡鏈路出現問題導致大量的誤報宕機。

在監控管理層面通過配置不同的模板，給不同集群、不同角色的用戶發送不同的告警，例如：對于數據庫主庫宕機發送語音告警，其它架構層面支持自動剔除故障機器的宕機發送短信告警即可。

服務器硬件監控，通過在監控 Agent 上部署插件，可以很好地支持多種多樣的硬件監控，也非常便于對硬件進行適配。對硬件監控的覆蓋程度視業務需求而定。

系統監控

服務器資源使用率，包括 CPU、內存、磁盤、網卡等各項指標。

對于一個中大型互聯網公司，業務比較復雜，服務器根據用途被劃分為不同的集群，由不同的運維和開發人員負責管理。

那么添加這些監控對于技術人員來說是較大的工作量，且只依靠人去添加監控很難保證監控的覆蓋率。我們的思路是盡可能自動化地添加基礎的監控。

我們對各個業務在系統監控層面的需求進行歸納，確定了一些核心的監控指標、異常判斷條件、告警方式等，生成一個默認的監控模板。

我們的 CMDB 系統包含最基礎的服務器資產數據，包括集群的名稱、集群中的服務器列表、集群的運維和研發負責人等信息。

這樣就可以從 CMDB 中同步這些信息，在監控系統中自動添加每個集群的基礎系統監控，也就是自動添加集群、自動創建監控模板（繼承了基礎監控模板），告警按需求發給運維和研發負責人。

通過這種方式在短時間內做到了所有集群基礎監控的 100% 覆蓋，起碼能做到服務器宕機和系統資源使用率問題導致的異常都能夠有效的發出告警，迅速解決了監控初始建設階段的核心痛點。

對于某些集群，由于業務的特殊性，基礎的監控模板不能滿足他的需求，可以繼承父模板的監控指標，然后進行告警條件、告警方式的修改。

應用監控

應用監控用來監控部署的應用程序是否正常，包括：端口，進程，功能（頁面或接口），QPS，連接數等指標。

一般來說，讓運維和開發人員去創建監控模板、關聯到集群、配置告警接收人等工作有一定的工作量，而且也有一定的難度。一些情況下，由于配置的問題會導致監控和告警不能生效。

為了解決這個問題，我們基于自動添加的系統監控：

• 一方面從部署上線系統同步應用程序的端口等信息，自動添加端口監控。
• 另一方面基于系統監控的模板，允許用戶方便的添加應用監控，例如：只需要填寫端口、進程名等就可以方便的添加端口監控和進程監控。

對于功能（頁面或接口）、QPS、連接數等指標，我們也提供了部署監控插件進行監控的方式。

用戶可以通過幫助文檔頁面下載多種語言（Java、PHP、Python，Shell等）的監控插件模板，然后進行簡單修改，采集到被監控指標后可以方便的接入監控系統。

通過這種方式我們快速提升了應用監控的覆蓋率。

業務監控

業務的監控對象包括業務關心的各項指標，例如訂單量、成交額等。

由于業務監控和具體的業務相關，不能采用通用的方式進行監控，所以采用自定義監控插件的方式監控。

所有可以采集到的指標都可以添加監控和告警；將數據以 Json 格式發給監控 Agent 即完成數據上報。

橫向各層級的監控指標

用戶端

有如下幾種采集數據的方式：

• 使用在用戶端網絡內合作用戶電腦或手機上部署的探針進行探測。
• 在頁面中嵌入 JS 代碼，從真實用戶的瀏覽器端對性能數據進行采集。
• 在 APP 端嵌入 SDK，從真實用戶的 APP 對訪問錯誤和性能數據進行采集。

采集的數據包括用戶端可用性、首屏時間、全部資源下載時間、全部資源字節數、基礎 HTML 頁面下載時間等數據，如下圖所示：

另外，還可以對 DNS 劫持、鏈路劫持、訪問出錯、訪問速度較慢的問題進行告警，以 DNS 劫持數據的展示舉例：

 

點擊圖例后，跳轉到詳情數據：

機房網絡出口端

既可以在網絡設備上采集流量，也可以在四層負載均衡上采集流量。并可分別對網絡的連通性、進出流量、進出包數等關鍵指標進行監控。

頁面和接口監控

對重點頁面、接口的可用性、響應時間進行監控。

這些監控都是對機房出口的 VIP 發起請求，流量經過負載均衡服務分發到后端業務集群，業務集群內有少量服務器出現異常，負載均衡服務會自動到另一臺服務器重試，異常不會暴露給外部用戶。

當探測此處的頁面和接口監控發現了異常，那么用戶已經可見了，是比較嚴重的故障。

通過這種監控方式也可以比較客觀的評價業務集群的運行狀況，重點關注的指標的穩定性和響應時間。

頁面監控：對頁面的基礎頁面（即 HTML）進行探測，連續一段時間發現狀態碼與預期不一致、響應時間過長、找不到匹配的關鍵詞、頁面長度較短等情況，會發出告警。

接口監控：對接口進行探測，連續一段時間發現狀態碼與預期不一致、響應時間過長，接口返回的消息體中業務狀態碼不符合預期或數據長度較短等情況，會發出告警。

流量接入端

大型網站的流量接入端包括四層和七層的負載均衡集群。

一般的網站可以使用 LVS 提供四層負載均衡服務，技術實力雄厚的公司可以使用自己定制開發的四層負載均衡服務。

七層負載均衡端是流量接入端的重要服務，處于用戶流量接入的咽喉要道，重要性不言而喻，所以要有完善的監控。

另外由于所有流量都經過該服務，可以收集到很多用戶端訪問和后端業務集群運行狀況的數據。

一般七層的負載均衡服務使用 Nginx，除了基礎的服務器、系統、應用層的監控，還可以實現更多的監控。

有以下幾種方式實現：

• 將日志實時傳輸，集中計算，再將結果給監控服務端。
• 將日志在 Nginx 上實時計算，傳送結果給監控服務端。
• 用 Lua 實現 Nginx 擴展，實時計算，傳送結果給監控服務端。

我們采用了第一種方式，復雜的計算不占用 Nginx 集群的計算資源。

采集的指標包括（如下圖）：

• 各域名的各種狀態碼的數量和比率、響應時間。
• 各后端集群的各種狀態碼的數量和比率、響應時間。

業務集群端

在流量接入端已經能夠對業務集群的可用性、響應時間等關鍵指標進行監控和告警，對業務集群還可以按照縱向各層級添加監控指標。

其他核心功能

監控數據展示

用戶能夠按照服務器和集群查看監控指標，為了便于用戶使用，可以直接查詢最常用的監控指標。

可以在一個視圖中展示所有機器的某項監控指標：

監控異常查看

為了方便用戶查看當前有哪些異常，我們提供了監控異常查看頁面，且可以對信息進行搜索：

另外還可以在時間維度上查看所有近期的告警：

監控墻

為了便于值班和巡檢，我們提供了監控墻功能，可以展示在監控大屏上：

容量管理

為了便于提升服務器的資源利用率，及時發現系統性能瓶頸，為服務器申請提供數據支持，基于監控系統的數據，我們開發了容量管理系統。

第一步先實現集群的基本容量評估，通過幾項主要的系統負載參數（CPU、內存、磁盤空間、磁盤 IO、網卡出入流量使用率）對集群負載進行分析。后續可以加入更多的業務指標來對容量進行管理。

[[216609]]

龔誠，58 集團技術工程平臺部高級經理，曾任職于百度、新浪微博等公司，負責運維及自動化團隊的技術和管理工作；擁有豐富的網站穩定性建設、網站優化等經驗。