【乾貨】58集團監控業務實踐：將網站執行資訊透明化

監控系統是服務穩定性的重要保障，本文將分享58集團監控業務實踐。總體工作思路是將網站執行資訊透明化，按照各項工作的重要性分步驟構建起立體化的監控體系。首先解決穩定性問題，再解決網站優化和節約成本的問題，有利於在短期內快速取得收益。

主要內容如下：

• 監控系統的業務定位
• 監控系統的核心需求
• 監控系統的應用規模
• 如何在監控方面快速取得收益

業務定位  

監控業務的定位可以概括為：線上服務的守護神，是服務穩定性的重要保障。

1、監控系統是運維和研發人員的眼睛，可以快速發現和排查故障。

2、監控系統將運維資料進行量化和視覺化，便於對網站優化。

核心需求  

監控業務的核心需求可以概括為：通知異常、發現故障、追查故障、預防故障、優化網站。

    1 .有效的告警（通知異常）

在監控系統發現異常後，通過告警資訊通知相關負責人。這就要求告警的有效性，有效性體現為：發生故障時要發出告警；確定是需要處理的異常才傳送告警；告警數量要控制在合理範圍內，可以深入跟蹤和處理，每天大量的告警和沒有告警是一樣的，不會引起重視；告警資訊中明確說明異常的相關資訊，通過告警可以明確知道出現了什麼異常，情況有多嚴重；告警要根據重要性分級，使用不同方式通知異常，重要的告警使用語音送達，確保告警資訊引起重視。

    2. 資料視覺化（發現故障）

監控資料視覺化有助於快速發現問題。在使用者收到告警後可以快速檢視到相關的監控資料變化趨勢，從資料上分析、定位問題。可以在告警資訊中加入連結，點選後直接跳轉到相關的監控資料檢視，這樣能夠減少查詢監控資料的時間。另外，對於使用者的個性化資料視覺化需求，可以新增自定義的監控檢視，將自己關注的指標新增進去。對於網站的重點服務和核心監控指標，將監控檢視配置為“監控牆”進行展示，便於日常進行巡檢和發現問題。

    3.    輔助排查故障（追查故障）

為了方便排查故障，除了基本的監控資料視覺化外，還需要提供一系列功能對異常告警進行展示。監控系統中可以展示所有當前存在的異常，使用者訪問系統直接看到與自己負責服務相關的異常。使用者還可以按照時間序列檢視最近處於異常狀態的事件，便於對關聯的異常進行分析，推斷故障根源原因。

為了方便了解網站在全域性的執行狀態，使用者可以在全域性檢視中看到各模組的執行狀態和模組之間的呼叫狀態，當某部分出現問題時能夠用突出的顏色標識出來。也可以定義服務之間的依賴關係，根據各服務之間的依賴關係自動分析故障的根源原因。

    4.    對告警做運營分析（預防故障）

為了預防故障，需要提供一系列功能對監控運營狀況做資料分析。

運營分析有的服務於監控系統的運營人員，以便了解監控系統的執行和使用情況，發現問題及時進行內部調整和推動相關部門進行優化。例如：每天傳送的告警電話、告警簡訊、告警郵件等的傳送次數，及近期變化趨勢。每天出現次數為TOP 10的異常型別、異常服務、異常叢集、告警接收人、異常伺服器等。

運營分析也服務於研發和運維部門的負責人。例如：相關負責人可以在web檢視自己負責範圍的異常事件資訊，也可以通過郵件報表檢視自己負責服務的告警次數和告警持續時間等。

    5.    網站系統透明化（優化網站）

通過所有服務必須包含的基礎框架採集服務之間的呼叫鏈，構建全域性系統架構檢視。通過全域性檢視，使用者可以看到各模組的執行狀態和模組之間的呼叫狀態，當某部分出現問題時能夠用突出的顏色標識出來。也可以定義服務之間的依賴關係，根據各服務之間的依賴關係自動分析故障的根源原因。另外，還能夠及時發現系統內部的不合理依賴，對架構不合理情況進行改造。

應用規模

    1.    覆蓋圍範

覆蓋58集團下網站：58同城、趕集網、中華英才網、安居客，轉轉。

覆蓋網路、主機、系統、應用、業務等多個層級。

覆蓋使用者端、IDC出口、流量接入端、IDC內部服務端。

    2.    資料規模

我們的監控系統中通過自動和人工新增的方式配置了超過萬臺伺服器和網路裝置，3000餘個叢集，近3000個監控模板，300餘萬個監控指標，每天實時處理的資料量超過2T。

工作思路  

如果要提升網站的穩定性、對網站進行優化，那麼監控是一個很好的切入點。我們的總體思路是按照各項工作的重要性分步驟構建起立體化的監控體系。首先解決穩定性問題，再解決網站優化和節約成本的問題，短期內快速取得收益。下面是一些具體步驟。

    1.    服務端基礎監控

為了保證監控的覆蓋度，首先要覆蓋所有伺服器的基礎監控，例如：伺服器是否當機、系統資源的使用率是否過高等。由於監控的新增也是需要較大的工作量，很多運維和開發人員在此方面投入的精力有限，出現問題不能及時發現。

為了解決該問題，我們從CMDB系統同步了叢集中包含的伺服器、叢集負責人等資訊，在監控系統中配置預設模板、自動新增了基礎的系統監控。這樣，當出現伺服器當機、假死、硬體故障、系統資源使用過高、埠不通、JVM狀態異常等情況，監控系統會傳送告警給對應叢集的負責人。通過這種方式，既不需要大量的人工配置，也能夠快速提升伺服器層面的監控覆蓋率。

另外我們也積極推進應用層監控和業務層監控的新增，在監控系統上提供了快速新增監控的功能，保證使用者能夠以較小的代價方便新增監控。

    2.    流量接入端監控

在完成伺服器的基礎監控後，需要對服務是否正常進行監控。由於後端業務叢集的數量非常多，逐個去新增服務的監控需要了解更多的業務資訊，一般來說需要投入更多的時間和精力。

為了在短時間內解決應用服務的監控問題，我們首先保證所有流量都經過nginx叢集進行分發，通過elk實時收集nginx的日誌，然後按照域名和後端叢集維度分別獲取錯誤率和響應時間。域名維度的監控更關注返回給使用者的錯誤率和響應時間；後端叢集維度更關注後端叢集出現的錯誤率和響應時間。

通過這種方式，我們可以對各業務叢集的狀況進行監控，故障時能快速縮小排查的範圍。

    3.    頁面監控

通過前面的工作，已經能夠對伺服器級別和重要的後端叢集進行監控了，一般較大的故障已經能夠及時發現了。

為了更好的發現一些重要的異常，我們還通過IDC出口的VIP對頁面進行監控，當IDC的出口鏈路故障或者後端叢集出現故障時能夠及時發現。該監控發現的故障是重要性較高的故障，當監控發現異常時，外部使用者已經能夠發現訪問異常。通過這些監控資料也能夠綜合評估頁面的可用性和響應時間。

    4.    網路監控

在網路監控上還需要對VIP的可用性、流量等進行監控，確保及時發現鏈路的異常。還要對各IDC之間的專線和IDC內部的網路進行監控，及時發現問題、進行優化。

    5.    資料視覺化

經過前面幾步，監控的覆蓋率已經比較高了，系統的異常已經基本都可以發現。那麼為了更方便的檢視監控資料、排查異常，需要將監控和告警的資料進行視覺化。

監控資料視覺化：可以方便的通過伺服器的IP、叢集名等方式快速檢視相關伺服器的監控指標變化趨勢，從而發現故障原因。另外，為了方便檢視常用的監控檢視，還可以定製監控檢視和監控牆，方便日常進行巡檢。

告警資料的視覺化：為了方便使用者檢視自己負責服務的異常，提供了多種角色檢視及搜尋功能便於檢視。為了方便排查相關服務的異常，還提供了按照時間軸組織的監控異常事件展示功能，在某個服務的故障時間點附近可能有依賴服務的異常告警，從而方便使用者快速定位故障的根源原因。

    6.    使用者端監控

由於使用者處於各個地域、各個運營商中，使用者的訪問速度和使用者體驗受公網的影響，與local DNS的解析、CDN的流量排程、CDN節點狀態、鏈路劫持等都有很大的關係。為了評估使用者真正的使用者體驗、及使用者網路的異常，需要通過第三方的APM或頁面中的js收集資料在使用者端進行監控。

    7.    運營分析

有了前面的監控資料，能夠從多層次、多維度進行運營質量分析，例如：

• 告警統計分析：TOP N的異常型別、服務、叢集、伺服器、告警接收人等。
• 後端叢集分析：可用性、響應時間、各種錯誤的比例。頁面的關鍵指標變化：可用性、首屏時間、載入時間、載入位元組數等。
• 動態頁面的訪問分析：在IDC出口和使用者端的對比可用性和響應時間。
• 使用者端資料分析：對使用者端的劫持和訪問較慢問題進行分析。

    8.    容量管理

容量管理也是與監控業務相關聯的，可以先從伺服器負載開始做容量管理。

通過監控資料和伺服器負載計算模型可以計算各事業群、業務線、叢集的負載情況。從而簡單、有效的評估負載情況，據此做伺服器採購預算和分配，節約成本。

在此基礎上，可以對服務叢集的極限容量進行測試和評估，做效能瓶頸分析、容量預警、彈性伸縮等。

最後我們總結一下，如果面對一個不是很穩定的站點，那麼從何入手呢？

首先可以先將監控搭建、完善起來，保證將重要的告警傳送出來、且控制告警的數量。對關鍵服務的監控包括通過nginx的日誌對後端叢集進行監控，在IDC的出口對頁面進行監控。

然後通過人工或自動化的方式逐漸提高監控的覆蓋率，輔助以監控資料視覺化、監控異常排查工具等方式縮短排查故障的時間。在保證了服務端比較穩定的基礎上，再對使用者端的訪問情況進行監控。有了這麼多的監控資料，就可以做一些運營分析，及時發現相關的問題、進行優化。

最後可以基於監控資料深入的做容量的管理，提升資源使用率、降低成本等。

QA環節

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。那麼根據這些資訊就可以完整的拼出整個網站系統的呼叫關係網，這就是所說的全域性檢視。