自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

如何構(gòu)建萬臺(tái)服務(wù)器下的立體化監(jiān)控體系?

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

為了更好地幫助大家理解監(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ù)集群

對于大多數(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)行管理。

[[216609]]

龔誠,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)。

責(zé)任編輯:武曉燕 來源: DBAplus社群
相關(guān)推薦

2013-10-15 13:11:36

安全防護(hù)安全監(jiān)控安全運(yùn)維

2020-02-19 11:07:40

運(yùn)維架構(gòu)技術(shù)

2018-05-11 09:40:10

服務(wù)器運(yùn)維運(yùn)營商

2016-09-21 10:25:20

私有云360私有云平臺(tái)Syndic

2011-03-16 09:12:21

內(nèi)網(wǎng)

2018-05-15 10:34:55

2013-10-10 11:17:57

UCloud云計(jì)算

2013-08-30 13:56:25

2017-04-08 21:30:29

科比特無人機(jī)治水

2013-07-22 10:37:51

微軟服務(wù)器數(shù)據(jù)中心

2015-04-23 09:35:15

阿里云智慧城市

2016-07-12 10:40:35

服務(wù)器

2020-10-05 21:41:58

漏洞網(wǎng)絡(luò)安全網(wǎng)絡(luò)攻擊

2024-02-20 14:18:13

2016-11-11 14:58:48

IBM 服務(wù)器

2016-08-16 15:21:19

服務(wù)器

2017-04-24 16:10:19

戴爾

2018-12-06 09:07:59

Ansible服務(wù)器運(yùn)維

2012-03-14 11:31:00

云計(jì)算

2013-11-24 17:27:25

Facebook運(yùn)維Facebook運(yùn)維
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)