《58集團監(jiān)控業(yè)務(wù)實踐：將網(wǎng)站運行信息透明化》要點：
本文介紹了58集團監(jiān)控業(yè)務(wù)實踐：將網(wǎng)站運行信息透明化，希望對您有用。如果有疑問，可以聯(lián)系我們。
作者介紹
龔誠,58集團技術(shù)工程平臺部高級經(jīng)理,碩士畢業(yè)于哈爾濱工業(yè)大學(xué)計算機應(yīng)用專業(yè).曾任職于百度、新浪微博等公司負(fù)責(zé)運維及自動化團隊的技術(shù)和管理工作,在網(wǎng)站的穩(wěn)定性建設(shè)、網(wǎng)站優(yōu)化等方面有豐富的經(jīng)驗.監(jiān)控系統(tǒng)是服務(wù)穩(wěn)定性的重要保障,本文將分享58集團監(jiān)控業(yè)務(wù)實踐.總體工作思路是將網(wǎng)站運行信息透明化,按照各項工作的重要性分步驟構(gòu)建起立體化的監(jiān)控體系.首先解決穩(wěn)定性問題,再解決網(wǎng)站優(yōu)化和節(jié)約成本的問題,有利于在短期內(nèi)快速取得收益.
主要內(nèi)容如下：
監(jiān)控業(yè)務(wù)的定位可以概括為：線上服務(wù)的守護神,是服務(wù)穩(wěn)定性的重要保障.
1、監(jiān)控系統(tǒng)是運維和研發(fā)人員的眼睛,可以快速發(fā)現(xiàn)和排查故障.
2、監(jiān)控系統(tǒng)將運維數(shù)據(jù)進行量化和可視化,便于對網(wǎng)站優(yōu)化.
監(jiān)控業(yè)務(wù)的核心需求可以概括為：通知異常、發(fā)現(xiàn)故障、追查故障、預(yù)防故障、優(yōu)化網(wǎng)站.
在監(jiān)控系統(tǒng)發(fā)現(xiàn)異常后,通過告警信息通知相關(guān)負(fù)責(zé)人.這就要求告警的有效性,有效性體現(xiàn)為：發(fā)生故障時要發(fā)出告警；確定是需要處理的異常才發(fā)送告警；告警數(shù)量要控制在合理范圍內(nèi),可以深入跟蹤和處理,每天大量的告警和沒有告警是一樣的,不會引起重視；告警信息中明確說明異常的相關(guān)信息,通過告警可以明確知道出現(xiàn)了什么異常,情況有多嚴(yán)重；告警要根據(jù)重要性分級,使用不同方式通知異常,重要的告警使用語音送達,確保告警信息引起重視.
監(jiān)控數(shù)據(jù)可視化有助于快速發(fā)現(xiàn)問題.在用戶收到告警后可以快速查看到相關(guān)的監(jiān)控數(shù)據(jù)變化趨勢,從數(shù)據(jù)上分析、定位問題.可以在告警信息中加入鏈接,點擊后直接跳轉(zhuǎn)到相關(guān)的監(jiān)控數(shù)據(jù)視圖,這樣能夠減少查詢監(jiān)控數(shù)據(jù)的時間.另外,對于用戶的個性化數(shù)據(jù)可視化需求,可以添加自定義的監(jiān)控視圖,將自己關(guān)注的指標(biāo)添加進去.對于網(wǎng)站的重點服務(wù)和核心監(jiān)控指標(biāo),將監(jiān)控視圖配置為“監(jiān)控墻”進行展示,便于日常進行巡檢和發(fā)現(xiàn)問題.
為了方便排查故障,除了基本的監(jiān)控數(shù)據(jù)可視化外,還需要提供一系列功能對異常告警進行展示.監(jiān)控系統(tǒng)中可以展示所有當(dāng)前存在的異常,用戶訪問系統(tǒng)直接看到與自己負(fù)責(zé)服務(wù)相關(guān)的異常.用戶還可以按照時間序列查看最近處于異常狀態(tài)的事件,便于對關(guān)聯(lián)的異常進行分析,推斷故障根源原因.
為了方便了解網(wǎng)站在全局的運行狀態(tài),用戶可以在全局視圖中看到各模塊的運行狀態(tài)和模塊之間的調(diào)用狀態(tài),當(dāng)某部分出現(xiàn)問題時能夠用突出的顏色標(biāo)識出來.也可以定義服務(wù)之間的依賴關(guān)系,根據(jù)各服務(wù)之間的依賴關(guān)系自動分析故障的根源原因.
為了預(yù)防故障,需要提供一系列功能對監(jiān)控運營狀況做數(shù)據(jù)分析.
運營分析有的服務(wù)于監(jiān)控系統(tǒng)的運營人員,以便了解監(jiān)控系統(tǒng)的運行和使用情況,發(fā)現(xiàn)問題及時進行內(nèi)部調(diào)整和推動相關(guān)部門進行優(yōu)化.例如：每天發(fā)送的告警電話、告警短信、告警郵件等的發(fā)送次數(shù),及近期變化趨勢.每天出現(xiàn)次數(shù)為TOP 10的異常類型、異常服務(wù)、異常集群、告警接收人、異常服務(wù)器等.
運營分析也服務(wù)于研發(fā)和運維部門的負(fù)責(zé)人.例如：相關(guān)負(fù)責(zé)人可以在web查看自己負(fù)責(zé)范圍的異常事件信息,也可以通過郵件報表查看自己負(fù)責(zé)服務(wù)的告警次數(shù)和告警持續(xù)時間等.
通過所有服務(wù)必須包含的基礎(chǔ)框架采集服務(wù)之間的調(diào)用鏈,構(gòu)建全局系統(tǒng)架構(gòu)視圖.通過全局視圖,用戶可以看到各模塊的運行狀態(tài)和模塊之間的調(diào)用狀態(tài),當(dāng)某部分出現(xiàn)問題時能夠用突出的顏色標(biāo)識出來.也可以定義服務(wù)之間的依賴關(guān)系,根據(jù)各服務(wù)之間的依賴關(guān)系自動分析故障的根源原因.另外,還能夠及時發(fā)現(xiàn)系統(tǒng)內(nèi)部的不合理依賴,對架構(gòu)不合理情況進行改造.
覆蓋58集團下網(wǎng)站：58同城、趕集網(wǎng)、中華英才網(wǎng)、安居客,轉(zhuǎn)轉(zhuǎn).
覆蓋網(wǎng)絡(luò)、主機、系統(tǒng)、應(yīng)用、業(yè)務(wù)等多個層級.
覆蓋用戶端、IDC出口、流量接入端、IDC內(nèi)部服務(wù)端.
我們的監(jiān)控系統(tǒng)中通過自動和人工添加的方式配置了超過萬臺服務(wù)器和網(wǎng)絡(luò)設(shè)備,3000余個集群,近3000個監(jiān)控模板,300余萬個監(jiān)控指標(biāo),每天實時處理的數(shù)據(jù)量超過2T.
如果要提升網(wǎng)站的穩(wěn)定性、對網(wǎng)站進行優(yōu)化,那么監(jiān)控是一個很好的切入點.我們的總體思路是按照各項工作的重要性分步驟構(gòu)建起立體化的監(jiān)控體系.首先解決穩(wěn)定性問題,再解決網(wǎng)站優(yōu)化和節(jié)約成本的問題,短期內(nèi)快速取得收益.下面是一些具體步驟.
為了保證監(jiān)控的覆蓋度,首先要覆蓋所有服務(wù)器的基礎(chǔ)監(jiān)控,例如：服務(wù)器是否宕機、系統(tǒng)資源的使用率是否過高等.由于監(jiān)控的添加也是需要較大的工作量,很多運維和開發(fā)人員在此方面投入的精力有限,出現(xiàn)問題不能及時發(fā)現(xiàn).
為了解決該問題,我們從CMDB系統(tǒng)同步了集群中包含的服務(wù)器、集群負(fù)責(zé)人等信息,在監(jiān)控系統(tǒng)中配置默認(rèn)模板、自動添加了基礎(chǔ)的系統(tǒng)監(jiān)控.這樣,當(dāng)出現(xiàn)服務(wù)器宕機、假死、硬件故障、系統(tǒng)資源使用過高、端口不通、JVM狀態(tài)異常等情況,監(jiān)控系統(tǒng)會發(fā)送告警給對應(yīng)集群的負(fù)責(zé)人.通過這種方式,既不需要大量的人工配置,也能夠快速提升服務(wù)器層面的監(jiān)控覆蓋率.
另外我們也積極推進應(yīng)用層監(jiān)控和業(yè)務(wù)層監(jiān)控的添加,在監(jiān)控系統(tǒng)上提供了快速添加監(jiān)控的功能,保證用戶能夠以較小的代價方便添加監(jiān)控.
在完成服務(wù)器的基礎(chǔ)監(jiān)控后,需要對服務(wù)是否正常進行監(jiān)控.由于后端業(yè)務(wù)集群的數(shù)量非常多,逐個去添加服務(wù)的監(jiān)控需要了解更多的業(yè)務(wù)信息,一般來說需要投入更多的時間和精力.
為了在短時間內(nèi)解決應(yīng)用服務(wù)的監(jiān)控問題,我們首先保證所有流量都經(jīng)過nginx集群進行分發(fā),通過elk實時收集nginx的日志,然后按照域名和后端集群維度分別獲取錯誤率和響應(yīng)時間.域名維度的監(jiān)控更關(guān)注返回給用戶的錯誤率和響應(yīng)時間；后端集群維度更關(guān)注后端集群出現(xiàn)的錯誤率和響應(yīng)時間.
通過這種方式,我們可以對各業(yè)務(wù)集群的狀況進行監(jiān)控,故障時能快速縮小排查的范圍.
通過前面的工作,已經(jīng)能夠?qū)Ψ?wù)器級別和重要的后端集群進行監(jiān)控了,一般較大的故障已經(jīng)能夠及時發(fā)現(xiàn)了.
為了更好的發(fā)現(xiàn)一些重要的異常,我們還通過IDC出口的VIP對頁面進行監(jiān)控,當(dāng)IDC的出口鏈路故障或者后端集群出現(xiàn)故障時能夠及時發(fā)現(xiàn).該監(jiān)控發(fā)現(xiàn)的故障是重要性較高的故障,當(dāng)監(jiān)控發(fā)現(xiàn)異常時,外部用戶已經(jīng)能夠發(fā)現(xiàn)訪問異常.通過這些監(jiān)控數(shù)據(jù)也能夠綜合評估頁面的可用性和響應(yīng)時間.
在網(wǎng)絡(luò)監(jiān)控上還需要對VIP的可用性、流量等進行監(jiān)控,確保及時發(fā)現(xiàn)鏈路的異常.還要對各IDC之間的專線和IDC內(nèi)部的網(wǎng)絡(luò)進行監(jiān)控,及時發(fā)現(xiàn)問題、進行優(yōu)化.
經(jīng)過前面幾步,監(jiān)控的覆蓋率已經(jīng)比較高了,系統(tǒng)的異常已經(jīng)基本都可以發(fā)現(xiàn).那么為了更方便的查看監(jiān)控數(shù)據(jù)、排查異常,需要將監(jiān)控和告警的數(shù)據(jù)進行可視化.
監(jiān)控數(shù)據(jù)可視化：可以方便的通過服務(wù)器的IP、集群名等方式快速查看相關(guān)服務(wù)器的監(jiān)控指標(biāo)變化趨勢,從而發(fā)現(xiàn)故障原因.另外,為了方便查看常用的監(jiān)控視圖,還可以定制監(jiān)控視圖和監(jiān)控墻,方便日常進行巡檢.
告警數(shù)據(jù)的可視化：為了方便用戶查看自己負(fù)責(zé)服務(wù)的異常,提供了多種角色視圖及搜索功能便于查看.為了方便排查相關(guān)服務(wù)的異常,還提供了按照時間軸組織的監(jiān)控異常事件展示功能,在某個服務(wù)的故障時間點附近可能有依賴服務(wù)的異常告警,從而方便用戶快速定位故障的根源原因.
由于用戶處于各個地域、各個運營商中,用戶的訪問速度和用戶體驗受公網(wǎng)的影響,與local DNS的解析、CDN的流量調(diào)度、CDN節(jié)點狀態(tài)、鏈路劫持等都有很大的關(guān)系.為了評估用戶真正的用戶體驗、及用戶網(wǎng)絡(luò)的異常,需要通過第三方的APM或頁面中的js收集數(shù)據(jù)在用戶端進行監(jiān)控.
有了前面的監(jiān)控數(shù)據(jù),能夠從多層次、多維度進行運營質(zhì)量分析,例如：
容量管理也是與監(jiān)控業(yè)務(wù)相關(guān)聯(lián)的,可以先從服務(wù)器負(fù)載開始做容量管理.
通過監(jiān)控數(shù)據(jù)和服務(wù)器負(fù)載計算模型可以計算各事業(yè)群、業(yè)務(wù)線、集群的負(fù)載情況.從而簡單、有效的評估負(fù)載情況,據(jù)此做服務(wù)器采購預(yù)算和分配,節(jié)約成本.
在此基礎(chǔ)上,可以對服務(wù)集群的極限容量進行測試和評估,做性能瓶頸分析、容量預(yù)警、彈性伸縮等.
最后我們總結(jié)一下,如果面對一個不是很穩(wěn)定的站點,那么從何入手呢?
首先可以先將監(jiān)控搭建、完善起來,保證將重要的告警發(fā)送出來、且控制告警的數(shù)量.對關(guān)鍵服務(wù)的監(jiān)控包括通過nginx的日志對后端集群進行監(jiān)控,在IDC的出口對頁面進行監(jiān)控.
然后通過人工或自動化的方式逐漸提高監(jiān)控的覆蓋率,輔助以監(jiān)控數(shù)據(jù)可視化、監(jiān)控異常排查工具等方式縮短排查故障的時間.在保證了服務(wù)端比較穩(wěn)定的基礎(chǔ)上,再對用戶端的訪問情況進行監(jiān)控.有了這么多的監(jiān)控數(shù)據(jù),就可以做一些運營分析,及時發(fā)現(xiàn)相關(guān)的問題、進行優(yōu)化.
最后可以基于監(jiān)控數(shù)據(jù)深入的做容量的管理,提升資源使用率、降低成本等.
Q1：銀行業(yè)務(wù)系統(tǒng)如何監(jiān)控,用哪些技術(shù)個軟件?
A1：銀行業(yè)務(wù)系統(tǒng)的監(jiān)控思路和互聯(lián)網(wǎng)系統(tǒng)的思路是一致的.關(guān)鍵還是看：希望發(fā)現(xiàn)哪些異常?這些異常有哪些特征?如何采集這些特征?如何判斷異常?在具體的技術(shù)和實現(xiàn)上都是類似的.可以自己開發(fā)、也可以選擇開源軟件,還可以購買一些廠商的產(chǎn)品.
Q2：你們的精細化監(jiān)控是如何實現(xiàn)?需要把監(jiān)控嵌入到業(yè)務(wù)上嗎,比如：監(jiān)控業(yè)務(wù)異常(進程還在,程序報致命異常)是如何實現(xiàn)?
A2：我們希望采用的是盡可能通用、盡可能對業(yè)務(wù)代碼侵入少的方式進行監(jiān)控,這樣會減少業(yè)務(wù)添加監(jiān)控的代價.有如下幾種方式：
1、在Nginx上對后端集群的錯誤率和響應(yīng)時間進行監(jiān)控.這樣可以在整體上發(fā)現(xiàn)后端集群的異常.
2、在監(jiān)控agent上部署插件,對服務(wù)型程序的接口進行探測,判斷返回數(shù)據(jù)的格式和內(nèi)容是否正常.
3、更精細的監(jiān)控是開發(fā)一個公共庫,所有代碼在編譯打包的時候都要包含該庫.該公共庫會自動采集程序內(nèi)部的信息發(fā)給監(jiān)控系統(tǒng).具體對監(jiān)控指標(biāo)精細化到什么程度,就可以根據(jù)需求對公共庫進行開發(fā).
Q3：pc端有什么好辦法防緩存和劫持嗎?
A3：網(wǎng)站使用https防止劫持還是有一定效果的.為了更好的解決劫持,還是要通過多種方式采集用戶端的數(shù)據(jù),及時發(fā)現(xiàn)劫持,才能更好的給出解決劫持的對策.防止緩存需要根據(jù)需要調(diào)整好HTTP頭中的緩存策略.
Q4：龔老師 您好 請問你們的監(jiān)控平臺是監(jiān)控日志嗎??有沒有使用ELK?
A4：我們的監(jiān)控系統(tǒng)不只是監(jiān)控日志,也在服務(wù)器上部署了agent采集相關(guān)的信息.在“流量接入端(Nginx)”的監(jiān)控里,我們使用了ELK,實時采集Nginx的日志,分析后端集群的運行狀態(tài).
Q5: 告警收斂怎么做比較好呢?貌似不太好在精準(zhǔn)與效率之間取得平衡
A5：告警收斂最重要的是保證告警的準(zhǔn)確性.如果有告警一定是出了問題,而且需要人去處理.告警數(shù)量太多和沒有告警幾乎是一致的,因為都沒法及時的追蹤和處理.告警收斂也有很多方法,例如：連續(xù)多次異常才告警,過濾掉短暫的異常；告警最多發(fā)送3次,恢復(fù)正常后再報1條正常,減少告警數(shù)量；連續(xù)2條告警之間間隔5分鐘,確保不會頻繁的打擾在處理問題的人員；設(shè)置合理的告警閾值；設(shè)置合理的告警接收人和告警方式等.
Q6: 有什么開源的監(jiān)控軟件推薦嗎?請問你龔老師,你們的監(jiān)控系統(tǒng)是自己開發(fā)的還是開源的,使用到哪里技術(shù)和工具?
A6：強烈推薦Open-Falcon,尤其適合有大規(guī)模服務(wù)器的互聯(lián)網(wǎng)公司,它的功能、性能、可擴展能力都是很強的,也非常適合做二次開發(fā).對于服務(wù)器數(shù)量較少的公司,由于Open-Falcon的模塊較多,部署起來略微復(fù)雜,可以簡單的使用Zabbix.
我們的監(jiān)控系統(tǒng)是在Open-Falcon的基礎(chǔ)上做的二次開發(fā),在功能上對很多前端和后端模塊都進行了大量的優(yōu)化.基本的架構(gòu)和Open-Falcon類似,只是根據(jù)我們的需求增加了一些模塊.
Q7: 監(jiān)控界面,常見的告警指標(biāo)可以展示下嗎?
A7：當(dāng)前對我們最重要的一些告警指標(biāo)是：頁面監(jiān)控和Nginx后端集群狀態(tài)的指標(biāo).這些指標(biāo)出現(xiàn)異常,那么肯定會對用戶的訪問產(chǎn)生不利影響.其他一些指標(biāo)包括：各種業(yè)務(wù)數(shù)據(jù)、流量數(shù)據(jù)、接口是否正常、端口是否存活、系統(tǒng)資源使用情況等.
Q8：我們目前也在建設(shè)監(jiān)控平臺,目前使用定時器輪詢check,實現(xiàn)“實時”監(jiān)控.有沒有更好的方案,實現(xiàn)真正的實時監(jiān)控.還有聲音告警是什么樣的概念?
A8：聲音告警就是有告警事件的時候使用程序撥打告警接收人的電話,通話中用語音播報異常的內(nèi)容.實時的監(jiān)控是使用agent周期性的采集數(shù)據(jù)上報給監(jiān)控服務(wù)端,在處理數(shù)據(jù)過程中使用流式計算的模型,監(jiān)控后端模塊每時每刻都在處理agent傳輸過來的數(shù)據(jù).
Q9：如何解決告警風(fēng)暴的問題?
A9：首先按照上面一個問題的回答做好告警收斂問題.另外采用合理的策略對同一個集群、同種類型的異常進行告警合并.更進一步的可以做好告警根源原因分析,直接告訴用戶是什么原因?qū)е碌拇罅扛婢?例如某個交換機故障導(dǎo)致這個網(wǎng)段的服務(wù)器不可達.
Q10：針對項目后端接口的監(jiān)控是無侵入式的嗎?
A10：有兩種：一種是無侵入式的,通過agent調(diào)用plugin對接口進行探測；另一種是類似侵入式的,需要在編譯打包的時候包含一個監(jiān)控相關(guān)的庫文件.
Q11：怎么能盡快確認(rèn)引起故障的點呢?因為故障發(fā)生時很可能有告警風(fēng)暴.我這邊想的是把異常日志按照時間先后匯總,有什么更好的方法嗎?
A11：為了方便了解網(wǎng)站在全局的運行狀態(tài),用戶可以在全局視圖中看到各模塊的運行狀態(tài)和模塊之間的調(diào)用狀態(tài),當(dāng)某部分出現(xiàn)問題時能夠用突出的顏色標(biāo)識出來.也可以定義服務(wù)之間的依賴關(guān)系,根據(jù)各服務(wù)之間的依賴關(guān)系自動分析故障的根源原因.為了方便排查相關(guān)服務(wù)的異常,系統(tǒng)可以按照時間軸組織的監(jiān)控異常事件展示功能,在某個服務(wù)的故障時間點附近可能有依賴服務(wù)的異常告警,從而方便用戶快速定位故障的根源原因.
Q12：2.5全局系統(tǒng)結(jié)構(gòu)視圖的建立,能否展開來說下來
A12：在程序中編譯打包了監(jiān)控相關(guān)的庫,那么監(jiān)控系統(tǒng)就能夠知道服務(wù)之間的調(diào)用關(guān)系,例如知道了A調(diào)用了B,也知道了B調(diào)用了C.那么根據(jù)這些信息就可以完整的拼出整個網(wǎng)站系統(tǒng)的調(diào)用關(guān)系網(wǎng),這就是所說的全局視圖.
文章來自微信公眾號：高效開發(fā)運維
轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4256.html
