APMCon 2017｜58集團龔誠：構建立體化的監(jiān)控體系—58集團監(jiān)控實踐

　　【轉載】　作者:轉載

　　【文章簡介】

　　APMCon 2017|58集團龔誠：構建立體化的監(jiān)控體系—58集團監(jiān)控實踐 … ……

　　中國應用性能管理行業(yè)盛宴—2017中國應用性能管理大會(簡稱APMCon 2017)于8月10日至11日在北京新云南皇冠假日酒店隆重召開。本屆APMCon是由聽云、極客邦和InfoQ聯(lián)合主辦，作為國內(nèi)APM領域最具影響力的技術大會，本次大會以“驅動應用架構優(yōu)化與創(chuàng)新”為主題，致力于推動APM在國內(nèi)的成長與發(fā)展。

　　58集團技術工程平臺群高級技術經(jīng)理—龔誠于APMCon 2017智能運維專場發(fā)表了題為《構建立體化的監(jiān)控體系-58集團監(jiān)控實踐》的演講，現(xiàn)場解讀了如何將運維數(shù)據(jù)進行量化和可視化，以及58集團在監(jiān)控方面如何快速的構建起立體化的監(jiān)控體系。

　　以下為演講實錄：

　　龔誠：首先歡迎大家，我今天演講的題目是“構建立體化的監(jiān)控體系-58集團監(jiān)控實踐”，主要講一下我們58集團是如何在最近一年多時間內(nèi)，從監(jiān)控做的不是很好的狀態(tài)，發(fā)展成為相對來說比較完善的狀態(tài)的。

　　我們的監(jiān)控工作其實可以劃分為四個階段：第一階段，如何快速獲得監(jiān)控收益，最開始的時候監(jiān)控的情況不是很好，所以要快速的實現(xiàn)基本的監(jiān)控功能;第二階段，構建立體化的監(jiān)控體系，各個端、各個層面的監(jiān)控都要比較完整和完善;第三階段，提升監(jiān)控系統(tǒng)用戶體驗，基本的功能都有了，怎么能讓大家用的更爽呢，就是要提升用戶體驗;第四階段，智能化監(jiān)控和發(fā)送告警。

　　那么，我們?yōu)槭裁匆霰O(jiān)控?監(jiān)控的定位和目標是什么呢?

　　l 監(jiān)控系統(tǒng)是線上服務的守護神，是我們整個網(wǎng)站穩(wěn)定性的一個重要的保障。

　　l 監(jiān)控系統(tǒng)是技術人員的眼睛，幫助我們快速發(fā)現(xiàn)異常和排查這些故障。

　　l 監(jiān)控系統(tǒng)可以對運維的數(shù)據(jù)進行量化和可視化，便于對網(wǎng)站進行優(yōu)化。

　　58集團監(jiān)控系統(tǒng)的發(fā)展經(jīng)過了如下幾個階段：

　　一、如何快速獲得監(jiān)控收益

　　這里先說下這些監(jiān)控的痛點，我們最初面對的也是這些問題：

　　l 監(jiān)控系統(tǒng)數(shù)量非常多。由于各種歷史原因導致每個機房的網(wǎng)絡運維、系統(tǒng)運維、應用運維、各個研發(fā)部門都有各自的監(jiān)控系統(tǒng)。

　　l 告警數(shù)量非常多。每天運維人員可能要接收幾百條的短信告警，這么大的告警數(shù)量對運維人員造成很多干擾。

　　l 告警覆蓋度不夠，很多故障發(fā)現(xiàn)不了。

　　l 監(jiān)控添加起來非常繁瑣，操作步驟過于復雜。

　　l 難以輔助定位故障，不能通過告警信息和監(jiān)控數(shù)據(jù)快速定位故障。

　　l 監(jiān)控系統(tǒng)運行情況未知，沒有運營數(shù)據(jù)的分析。

　　根據(jù)這些痛點我們整理了一下對于監(jiān)控的需求，主要分為兩點：

　　1、監(jiān)控業(yè)務模型

　　l 針對集群進行監(jiān)控。早期的很多開源監(jiān)控系統(tǒng)是服務器級別的監(jiān)控，我們負責運維58集團下屬的很多網(wǎng)站，包括58同城、趕集網(wǎng)、中華英才網(wǎng)、安居客、轉轉等網(wǎng)站，我們的服務器數(shù)量是非常多的，為了管理方便，一定要以集群維度進行監(jiān)控的管理。

　　l 支持模板和模板的繼承。這么多服務器的監(jiān)控調(diào)整起來是很麻煩的，所以我們要求監(jiān)控的模型一定要針對集群進行管理。監(jiān)控策略綁定在集群層面上，不需要綁定到某一個機器，調(diào)整機器的時候可以不需要調(diào)整監(jiān)控模板，極大的簡化了監(jiān)控信息的維護。

　　l 模板中包含多條監(jiān)控策略。對于監(jiān)控肯定有很多共同的需求，可以把這些需求都寫在通用的模板里，然后用集群自己個性化的模板繼承共用的父模板，這樣既實現(xiàn)了大家共同的需求，每個人也不需要重復配置，也可以添加自己服務特殊的監(jiān)控策略，這樣很好的兼顧了通用性和個性化。

　　l 支持告警組。在一個公司里總會有人員的變更，為了方便告警管理，可以將告警發(fā)送給告警組，告警組里可以配置用戶，用戶可以隨時進行調(diào)整，有效減少了監(jiān)控的維護代價。

　　2、對監(jiān)控系統(tǒng)的要求

　　l 高穩(wěn)定性和分布式系統(tǒng)。監(jiān)控系統(tǒng)是用來保障網(wǎng)站穩(wěn)定性的，所以它自身的穩(wěn)定性就必須要高，且具有很強的容錯能力。

　　l 性能強大，支持橫向可擴展，無性能瓶頸。當我們的服務器數(shù)量和業(yè)務規(guī)模增加的時候，可以簡單通過橫向擴展各模塊的方式實現(xiàn)容量的提升，不需要對系統(tǒng)進行大規(guī)模的升級改造。

　　l 單個模塊邏輯簡單，方便二次開發(fā)。為了更好的支持我們的業(yè)務，任何一個監(jiān)控系統(tǒng)都需要根據(jù)我們自己的業(yè)務需求做一些定制化的開發(fā)，那么它的二次開發(fā)是否方便就非常重要了。

　　基于前面提到的這幾點，為了減少整個監(jiān)控系統(tǒng)的開發(fā)周期，我們以現(xiàn)在業(yè)界比較流行的open-falcon為基礎進行二次開發(fā)。

　　在第一階段的工作中，首先我們將監(jiān)控切換到open-falcon，它解決了以下三個主要問題：

　　l 解決部分服務器無監(jiān)控的問題，把很多套監(jiān)控整合為一套，把所有系統(tǒng)層的監(jiān)控、應用層的監(jiān)控、網(wǎng)絡層的監(jiān)控完全整合起來，保證了服務器級別的監(jiān)控覆蓋率。

　　l 解決告警發(fā)送數(shù)量過多的問題，主要從兩個方面：open-falcon本身就有比較好的告警數(shù)量控制的機制，可以支持定義告警最多發(fā)送次數(shù)，對異常做告警分級，對不同的告警以不同的方式來發(fā)送;也會針對不同重要性的異常進行判斷，初期只針對最核心的集群發(fā)告警。

　　l 解決了告警接收人的問題。在老的系統(tǒng)里，很多告警接收人由于業(yè)務的變化，人員的變化已經(jīng)不是很準確了，這一塊我們也重新進行了梳理和配置。

　　其次，我們開發(fā)了“快速添加監(jiān)控”的功能。在滿足基本監(jiān)控需求后，技術人員對于每個集群會有更多更個性化的監(jiān)控需求。大家用過open-falcon可能有些體會，功能非常強大，但是添加監(jiān)控的流程還是很復雜的。首先要創(chuàng)建一個集群，然后在集群里綁定一些服務器，再創(chuàng)建一個監(jiān)控模板，然后在模板里創(chuàng)建很多監(jiān)控策略，再創(chuàng)建一個告警組，告警組里加告警接收人，再把監(jiān)控模板跟告警組關聯(lián)起來，最后把集群和模板關聯(lián)起來。基本上要通過十幾個操作才能把一個集群的監(jiān)控添加好，這個過程是比較復雜的，也是容易出錯的。所以我們開發(fā)了快速添加監(jiān)控的功能，很好的解決了上述問題：

　　l 便于技術人員快速添加監(jiān)控，提升了易用性和監(jiān)控添加效率。

　　l 在一個頁面添加集群名、機器列表、監(jiān)控策略、告警接收人即完成告警添加。

　　l 可以自定義集群、監(jiān)控模板、告警接收人。

　　l 對關鍵的集群都添加了系統(tǒng)層和應用層的監(jiān)控，保障了關鍵服務的穩(wěn)定性。

　　接下來，我們實現(xiàn)了對集群自動添加監(jiān)控。如果依靠大量的技術人員依靠人工來添加監(jiān)控功能的話，必然帶來很多工作量，而且監(jiān)控的覆蓋度也無法保證，所以接下來做了自動的添加系統(tǒng)監(jiān)控。具體做法如下：

　　l 從CMDB同步信息，為各集群自動添加基礎監(jiān)控。

　　l 所有集群的模板繼承公共的系統(tǒng)監(jiān)控模板。我們會根據(jù)共同的需求整理一個公共的模板，基礎的監(jiān)控策略都配置在這個公共模板中，每個集群的監(jiān)控模板都繼承該公共模板。

　　l 告警信息發(fā)送給各集群對應的運維和研發(fā)負責人。

　　l 從自動部署系統(tǒng)同步端口號添加端口監(jiān)控。

　　l 可自定義監(jiān)控指標。在本集群的監(jiān)控模板中可以添加很多自定義的監(jiān)控指標，比如服務QPS、訂單量、用戶量等只要能采集到的指標都可以進行監(jiān)控。

　　另外我們在加強功能、提升易用性方面也做了很多工作，對于監(jiān)控來說最關鍵的無非是以下幾點：

　　l 監(jiān)控配置：方便添加常用監(jiān)控。

　　l 數(shù)據(jù)查看：便于查看監(jiān)控數(shù)據(jù)、監(jiān)控視圖、監(jiān)控墻。

　　l 告警查看：提供了多種告警的接收方式包括郵件、微信、短信和語音。

　　l 異常查看：方便查看當前有哪些異常，以及我接收告警的異常有哪些，這個功能方便大家快速的知道我負責的系統(tǒng)是否有問題。

　　上面這些工作做好了之后，在監(jiān)控方面已經(jīng)基本上能夠滿足大家的需求，為了讓系統(tǒng)起到更大的作用，也更新了幫助文檔協(xié)助大家更好的使用我們的系統(tǒng)，另外也會在公司的技術開放日，以及去各個部門宣講我們的監(jiān)控系統(tǒng)。

　　二、構建立體化的監(jiān)控體系

　　通過上圖我們可以看到網(wǎng)站的通用架構。首先在機房外部有域名解析，它會讓動態(tài)請求直接到機房進行訪問，靜態(tài)請求到CDN訪問，機房內(nèi)部有網(wǎng)絡出口以及四層和七層的負載均衡設備，再到nginx和業(yè)務集群上。剛才做的監(jiān)控工作主要在集群或者服務器維度，對于整個用戶端、機房出口端及四層、七層負載均衡設備上做的相對比較少，我們這個階段就是主要完成這些工作。

　　縱向構建立體化的監(jiān)控體系

　　上圖右側是集群和服務器維度的監(jiān)控，自底向上是網(wǎng)絡層、服務器層、系統(tǒng)層、應用層和業(yè)務層監(jiān)控。對于網(wǎng)絡層監(jiān)控我們最關心的是網(wǎng)絡設備有沒有宕機、資源使用率和流量是否正常，以及內(nèi)網(wǎng)和專線的服務質量等;在服務器層關心機器是否宕機、是否無法登陸或者是否有硬件故障;系統(tǒng)層主要關注資源使用率，例如CPU、內(nèi)存、磁盤、網(wǎng)絡等指標;應用層與應用程序更加相關了，比如端口、進程、接口狀態(tài)、服務QPS等所有與應用層程序相關的指標都可以在這里進行監(jiān)控;業(yè)務層是與具體的某項業(yè)務更加相關了，比如說我是電商類型的網(wǎng)站，那么對于訂單量、交易量就會非常關注。

　　橫向構建立體化的監(jiān)控體系

　　再來看橫向的監(jiān)控，前面我們提到了比較粗略的通用網(wǎng)站架構圖，我們把這些信息略微細化一些，從左到右，首先是在機房外部對域名的解析。由于用戶處于一個比較復雜的公網(wǎng)環(huán)境當中，所以用戶訪問過程中會遇到很多如DNS劫持、鏈路劫持等問題，導致無法訪問正常。對于CDN節(jié)點來說，也會出現(xiàn)一些跨運營商或者跨區(qū)域調(diào)度造成的訪問速度較慢問題。對于我們機房的網(wǎng)絡出口，VIP是否正常也是需要我們監(jiān)控的。在四層負載均衡設備上我們比較關心流量的變化，在七層負載均衡服務上比較關心域名、集群維度的錯誤率(狀態(tài)碼)、響應時間等指標的變化。再往右看，業(yè)務集群的監(jiān)控跟縱向監(jiān)控更加相關了，關注集群和服務器的維度。

　　基于上述的分析，我們在用戶端監(jiān)控對于一些重點頁面的關鍵指標進行了監(jiān)控，包括頁面的首屏時間、全部加載時間、可用性等。這些指標能夠幫助我們比較好的描述網(wǎng)站的用戶體驗是怎么樣的。對于DNS劫持、鏈路劫持、頁面訪問較慢、訪問錯誤等都進行了監(jiān)控。

　　在機房網(wǎng)絡出口端，首先會對VIP是否存活做監(jiān)控，也會在業(yè)務層上針對關鍵頁面或者關鍵接口從機房出口VIP上進行探測，這樣可以比較清楚的知道整個集群服務所提供的服務狀態(tài)是如何的。因為是直接從機房網(wǎng)絡出口進行探測的，所以它不會受到公網(wǎng)服務質量的影響，能夠比較全面的評價從流量接入端到后端業(yè)務集群的服務質量。另外也會對集群中的每臺服務器做頁面和接口的監(jiān)控，便于發(fā)現(xiàn)部分服務器的異常。

　　在流量接入端的網(wǎng)絡設備上可以監(jiān)控流量變化，以及是否受到攻擊。另外在Nginx上可以針對域名維度、集群維度進行監(jiān)控，評價域名和集群的可用性和響應時間。

　　在業(yè)務端集群，監(jiān)控的維度是針對于單機和集群的。單機的監(jiān)控更像剛才提到的縱向監(jiān)控，從網(wǎng)絡層、服務器層、系統(tǒng)層一直往上，還有針對服務器的頁面和接口監(jiān)控。針對集群，一方面有通過機房的網(wǎng)絡出口做的頁面監(jiān)控和接口監(jiān)控，另一方面也會通過Nginx上的一些流量的變化看后端業(yè)務集群的運行狀態(tài)，看它整體的可用性和響應時間。

　　所以簡單的總結一下，構建立體化的監(jiān)控體系是從縱向和橫向兩個維度來實現(xiàn)的。

　　立體化監(jiān)控體系構建完之后還要在監(jiān)控的核心功能上下功夫，比如監(jiān)控的添加、數(shù)據(jù)的查看、監(jiān)控數(shù)據(jù)視圖、告警查看、提供更好的功能以方便我們快速發(fā)現(xiàn)故障、排查故障、解決故障。另外，我們也做了很多運營質量評估方面的工作，我們認為監(jiān)控要做的一項比較重要的工作是使整個網(wǎng)站的運行信息透明化，原來沒有監(jiān)控的時候整個網(wǎng)站像一個黑盒子，哪個地方運行的好或不好、哪個地方是瓶頸我們都不清楚，通過監(jiān)控系統(tǒng)可以把它由黑盒子變?yōu)榘缀凶?，每部分的運行情況都清清楚楚，這樣就知道哪部分出現(xiàn)的異常更多，哪部分是性能瓶頸，需要及時進行優(yōu)化。我們運營質量評估分成了三個層次：

　　l 業(yè)務集群：在Nginx上看整個業(yè)務集群的服務質量怎么樣。

　　l 機房網(wǎng)絡出口端：看流量經(jīng)過TGW，Nginx和業(yè)務集群的整個過程的服務質量。

　　l 用戶端：以用戶視角在公網(wǎng)環(huán)境看服務的質量。

　　三、提升監(jiān)控系統(tǒng)的用戶體驗

　　監(jiān)控的基本功能都可用后，完善的用戶體驗就成了我們的重要目標。剛才也提到了open-falcon本身添加監(jiān)控是比較復雜的，我們發(fā)現(xiàn)用戶在使用的時候也會覺得比較困惑，添加監(jiān)控、管理監(jiān)控總會出現(xiàn)一些錯誤的情況，怎么辦呢?

　　簡化監(jiān)控業(yè)務模型

　　之前提到過，open-falcon的監(jiān)控模型是相對比較復雜的，如下圖所示：

　　所以我們就對監(jiān)控的業(yè)務模型進行了簡化，所有監(jiān)控的配置項都是與服務樹的節(jié)點也就是集群進行關聯(lián)，集群是我們從CMDB里同步過來的，集群會關聯(lián)服務器列表，集群也會關聯(lián)唯一的監(jiān)控模板，這個監(jiān)控模板會繼承公共的監(jiān)控模板，就是說一些通用的監(jiān)控項都已經(jīng)在里面設置好了。另外我們把之前關聯(lián)在監(jiān)控模板上的告警接收人直接關聯(lián)到集群上，這樣的話對于一個集群的監(jiān)控只需要關注這三點：服務器的列表、監(jiān)控的模板和告警接收人。只要這三部分信息都設置正確了，那么這個監(jiān)控的添加肯定是沒有問題的，這樣既滿足了我們的需求又極大降低了復雜性。簡化后的監(jiān)控業(yè)務模型如下：

　　Web頁面框架和服務樹模型

　　我們在監(jiān)控系統(tǒng)Web界面的展示上提供了基于服務樹的展示模型。所謂服務樹模型是將公司整個集團下屬的事業(yè)群、業(yè)務線、集群按照一個樹型的結構進行組織。當你想操作某一個業(yè)務線或者某個集群的時候，選擇服務樹里這個節(jié)點就可以對它進行操作了。

　　另外我們的監(jiān)控系統(tǒng)除了包含開源的open-falcon之外還有很多自研的系統(tǒng)，這么多系統(tǒng)怎么樣更好的進行整合呢?如何統(tǒng)一整體的用戶體驗、頁面的風格以及交互方式呢?如果上述方面統(tǒng)一的話，在用戶看來學習的代價就會很小、易用性就會很好。所以，我們使用了一個統(tǒng)一的web框架，用戶操作的時候，首先通過服務樹節(jié)點選擇一個操作范圍，然后通過菜單選擇使用的功能，頁面中就可以展示相關的業(yè)務信息了。這樣就可以把用戶使用監(jiān)控系統(tǒng)的交互方式統(tǒng)一了。我們也對自研的監(jiān)控相關系統(tǒng)做了整合，包括Nginx業(yè)務流量的監(jiān)控、網(wǎng)絡的監(jiān)控、用戶端監(jiān)控、IDC出口以及運營質量數(shù)據(jù)等。

　　我們根據(jù)簡化的監(jiān)控業(yè)務模型開發(fā)了一套web的頁面，如下圖所示：

　　這個頁面展示的是統(tǒng)一的web框架和服務樹模型：左側是樹型的結構，根節(jié)點是58集團，下面是各個事業(yè)群，再下一級節(jié)點是業(yè)務線，再下一級節(jié)點是集群;頁面上面是一排菜單，每一項是一個一級菜單，當把鼠標放上去的時候會看到二、三級菜單。在左側的服務樹上選擇服務樹節(jié)點相當于選擇了一個業(yè)務的范圍，也就是要操作的是這塊業(yè)務;在上面的菜單中選擇某個菜單就是選擇某個功能，兩者都選中后，右側就會顯示出相關的業(yè)務頁面，用戶就可以完成相關的數(shù)據(jù)查看和管理操作了。

　　監(jiān)控信息的管理

　　剛才提到過，管理監(jiān)控需要關注三部分信息：

　　l 告警接收人：這里可以看到配置了哪些告警組，包括出現(xiàn)異常時發(fā)送告警的告警組，以及告警升級后的告警組。

　　l 監(jiān)控模板和監(jiān)控策略：通過這里可以看到，集群對應的模板是繼承了一個公共的父模板，在父模板里定義了一些像剩余磁盤空間、系統(tǒng)的負載、是否宕機等這些最基礎、最重要的監(jiān)控。另外，在這個集群的監(jiān)控模板中可以根據(jù)它的需要去添加一些個性化的監(jiān)控策略。

　　l 服務器的列表：在服務樹里面搜索某一個集群，服務樹上自然會把包含關健詞的集群顯示出來，選中這個集群直接可以看到這個集群的服務器列表。當集群中的服務器列表發(fā)生變化的時候，可以在這里增加機器或者刪除機器，并且可以看到某臺機器是不是被其他集群共用。

　　上述的信息對每個集群來說都自動添加了監(jiān)控，只要維護好了每個集群的上述信息，就能夠正常的告警了，通過這種方式極大的降低了監(jiān)控的維護代價。

　　告警發(fā)送策略優(yōu)化

　　我們在原來open-falcon的基礎之上做的一點改進。我們對告警進行了分級，并且提供了多種方式發(fā)送告警，包括：郵件、微信、短信、語音，不同重要程度的告警采用不同的方式進行通知。

　　open-falcon在異常告警的發(fā)送次數(shù)控制上做的還是比較好的，它可以控制發(fā)送告警的最多次數(shù)，比如設置告警發(fā)送次數(shù)最多為3次，當告警發(fā)了3次之后就不會再發(fā)了，直到從異常中恢復了才發(fā)一條恢復正常的告警。我們來看一個場景，如果前3條告警由于運營商問題沒有收到或者負責人當時正在忙什么事把這個告警忘記了，這個異常要持續(xù)幾天甚至幾十天，那么對網(wǎng)站穩(wěn)定性有很大的威脅，所以我們增加了告警升級和告警提供功能。

　　比如說我們設置的連續(xù)3次異常的時候再告警，兩次告警時間間隔5分鐘，最多告警3次。我們結合上圖看一下，藍色的線是時間軸，底下的數(shù)字代表時間，綠色代表數(shù)據(jù)正常的點，紅色代表數(shù)據(jù)異常的點，在前3分鐘連續(xù)3次出現(xiàn)了異常，所以它發(fā)出了第一條黃色的告警，5分鐘之后發(fā)送了第二條，又過了5分鐘又發(fā)送了第三條告警。按照之前的策略，這個告警如果不去處理的話，可能未來幾天甚至幾十天都不會發(fā)任何告警，我們這里增加了一個策略，在最后一條告警發(fā)送完之后30分鐘后如果異常還存在則會把告警升級，且使用更明顯的方式提醒用戶。另外如果說這個故障持續(xù)時間超過一天了，之后的每一天我們也會給再發(fā)告警提醒一次。

　　當前異常信息的查看

　　當前異常信息的查看也是監(jiān)控系統(tǒng)中非常重要的一項功能，下圖就是該功能的頁面，這里可以通過服務樹選擇一個業(yè)務范圍，選擇查看整個公司的異?；蛘咧徊榭茨硞€業(yè)務線或者集群的異常。右側還有“我的告警”選項，選中這個選項會看到所有與“我”相關的告警和異常，頁面還可以根據(jù)設置自動刷新，這個功能對于運維值班和做系統(tǒng)巡檢是非常有用的。

　　這個頁面是展示的當前處于異常狀態(tài)的告警，當它從異常狀態(tài)恢復到正常之后這個信息就自動消失了。另外在這里也可以很方便的進行搜索，比如根據(jù)告警條件、異常類型甚至告警接收人進行搜索。

　　如下頁面展示了最近的告警事件有哪些：

　　這個頁面把每個告警事件作為一個圓圈展示出來，圓圈越大說明告警級別越高，顏色越深代表告警次數(shù)越多，而且把鼠標放到某個圓圈上的時候能夠看到某一個告警的詳情。因為服務有可能依賴于一些存儲服務或依賴于別人的接口，所以當出現(xiàn)異常的時候，可以上來看一看是不是跟你相關的服務在這個時間附近也出現(xiàn)了異常，有可能因為它的異常引起我們服務的異常。

　　監(jiān)控數(shù)據(jù)查看

　　監(jiān)控數(shù)據(jù)的查看也是非常重要的一個功能，故障時對異常原因進行排查、做完系統(tǒng)優(yōu)化后對比效果、規(guī)劃系統(tǒng)容量等操作都會用到這個功能。

　　用戶操作界面如下圖所示：

　　用戶在使用該功能的時候，首先在左側服務樹里選擇事業(yè)群、業(yè)務線或者集群，在右側會顯示出來它對應節(jié)點下的機器列表，而且在上面可以對IP模式進行一定的搜索，通過右側的常用指標選項可以快速選擇我們平時常用的監(jiān)控指標，比如概況、CPU、磁盤、IO等，這樣就能夠很方便的通過幾次點擊的方式看到一些常見的視圖。當然高級搜索可以滿足更加個性化的需求。點擊看圖按紐就能夠看到相關的監(jiān)控數(shù)據(jù)。

　　當然這些監(jiān)控數(shù)據(jù)可能不只是今天看一下，有可能平時工作當中會常常查看的一些視圖，可以在這里面點擊生成視圖按紐，生成視圖并且收藏起來。那么下次直接在“我收藏的視圖”中就可以快速查看監(jiān)控視圖了，我生成的視圖也可以被其他用戶收藏和查看。

　　監(jiān)控墻

　　我們把核心數(shù)據(jù)放到監(jiān)控墻中展示，可以很方便的看到網(wǎng)站運行中最重要的一些數(shù)據(jù)。

　　容量管理

　　通過監(jiān)控系統(tǒng)采集的服務器的數(shù)據(jù)和業(yè)務相關的數(shù)據(jù)，也可以針對不同的容量、負載模型進行計算，得出每個集群、每個業(yè)務線相關的負載指數(shù)，通過雷達圖可以展示各個分項指標，可以很好的規(guī)劃容量，也可以在分配服務器的時候有效的控制服務器成本。

　　運營質量評估

　　在運營質量評估方面，我們可以針對業(yè)務集群維度、機房IDC出口維度、用戶端維度進行評估。這個頁面展示了集群的關鍵指標，可以看到某事業(yè)群下面的多個集群的響應時間。

　　我的監(jiān)控

　　對于大家平時常用的功能，都可以在這個菜單內(nèi)找到，比如我收藏的視圖、我負責的異常、我訂閱的告警、我的集群和我的模板等。如下是訪問監(jiān)控系統(tǒng)首頁后默認展示的“我收藏的視圖”頁面：

　　四、智能化的監(jiān)控和告警信息

　　告警信息的合并

　　l 同服務器告警合并。我們可以對同一個服務器的告警進行合并，因為如果一個服務器宕機的話這個機器上肯定有其他的告警，只需要告訴用戶這個服務器宕機就可以了。

　　l 同集群告警合并。由于用戶流量特別大或者程序出現(xiàn)某個bug，這個集群當中每一臺服務器都會出現(xiàn)告警，如果同時發(fā)幾十條告警也是一種干擾，所以我們對同一個集群的告警進行了合并，直接發(fā)送一條告警。

　　l 同網(wǎng)段的宕機合并告警。由于某個交換機出現(xiàn)了異常，肯定有同網(wǎng)絡上的機器出現(xiàn)了大量的丟包告警消息，其實這些告警合并起來就可以推斷出某個交換機網(wǎng)絡設備出現(xiàn)了問題。

　　l 同根因的告警合并。當監(jiān)控的覆蓋度比較高的時候，對每一個層級都會有監(jiān)控，如果一個集群出現(xiàn)問題就會在很多層級的監(jiān)控告警體現(xiàn)出來，這些問題都是可以進行合并的。

　　告警信息優(yōu)化

　　l 提供更多的告警方式：對異常告警進行分級，增加語音告警和微信告警。

　　l 告警信息豐富化：在微信告警中，可以展示更豐富的信息。除文字外增加了很多監(jiān)控指標相關的圖片，能夠直觀看出異常數(shù)據(jù)的變化趨勢。另外也增加很多鏈接，可以快速的通過點擊這些鏈接修改相關配置信息。

　　l 異常的根因分析：需要我們逐漸構建起運維的知識庫推斷出來異常的根源原因。

　　新的監(jiān)控策略

　　l 數(shù)據(jù)的同比環(huán)比監(jiān)控：可進行趨勢異常變化的告警和數(shù)據(jù)對比展示。

　　l 數(shù)據(jù)的異常變化率監(jiān)控：連續(xù)一段時間內(nèi)數(shù)據(jù)出現(xiàn)突增和突降。

　　l 集群中異常機器比例監(jiān)控：集群中超過一定比例的機器有問題才發(fā)告警。

　　l 組合條件的告警：多個監(jiān)控指標都滿足條件則告警。

　　l 容量監(jiān)控：預測即將達到容量水位則告警。

　　故障自愈

　　l 服務器宕機自動處理：如果服務器宕機，自動重啟服務器;如果服務器出現(xiàn)硬件故障可以通過服務器的機型、對網(wǎng)絡的需求等信息自動分配備機。

　　l 磁盤空間不足自動處理：通過一些告警事件觸發(fā)自動刪除一些預定義目錄的文件。

　　l 負載升高自動擴容：當集群負載升高，達到警戒值后自動調(diào)用部署管理系統(tǒng)和云平臺，自動對系統(tǒng)做擴容。

　　l 流量自動調(diào)度：當某個機房或網(wǎng)段出現(xiàn)問題時，操作TGW和Nginx進行流量調(diào)度。

　　我今天分享的內(nèi)容就是這些，謝謝大家!

　　QA：

　　問題：Nginx的日志監(jiān)控是怎么做的?

　　龔誠：使用ELK將Nginx日志實時傳輸和計算，再把數(shù)據(jù)實時灌到open-falcon里，通過open-falcon做數(shù)據(jù)展示和告警?，F(xiàn)在正在從ELK遷移到storm。

　　問題：對于關鍵業(yè)務的關鍵接口，這些接口監(jiān)控是在Nginx日志里分析還是請求接口做的?

　　龔誠：兩方面都有，我們會實時分析nginx日志，也會實時對接口發(fā)送請求進行監(jiān)測。

　　問題：監(jiān)控DNS劫持和用戶打開頁面體驗好不好的監(jiān)控是怎么做的?

　　龔誠：通過聽云在全國各區(qū)域各運營商的探針采集數(shù)據(jù)，然后將原始數(shù)據(jù)拉回來自己做分析，再進行數(shù)據(jù)展示和告警。

　　問題：我想問怎么做壓縮告警，因為我們的日志有可能發(fā)生大量的error，假如1分鐘內(nèi)有100個A錯誤、1個B錯誤，又有100個C錯誤，理想的狀態(tài)是收到三條告警?，F(xiàn)在我們是通過一個case來判斷次數(shù)的，但是這個次數(shù)沒有做智能壓縮的，只能是一分鐘收到多少條就壓縮為一條，但是不能把不同的錯誤分級別發(fā)出來，您這一塊是怎么做的?

　　龔誠：這個是具體實現(xiàn)層面上的事情，告警可以按照不同業(yè)務需求進行實現(xiàn)，需要具體問題具體分析。剛才你說的情況是根據(jù)錯誤的類型對告警數(shù)量進行合并，你可以每分鐘對這些錯誤的數(shù)據(jù)按照錯誤類型進行合并，得到A錯誤100次、B錯誤1次、C錯誤100次，然后將這3個信息使用不同的監(jiān)控指標推給監(jiān)控系統(tǒng)，對不同的指標設置不同的告警策略和級別，就能夠實現(xiàn)對不同錯誤類型做告警分級。

　　問題：是我們自己研發(fā)還是用第三方比較好，因為開源工具包括小米的還是其它都實現(xiàn)不了。

　　龔誠：要把自己的需求和開源系統(tǒng)較好的結合起來，開源監(jiān)控系統(tǒng)實現(xiàn)的都是通用的模型和功能，自己的業(yè)務要選擇一個好的方式和開源系統(tǒng)結合起來。跟自己業(yè)務和需求相關的部分，要自己控制這部分邏輯，把數(shù)據(jù)處理成標準格式后，再推給監(jiān)控系統(tǒng)，使用開源的系統(tǒng)來解決。