之前聊的《多維度立體化監(jiān)控）》，是非常完善的監(jiān)控體系，但其中還缺了一環(huán)“用戶視角的監(jiān)控”，這一環(huán)，一定程度上決定了：凌晨收到告警，我要不要立刻起床處理。

什么是用戶視角的監(jiān)控？

把系統(tǒng)內(nèi)部當作黑盒：

• 用戶怎么訪問系統(tǒng)，用戶視角的監(jiān)控就怎么訪問系統(tǒng)；
• 用戶調(diào)用哪些接口，用戶視角的監(jiān)控就調(diào)用哪些接口；

用戶視角的監(jiān)控有什么特點？

此類監(jiān)控的粒度較粗，并不直接監(jiān)控web-server, service, db, cache…

為什么要有用戶視角的監(jiān)控？

非用戶視角進行的監(jiān)控有什么不足？

如上圖所示，立體化監(jiān)控的八大維度，除了用戶視角的監(jiān)控，另外七大維度，不管是機器監(jiān)控，日志監(jiān)控，接口監(jiān)控，都是系統(tǒng)內(nèi)部發(fā)起的，當系統(tǒng)外部與系統(tǒng)之間出現(xiàn)問題的時候，例如：

• “某個省的光纖被挖斷”；
• “某條網(wǎng)絡鏈路出現(xiàn)丟包”；
• “某個地域供應商往頁面里又插入小廣告了”；

常態(tài)監(jiān)控是檢測不出來的。

只有站在用戶視角的監(jiān)控，才能檢測出類似的問題。

凌晨三點，告警短信響了，到底要不要起床檢查系統(tǒng)？

這個問題，是和技術人密切相關的問題。

如何系統(tǒng)設計的合理，不管是任何一臺 nginx, tomcat, service, cache, db 掛了，由于系統(tǒng)的高可用架構(gòu)設計，理論上都不應該影響一線用戶的訪問。

于是乎，只要用戶視角的監(jiān)控不告警，是可以第二天再起床處理其他監(jiān)控的告警的。

畫外音：這幫不靠譜的架構(gòu)師，每次都說能高可用，任何一個地方掛了，用戶就受影響了。

如何進行用戶視角的監(jiān)控？

主要有三類方法：

• 用戶所在的地方，租機房布點監(jiān)控；
• 端（APP/browser）上布點監(jiān)控；
• 使用第三方監(jiān)控平臺；

如何租機房布點監(jiān)控？

如上圖所示，在用戶所在城市租賃機房（只需要一臺服務器），部署監(jiān)控小程序，對系統(tǒng)進行外網(wǎng)訪問監(jiān)控，就能夠檢測網(wǎng)絡鏈路，路由延時。

缺點：額，各個城市租賃一臺服務器，成本有點高（不止費用，管理成本也高）。

如何端上布點監(jiān)控？

如上圖所示，假設用戶使用的是APP產(chǎn)品，可以在APP上部署一個小的監(jiān)控sdk，定期上報一些數(shù)據(jù)，根據(jù)地域IP訪問的同比環(huán)比“趨勢”判定某個地域用戶的網(wǎng)絡情況。

缺點：會損耗用戶一些流量。另外，既然是“趨勢判定”，沒有在自己機房內(nèi)布點那么精確。

如何使用第三方監(jiān)控平臺？

既然是每個公司都有的痛點，實施起來又這么麻煩，自然有創(chuàng)業(yè)公司做這個事情。

可以購買第三方監(jiān)控平臺的服務，在配置后臺配置：

• 待監(jiān)控的頁面，或者http接口；
• 頻率，閾值；
• 告警接收人；

等信息，就能夠快速實時全國各城市，甚至全世界各個國家的用戶視角監(jiān)控了，非常帥氣。

第三方監(jiān)控平臺是怎么實現(xiàn)全國，全世界布點監(jiān)控的？

額，他們租了機房。

缺點：有點貴，一般是按照調(diào)用次數(shù)來收費的。

簡單總結(jié)：

• 用戶視角監(jiān)控，把系統(tǒng)當作黑盒的一種粗粒度監(jiān)控；
• 用戶視角監(jiān)控，能檢測出局部地域的用戶訪問異常；
• 用戶視角監(jiān)控，有自主租賃機房布點，端上布點趨勢檢測，使用第三方服務三種方式；

知其然，知其所以然。

思路比結(jié)論更重要。