本文源碼:GitHub·點這裏 || GitEE·點這裏git
分佈式系統的架構,業務開發,這些在良好的思路和設計文檔規範之下,是相對來講好處理的,這裏的相對是指比較分佈式架構下生產環境的忽然故障。github
在實際的開發中,有這樣一個很妖嬈的狀況:越是核心複雜的業務,越是擔憂出問題,越容易出問題。數據庫
因此當核心服務的鏈路出現故障時,如何快速定位問題就是一件很頭疼的事情,尤爲是一些特殊狀況下,問題很模糊很難復現,外加客戶或者領導催促,這種場景內心陰影是大部分開發都有的。更有甚者,可能問題發生的切入點的開發是某人負責的,實際問題是發生在請求鏈路的其餘服務上,這種狀況遇多了,甩鍋水平會直線上升。緩存
越是複雜的系統,越是經驗豐富的開發或者運維,對監控系統就越是有執念,尤爲是全鏈路的監控,底層,網絡,中間件,服務鏈路,日誌觀察預警等,用來快速定位問題,省時省心。網絡
在分佈式系統中,須要監控的體系和層次極其複雜,一般總體上劃分爲三個層次:應用服務,軟件服務,硬件服務。架構
一般狀況,運維管理硬件服務,開發管理應用和軟件服務。併發
應用層爲開發的業務邏輯服務,也是最容易突發問題的一個層面,當在一家公司待久了,由於開發過多個業務線,就會感受本身不是開發,是個打雜的,天天都要分出大量時間處理各類問題。應用層監控涉及下面幾個核心模塊:框架
請求流量運維
任何服務,高併發的流量都會暴露各類服務問題,尤爲核心接口的流量更是監控的重點。異步
服務鏈路
一次請求發生問題,快速判斷問題所在的服務,或者哪些服務之間,這對快速處理問題是相當重要的。
日誌體系
核心接口日誌記錄也是必備的功能,一般狀況下基於日誌體系的分析結果,能夠明確系統的異常點,重點優化。
爲了解決分佈式系統的各類複雜業務場景,一般會引入各類中間軟件來作支撐,例如必備的數據庫,緩存,消息MQ等,一般這些中間件都會有自帶的監控管理端口。
數據庫:較多使用Druid監控分析;
消息隊列:經常使用RocketMQ和控制檯;
Redis緩存:提供命令獲取相關監控數據;
還有一些公司甚至直接在中間件層開發一套管理運維和監控的聚合平臺,這樣更容易從總體上分析問題。
硬件層面,運維最關注的三大核心內容:CPU、內存、網絡。底層硬件資源爆發的故障,來自上層的應用服務或者中間件服務觸發的可能性偏高。
硬件層面的監控有許多成熟的框架,例如zabbix,grafana等,固然這些組件功能很豐富,不只僅在硬件層應用。
有些故障致使大面積服務癱瘓,也稱爲雪崩效應,可能故障源沒有快速處理,也沒有熔斷機制,致使整個服務鏈路所有垮掉,這是常見的問題,因此在處理故障時,要學會基於全棧監控信息,全局關聯分析核心故障點,快速切斷單點服務的故障,保證整個系統的可用性。
監控系統雖然做用很大,可是實際搭建的時候難度仍是很大,須要有較好的意識,不是業務開發那種感受,方方面面需求都須要處理,作監控系統的基本策略以下。
不是全部服務的全部環境,和全部接口都須要監控,一般都是監控核心鏈路,核心中間件,和服務所在環境。
例如:交易鏈路,交易庫,和部署的環境;或者大客戶高併發業務,一旦出問題須要及時響應,當即處理。說的直接點,帶來收益的服務是須要重點關注的。
非關鍵服務即便出現問題,是有緩衝時間的,因此不須要花費精力添加監控,在作監控系統的時候存在這樣一句話:簡單的鏈路添加監控,複雜了容易出錯;複雜鏈路添加監控,更復雜更容易出錯,然而這樣倒是爲了更好的解決故障。
監控系統的自己發生故障,不能影響正常業務流程,即便在必定狀況下沒有監控信息,也不能由於監控服務影響正常業務服務。
聚合的監控系統能夠觀察監控鏈路的全局狀態,這樣能夠快速定位故障座標,能夠關聯性分析問題緣由。
例如CPU忽然升高,某個中間件服務忽然中止,內存佔用太高,這些能夠基於監控系統作預警通知,而後郵件或者消息通知到相關負責人,達到快速響應的目的,這個場景大部分開發都熟悉,且有心理陰影。
GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent
推薦閱讀:架構設計系列