58項目經理教你如何構建萬臺服務器下的立體化監控體系

爲了更好地幫助你們理解監控的維度，本文先從一個通用的網站架構開始談起，而後講一講 58 集團是怎麼在橫向和縱向兩個維度覆蓋各類類型監控的。

爲了更好地幫助你們理解監控的維度，本文先從一個通用的網站架構開始談起，而後講一講 58 集團是怎麼在橫向和縱向兩個維度覆蓋各類類型監控的。

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

網站的整體架構

構創建體化的監控體系

網站的整體架構

業務集羣

對於大多數的技術人員來講，最熟悉的就是業務集羣，咱們在業務集羣上實現業務邏輯，由 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 延時等。針對上面的技術我特地整理了一下，有不少技術不是靠幾句話能講清楚，因此乾脆找朋友錄製了一些視頻，不少問題其實答案很簡單，可是背後的思考和邏輯不簡單，要作到知其然還要知其因此然。若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java進階羣：591240817，羣裏有大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

服務器監控

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

宕機監控，在每一個機房都部署監控機，經過 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、網卡出入流量使用率）對集羣負載進行分析。後續能夠加入更多的業務指標來對容量進行管理。