優(yōu)化的解決方案:離線(xiàn)電商數倉-用戶(hù)行為采集平臺-第4章 用戶(hù)行為數據采集模塊

　　前言

　　此博客是一個(gè)學(xué)習記錄，可能收錄錯誤，僅供參考。

　　如果您發(fā)現錯誤，請在評論區進(jìn)行更正，我會(huì )及時(shí)更正。

　　同時(shí)，我也希望大家能在評論區與我多討論，或者給我發(fā)私信，討論能讓我們更高效地學(xué)習。

　　當前版本不是最終版本，我將隨著(zhù)學(xué)習繼續更新。

　　第 4 章：用戶(hù)行為數據采集模塊 4.2 環(huán)境準備 4.2.2 Hadoop 安裝

　　1） 配置集群

　　1. 核心站點(diǎn)配置

　　配置此 atguigu（超級用戶(hù)）以允許代理訪(fǎng)問(wèn)所有主機節點(diǎn)、用戶(hù)所屬的所有組以及所有用戶(hù)

　　2.紗線(xiàn)現場(chǎng).xml配置

　　這三個(gè)參數不是直接分布的，而是根據每臺機器的內存大小單獨設置的。

　　2） 項目經(jīng)驗

　　HDFS 存儲 多目錄集群數據平衡 節點(diǎn)和磁盤(pán)之間的數據平衡 Hadoop 參數調整 HDFS 參數調整 YARN 參數調整 4.2.3 動(dòng)物園管理員安裝 1）動(dòng)物園管理員重命名后可能出現的問(wèn)題，與文檔不一致，但文檔中的路徑也使用了，所以要注意動(dòng)物園管理員的安裝，重命名應與文檔中相同。2）動(dòng)物園管理員的選舉機制

　?。?條消息）動(dòng)物園管理員流亡Mechanism_Blog - CSDN博客_zookeeper選舉機制

　　4.2.4 卡夫卡安裝

　　首先啟動(dòng)動(dòng)物園管理員，然后啟動(dòng)卡夫卡。

　　先關(guān)上卡夫卡，然后關(guān)上動(dòng)物園管理員。

　　配置環(huán)境變量時(shí)，

　　需要注意的是，一般是在hadoop102上配置，然后分發(fā)，配置環(huán)境變量后，需要源/etc/profile

　　主題

　　制作人

　　消費者

　　這三者仍然需要學(xué)習#待學(xué)

　　4.2.5 水槽安裝

　　當您啟動(dòng) flume 時(shí)，它會(huì )根據其配置文件啟動(dòng)。

　　4.3 對數采集水槽

　　卡夫卡*敏*感*詞*相當于生產(chǎn)者的實(shí)現，將數據寫(xiě)入卡夫卡的主題

　　卡夫卡源相當于消費者實(shí)現，從卡夫卡的主題中讀取數據

　　卡夫卡頻道使用三種方案

　　引用：

　　解決方案一：與水槽和水槽一起使用

　　描述: __________：

　　

　　Taildir讀取文件中的數據并將其輸入到卡夫卡通道中以將數據寫(xiě)入主題hdfs*敏*感*詞*從卡夫卡通道讀取數據時(shí)，卡夫卡通道將首先讀取主題中的數據，然后傳遞到最終的hdfs*敏*感*詞*將數據寫(xiě)入hdfs

　　選項二：與水煙酸一起使用

　　注意：只有從文件中讀取的數據才會(huì )寫(xiě)入 kafka

　　解決方案三：與水槽一起使用

　　注意：僅從卡夫卡讀取數據，寫(xiě)入HDFS

　　因為卡夫卡通道中有一個(gè)參數如下

　　如果參數解析為“流量”設置為 True，則數據將傳輸到

　　事件的形式（header+body），然后從 kafka 通道到 kafka 的主題，并將有用的數據存儲在正文中，因此會(huì )存儲更多的數據標頭。對于離線(xiàn)數據倉庫，可以在下游解析正文，但對于直接從Kafka主題讀取數據的實(shí)時(shí)數據數據倉庫來(lái)說(shuō)，標頭是無(wú)用的。

　　如果參數解析為“流量”設置為“假”，則數據僅傳輸到卡夫卡通道，沒(méi)有標頭，但與*敏*感*詞*一起使用時(shí)需要卡夫卡通道

　　對于本項目，使用了備選方案二和三的組合

　　上游首先使用卡夫卡通道（將解析為“事件”設置為“假”）將數據寫(xiě)入卡夫卡

　　再往下游穿過(guò)*敏*感*詞*（#待學(xué)）。

　　使用卡夫卡通道可以減少一個(gè)步驟并提高效率。

　　4.3.2 記錄采集水槽配置實(shí)踐

　　2） 配置文件的內容如下

　　1. 配置源

　　2. 配置通道

　　3. 最終配置文件

　　#1.定義組件

a1.sources=r1

a1.channels=c1

#2.配置sources

a1.sources.r1.type=TAILDIR

a1.sources.r1.filegroups=f1

#設置監控的文件

a1.sources.r1.filegroups.f1=/opt/module/applog/log/app.*

#設置斷點(diǎn)續傳

a1.sources.r1.positionFile=/opt/module/flume/taildir_position.json

#3.配置channels

a1.channels.c1.type = org.apache.flume.channel.kafka.KafkaChannel

<p>

a1.channels.c1.kafka.bootstrap.servers=hadoop102:9092,hadoop103:9092

a1.channels.c1.kafka.topic = topic_log

a1.channels.c1.parseAsFlumeEvent = false

#4.組裝

a1.sources.r1.channels=c1

</p>

　　3）編寫(xiě)水槽*敏*感*詞*

　　*敏*感*詞*使用-flume官方網(wǎng)站說(shuō)明

　　Flume具有在飛行中修改/丟棄事件的能力。這是在*敏*感*詞*的幫助下完成的。*敏*感*詞*是實(shí)現 org 的類(lèi)。阿帕奇。水槽。攔截 器。*敏*感*詞*接口。*敏*感*詞*可以根據*敏*感*詞*開(kāi)發(fā)人員選擇的任何條件修改甚至刪除事件。水槽支持*敏*感*詞*的鏈接。這是通過(guò)在配置中指定*敏*感*詞**敏*感*詞*類(lèi)名列表來(lái)實(shí)現的。*敏*感*詞*在源配置中被指定為空格分隔列表。

　　指定*敏*感*詞*的順序是調用它們的順序。一個(gè)*敏*感*詞*返回的事件列表被傳遞到鏈中的下一個(gè)*敏*感*詞*。*敏*感*詞*可以修改或刪除事件。如果*敏*感*詞*需要丟棄事件，它只是不會(huì )在它返回的列表中返回該事件。如果要刪除所有事件，則它只是返回一個(gè)空列表。*敏*感*詞*被命名為組件，下面是如何通過(guò)配置創(chuàng )建它們的示例：

　　a1.sources = r1

a1.sinks = k1

a1.channels = c1

a1.sources.r1.interceptors = i1 i2

a1.sources.r1.interceptors.i1.type = org.apache.flume.interceptor.HostInterceptor$Builder

a1.sources.r1.interceptors.i1.preserveExisting = false

a1.sources.r1.interceptors.i1.hostHeader = hostname

a1.sources.r1.interceptors.i2.type = org.apache.flume.interceptor.TimestampInterceptor$Builder

a1.sinks.k1.filePrefix = FlumeData.%{CollectorHost}.%Y-%m-%d

a1.sinks.k1.channel = c1

　　4）我的理解：

　　1. 就是用Java寫(xiě)一個(gè)*敏*感*詞*的jar包，然后這個(gè)*敏*感*詞*類(lèi)需要繼承這個(gè)類(lèi)組織.apache.flume.*敏*感*詞*，并重寫(xiě)里面的接口。

　　2.然后用maven制作一個(gè)罐子包（帶有依賴(lài)項）

　　3. 將罐子包裝放入 /選擇/模塊/水槽/庫

　　4. 然后將此*敏*感*詞*配置到 flume 中，并將配置文件放入 /opt/模塊/flume/job 中，并按如下方式進(jìn)行配置：

　　a1.sources.r1.interceptors=i1

a1.sources.r1.interceptors.i1.type=com.atguigu.gmall.flume.interceptor.ETLInterceptor$Builder

　　其中，com.atguigu.gmall.flume.*敏*感*詞*.ETL感知器*敏*感*詞*是*敏*感*詞*jar的*敏*感*詞*全類(lèi)名，請注意，您必須使用“*敏*感*詞*是*敏*感*詞*罐的*敏*感*詞*全類(lèi)名”，請注意“*敏*感*詞*”

　　是*敏*感*詞* jar 的*敏*感*詞*全類(lèi)名，請注意，您必須在此處使用“”符號，而不是“.”符號。

　　5. 使用 /opt/模塊/水槽/作業(yè)中的配置文件啟動(dòng)水槽

　　6. 然后在 hadoop103 中打開(kāi)卡夫卡消費者，掛起

　　7. 然后將非法 JSON 添加到 /opt/module/applog/log 中的日志文件中，如果 Kafka 使用者無(wú)法獲取此非法 JSON 數據，則表示*敏*感*詞*已正常工作。

　　其他 __________

　　ArrayList 集合的索引是動(dòng)態(tài)可縮放的，當您使用刪除到刪除時(shí)，很容易出現數據超出邊界的異常。

　　成熟的解決方案:前端監控的搭建步驟，別再一頭霧水了！

　　大家好，我叫楊成功。

　　上一篇介紹了為什么前端會(huì )有監控系統？前端監控系統有什么意義？有朋友看完后留言，想聽(tīng)聽(tīng)一些詳細的實(shí)現。那么在本文中，我們將開(kāi)始介紹前端監控是如何實(shí)現的。

　　如果還是不明白為什么，監控有什么用，推薦閱讀上一篇文章文章：前端為什么不能沒(méi)有監控系統？

　　在實(shí)施之前，首先要在腦海中有一個(gè)整體的背景，了解構建前端監控的具體流程步驟。因為前端監控系統其實(shí)是一個(gè)完整的全棧項目，不僅僅是前端，甚至主要的實(shí)現都圍繞著(zhù)數據。

　　當然，還有一點(diǎn)需要說(shuō)明。本文的實(shí)現主要針對普通業(yè)務(wù)和中小廠(chǎng)自研方向。我看過(guò)大廠(chǎng)做的監控系統。它非常復雜和強大，動(dòng)輒數以?xún)|計的數據。最終走向了大數據的方向。我只介紹如何實(shí)現main函數，如何解決問(wèn)題。

　　前端監控的構建過(guò)程分為以下幾個(gè)階段：

　　采集Stage：Data 采集API Stage：構建API應用，接收采集Data Storage Stage：將API應用連接到數據庫，存儲采集 查詢(xún)統計階段：對采集接收到的數據進(jìn)行查詢(xún)、統計、分析 可視化階段：前端通過(guò)API查詢(xún)統計數據，可視化展示告警階段：API對接告警通知服務(wù)，如釘釘部署階段：整體應用部署上線(xiàn)

　　下面我來(lái)梳理一下各個(gè)階段的關(guān)鍵實(shí)現思路。

　　采集階段：采集什么數據？

　　監控的第一步是采集數據。有數據是監控的前提。

　　采集數據的含義是記錄用戶(hù)在使用產(chǎn)品過(guò)程中的真實(shí)操作。結合我們上一篇的分析，實(shí)際操作產(chǎn)生的數據可以分為兩類(lèi)：異常數據和行為數據。

　　我們先分析異常數據。項目中的異常一般可以分為兩類(lèi)，一類(lèi)是前端異常，一類(lèi)是接口異常。

　　前端異常

　　前端異常大致可以分為：

　　最重要的，也是我們遇到最多的，就是各種js代碼執行異常。比如類(lèi)型錯誤、引用錯誤等。這些異常大部分是由于我們的編碼不精確造成的，所以采集這些異常有助于我們提高編碼質(zhì)量。

　　然后是 Promise 異常。Promise 是 ES6 最重要的屬性之一?？简炍覀兊膉s異步編程能力，主要體現在接口請求上。因此，這兩部分的異常捕獲非常關(guān)鍵。

　　另外，靜態(tài)資源加載異常一般是指引用了一些html中的圖片地址、第三方j(luò )s地址等，由于各種原因不能正常加載，這個(gè)也要監控。

　　console.error 異常一般用在第三方前端框架中。它自定義了一些錯誤，會(huì )被console.error拋出。此類(lèi)異常也需要被捕獲。

　　至于跨域異常，我們經(jīng)常會(huì )遇到這種情況，通?？梢栽谇昂蠖碎_(kāi)發(fā)聯(lián)調階段發(fā)現。但不確定是后端的配置突然在線(xiàn)更改，導致前端跨域。為了安全起見(jiàn)，您還應該對其進(jìn)行監控。

　　前端異常采集大概只有這5種，基本覆蓋了前端90%以上的異常。

　　接口異常

　　接口異常屬于后端異常，但是接口異常會(huì )直接導致前端頁(yè)面錯誤。因此，此類(lèi)異常是我們判斷線(xiàn)上問(wèn)題根源的重要依據。接口異?？梢愿鶕憫Y果分類(lèi)：

　　有時(shí)由于網(wǎng)絡(luò )問(wèn)題或服務(wù)器問(wèn)題，前端發(fā)起請求后沒(méi)有收到響應，請求被掛起。這次是無(wú)響應/超時(shí)響應異常。對于此類(lèi)異常，我們可以設置最大請求時(shí)間，超時(shí)后主動(dòng)斷開(kāi)請求，添加接口超時(shí)記錄。

　　另外，其他類(lèi)型的接口異?？梢愿鶕﨟TTP狀態(tài)碼或者后端返回的error_code等指定字段來(lái)判斷。

　　不管是使用狀態(tài)碼還是其他判斷方式，只要能區分異常類(lèi)型，這個(gè)不是嚴格要求的。

　　4xx異常類(lèi)型是請求異常，一般是前端傳遞的參數有問(wèn)題，或者接口驗證參數有問(wèn)題。處理此類(lèi)異常的關(guān)鍵是保存請求參數，這樣可以方便前端排查。

　　

　　5xx 錯誤是服務(wù)器內部處理的異常。此類(lèi)異常的關(guān)鍵信息是報錯時(shí)間和返回的異常描述。保存這些可以方便后端查找日志。

　　我認為權限不足也是一種重要的錯誤類(lèi)型。因為有些管理系統的權限設計比較復雜，有時(shí)候界面突然莫名其妙無(wú)法調整，影響用戶(hù)接下來(lái)的操作，也需要記錄和跟蹤。

　　行為數據

　　行為數據比較廣泛，用戶(hù)任何有意義的操作都可以定義為行為數據。

　　例如，當一個(gè)按鈕被點(diǎn)擊時(shí)，它在那里停留了多長(cháng)時(shí)間，新功能的點(diǎn)擊率，何時(shí)使用等等。自主研發(fā)的監控系統的優(yōu)勢之一是靈活性。您需要的任何有用信息都可以在此階段進(jìn)行設計。

　　這個(gè)階段非常關(guān)鍵，是監控系統設計的核心，所以我寫(xiě)的很詳細，這個(gè)階段大家要多考慮采集哪些數據。后面的階段都是基于這個(gè)設計的具體實(shí)現。

　　API階段：構建上報數據的API接口

　　在上一階段，采集數據計劃已經(jīng)準備好了。當 采集 數據到達時(shí)，接下來(lái)會(huì )上報數據。

　　說(shuō)白了，數據上報就是通過(guò)調用API接口將數據傳輸出來(lái)，然后存入數據庫。因此，這個(gè)階段的任務(wù)是構建一個(gè)用于報告數據的API接口應用程序。

　　作為一名光榮的前端工程師，在開(kāi)發(fā)接口時(shí)自然會(huì )選擇屬于 JS 家族的 Node.js。Node.js 目前有很多框架。我比較喜歡輕量簡(jiǎn)潔，什么都需要自己安裝，所以選擇了簡(jiǎn)潔經(jīng)典的Express框架。

　　構建 API 應用程序要做的事情是：

　　還有一些細節需要處理。這個(gè)階段對于后端基礎薄弱的同學(xué)來(lái)說(shuō)是一個(gè)很好的學(xué)習機會(huì )。

　　強烈建議前端的朋友掌握一些后端的基礎知識，至少從簡(jiǎn)單的原理上了解是怎么回事。這個(gè)階段主要是了解API應用是如何搭建的，每個(gè)部分為什么要做，可以解決哪些問(wèn)題，這樣你對后端的基礎知識就會(huì )建立起來(lái)。

　　框架搭建好后，主要是設計接口URL，然后編寫(xiě)處理邏輯，保證這一步設計的接口可以調整，可以接收數據。

　　數據存儲階段：與數據庫接口對接

　　上一步我們構建了API接口，接收到采集的數據。然后，在這一步中，我們需要連接數據庫，并將 采集 中的數據存儲到數據庫中。

　　數據庫方面，選擇對前端最友好的，屬于NoSQL家族的文檔數據庫MongoDB。

　　這個(gè)數據庫最大的特點(diǎn)就是存儲的數據格式類(lèi)似于JSON，操作就像在JS中調用函數，結合JOSN數據。我們很容易理解并開(kāi)始使用前端?？梢栽趯?shí)戰過(guò)程中體驗。優(yōu)雅也。

　　數據存儲階段主要介紹數據庫的基本信息和操作，包括以下幾個(gè)方面：

　　這個(gè)階段的關(guān)鍵是數據驗證。在設計完數據庫字段后，我們希望所有寫(xiě)入的數據都必須符合我們想要的數據格式。如果驗證后不符合，我們可以補充或修改數據字段，或者干脆拒絕寫(xiě)入，這樣可以保證數據的可靠性，避免不必要的數據清洗。

　　數據寫(xiě)入完成后，需要添加一些簡(jiǎn)單的查詢(xún)和修改功能。因為要在寫(xiě)完數據后查看執行是否成功，可以查看一個(gè)列表來(lái)查看結果。

　　還需要修改功能。前端監控中一個(gè)很常見(jiàn)的需求就是計算用戶(hù)的頁(yè)面停留時(shí)間。我的計劃是在用戶(hù)進(jìn)入某個(gè)頁(yè)面時(shí)創(chuàng )建一條記錄，然后在用戶(hù)離開(kāi)時(shí)修改該記錄并添加一個(gè)結束時(shí)間字段，這需要修改功能。

　　最后但并非最不重要的一點(diǎn)是，許多人都在談?wù)撊绾吻謇頂祿?。?shí)際上，這取決于您在將數據存儲在您面前時(shí)如何驗證。如果確實(shí)可以存儲無(wú)效數據，可以寫(xiě)一個(gè)清空數據的接口，自己寫(xiě)清空邏輯，定時(shí)執行。

　　查詢(xún)統計階段：數據查詢(xún)和統計分析

　　經(jīng)過(guò)一系列的準備，我們已經(jīng)完成了API接口和數據寫(xiě)入的功能。假設我們有 采集 足夠的數據并存儲在數據庫中，這個(gè)階段就是充分利用這些數據的時(shí)候了。

　　這個(gè)階段的主要任務(wù)是對數據進(jìn)行檢索和統計分析，基本上是“查詢(xún)”操作。

　　這里的查詢(xún)不僅僅是為了檢查，如何檢查，關(guān)系到我們采集到的數據能否得到有效利用。我的想法是從這兩個(gè)方面入手：

　　

　　當然，這只是籠統的說(shuō)法。行為數據也將在一行中查詢(xún)。例如，如果我想查看用戶(hù)在某個(gè)時(shí)間做了什么，這就是精確搜索。還有異常數據的統計，比如異常接口的觸發(fā)頻率排名。

　　行為數據量會(huì )非常大，在用戶(hù)使用系統的過(guò)程中會(huì )頻繁生成并寫(xiě)入數據庫。因此，在這類(lèi)數據的大部分情況下，都是通過(guò)聚合查詢(xún)的方式，從頁(yè)數、時(shí)間等多個(gè)維度進(jìn)行整體統計，最后得出一些百分比的結論。這些統計值可以大致反映產(chǎn)品的實(shí)際使用情況。

　　這里有個(gè)優(yōu)化點(diǎn)，因為頻繁的請求會(huì )增加接口的負擔，所以一部分數據也可以在本地存儲，達到一定數量后，一次性請求并存儲接口。

　　異常數據對于開(kāi)發(fā)者來(lái)說(shuō)非常重要，對于我們定位和解決bug來(lái)說(shuō)是天賜之物。與行為數據的多重統計不同，我們更關(guān)心異常數據的每一條記錄的詳細信息，讓錯誤一目了然。

　　查詢(xún)異常數據也比較簡(jiǎn)單。和普通的列表查詢(xún)一樣，只需要返回最新的異常數據即可。當然，我們排查問(wèn)題后，也要把處理的異常標記為已處理，這樣可以防止重復排查。

　　可以看出，這個(gè)階段最重要的是做一個(gè)統計界面，為下一階段圖表展示的可視化做準備。

　　可視化階段：最終數據圖表展示

　　在最后階段，我們開(kāi)發(fā)了一個(gè)統計界面并找到了想要的數據結果。不幸的是，這些結果只有程序員才能理解，其他人可能無(wú)法理解。所以最后，為了更直觀(guān)的反映數據，我們需要使用前端的可視化圖表，讓這些數據活起來(lái)。

　　在這個(gè)階段，我們終于回到了最熟悉的前端領(lǐng)域。這個(gè)階段的任務(wù)比較簡(jiǎn)單，比較順利?；赗eact構建一個(gè)新的前端應用，訪(fǎng)問(wèn)上一步的統計界面，然后集成前端圖表庫，以圖表的形式展示統計結果。

　　這個(gè)新應用是一個(gè)前端監控系統，真正需要展示給外界。供團隊內部的開(kāi)發(fā)人員或產(chǎn)品學(xué)生使用，方便他們實(shí)時(shí)查看產(chǎn)品產(chǎn)生的數據信息，解決自己的問(wèn)題。

　　事實(shí)上，現階段沒(méi)有關(guān)鍵問(wèn)題可談。主要是選擇一個(gè)好用的圖表庫并連接接口。還有各種類(lèi)型的圖表。需要考慮哪些數據適合哪些圖表，根據實(shí)際情況做出判斷。

　　最后，監控系統的前端頁(yè)面和界面數據不是人人都能看到的，所以要有基本的登錄頁(yè)面和功能。做到這一點(diǎn)，這個(gè)階段的任務(wù)就結束了。

　　報警階段：發(fā)現異常立即報警通知

　　前一階段，監控系統前端搭建完成，統計數據以圖表形式展示后，整個(gè)監控系統基本可用。

　　但是還有另一種情況，就是用戶(hù)在使用我們的產(chǎn)品時(shí)突然報錯，錯誤信息也被寫(xiě)入了數據庫。如果此時(shí)你不主動(dòng)刷新頁(yè)面，實(shí)際上你也不能一直刷新頁(yè)面，那么我們根本不知道這個(gè)錯誤。

　　如果這是一個(gè)非常致命的bug，影響范圍很廣，我們甚至不知道這個(gè)bug是什么時(shí)候發(fā)生的，那會(huì )給我們帶來(lái)很大的損失。

　　所以，為了保證我們能及時(shí)解決bug，告警通知的功能就顯得非常重要了。它的作用是在出現異常的第一時(shí)間推送給開(kāi)發(fā)者，讓大家第一時(shí)間發(fā)現問(wèn)題，然后以最快的速度解決，避免遺漏。

　　報警通知，現在一般的解決方案是連接釘釘或者企業(yè)微信的機器人，我們這里使用釘釘。使用哪個(gè)平臺取決于您的主題所在的平臺。比如我的團隊主體在釘釘上，所以在發(fā)送報警通知時(shí)，可以直接用手機號@任意一個(gè)團隊成員，實(shí)現更精準的提醒。

　　本部分是對 API 應用的補充。申請釘釘開(kāi)發(fā)者權限后，訪(fǎng)問(wèn)API中的相關(guān)代碼。

　　部署階段：萬(wàn)事俱備，只等上線(xiàn)

　　在前面的階段，我們已經(jīng)完成了數據采集、API應用構建、數據存儲、前端可視化展示、監控告警。整個(gè)前端監控系統功能齊全。最后一步是將所有的前端和后端數據庫都在線(xiàn)部署，供大家訪(fǎng)問(wèn)。

　　部署主要是nginx解析、https配置、數據庫安裝、nodejs的應用部署等，這個(gè)階段的內容會(huì )多一點(diǎn)運維。不過(guò)不用擔心，這里我也會(huì )詳細介紹關(guān)鍵操作。

　　系統上線(xiàn)后，你可以按照第一篇中的采集方法，嘗試通過(guò)API將數據采集保存在你的任意一個(gè)前端項目中，然后登錄監控系統來(lái)查看真實(shí)的使用數據。

　　當這部分完成后，恭喜，一個(gè)小型的前端監控系統搭建完成。未來(lái)我們可以在此基礎上繼續擴展功能，慢慢讓這個(gè)自研的監控系統變得更強大。

　　總結

　　本文介紹了前端監控系統的搭建流程，將整個(gè)流程分為幾個(gè)階段，簡(jiǎn)要說(shuō)明每個(gè)階段要做什么，有哪些關(guān)鍵問(wèn)題，以幫助大家理清思路?????建立監控系統。