【升職加薪祕籍】我在服務監控方面的實踐(1)-監控藍圖

大家好,我是藍胖子，關於效能分析的視訊和文章我也大大小小出了有一二十篇了，算是已經有了一個系列，之前的程式碼已經上傳到github.com/HobbyBear/performance-analyze，接下來這段時間我將在之前內容的基礎上，結合自己在公司生產上構建監控系統的經驗，詳細的展示如何對線上服務進行監控，內容涉及到的指標設計，軟體設定，監控方案等等你都可以拿來直接復刻到你的專案裡，這是一套非常適合中小企業的監控體系。

溫馨提示: 本系列主要是搞懂監控什麼，如何監控的問題，對於prometheus和grafana的基本使用和指標型別不會過多的講解。

如果對prometheus的histogram直方圖和描點原理有疑惑的同學還可以看看我之前的兩篇文章,# 【prometheus】分位數統計Histogram原理 和# prometheus描點原理。

完整程式碼我已經上傳到了github

github.com/HobbyBear/easymonitor

此篇是監控實踐的開篇，我將會介紹我們監控的目的，做什麼事情，特別是開發一定要搞清楚做事的目的，之後我會介紹監控的物件，以及監控的方案選型，當然，這篇僅僅是樹立起後續我們構建監控系統的藍圖，實際的詳細步驟還是會放到後續章節裡。現在，讓我們開始吧。

監控架構一覽

這套監控系統目前還未支援對容器化的伺服器端架構提供監控，不過你依然能從這套教學裡學會常見的監控套路，設計方案。對容器化的服務進行僅僅是監控元件的設定發生變化而已。

如上圖所示，是這個系列的監控架構圖，主機上執行的應用程式會將各項指標通過介面暴露出來，node exporter 會將機器以及作業系統的指標資訊也通過介面暴露出來，prometheus 通過這些介面進行指標採集，採集到的指標將會通過grafana建立各種監控面板對其進行顯示。

在各個主機上也會有filebeat將紀錄檔經由logstash採集到elasticsearch裡，elasticsearch裡的紀錄檔通過kibana進行顯示。

在報警方面，我們是自研了一個報警系統，目的是為了針對不同專案組，不同應用服務能有不同的報警策略，目前會將紀錄檔等級為error的紀錄檔報警到對應的專案組釘釘群，同時在grafana上也針對監控面板設定告警規則，grafana觸發報警時，同樣會回撥到這個報警系統。所有應用的報警通知最終都會由報警系統進行發出。

在設計系統時，也需要考慮後續擴容的問題，這套架構主要考慮兩個方面的擴容，一個prometheus的擴容，一個是elasticsearch的擴容。

首先說下prometheus擴容的問題，如果後續指標越來越多，單個prometheus肯定是不能滿足查詢和儲存要求的，一個可行的方案是用不同的prometheus採集不同的業務系統指標。

因為伴隨著指標越來越多，我相信也不可能單個團隊或者部門需要去瀏覽所有的服務指標資訊，好的方案應該是每個部門或者開發只看他自己需要關注的指標，比如一個大型電商系統，會有許多不同的業務系統，比如行銷系統，物流系統，行銷系統的開發人員一般是不需要關注物流系統的情況的。每個業務系統開發只需各自安排人員負責各自的業務指標監控即可。所以完全可以不同業務系統使用不同的prometheus進行採集。

注意，雖然是對不同業務系統用不同的prometheus採集，但是它們的監控面板其實還是一樣的，只是指標的資料來源不同，通過grafana可以用同一套監控面板實現不同資料來源的切換。

再來談談elasticsearch擴容問題，當前的紀錄檔採集還是將多個產品線的紀錄檔統一收集到一個elasticsearch叢集裡，所以當後續紀錄檔量達到一個叢集裡不能滿足查詢需求時，首先考慮通過產品線對紀錄檔儲存進行拆分，不同產品線可以採用不同的叢集進行儲存。 但是這樣沒辦法解決一個產品線紀錄檔量過大的問題。因為我們看紀錄檔肯定是多個關聯的服務一起看，同一個產品的服務紀錄檔肯定不能程序拆分了，那就只有一個方法加elasticsearch節點 ，具體加多少節點這也和紀錄檔量有關，設定紀錄檔定期刪除可以緩解紀錄檔查詢壓力。

監控的目的

看完了整個監控報警架構，接著我們看看搞監控的目的是啥？搞清楚這個問題對我們以後如何設計指標十分具有指導意義。

監控最主要的目的是為了及時發現程式問題，這些問題提現在監控指標上可能是短時間內錯誤次數增多，服務連線數一直在上漲，記憶體使用量一直增大等，但能發現問題僅僅是第一步，發現問題後還要能定位問題出現的原因 ，往往初學者會犯的一個錯誤就是監控指標多且雜，但是卻不能很好的定位問題出現的原因。

我們往後的指標設計都將圍繞著這兩個目的去建立我們的相關指標與紀錄檔記錄，你可以發現，我們做的一切都是建立在發現問題和定位問題這兩個目的之上的。

其次，監控也會提供後續容量規劃的依據，我們能夠通過監控圖表很清晰的看出業務高低峰期的流量，壓力情況，這些指標對後續業務擴張時的資源評估具有指導意義。

監控的手段

瞭解了監控的目的，我們還需要知道，我們能通過哪些手段或者說工具來幫助我們監控服務。

常用的監控手段有指標metric，紀錄檔，鏈路追蹤，在我們這個系列裡，我麼會建立指標以及紀錄檔打點的方式對系統服務進行監控，為什麼沒有用上鍊路追蹤呢？考慮到公司應用目前並沒有過多的服務依賴，請求鏈路不長，硬生生的用上有種殺雞用牛刀的感覺，就捨棄了，在少量的服務依賴的地方，僅僅用紀錄檔打點來代替。

在紀錄檔收集方面，我採用了elasticsearch,kibana，filebeat，logstash的elfk架構構建了一個紀錄檔收集查詢的平臺，在指標方面，採用了prometheus+grafana的方案，這也是目前相當成熟的監控選型，資料很多，可以避免踩坑。

如何發現問題

接著，我們來思考下如何設計指標來發現系統服務的問題？簡而言之，需要建立哪些指標說明服務是好的或是壞的。

在這方面，谷歌提出了四大黃金指標，它有助於我們衡量服務的質量。四大黃金指標分別是:

1， 延遲 : 也就是請求耗時。 這個值越高，說明服務對外提供服務越慢。

2，流量 : 這型別指標不是單純的指網路頻寬，每秒經過系統的請求數qps也可以看成是流量的一種表現，一般情況下，qps越高，頻寬越高，流量型指標能夠衡量服務容量。

3，錯誤數 : 發生錯誤請求的次數，這型別指標簡單粗暴，最能反應服務監控狀態，短時間內大量報錯肯定是不正常的。

4，飽和度 : 這型別指標能夠反映系統的極限能力，比如一個4核的cpu，服務已經要跑滿3.8核了，那麼說明cpu要飽和了，反映到應用服務則可能是程式執行緩慢。

四大黃金指標給我們後續建立指標提供了幾個維度，我們後續建立指標時也是按這幾個維度去建立相應的指標。

業務報警

上述的指標對衡量服務的質量有很好的幫助，但有時我們出現的問題不僅僅是效能上的問題，還可能和業務掛鉤，比如業務邏輯得到的結果是錯的，如何發現這類問題。

這型別報警設計比較靈活，跟具體需求相關，在我從事的專案裡，我往往是新增了結果檢查機制，從結果看業務是否正常，比如客戶發起了一筆訂單，如果發現最後客戶扣款了，但是訂單對應的商品卻沒有到手，這種情況則是需要報警的，我們需要建立起這種報警機制，比如定時迴圈 查詢過去1小時的付完款的訂單，然後看這批訂單中是不是存在商品沒有收到的情況。如果有，馬上將對應的客戶訂單號進行報警，進行排查。

這型別的報警可能會涉及到寫檢查機制的程式碼，或者定時sql，所以一般只針對很核心的業務就行。

報警方式的選擇也很靈活，釘釘郵件皆可。

如何定位問題

知道了如何建立指標了，我們後續就可以通過相應的指標建立報警規則，從而能夠發現問題，但是根據這些指標能不能定位到問題呢？這將是我們時時刻刻需要想的。

我們知道一個應用服務是有元件依賴的，首先服務執行於作業系統上，所以應用服務想要健康，作業系統也必須是正常才行，同時應用服務依賴很多中介軟體，mysql，redis，訊息佇列等等，這些元件也都必須正常才能保證應用服務是正常的。

所以你可以看到如果你應用服務的某個指標異常了，你可能會去中介軟體或者作業系統層面去看它們的指標是否正常。整個監控其實是分層的。

分層監控是我們在建立指標時需要考慮的，通過分層監控，能夠定位到發生問題的根本原因是在哪一個層次。

我們通常按照機器監控，中介軟體監控，應用監控，業務監控這幾個層次去進行監控指標的設計，多個層次間的指標往往是相互影響的。比如當你發現在應用監控層的服務qps的指標變大了，由於應用可能會請求redis，mysql等，所以在中介軟體這一層的某些流量型別指標也會變大。

最好能定位到具體程式碼

僅僅分層監控去設計指標還不足以定位到問題的根本原因，因為我們出問題常常是程式碼的bug導致，比如 定位到了是mysql的問題， 你發現mysql的更新請求突然增加了，導致mysql的cpu和記憶體上漲，但是你能通過它去發現這是哪段程式導致的嗎？顯然不能。

我們需要更細緻的指標，和業務掛鉤的指標，資料庫和業務掛鉤的就是sql和表，如果我們沒有開審計紀錄檔的話，也可以設計按表維度去記錄每個表的crud操作次數，這樣能快速定位到是哪張表引起的更新，通過表名大致定位問題程式碼。

類似的在對redis建立指標時，可以按業務功能去劃分各個業務功能操作的次數，不過這要求我們在對redis key命名的時候要嚴格遵守相關開發規範，通過字首名去劃分不同的業務。

除此以外，應用服務出現cpu，記憶體上漲時，也要求定位到問題程式碼，這種機制可以採用與開發語言相關的一些監控工具，對於golang而言，有自帶的pprof工具，像java，有jconsle等等。我們可以在服務cpu或其他指標異常時，迅速進行取樣，在後面我也會用golang服務具體演示這一步要如何做。

請記住，你監控設計時做的一切不僅要發現問題，還要想想在發現問題後，如何快速定位問題。

總結

簡單總結下，這一節我們主要了解了整個系統的監控架構，以及監控的目的，如何去設計指標，讓自己對監控 相關的知識有個譜。 在接下來的時間，我們就要正式動手開幹了。

在萬千人海中，相遇就是緣分，為了這份緣分，給作者點個贊