K60 Pro官方停產(chǎn) 第三方瞬間漲價(jià)
雖然沒(méi)有官方宣布，但Redmi的一些高管也已經(jīng)透露了，Redmi K60 Pro已經(jīng)停產(chǎn)且不會(huì)補(bǔ)貨，這一切都是為了即將到來(lái)的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機(jī)在停產(chǎn)之后
圖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ì)介紹一下。
插件監(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)控。
使用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)控方案呢?
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)器
上文提到，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)容輸入。
如圖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)控配置
最后給大家介紹一些webeye系統(tǒng)在落地過(guò)程中遇到的問(wèn)題及解決方案。
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ù)中。
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è)相同元素
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)行屏蔽。
本文簡(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)化思路。
本文鏈接：http://www.www897cc.com/showinfo-26-6168-0.htmlUI自動(dòng)化低代碼平臺(tái)webeye在數(shù)科業(yè)務(wù)的應(yīng)用
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 高并發(fā)場(chǎng)景下的性能優(yōu)化：解析RabbitMQ的性能調(diào)優(yōu)策略
下一篇： 利用 GetUserMedia 和 MediaRecorder API 玩轉(zhuǎn)音頻錄制、播放和下載
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)