為了更好地幫助大家理解監(jiān)控的維度，本文先從一個(gè)通用的網(wǎng)站架構(gòu)開始談起，然后講一講 58 集團(tuán)是怎么在橫向和縱向兩個(gè)維度覆蓋各種類型監(jiān)控的。

主要分為兩個(gè)部分進(jìn)行分享：

1. 網(wǎng)站的總體架構(gòu)
2. 構(gòu)建立體化的監(jiān)控體系

網(wǎng)站的總體架構(gòu)

業(yè)務(wù)集群

對(duì)于大多數(shù)的技術(shù)人員來(lái)說(shuō)，最熟悉的就是業(yè)務(wù)集群，我們?cè)跇I(yè)務(wù)集群上實(shí)現(xiàn)業(yè)務(wù)邏輯，由 Nginx 將流量分發(fā)到這些業(yè)務(wù)集群上。

如上圖所示，是相關(guān)的架構(gòu)，這部分大家都比較熟悉，我們就不展開了。下面詳細(xì)說(shuō)一下大型網(wǎng)站在機(jī)房外部和機(jī)房?jī)?nèi)部的流量接入端的架構(gòu)。

機(jī)房外部

用戶訪問(wèn)一個(gè)頁(yè)面，從瀏覽器的地址欄輸入網(wǎng)址，按下回車鍵，到頁(yè)面加載出來(lái)，經(jīng)過(guò)哪些步驟呢。

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

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

我們將前一種劃分為動(dòng)態(tài)內(nèi)容，將后一種劃分為靜態(tài)資源。如果我們?cè)谌珖?guó)只有一個(gè)機(jī)房，那么全國(guó)各地的用戶都需要跨越多個(gè)區(qū)域、多個(gè)運(yùn)營(yíng)商的網(wǎng)絡(luò)才能訪問(wèn)到網(wǎng)站，如下圖所示，這樣訪問(wèn)速度一定不是很快。

怎么解決這個(gè)問(wèn)題呢？最簡(jiǎn)單的方法就是讓用戶就近訪問(wèn)頁(yè)面資源，在全國(guó)各區(qū)域、各運(yùn)營(yíng)商用戶數(shù)量比較多的網(wǎng)絡(luò)內(nèi)建立節(jié)點(diǎn)，讓用戶就近訪問(wèn)。

如下圖所示，不同顏色的圓圈代表不同的運(yùn)營(yíng)商，節(jié)點(diǎn)覆蓋了頁(yè)面數(shù)量大的區(qū)域。

頁(yè)面上加載的絕大多數(shù)資源都是靜態(tài)資源，通過(guò)這種方式可以非常顯著地提升頁(yè)面的加載速度。

這種技術(shù)就是 CDN 技術(shù)（Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)）。

對(duì)于動(dòng)態(tài)請(qǐng)求的優(yōu)化思路也是類似，前面提到的是只有一個(gè)機(jī)房提供動(dòng)態(tài)請(qǐng)求響應(yīng)的情況，南方用戶的動(dòng)態(tài)請(qǐng)求響應(yīng)速度是較慢的。

如下圖所示，如果在華東、華南等區(qū)域部署機(jī)房，可以更好地對(duì)華東、華南的用戶進(jìn)行覆蓋，提升動(dòng)態(tài)內(nèi)容的訪問(wèn)速度。

那 CDN 是如何實(shí)現(xiàn)靜態(tài)資源的就近訪問(wèn)的呢？使用的就是 DNS 調(diào)度的方法。

我們都知道通過(guò) HTTP 協(xié)議發(fā)起請(qǐng)求的幾個(gè)步驟如下：

• 域名解析
• 建立連接
• 發(fā)送請(qǐng)求
• 接收響應(yīng)

如下圖所示，用戶在向域名解析服務(wù)器發(fā)起域名解析請(qǐng)求的時(shí)候，DNS 服務(wù)器返回了離該用戶最近的 CDN 節(jié)點(diǎn)的 IP，從而實(shí)現(xiàn)了用戶的就近訪問(wèn)。

機(jī)房?jī)?nèi)部

如上圖，在經(jīng)過(guò)域名解析階段后，動(dòng)態(tài)的請(qǐng)求會(huì)直接訪問(wèn)機(jī)房（也可以做動(dòng)態(tài)內(nèi)容的加速），靜態(tài)資源在無(wú)緩存時(shí)也會(huì)回源（去機(jī)房獲取資源文件），這兩種情況都會(huì)訪問(wèn)機(jī)房的 VIP。

分別經(jīng)過(guò)四層負(fù)載均衡和七層負(fù)載均衡集群后，流量被分發(fā)到業(yè)務(wù)集群。業(yè)務(wù)集群之間也會(huì)存在互相調(diào)用的情況。

對(duì)每一個(gè)關(guān)鍵集群來(lái)說(shuō)都存在主備，主集群出現(xiàn)問(wèn)題則切換到備集群；也可以主備集群同時(shí)提供服務(wù)，每個(gè)集群都預(yù)留承擔(dān)全部流量的資源。

每個(gè)集群內(nèi)部都包含多臺(tái)服務(wù)器，少量服務(wù)器出現(xiàn)異常不影響集群提供服務(wù)。機(jī)房網(wǎng)絡(luò)出口提供備份鏈路，主鏈路出現(xiàn)問(wèn)題可以自動(dòng)切換到備鏈路。

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

構(gòu)建立體化的監(jiān)控體系

監(jiān)控的定位和目標(biāo)

監(jiān)控的定位和目標(biāo)如下：

• 線上服務(wù)的守護(hù)神，服務(wù)穩(wěn)定性的重要保障
• 運(yùn)維和研發(fā)、測(cè)試人員的眼睛，快速發(fā)現(xiàn)和排查故障
• 將運(yùn)維數(shù)據(jù)進(jìn)行量化和可視化，便于對(duì)網(wǎng)站進(jìn)行優(yōu)化

監(jiān)控系統(tǒng)架構(gòu)

監(jiān)控系統(tǒng)的底層模塊基于 Open-Falcon，上層做了很多深度的二次開發(fā)，整體系統(tǒng)架構(gòu)圖如下：

監(jiān)控的應(yīng)用規(guī)模

監(jiān)控體系在 58 集團(tuán)的應(yīng)用規(guī)模如下：

• 覆蓋了近萬(wàn)臺(tái)服務(wù)器，包括 58 集團(tuán)下屬的各網(wǎng)站，如 58 同城、趕集網(wǎng)、中華英才網(wǎng)、安居客、轉(zhuǎn)轉(zhuǎn)。
• 監(jiān)控的業(yè)務(wù)指標(biāo)，監(jiān)控系統(tǒng)中配置了超過(guò) 3000 個(gè)集群、近 3000 個(gè)監(jiān)控模板、近 300 萬(wàn)個(gè)監(jiān)控指標(biāo)、每天實(shí)時(shí)處理的數(shù)據(jù)量超過(guò) 2T。

立體化監(jiān)控體系概述

參考網(wǎng)站的架構(gòu)圖，立體化的監(jiān)控體系包括縱向和橫向兩個(gè)方向。

縱向?qū)崿F(xiàn)了自底向上各層級(jí)的監(jiān)控，包括網(wǎng)絡(luò)、服務(wù)器、系統(tǒng)層、應(yīng)用層、業(yè)務(wù)層，如下圖所示：

橫向?qū)崿F(xiàn)了從外到內(nèi)各層級(jí)的監(jiān)控，包括用戶端、機(jī)房網(wǎng)絡(luò)出口端、流量接入端、業(yè)務(wù)端等，如下圖所示：

縱向各層級(jí)的監(jiān)控指標(biāo)

網(wǎng)絡(luò)監(jiān)控

最基本的網(wǎng)絡(luò)監(jiān)控包括：

• 機(jī)房出口 VIP 是否存活，從機(jī)房外對(duì) VIP 進(jìn)行 ping，如果連續(xù)多次發(fā)現(xiàn) VIP 不通則發(fā)出告警。
• 流量是否正常，在四層網(wǎng)絡(luò)設(shè)備上監(jiān)測(cè)出入流量和包量等關(guān)鍵指標(biāo)。
• 機(jī)房間專線流量和質(zhì)量是否正常，以及網(wǎng)絡(luò)設(shè)備及流量是否正常等。在機(jī)房之間的網(wǎng)絡(luò)設(shè)備上監(jiān)控專線的流量和質(zhì)量，例如：帶寬使用量，丟包率、ping 延時(shí)等。

服務(wù)器監(jiān)控

服務(wù)器的監(jiān)控包括服務(wù)器是否宕機(jī)，服務(wù)器硬件是否有異常等。

宕機(jī)監(jiān)控，在每個(gè)機(jī)房都部署監(jiān)控機(jī)，通過(guò) ping 的方式對(duì)同機(jī)房的服務(wù)器進(jìn)行宕機(jī)監(jiān)控。

為了避免網(wǎng)絡(luò)抖動(dòng)的影響，當(dāng)連續(xù)多次發(fā)現(xiàn) ping 不通則發(fā)出宕機(jī)告警。

在同機(jī)房進(jìn)行部署是為了避免由于機(jī)房間網(wǎng)絡(luò)鏈路出現(xiàn)問(wèn)題導(dǎo)致大量的誤報(bào)宕機(jī)。

在監(jiān)控管理層面通過(guò)配置不同的模板，給不同集群、不同角色的用戶發(fā)送不同的告警，例如：對(duì)于數(shù)據(jù)庫(kù)主庫(kù)宕機(jī)發(fā)送語(yǔ)音告警，其它架構(gòu)層面支持自動(dòng)剔除故障機(jī)器的宕機(jī)發(fā)送短信告警即可。

服務(wù)器硬件監(jiān)控，通過(guò)在監(jiān)控 Agent 上部署插件，可以很好地支持多種多樣的硬件監(jiān)控，也非常便于對(duì)硬件進(jìn)行適配。對(duì)硬件監(jiān)控的覆蓋程度視業(yè)務(wù)需求而定。

系統(tǒng)監(jiān)控

服務(wù)器資源使用率，包括 CPU、內(nèi)存、磁盤、網(wǎng)卡等各項(xiàng)指標(biāo)。

對(duì)于一個(gè)中大型互聯(lián)網(wǎng)公司，業(yè)務(wù)比較復(fù)雜，服務(wù)器根據(jù)用途被劃分為不同的集群，由不同的運(yùn)維和開發(fā)人員負(fù)責(zé)管理。

那么添加這些監(jiān)控對(duì)于技術(shù)人員來(lái)說(shuō)是較大的工作量，且只依靠人去添加監(jiān)控很難保證監(jiān)控的覆蓋率。我們的思路是盡可能自動(dòng)化地添加基礎(chǔ)的監(jiān)控。

我們對(duì)各個(gè)業(yè)務(wù)在系統(tǒng)監(jiān)控層面的需求進(jìn)行歸納，確定了一些核心的監(jiān)控指標(biāo)、異常判斷條件、告警方式等，生成一個(gè)默認(rèn)的監(jiān)控模板。

我們的 CMDB 系統(tǒng)包含最基礎(chǔ)的服務(wù)器資產(chǎn)數(shù)據(jù)，包括集群的名稱、集群中的服務(wù)器列表、集群的運(yùn)維和研發(fā)負(fù)責(zé)人等信息。

這樣就可以從 CMDB 中同步這些信息，在監(jiān)控系統(tǒng)中自動(dòng)添加每個(gè)集群的基礎(chǔ)系統(tǒng)監(jiān)控，也就是自動(dòng)添加集群、自動(dòng)創(chuàng)建監(jiān)控模板（繼承了基礎(chǔ)監(jiān)控模板），告警按需求發(fā)給運(yùn)維和研發(fā)負(fù)責(zé)人。

通過(guò)這種方式在短時(shí)間內(nèi)做到了所有集群基礎(chǔ)監(jiān)控的 100% 覆蓋，起碼能做到服務(wù)器宕機(jī)和系統(tǒng)資源使用率問(wèn)題導(dǎo)致的異常都能夠有效的發(fā)出告警，迅速解決了監(jiān)控初始建設(shè)階段的核心痛點(diǎn)。

對(duì)于某些集群，由于業(yè)務(wù)的特殊性，基礎(chǔ)的監(jiān)控模板不能滿足他的需求，可以繼承父模板的監(jiān)控指標(biāo)，然后進(jìn)行告警條件、告警方式的修改。

應(yīng)用監(jiān)控

應(yīng)用監(jiān)控用來(lái)監(jiān)控部署的應(yīng)用程序是否正常，包括：端口，進(jìn)程，功能（頁(yè)面或接口），QPS，連接數(shù)等指標(biāo)。

一般來(lái)說(shuō)，讓運(yùn)維和開發(fā)人員去創(chuàng)建監(jiān)控模板、關(guān)聯(lián)到集群、配置告警接收人等工作有一定的工作量，而且也有一定的難度。一些情況下，由于配置的問(wèn)題會(huì)導(dǎo)致監(jiān)控和告警不能生效。

為了解決這個(gè)問(wèn)題，我們基于自動(dòng)添加的系統(tǒng)監(jiān)控：

• 一方面從部署上線系統(tǒng)同步應(yīng)用程序的端口等信息，自動(dòng)添加端口監(jiān)控。
• 另一方面基于系統(tǒng)監(jiān)控的模板，允許用戶方便的添加應(yīng)用監(jiān)控，例如：只需要填寫端口、進(jìn)程名等就可以方便的添加端口監(jiān)控和進(jìn)程監(jiān)控。

對(duì)于功能（頁(yè)面或接口）、QPS、連接數(shù)等指標(biāo)，我們也提供了部署監(jiān)控插件進(jìn)行監(jiān)控的方式。

用戶可以通過(guò)幫助文檔頁(yè)面下載多種語(yǔ)言（Java、PHP、Python，Shell等）的監(jiān)控插件模板，然后進(jìn)行簡(jiǎn)單修改，采集到被監(jiān)控指標(biāo)后可以方便的接入監(jiān)控系統(tǒng)。

通過(guò)這種方式我們快速提升了應(yīng)用監(jiān)控的覆蓋率。

業(yè)務(wù)監(jiān)控

業(yè)務(wù)的監(jiān)控對(duì)象包括業(yè)務(wù)關(guān)心的各項(xiàng)指標(biāo)，例如訂單量、成交額等。

由于業(yè)務(wù)監(jiān)控和具體的業(yè)務(wù)相關(guān)，不能采用通用的方式進(jìn)行監(jiān)控，所以采用自定義監(jiān)控插件的方式監(jiān)控。

所有可以采集到的指標(biāo)都可以添加監(jiān)控和告警；將數(shù)據(jù)以 Json 格式發(fā)給監(jiān)控 Agent 即完成數(shù)據(jù)上報(bào)。

橫向各層級(jí)的監(jiān)控指標(biāo)

用戶端

有如下幾種采集數(shù)據(jù)的方式：

• 使用在用戶端網(wǎng)絡(luò)內(nèi)合作用戶電腦或手機(jī)上部署的探針進(jìn)行探測(cè)。
• 在頁(yè)面中嵌入 JS 代碼，從真實(shí)用戶的瀏覽器端對(duì)性能數(shù)據(jù)進(jìn)行采集。
• 在 APP 端嵌入 SDK，從真實(shí)用戶的 APP 對(duì)訪問(wèn)錯(cuò)誤和性能數(shù)據(jù)進(jìn)行采集。

采集的數(shù)據(jù)包括用戶端可用性、首屏?xí)r間、全部資源下載時(shí)間、全部資源字節(jié)數(shù)、基礎(chǔ) HTML 頁(yè)面下載時(shí)間等數(shù)據(jù)，如下圖所示：

另外，還可以對(duì) DNS 劫持、鏈路劫持、訪問(wèn)出錯(cuò)、訪問(wèn)速度較慢的問(wèn)題進(jìn)行告警，以 DNS 劫持?jǐn)?shù)據(jù)的展示舉例：

 

點(diǎn)擊圖例后，跳轉(zhuǎn)到詳情數(shù)據(jù)：

機(jī)房網(wǎng)絡(luò)出口端

既可以在網(wǎng)絡(luò)設(shè)備上采集流量，也可以在四層負(fù)載均衡上采集流量。并可分別對(duì)網(wǎng)絡(luò)的連通性、進(jìn)出流量、進(jìn)出包數(shù)等關(guān)鍵指標(biāo)進(jìn)行監(jiān)控。

頁(yè)面和接口監(jiān)控

對(duì)重點(diǎn)頁(yè)面、接口的可用性、響應(yīng)時(shí)間進(jìn)行監(jiān)控。

這些監(jiān)控都是對(duì)機(jī)房出口的 VIP 發(fā)起請(qǐng)求，流量經(jīng)過(guò)負(fù)載均衡服務(wù)分發(fā)到后端業(yè)務(wù)集群，業(yè)務(wù)集群內(nèi)有少量服務(wù)器出現(xiàn)異常，負(fù)載均衡服務(wù)會(huì)自動(dòng)到另一臺(tái)服務(wù)器重試，異常不會(huì)暴露給外部用戶。

當(dāng)探測(cè)此處的頁(yè)面和接口監(jiān)控發(fā)現(xiàn)了異常，那么用戶已經(jīng)可見了，是比較嚴(yán)重的故障。

通過(guò)這種監(jiān)控方式也可以比較客觀的評(píng)價(jià)業(yè)務(wù)集群的運(yùn)行狀況，重點(diǎn)關(guān)注的指標(biāo)的穩(wěn)定性和響應(yīng)時(shí)間。

頁(yè)面監(jiān)控：對(duì)頁(yè)面的基礎(chǔ)頁(yè)面（即 HTML）進(jìn)行探測(cè)，連續(xù)一段時(shí)間發(fā)現(xiàn)狀態(tài)碼與預(yù)期不一致、響應(yīng)時(shí)間過(guò)長(zhǎng)、找不到匹配的關(guān)鍵詞、頁(yè)面長(zhǎng)度較短等情況，會(huì)發(fā)出告警。

接口監(jiān)控：對(duì)接口進(jìn)行探測(cè)，連續(xù)一段時(shí)間發(fā)現(xiàn)狀態(tài)碼與預(yù)期不一致、響應(yīng)時(shí)間過(guò)長(zhǎng)，接口返回的消息體中業(yè)務(wù)狀態(tài)碼不符合預(yù)期或數(shù)據(jù)長(zhǎng)度較短等情況，會(huì)發(fā)出告警。

流量接入端

大型網(wǎng)站的流量接入端包括四層和七層的負(fù)載均衡集群。

一般的網(wǎng)站可以使用 LVS 提供四層負(fù)載均衡服務(wù)，技術(shù)實(shí)力雄厚的公司可以使用自己定制開發(fā)的四層負(fù)載均衡服務(wù)。

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

另外由于所有流量都經(jīng)過(guò)該服務(wù)，可以收集到很多用戶端訪問(wèn)和后端業(yè)務(wù)集群運(yùn)行狀況的數(shù)據(jù)。

一般七層的負(fù)載均衡服務(wù)使用 Nginx，除了基礎(chǔ)的服務(wù)器、系統(tǒng)、應(yīng)用層的監(jiān)控，還可以實(shí)現(xiàn)更多的監(jiān)控。

有以下幾種方式實(shí)現(xiàn)：

• 將日志實(shí)時(shí)傳輸，集中計(jì)算，再將結(jié)果給監(jiān)控服務(wù)端。
• 將日志在 Nginx 上實(shí)時(shí)計(jì)算，傳送結(jié)果給監(jiān)控服務(wù)端。
• 用 Lua 實(shí)現(xiàn) Nginx 擴(kuò)展，實(shí)時(shí)計(jì)算，傳送結(jié)果給監(jiān)控服務(wù)端。

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

采集的指標(biāo)包括（如下圖）：

• 各域名的各種狀態(tài)碼的數(shù)量和比率、響應(yīng)時(shí)間。
• 各后端集群的各種狀態(tài)碼的數(shù)量和比率、響應(yīng)時(shí)間。

業(yè)務(wù)集群端

在流量接入端已經(jīng)能夠?qū)I(yè)務(wù)集群的可用性、響應(yīng)時(shí)間等關(guān)鍵指標(biāo)進(jìn)行監(jiān)控和告警，對(duì)業(yè)務(wù)集群還可以按照縱向各層級(jí)添加監(jiān)控指標(biāo)。

其他核心功能

監(jiān)控?cái)?shù)據(jù)展示

用戶能夠按照服務(wù)器和集群查看監(jiān)控指標(biāo)，為了便于用戶使用，可以直接查詢最常用的監(jiān)控指標(biāo)。

可以在一個(gè)視圖中展示所有機(jī)器的某項(xiàng)監(jiān)控指標(biāo)：

監(jiān)控異常查看

為了方便用戶查看當(dāng)前有哪些異常，我們提供了監(jiān)控異常查看頁(yè)面，且可以對(duì)信息進(jìn)行搜索：

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

監(jiān)控墻

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

容量管理

為了便于提升服務(wù)器的資源利用率，及時(shí)發(fā)現(xiàn)系統(tǒng)性能瓶頸，為服務(wù)器申請(qǐng)?zhí)峁?shù)據(jù)支持，基于監(jiān)控系統(tǒng)的數(shù)據(jù)，我們開發(fā)了容量管理系統(tǒng)。

第一步先實(shí)現(xiàn)集群的基本容量評(píng)估，通過(guò)幾項(xiàng)主要的系統(tǒng)負(fù)載參數(shù)（CPU、內(nèi)存、磁盤空間、磁盤 IO、網(wǎng)卡出入流量使用率）對(duì)集群負(fù)載進(jìn)行分析。后續(xù)可以加入更多的業(yè)務(wù)指標(biāo)來(lái)對(duì)容量進(jìn)行管理。

[[216609]]

龔誠(chéng)，58 集團(tuán)技術(shù)工程平臺(tái)部高級(jí)經(jīng)理，曾任職于百度、新浪微博等公司，負(fù)責(zé)運(yùn)維及自動(dòng)化團(tuán)隊(duì)的技術(shù)和管理工作；擁有豐富的網(wǎng)站穩(wěn)定性建設(shè)、網(wǎng)站優(yōu)化等經(jīng)驗(yàn)。