我們想像中的監控？

我們想像中監控無所不能，是個超人。需要什麼資料，它就能給我們什麼資料；需要找到故障根源，它就能及時告知我們故障根源。

現實中的監控

可事實上並非如此，我們對監控寄予了太多，想到的就加上去，導致它越來越胖，越來越臃腫，但似乎並未解決我們的問題。

目前的監控平臺和工具都很多，開源的、商業的、甚至我們自己開發的，但都真正的解決了我們的問題嗎？

種類多樣的監控工具

所以，多並不意味著好，或者說多並不意味著有用。真正解決問題即可，而不是將有用的沒用的監控一股腦的全部搞出來，這樣只會擾亂你的視線，分散你的注意力，影響你分析和梳理故障原因和效能瓶頸。

監控的目的

我們監控的目的到底是什麼？一個好的監控需要幫助我們解決以下問題。

• 掌握系統健康狀況

• 查詢故障根源

• 系統瓶頸診斷

• 效能調優

• 排查安全隱患

故障排查過程

故障發生時，我們查CPU、記憶體、程序、網路等等，同時還要對日誌進行問題排查，php日誌、apache/nginx日誌、負載均衡及資料庫的日誌，很多時候我們排查日誌還是在使用shell命令與指令碼，對故障時間點日誌進行過濾，整個處理過程都是回溯狀態，無法做到實時，顯得手忙腳亂還無法讓我們儘快發現問題。另外，所有這些都是單點IT資源的問題排查，我們需要將各種監控聯絡起來分析考慮。
在微服務架構時代，這些單點資源的監控已經無法滿足我們的需求。

為什麼不理想？

• 維度單一、排查點太多

• 無法有效建立聯絡

• 日誌處理困難

• 不實時

• 依賴經驗

我們的結論

監控必然面臨著以上幾個進化，從基礎到業務、從靜態到動態、從表象到本質。
面向業務的監控不僅僅關注技術層面的單點資源，而是關注整個業務系統的健康狀態。
在實際場景中，使用業務監控可以替代技術監控，而且更加簡單容易理解。
大量微服務如何同時監控？CPU？負載？顯然不是這樣。
同時又是我們平臺上服務自動伸縮的依據。

業務指標

響應時間

指負載均衡將請求發給後端服務節點，經過處理後，再由後端節點返回給負載均衡的時間。這個值可以有效評估當前服務節點的處理能力並結合吞吐率瞭解當前前端訪問的壓力大小。單位是毫秒(ms)。

線上人數

指10分鐘內訪問你的網站或服務的人數，通過此監控項可以直觀瞭解到線上使用者數。

吞吐率

指1分鐘內你的網站或服務的總訪問次數。

實時服務監控

服務效能分析

• 多維度

• 實時

• 智慧

多維度使我們能夠從廣意上來全盤考慮，不再計較單一的資源情況，再好的把握多種監控資料之間的聯絡。
實時讓我們更快速的瞭解當前的系統狀態，而不是再回溯歷史。
智慧體現在對資料的處理排序上，抓住影響最大的關鍵點。

web服務效能分析

對過去5分鐘耗時最多的URL進行排行，分析一個web服務當前影響效能的最關鍵點。

mysql服務效能分析

從我們的經驗來說，對於解決資料庫的故障問題，查詢slowlog並不是最有效的方法，因為不一定最慢的是影響最大的，有些SQL是很慢，但數量並不多，也許1分鐘1條，但有些SQL的耗時並不大，可是數量巨大，對效能影響就非常高，而且並不出現在slowlog中，所以綜合耗時是關鍵。

通過服務效能分析可以直觀的看到當時的問題url與問題sql，對排查故障根源非常有效。

時間視窗

對於動態實時的監控有一個很重要的概念就是時間視窗

簡單來說就是一個 滑動視窗。固定好一個時間視窗對資料進行查詢統計。
因為資料流是持續不斷的，在對業務進行監控的時候，我們不會對所有的資料感興趣，而是對“最近五分鐘平均響應時間”、“最近十分鐘URL排行”以及“當前線上人數”這類問題更關心，要得到這些資料，通過時間視窗對資料的查詢計算即可解決我們的問題。

有哪些使用場景

• 故障提前預知

• 壓力測試

• 效能調優

監控的終級目的

現在我們回過頭來再看看前文中說過的監控目的，這些目的其實都是一個“中間過程”，還停留在“把事兒給辦了”的階段，其實監控的終級目的或者說重要意義是“價值”。
我們不是為了監控而監控，是通過監控產生價值，產出利潤。對我們的業務提供幫助，讓業務來創造更多的價值。
所以我們不要將問題複雜化，要讓複雜變得簡單，才是我們的根本。

我們的理念

我們希望可以像用水、用電一樣使用雲端計算資源，來了就用，用了就爽！
歡迎志同道合的夥伴們加入，分享成功、分享快樂！