如何構(gòu)建萬臺(tái)服務(wù)器下的立體化監(jiān)控體系?
為了更好地幫助大家理解監(jiān)控的維度,本文先從一個(gè)通用的網(wǎng)站架構(gòu)開始談起,然后講一講 58 集團(tuán)是怎么在橫向和縱向兩個(gè)維度覆蓋各種類型監(jiān)控的。
主要分為兩個(gè)部分進(jìn)行分享:
- 網(wǎng)站的總體架構(gòu)
- 構(gòu)建立體化的監(jiān)控體系
網(wǎng)站的總體架構(gòu)
業(yè)務(wù)集群
對于大多數(shù)的技術(shù)人員來說,最熟悉的就是業(yè)務(wù)集群,我們在業(yè)務(wù)集群上實(shí)現(xiàn)業(yè)務(wù)邏輯,由 Nginx 將流量分發(fā)到這些業(yè)務(wù)集群上。
如上圖所示,是相關(guān)的架構(gòu),這部分大家都比較熟悉,我們就不展開了。下面詳細(xì)說一下大型網(wǎng)站在機(jī)房外部和機(jī)房內(nèi)部的流量接入端的架構(gòu)。
機(jī)房外部
用戶訪問一個(gè)頁面,從瀏覽器的地址欄輸入網(wǎng)址,按下回車鍵,到頁面加載出來,經(jīng)過哪些步驟呢。
拿一個(gè)典型頁面舉例,通過瀏覽器中的開發(fā)者工具,我們可以看到加載和渲染這個(gè)頁面需要加載很多頁面資源。
不但加載了很多文檔類型的資源,例如 HTML;也加載了很多靜態(tài)資源,例如 CSS、JS 和圖片文件。
我們將前一種劃分為動(dòng)態(tài)內(nèi)容,將后一種劃分為靜態(tài)資源。如果我們在全國只有一個(gè)機(jī)房,那么全國各地的用戶都需要跨越多個(gè)區(qū)域、多個(gè)運(yùn)營商的網(wǎng)絡(luò)才能訪問到網(wǎng)站,如下圖所示,這樣訪問速度一定不是很快。
怎么解決這個(gè)問題呢?最簡單的方法就是讓用戶就近訪問頁面資源,在全國各區(qū)域、各運(yùn)營商用戶數(shù)量比較多的網(wǎng)絡(luò)內(nèi)建立節(jié)點(diǎn),讓用戶就近訪問。
如下圖所示,不同顏色的圓圈代表不同的運(yùn)營商,節(jié)點(diǎn)覆蓋了頁面數(shù)量大的區(qū)域。
頁面上加載的絕大多數(shù)資源都是靜態(tài)資源,通過這種方式可以非常顯著地提升頁面的加載速度。
這種技術(shù)就是 CDN 技術(shù)(Content Delivery Network,即內(nèi)容分發(fā)網(wǎng)絡(luò))。
對于動(dòng)態(tài)請求的優(yōu)化思路也是類似,前面提到的是只有一個(gè)機(jī)房提供動(dòng)態(tài)請求響應(yīng)的情況,南方用戶的動(dòng)態(tài)請求響應(yīng)速度是較慢的。
如下圖所示,如果在華東、華南等區(qū)域部署機(jī)房,可以更好地對華東、華南的用戶進(jìn)行覆蓋,提升動(dòng)態(tài)內(nèi)容的訪問速度。
那 CDN 是如何實(shí)現(xiàn)靜態(tài)資源的就近訪問的呢?使用的就是 DNS 調(diào)度的方法。
我們都知道通過 HTTP 協(xié)議發(fā)起請求的幾個(gè)步驟如下:
- 域名解析
- 建立連接
- 發(fā)送請求
- 接收響應(yīng)
如下圖所示,用戶在向域名解析服務(wù)器發(fā)起域名解析請求的時(shí)候,DNS 服務(wù)器返回了離該用戶最近的 CDN 節(jié)點(diǎn)的 IP,從而實(shí)現(xiàn)了用戶的就近訪問。
機(jī)房內(nèi)部
如上圖,在經(jīng)過域名解析階段后,動(dòng)態(tài)的請求會(huì)直接訪問機(jī)房(也可以做動(dòng)態(tài)內(nèi)容的加速),靜態(tài)資源在無緩存時(shí)也會(huì)回源(去機(jī)房獲取資源文件),這兩種情況都會(huì)訪問機(jī)房的 VIP。
分別經(jīng)過四層負(fù)載均衡和七層負(fù)載均衡集群后,流量被分發(fā)到業(yè)務(wù)集群。業(yè)務(wù)集群之間也會(huì)存在互相調(diào)用的情況。
對每一個(gè)關(guān)鍵集群來說都存在主備,主集群出現(xiàn)問題則切換到備集群;也可以主備集群同時(shí)提供服務(wù),每個(gè)集群都預(yù)留承擔(dān)全部流量的資源。
每個(gè)集群內(nèi)部都包含多臺(tái)服務(wù)器,少量服務(wù)器出現(xiàn)異常不影響集群提供服務(wù)。機(jī)房網(wǎng)絡(luò)出口提供備份鏈路,主鏈路出現(xiàn)問題可以自動(dòng)切換到備鏈路。
當(dāng)遇到極端情況,兩條鏈路都中斷的情況,可以切換域名的解析結(jié)果和 CDN 的回源 IP 到備份機(jī)房的 VIP,然后通過機(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ā)、測試人員的眼睛,快速發(fā)現(xiàn)和排查故障
- 將運(yùn)維數(shù)據(jù)進(jìn)行量化和可視化,便于對網(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ī)模如下:
- 覆蓋了近萬臺(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)中配置了超過 3000 個(gè)集群、近 3000 個(gè)監(jiān)控模板、近 300 萬個(gè)監(jiān)控指標(biāo)、每天實(shí)時(shí)處理的數(shù)據(jù)量超過 2T。
立體化監(jiān)控體系概述
參考網(wǎng)站的架構(gòu)圖,立體化的監(jiān)控體系包括縱向和橫向兩個(gè)方向。
縱向?qū)崿F(xiàn)了自底向上各層級的監(jiān)控,包括網(wǎng)絡(luò)、服務(wù)器、系統(tǒng)層、應(yīng)用層、業(yè)務(wù)層,如下圖所示:
橫向?qū)崿F(xiàn)了從外到內(nèi)各層級的監(jiān)控,包括用戶端、機(jī)房網(wǎng)絡(luò)出口端、流量接入端、業(yè)務(wù)端等,如下圖所示:
縱向各層級的監(jiān)控指標(biāo)
網(wǎng)絡(luò)監(jiān)控
最基本的網(wǎng)絡(luò)監(jiān)控包括:
- 機(jī)房出口 VIP 是否存活,從機(jī)房外對 VIP 進(jìn)行 ping,如果連續(xù)多次發(fā)現(xiàn) VIP 不通則發(fā)出告警。
- 流量是否正常,在四層網(wǎng)絡(luò)設(shè)備上監(jiān)測出入流量和包量等關(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ī),通過 ping 的方式對同機(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)問題導(dǎo)致大量的誤報(bào)宕機(jī)。
在監(jiān)控管理層面通過配置不同的模板,給不同集群、不同角色的用戶發(fā)送不同的告警,例如:對于數(shù)據(jù)庫主庫宕機(jī)發(fā)送語音告警,其它架構(gòu)層面支持自動(dòng)剔除故障機(jī)器的宕機(jī)發(fā)送短信告警即可。
服務(wù)器硬件監(jiān)控,通過在監(jiān)控 Agent 上部署插件,可以很好地支持多種多樣的硬件監(jiān)控,也非常便于對硬件進(jìn)行適配。對硬件監(jiān)控的覆蓋程度視業(yè)務(wù)需求而定。
系統(tǒng)監(jiān)控
服務(wù)器資源使用率,包括 CPU、內(nèi)存、磁盤、網(wǎng)卡等各項(xiàng)指標(biāo)。
對于一個(gè)中大型互聯(lián)網(wǎng)公司,業(yè)務(wù)比較復(fù)雜,服務(wù)器根據(jù)用途被劃分為不同的集群,由不同的運(yùn)維和開發(fā)人員負(fù)責(zé)管理。
那么添加這些監(jiān)控對于技術(shù)人員來說是較大的工作量,且只依靠人去添加監(jiān)控很難保證監(jiān)控的覆蓋率。我們的思路是盡可能自動(dòng)化地添加基礎(chǔ)的監(jiān)控。
我們對各個(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é)人。
通過這種方式在短時(shí)間內(nèi)做到了所有集群基礎(chǔ)監(jiān)控的 100% 覆蓋,起碼能做到服務(wù)器宕機(jī)和系統(tǒng)資源使用率問題導(dǎo)致的異常都能夠有效的發(fā)出告警,迅速解決了監(jiān)控初始建設(shè)階段的核心痛點(diǎn)。
對于某些集群,由于業(yè)務(wù)的特殊性,基礎(chǔ)的監(jiān)控模板不能滿足他的需求,可以繼承父模板的監(jiān)控指標(biāo),然后進(jìn)行告警條件、告警方式的修改。
應(yīng)用監(jiān)控
應(yīng)用監(jiān)控用來監(jiān)控部署的應(yīng)用程序是否正常,包括:端口,進(jìn)程,功能(頁面或接口),QPS,連接數(shù)等指標(biāo)。
一般來說,讓運(yùn)維和開發(fā)人員去創(chuàng)建監(jiān)控模板、關(guān)聯(lián)到集群、配置告警接收人等工作有一定的工作量,而且也有一定的難度。一些情況下,由于配置的問題會(huì)導(dǎo)致監(jiān)控和告警不能生效。
為了解決這個(gè)問題,我們基于自動(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)控。
對于功能(頁面或接口)、QPS、連接數(shù)等指標(biāo),我們也提供了部署監(jiān)控插件進(jìn)行監(jiān)控的方式。
用戶可以通過幫助文檔頁面下載多種語言(Java、PHP、Python,Shell等)的監(jiān)控插件模板,然后進(jìn)行簡單修改,采集到被監(jiān)控指標(biāo)后可以方便的接入監(jiān)控系統(tǒng)。
通過這種方式我們快速提升了應(yīng)用監(jiān)控的覆蓋率。
業(yè)務(wù)監(jiān)控
業(yè)務(wù)的監(jiān)控對象包括業(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)。
橫向各層級的監(jiān)控指標(biāo)
用戶端
有如下幾種采集數(shù)據(jù)的方式:
- 使用在用戶端網(wǎng)絡(luò)內(nèi)合作用戶電腦或手機(jī)上部署的探針進(jìn)行探測。
- 在頁面中嵌入 JS 代碼,從真實(shí)用戶的瀏覽器端對性能數(shù)據(jù)進(jìn)行采集。
- 在 APP 端嵌入 SDK,從真實(shí)用戶的 APP 對訪問錯(cuò)誤和性能數(shù)據(jù)進(jìn)行采集。
采集的數(shù)據(jù)包括用戶端可用性、首屏?xí)r間、全部資源下載時(shí)間、全部資源字節(jié)數(shù)、基礎(chǔ) HTML 頁面下載時(shí)間等數(shù)據(jù),如下圖所示:
另外,還可以對 DNS 劫持、鏈路劫持、訪問出錯(cuò)、訪問速度較慢的問題進(jìn)行告警,以 DNS 劫持?jǐn)?shù)據(jù)的展示舉例:
點(diǎn)擊圖例后,跳轉(zhuǎn)到詳情數(shù)據(jù):
機(jī)房網(wǎng)絡(luò)出口端
既可以在網(wǎng)絡(luò)設(shè)備上采集流量,也可以在四層負(fù)載均衡上采集流量。并可分別對網(wǎng)絡(luò)的連通性、進(jìn)出流量、進(jìn)出包數(shù)等關(guān)鍵指標(biāo)進(jìn)行監(jiān)控。
頁面和接口監(jiān)控
對重點(diǎn)頁面、接口的可用性、響應(yīng)時(shí)間進(jìn)行監(jiān)控。
這些監(jiān)控都是對機(jī)房出口的 VIP 發(fā)起請求,流量經(jīng)過負(fù)載均衡服務(wù)分發(fā)到后端業(yè)務(wù)集群,業(yè)務(wù)集群內(nèi)有少量服務(wù)器出現(xiàn)異常,負(fù)載均衡服務(wù)會(huì)自動(dòng)到另一臺(tái)服務(wù)器重試,異常不會(huì)暴露給外部用戶。
當(dāng)探測此處的頁面和接口監(jiān)控發(fā)現(xiàn)了異常,那么用戶已經(jīng)可見了,是比較嚴(yán)重的故障。
通過這種監(jiān)控方式也可以比較客觀的評價(jià)業(yè)務(wù)集群的運(yùn)行狀況,重點(diǎn)關(guān)注的指標(biāo)的穩(wěn)定性和響應(yīng)時(shí)間。
頁面監(jiān)控:對頁面的基礎(chǔ)頁面(即 HTML)進(jìn)行探測,連續(xù)一段時(shí)間發(fā)現(xiàn)狀態(tài)碼與預(yù)期不一致、響應(yīng)時(shí)間過長、找不到匹配的關(guān)鍵詞、頁面長度較短等情況,會(huì)發(fā)出告警。
接口監(jiān)控:對接口進(jìn)行探測,連續(xù)一段時(shí)間發(fā)現(xiàn)狀態(tài)碼與預(yù)期不一致、響應(yīng)時(shí)間過長,接口返回的消息體中業(yè)務(wù)狀態(tài)碼不符合預(yù)期或數(shù)據(jù)長度較短等情況,會(huì)發(fā)出告警。
流量接入端
大型網(wǎng)站的流量接入端包括四層和七層的負(fù)載均衡集群。
一般的網(wǎng)站可以使用 LVS 提供四層負(fù)載均衡服務(wù),技術(shù)實(shí)力雄厚的公司可以使用自己定制開發(fā)的四層負(fù)載均衡服務(wù)。
七層負(fù)載均衡端是流量接入端的重要服務(wù),處于用戶流量接入的咽喉要道,重要性不言而喻,所以要有完善的監(jiān)控。
另外由于所有流量都經(jīng)過該服務(wù),可以收集到很多用戶端訪問和后端業(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)控和告警,對業(yè)務(wù)集群還可以按照縱向各層級添加監(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)控異常查看頁面,且可以對信息進(jìn)行搜索:
另外還可以在時(shí)間維度上查看所有近期的告警:
監(jiān)控墻
為了便于值班和巡檢,我們提供了監(jiān)控墻功能,可以展示在監(jiān)控大屏上:
容量管理
為了便于提升服務(wù)器的資源利用率,及時(shí)發(fā)現(xiàn)系統(tǒng)性能瓶頸,為服務(wù)器申請?zhí)峁?shù)據(jù)支持,基于監(jiān)控系統(tǒng)的數(shù)據(jù),我們開發(fā)了容量管理系統(tǒng)。
第一步先實(shí)現(xiàn)集群的基本容量評估,通過幾項(xiàng)主要的系統(tǒng)負(fù)載參數(shù)(CPU、內(nèi)存、磁盤空間、磁盤 IO、網(wǎng)卡出入流量使用率)對集群負(fù)載進(jìn)行分析。后續(xù)可以加入更多的業(yè)務(wù)指標(biāo)來對容量進(jìn)行管理。
龔誠,58 集團(tuán)技術(shù)工程平臺(tái)部高級經(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)。