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