1. 淺談系統(tǒng)監(jiān)控

作為一名開(kāi)發(fā)人員，對(duì)“監(jiān)控”這個(gè)詞應(yīng)該是無(wú)比的熟悉，它是系統(tǒng)高可用的核心保障之一，完善的監(jiān)控體系不僅可以迅速發(fā)現(xiàn)異常還能在一定程度上預(yù)測(cè)即將發(fā)生的異常，即故障洞察和故障預(yù)測(cè)。本文主要向大家介紹一下UI自動(dòng)化低代碼平臺(tái)webeye，在此之前，我們先簡(jiǎn)單的聊一下“監(jiān)控”。

1.1常見(jiàn)的監(jiān)控形式

根據(jù)不同的監(jiān)控?cái)?shù)據(jù)形式，可以分為：Logging(日志)、Metrics(指標(biāo))，隨著微服務(wù)架構(gòu)的興起，Tracing(鏈路追蹤)變成了不可或缺的一種數(shù)據(jù)形式，它記錄著某次RPC調(diào)用信息，也可以將他理解成一種特殊的訪問(wèn)日志，所以筆者更傾向于將他歸為L(zhǎng)ogging的一種。下面分別介紹一下這幾種監(jiān)控?cái)?shù)據(jù)：

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

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

Tracing：記錄請(qǐng)求范圍內(nèi)信息，最常見(jiàn)的就是記錄一次RPC的調(diào)用過(guò)程和執(zhí)行耗時(shí)，目前的大型互聯(lián)網(wǎng)應(yīng)用大多是采用微服務(wù)架構(gòu)，系統(tǒng)間的依賴關(guān)系會(huì)越來(lái)越復(fù)雜，Tracing的誕生就是為了追蹤調(diào)用鏈路，梳理出系統(tǒng)依賴關(guān)系(類似于Linux下的traceroute和windows下的tracert命令，用來(lái)追蹤從本地計(jì)算機(jī)到遠(yuǎn)程主機(jī)所通過(guò)的所有路由信息)。

通過(guò)上面的分析，我們可以發(fā)現(xiàn)Logging和Metrics的一個(gè)明顯區(qū)別：Logging是離散數(shù)據(jù)而Metrics則是一種基于“時(shí)間點(diǎn)”線性狀態(tài)數(shù)據(jù)，因此Metrics存儲(chǔ)時(shí)，一般會(huì)采用InfluxDB之類的時(shí)序數(shù)據(jù)庫(kù)。這也是為什么筆者認(rèn)為T(mén)racing實(shí)質(zhì)上是一種Logging的原因。

1.2體系化監(jiān)控

上面我們簡(jiǎn)單的介紹了監(jiān)控?cái)?shù)據(jù)的類型，那么在實(shí)際業(yè)務(wù)中，我們應(yīng)該如何基于現(xiàn)有的數(shù)據(jù)載體搭建一套完善的監(jiān)控體系呢?筆者認(rèn)為，傳統(tǒng)的Web互聯(lián)網(wǎng)服務(wù)可以分為五層(硬件、中間件、后端程序、業(yè)務(wù)流程、UI)，如下圖1所示，我們的監(jiān)控應(yīng)該覆蓋每一層。

圖1：分層監(jiān)控

物理層監(jiān)控：對(duì)IaaS層硬件指標(biāo)進(jìn)行監(jiān)控，如CPU使用率、網(wǎng)絡(luò)IO、RAM使用量等Metrics類型的數(shù)據(jù)。主流做法是使用Agent程序采集硬件指標(biāo)，再將這些指標(biāo)數(shù)據(jù)存入時(shí)序數(shù)據(jù)庫(kù)，再定期檢索指標(biāo)數(shù)據(jù)，通過(guò)判斷閾值的方式觸發(fā)報(bào)警。

中間件監(jiān)控：對(duì)PaaS層中間件指標(biāo)進(jìn)行監(jiān)控，如Web Server吞吐、JVM內(nèi)存使用情況、RDMS QPS數(shù)等。實(shí)現(xiàn)方案與物理層類似，如Prometheus社區(qū)提供各種中間件的指標(biāo)收集程序(Exporter)，通過(guò)Service Mesh模式采集指標(biāo)。

應(yīng)用監(jiān)控：主要對(duì)應(yīng)用的運(yùn)行日志進(jìn)行監(jiān)控，包括：程序日志、訪問(wèn)日志、調(diào)用鏈日志等。程序日志一般在程序運(yùn)行時(shí)上報(bào)，而訪問(wèn)日志大多由Web Server自動(dòng)收集，調(diào)用鏈日志由框架(如：Skywalking)自動(dòng)采集，然后將這些離散數(shù)據(jù)存入分布式數(shù)據(jù)庫(kù)(如：ES)，監(jiān)控程序通過(guò)定期檢索日志進(jìn)行監(jiān)控。

業(yè)務(wù)流程監(jiān)控：監(jiān)測(cè)業(yè)務(wù)鏈路是否通暢，與上述幾種監(jiān)控方式不同，業(yè)務(wù)流程監(jiān)控通常不具備通用性。常見(jiàn)的做法有兩種：

(1)提供業(yè)務(wù)接口，該接口內(nèi)提供完整的業(yè)務(wù)操作和校驗(yàn)流程，通過(guò)對(duì)接口返回內(nèi)容進(jìn)行解析，判斷業(yè)務(wù)是否正常。筆者支持的某個(gè)業(yè)務(wù)依賴第三方OCR識(shí)別駕照的服務(wù)，該服務(wù)經(jīng)常出現(xiàn)接口正常返回，但是圖片內(nèi)容無(wú)法識(shí)別的問(wèn)題，為了及時(shí)發(fā)現(xiàn)服務(wù)異常，可以通過(guò)接口的形式，周期性將一張已知駕照?qǐng)D片提交給接口，通過(guò)解析識(shí)別結(jié)果判斷服務(wù)是否正常。

(2)通過(guò)直接檢索業(yè)務(wù)數(shù)據(jù)庫(kù)，業(yè)務(wù)完整性，之家內(nèi)部的鷹眼系統(tǒng)提供了通過(guò)直接執(zhí)行sql進(jìn)行監(jiān)控的能力，通過(guò)解析ResultSet實(shí)現(xiàn)業(yè)務(wù)監(jiān)控的方案。如常見(jiàn)的留資業(yè)務(wù)，系統(tǒng)收到用戶的留資數(shù)據(jù)后，需要通過(guò)定時(shí)任務(wù)對(duì)線索信息進(jìn)行補(bǔ)齊，然后再執(zhí)行外呼清洗和推送流程。那么就可以通過(guò)檢索原始線索數(shù)據(jù)是否完整，清洗記錄表、推送記錄表是否存在關(guān)聯(lián)數(shù)據(jù)記錄，從而判斷流程完整性。

UI監(jiān)控：通過(guò)對(duì)頁(yè)面展示內(nèi)容、交互流程進(jìn)行監(jiān)控，確保頁(yè)面正常工作。UI離用戶最近，最能直接影響用戶體驗(yàn)，同時(shí)，由于網(wǎng)絡(luò)環(huán)境復(fù)雜，設(shè)備版本差異，UI問(wèn)題出現(xiàn)頻繁。常見(jiàn)的UI監(jiān)控包含插件監(jiān)控和UI自動(dòng)化兩種，下面給大家詳細(xì)介紹一下。

2. 常見(jiàn)的web監(jiān)控方案

2.1插件監(jiān)控

插件監(jiān)控主要通過(guò)在H5中引入js腳本，通過(guò)JS收集頁(yè)面中的錯(cuò)誤和性能數(shù)據(jù)，再將數(shù)據(jù)上報(bào)到ES集群中，通過(guò)檢測(cè)日志實(shí)現(xiàn)錯(cuò)誤報(bào)警，比如之家內(nèi)部的ftwo系統(tǒng)。這種監(jiān)控方式存在不足：

1. 時(shí)效性低，只有在用戶訪問(wèn)頁(yè)面時(shí)，監(jiān)控程序才會(huì)開(kāi)始工作，因而無(wú)法早于用戶發(fā)現(xiàn)問(wèn)題;

2. 網(wǎng)絡(luò)或機(jī)房故障類型錯(cuò)誤無(wú)法檢測(cè)，頁(yè)面返回404或502，頁(yè)面未加載的情況下， 無(wú)法監(jiān)控異常;

3. 局限性：只能發(fā)現(xiàn)腳本、網(wǎng)絡(luò)等通用錯(cuò)誤，無(wú)法對(duì)業(yè)務(wù)邏輯和頁(yè)面內(nèi)容進(jìn)行監(jiān)控。

2.2UI自動(dòng)化

使用pupputeer等無(wú)頭瀏覽器，通過(guò)Python、nodejs等腳本語(yǔ)言，構(gòu)建case，這種主動(dòng)探測(cè)的監(jiān)控方式比較常見(jiàn)，檢測(cè)精度高，但是學(xué)習(xí)和維護(hù)成本高。

基于以上分析，需要實(shí)現(xiàn)完善的UI可用性監(jiān)控，使用UI自動(dòng)化無(wú)疑是更好的選擇，但是其高昂的case維護(hù)成本，導(dǎo)致其在筆者所在的業(yè)務(wù)沒(méi)有被廣泛應(yīng)用。那么有沒(méi)有一種兼顧有效性和低成本UI監(jiān)控方案呢?

3. webeye系統(tǒng)介紹

3.1什么是webeye

UI自動(dòng)化的核心思路是通過(guò)腳本語(yǔ)言模擬一系列的人工操作，實(shí)現(xiàn)自動(dòng)化人工頁(yè)面巡檢的操作，在這里，我們不妨抽象一下用戶巡檢的流程：

1. 打開(kāi)F12，用于觀察是否存在腳本或網(wǎng)絡(luò)錯(cuò)誤;

2. 輸入網(wǎng)址，觀察網(wǎng)頁(yè)是否正常打開(kāi);

3. 查看頁(yè)面內(nèi)容，確定內(nèi)容是否正確;

4. 與頁(yè)面交互(滑動(dòng)、點(diǎn)擊、輸入)后，觀察頁(yè)面反饋是否正常;

webeye系統(tǒng)是一個(gè)基于用戶巡檢的核心思路，通過(guò)headless browser實(shí)現(xiàn)一套配置式的UI自動(dòng)化的低代碼平臺(tái)。webeye中有兩個(gè)核心概念：“動(dòng)作”及“校驗(yàn)器”：

動(dòng)作：模擬一系列用戶操作，如：打開(kāi)頁(yè)面、鼠標(biāo)滾動(dòng)、內(nèi)容查找、用戶點(diǎn)擊、用戶輸入等。

校驗(yàn)器：通過(guò)監(jiān)測(cè)頁(yè)面運(yùn)行中的頁(yè)面錯(cuò)誤或非預(yù)期內(nèi)容，從而觸發(fā)報(bào)警。包括全局校驗(yàn)器與動(dòng)作校驗(yàn)器。全局校驗(yàn)器貫穿在整個(gè)頁(yè)面生命周期中，如圖片加載失敗，js錯(cuò)誤等，動(dòng)作校驗(yàn)器是對(duì)某個(gè)具體用戶動(dòng)作產(chǎn)生的結(jié)果進(jìn)行校驗(yàn)，如打開(kāi)頁(yè)面后，判斷可見(jiàn)DOM數(shù)量是否符合預(yù)期等。

動(dòng)作與校驗(yàn)器的關(guān)系如圖二所示：

圖2：用戶動(dòng)作與校驗(yàn)器

3.2webeye中的動(dòng)作與校驗(yàn)器

上文提到，webeye中存在動(dòng)作和校驗(yàn)器兩個(gè)核心概念：動(dòng)作和校驗(yàn)器。校驗(yàn)器分為全局校驗(yàn)器和動(dòng)作校驗(yàn)器，動(dòng)作校驗(yàn)器是對(duì)具體動(dòng)作執(zhí)行后的結(jié)果進(jìn)行校驗(yàn)，所以我們先介紹一下全局校驗(yàn)器，后面介紹動(dòng)作時(shí)，同時(shí)介紹關(guān)聯(lián)的動(dòng)作校驗(yàn)器。

?全局校驗(yàn)器

http狀態(tài)碼校驗(yàn)器(http_status_error)：捕捉頁(yè)面生命周期內(nèi)非200的http請(qǐng)求;

網(wǎng)絡(luò)請(qǐng)求錯(cuò)誤(network_error)：監(jiān)聽(tīng)生命周期內(nèi)全部失敗的http請(qǐng)求，它與http_status_error核心區(qū)別是http_status_error關(guān)注response中的狀態(tài)碼，network-error更加關(guān)注請(qǐng)求本身，如域名DNS解析錯(cuò)誤、CORS請(qǐng)求失敗等;

API請(qǐng)求錯(cuò)誤(api_error)：xhr接口內(nèi)容監(jiān)控，之家內(nèi)部使用的接口協(xié)議均包含returncode 字段，可以通過(guò)檢測(cè) returncode 的值是否0從未判斷接口是否異常;

js錯(cuò)誤(js_error)：頁(yè)面生命周期內(nèi)的js錯(cuò)誤。

? 動(dòng)作及動(dòng)作校驗(yàn)器

打開(kāi)頁(yè)面(load)：通過(guò)puppeteer打開(kāi)指定URL，并等待加載完成。動(dòng)作校驗(yàn)器有：可見(jiàn)dom數(shù)量(visible_dom_count)，即頁(yè)面加載完成后，檢測(cè)可見(jiàn)dom數(shù)量是否達(dá)到閾值。在SPA應(yīng)用中，經(jīng)常出現(xiàn)因CDN異常，后臺(tái)配置錯(cuò)誤等導(dǎo)致頁(yè)面白屏或一直loading：

圖3：可見(jiàn)dom數(shù)量校驗(yàn)報(bào)警

內(nèi)容查找(query_dom)：通過(guò)指定的選擇器選擇進(jìn)行dom查找，并將查找結(jié)果暫存供檢驗(yàn)。query_dom有兩個(gè)動(dòng)作校驗(yàn)器：匹配元素?cái)?shù)量(query_dom_count)及匹配內(nèi)容(query_dom_content_contains)。query_dom_count用來(lái)校驗(yàn)匹配的元素?cái)?shù)量，如某商品面，校驗(yàn)SKU數(shù)量是否符合預(yù)期。query_dom_content_contains用來(lái)校驗(yàn)查找結(jié)果中是否包含具體文本內(nèi)容，如某次業(yè)務(wù)上線，導(dǎo)致頁(yè)面?zhèn)€別模塊展示開(kāi)關(guān)失效，該模塊直接消失：

圖4：內(nèi)容匹配失敗報(bào)警

鼠標(biāo)滾動(dòng)(mouse_wheel)：在垂直方向上模擬鼠標(biāo)滾動(dòng)指定距離。

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

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

4. webeye使用案例

如圖5所示，是一個(gè)典型的留資場(chǎng)景的業(yè)務(wù)，我們以它為例，看看配置一個(gè)UI監(jiān)控有多簡(jiǎn)單。

圖5：留資業(yè)務(wù)頁(yè)面示意圖

動(dòng)作1：執(zhí)行l(wèi)oad，地址為https://m.autohome.com.cn/some_query，校驗(yàn)器：visible_dom_count閾值設(shè)置為10(根據(jù)頁(yè)面元素多少，動(dòng)態(tài)設(shè)置)，該步驟可校驗(yàn)頁(yè)面是否正常打開(kāi)并正確顯示內(nèi)容;

動(dòng)作2：執(zhí)行dom_query，選擇器為“span.series_name”，校驗(yàn)器query_dom_content_contains校驗(yàn)是否存在文本“沃爾沃CX60”;

動(dòng)作3：執(zhí)行user_input，選擇器為“input.user_name”，內(nèi)容為“之家車友007”;

動(dòng)作4：執(zhí)行user_input，選擇器為“input.mobile”，內(nèi)容為“18123456678”;

動(dòng)作5：執(zhí)行user_click，選擇器為“button.btn-submit”;

動(dòng)作6：執(zhí)行dom_query，選擇器為“span.success_tip”，校驗(yàn)器query_dom_content_contains校驗(yàn)是否存在文本“預(yù)約成功”;

使用低代碼配置界面，只需要簡(jiǎn)單的幾步，就可以完成的校驗(yàn)案例，除了監(jiān)控頁(yè)面中網(wǎng)絡(luò)、腳本、API異常外，還可以監(jiān)控整個(gè)留資業(yè)務(wù)流程，配置界面所下圖所示：

圖6：低代碼配置界面

最終生成如下的配置JSON:

圖7：留資業(yè)務(wù)監(jiān)控配置

5. 問(wèn)題及總結(jié)

最后給大家介紹一些webeye系統(tǒng)在落地過(guò)程中遇到的問(wèn)題及解決方案。

5.1如何保證擴(kuò)展性

webeye系統(tǒng)設(shè)計(jì)之初是為了滿足本業(yè)務(wù)常見(jiàn)的線上問(wèn)題，所以支持的動(dòng)作和校驗(yàn)器數(shù)量不多，只包含了一些常見(jiàn)的功能。不過(guò)webeye在設(shè)計(jì)上就使用了類似模版方法的設(shè)計(jì)模式，實(shí)現(xiàn)新的動(dòng)作和校驗(yàn)器只需要簡(jiǎn)單提供一個(gè)function，就可以直接通過(guò)名稱注冊(cè)時(shí)動(dòng)作庫(kù)中。

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

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

圖8：一個(gè)頁(yè)面存在多個(gè)相同元素

5.3如何避免監(jiān)控服務(wù)影響業(yè)務(wù)統(tǒng)計(jì)

webeye通過(guò)headless browser訪問(wèn)頁(yè)面，不可避免的會(huì)產(chǎn)生訪問(wèn)流量，從而影響實(shí)際的業(yè)務(wù)統(tǒng)計(jì)，我們的做法是通過(guò)黑名單機(jī)制對(duì)指定流量URL進(jìn)行屏蔽，實(shí)踐中，我們屏蔽了ftwo-receiver.autohome.com.cn以及al.autohome.com.cn兩個(gè)域名，分別對(duì)性能監(jiān)控和流量采集進(jìn)行屏蔽。

6. 寫(xiě)在最后

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