1. 淺談系統監控

作為一名開發人員，對“監控”這個詞應該是無比的熟悉，它是系統高可用的核心保障之一，完善的監控體系不僅可以迅速發現異常還能在一定程度上預測即將發生的異常，即故障洞察和故障預測。本文主要向大家介紹一下UI自動化低代碼平臺webeye，在此之前，我們先簡單的聊一下“監控”。

1.1常見的監控形式

根據不同的監控數據形式，可以分為：Logging(日志)、Metrics(指標)，隨著微服務架構的興起，Tracing(鏈路追蹤)變成了不可或缺的一種數據形式，它記錄著某次RPC調用信息，也可以將他理解成一種特殊的訪問日志，所以筆者更傾向于將他歸為Logging的一種。下面分別介紹一下這幾種監控數據：

Logging：記錄離散的事件信息，如訪問日志、程序日志等。

Metrics：記錄可被聚合的數據，一般都是具體的數值，如某一時刻機器的IO負載、CPU使用率或者某個消息隊列的積壓數等。早期單機時代的zabbix以及現在云原生時代被廣泛使用的prometheus，均是比較常見的Metrics采集工具。

Tracing：記錄請求范圍內信息，最常見的就是記錄一次RPC的調用過程和執行耗時，目前的大型互聯網應用大多是采用微服務架構，系統間的依賴關系會越來越復雜，Tracing的誕生就是為了追蹤調用鏈路，梳理出系統依賴關系(類似于Linux下的traceroute和windows下的tracert命令，用來追蹤從本地計算機到遠程主機所通過的所有路由信息)。

通過上面的分析，我們可以發現Logging和Metrics的一個明顯區別：Logging是離散數據而Metrics則是一種基于“時間點”線性狀態數據，因此Metrics存儲時，一般會采用InfluxDB之類的時序數據庫。這也是為什么筆者認為Tracing實質上是一種Logging的原因。

1.2體系化監控

上面我們簡單的介紹了監控數據的類型，那么在實際業務中，我們應該如何基于現有的數據載體搭建一套完善的監控體系呢?筆者認為，傳統的Web互聯網服務可以分為五層(硬件、中間件、后端程序、業務流程、UI)，如下圖1所示，我們的監控應該覆蓋每一層。

圖1：分層監控

物理層監控：對IaaS層硬件指標進行監控，如CPU使用率、網絡IO、RAM使用量等Metrics類型的數據。主流做法是使用Agent程序采集硬件指標，再將這些指標數據存入時序數據庫，再定期檢索指標數據，通過判斷閾值的方式觸發報警。

中間件監控：對PaaS層中間件指標進行監控，如Web Server吞吐、JVM內存使用情況、RDMS QPS數等。實現方案與物理層類似，如Prometheus社區提供各種中間件的指標收集程序(Exporter)，通過Service Mesh模式采集指標。

應用監控：主要對應用的運行日志進行監控，包括：程序日志、訪問日志、調用鏈日志等。程序日志一般在程序運行時上報，而訪問日志大多由Web Server自動收集，調用鏈日志由框架(如：Skywalking)自動采集，然后將這些離散數據存入分布式數據庫(如：ES)，監控程序通過定期檢索日志進行監控。

業務流程監控：監測業務鏈路是否通暢，與上述幾種監控方式不同，業務流程監控通常不具備通用性。常見的做法有兩種：

(1)提供業務接口，該接口內提供完整的業務操作和校驗流程，通過對接口返回內容進行解析，判斷業務是否正常。筆者支持的某個業務依賴第三方OCR識別駕照的服務，該服務經常出現接口正常返回，但是圖片內容無法識別的問題，為了及時發現服務異常，可以通過接口的形式，周期性將一張已知駕照圖片提交給接口，通過解析識別結果判斷服務是否正常。

(2)通過直接檢索業務數據庫，業務完整性，之家內部的鷹眼系統提供了通過直接執行sql進行監控的能力，通過解析ResultSet實現業務監控的方案。如常見的留資業務，系統收到用戶的留資數據后，需要通過定時任務對線索信息進行補齊，然后再執行外呼清洗和推送流程。那么就可以通過檢索原始線索數據是否完整，清洗記錄表、推送記錄表是否存在關聯數據記錄，從而判斷流程完整性。

UI監控：通過對頁面展示內容、交互流程進行監控，確保頁面正常工作。UI離用戶最近，最能直接影響用戶體驗，同時，由于網絡環境復雜，設備版本差異，UI問題出現頻繁。常見的UI監控包含插件監控和UI自動化兩種，下面給大家詳細介紹一下。

2. 常見的web監控方案

2.1插件監控

插件監控主要通過在H5中引入js腳本，通過JS收集頁面中的錯誤和性能數據，再將數據上報到ES集群中，通過檢測日志實現錯誤報警，比如之家內部的ftwo系統。這種監控方式存在不足：

1. 時效性低，只有在用戶訪問頁面時，監控程序才會開始工作，因而無法早于用戶發現問題;

2. 網絡或機房故障類型錯誤無法檢測，頁面返回404或502，頁面未加載的情況下， 無法監控異常;

3. 局限性：只能發現腳本、網絡等通用錯誤，無法對業務邏輯和頁面內容進行監控。

2.2UI自動化

使用pupputeer等無頭瀏覽器，通過Python、nodejs等腳本語言，構建case，這種主動探測的監控方式比較常見，檢測精度高，但是學習和維護成本高。

基于以上分析，需要實現完善的UI可用性監控，使用UI自動化無疑是更好的選擇，但是其高昂的case維護成本，導致其在筆者所在的業務沒有被廣泛應用。那么有沒有一種兼顧有效性和低成本UI監控方案呢?

3. webeye系統介紹

3.1什么是webeye

UI自動化的核心思路是通過腳本語言模擬一系列的人工操作，實現自動化人工頁面巡檢的操作，在這里，我們不妨抽象一下用戶巡檢的流程：

1. 打開F12，用于觀察是否存在腳本或網絡錯誤;

2. 輸入網址，觀察網頁是否正常打開;

3. 查看頁面內容，確定內容是否正確;

4. 與頁面交互(滑動、點擊、輸入)后，觀察頁面反饋是否正常;

webeye系統是一個基于用戶巡檢的核心思路，通過headless browser實現一套配置式的UI自動化的低代碼平臺。webeye中有兩個核心概念：“動作”及“校驗器”：

動作：模擬一系列用戶操作，如：打開頁面、鼠標滾動、內容查找、用戶點擊、用戶輸入等。

校驗器：通過監測頁面運行中的頁面錯誤或非預期內容，從而觸發報警。包括全局校驗器與動作校驗器。全局校驗器貫穿在整個頁面生命周期中，如圖片加載失敗，js錯誤等，動作校驗器是對某個具體用戶動作產生的結果進行校驗，如打開頁面后，判斷可見DOM數量是否符合預期等。

動作與校驗器的關系如圖二所示：

圖2：用戶動作與校驗器

3.2webeye中的動作與校驗器

上文提到，webeye中存在動作和校驗器兩個核心概念：動作和校驗器。校驗器分為全局校驗器和動作校驗器，動作校驗器是對具體動作執行后的結果進行校驗，所以我們先介紹一下全局校驗器，后面介紹動作時，同時介紹關聯的動作校驗器。

?全局校驗器

http狀態碼校驗器(http_status_error)：捕捉頁面生命周期內非200的http請求;

網絡請求錯誤(network_error)：監聽生命周期內全部失敗的http請求，它與http_status_error核心區別是http_status_error關注response中的狀態碼，network-error更加關注請求本身，如域名DNS解析錯誤、CORS請求失敗等;

API請求錯誤(api_error)：xhr接口內容監控，之家內部使用的接口協議均包含returncode 字段，可以通過檢測 returncode 的值是否0從未判斷接口是否異常;

js錯誤(js_error)：頁面生命周期內的js錯誤。

? 動作及動作校驗器

打開頁面(load)：通過puppeteer打開指定URL，并等待加載完成。動作校驗器有：可見dom數量(visible_dom_count)，即頁面加載完成后，檢測可見dom數量是否達到閾值。在SPA應用中，經常出現因CDN異常，后臺配置錯誤等導致頁面白屏或一直loading：

圖3：可見dom數量校驗報警

內容查找(query_dom)：通過指定的選擇器選擇進行dom查找，并將查找結果暫存供檢驗。query_dom有兩個動作校驗器：匹配元素數量(query_dom_count)及匹配內容(query_dom_content_contains)。query_dom_count用來校驗匹配的元素數量，如某商品面，校驗SKU數量是否符合預期。query_dom_content_contains用來校驗查找結果中是否包含具體文本內容，如某次業務上線，導致頁面個別模塊展示開關失效，該模塊直接消失：

圖4：內容匹配失敗報警

鼠標滾動(mouse_wheel)：在垂直方向上模擬鼠標滾動指定距離。

用戶點擊(user_click)：模擬指定DOM元素的點擊。

用戶輸入(user_input)：模擬文本框內容輸入。

4. webeye使用案例

如圖5所示，是一個典型的留資場景的業務，我們以它為例，看看配置一個UI監控有多簡單。

圖5：留資業務頁面示意圖

動作1：執行load，地址為https://m.autohome.com.cn/some_query，校驗器：visible_dom_count閾值設置為10(根據頁面元素多少，動態設置)，該步驟可校驗頁面是否正常打開并正確顯示內容;

動作2：執行dom_query，選擇器為“span.series_name”，校驗器query_dom_content_contains校驗是否存在文本“沃爾沃CX60”;

動作3：執行user_input，選擇器為“input.user_name”，內容為“之家車友007”;

動作4：執行user_input，選擇器為“input.mobile”，內容為“18123456678”;

動作5：執行user_click，選擇器為“button.btn-submit”;

動作6：執行dom_query，選擇器為“span.success_tip”，校驗器query_dom_content_contains校驗是否存在文本“預約成功”;

使用低代碼配置界面，只需要簡單的幾步，就可以完成的校驗案例，除了監控頁面中網絡、腳本、API異常外，還可以監控整個留資業務流程，配置界面所下圖所示：

圖6：低代碼配置界面

最終生成如下的配置JSON:

圖7：留資業務監控配置

5. 問題及總結

最后給大家介紹一些webeye系統在落地過程中遇到的問題及解決方案。

5.1如何保證擴展性

webeye系統設計之初是為了滿足本業務常見的線上問題，所以支持的動作和校驗器數量不多，只包含了一些常見的功能。不過webeye在設計上就使用了類似模版方法的設計模式，實現新的動作和校驗器只需要簡單提供一個function，就可以直接通過名稱注冊時動作庫中。

5.2如何保證選擇器的靈活性

webeye中很多動作需要指定DOM選擇器，如下圖所示，若需要點擊“活動專區”后的“查看更多”文字鏈，傳統的選擇器就無法準確選擇目標元素。這里我們就需要一種類似于XPath的增強選擇器(puppeteer原生支持XPath，但是考慮到使用成本，我們沒有直接使用)，webeye通過獨立的模塊對DOM選擇器做了增強，通過".more_message[0]"就可以輕松選擇到該元素。

圖8：一個頁面存在多個相同元素

5.3如何避免監控服務影響業務統計

webeye通過headless browser訪問頁面，不可避免的會產生訪問流量，從而影響實際的業務統計，我們的做法是通過黑名單機制對指定流量URL進行屏蔽，實踐中，我們屏蔽了ftwo-receiver.autohome.com.cn以及al.autohome.com.cn兩個域名，分別對性能監控和流量采集進行屏蔽。

6. 寫在最后

本文簡單介紹了筆者所理解的體系化監控架構，并詳細介紹了webeye UI自動化低代碼平臺的設計思路及使用方法。目前，平臺已覆蓋筆者所在業務90%以上核心C端頁面，單個頁面平均接入時間3分鐘。上線兩個月發現4個線上問題，占全部線上問題的50%，C端問題的80%。下一步我們將繼續豐富平臺能力及易用性。webeye系統本身并不復雜，更多的希望給各位讀者帶來一些UI自動化思路。