DIY一個前端監控平臺（上）

時間 2019-11-06

標籤 diy 一個前端監控平臺简体版

原文原文鏈接

你只有不遺餘力以後，纔有資格說運氣很差。前端

前言

我認爲，流量分析平臺 + 日誌採集平臺 + 異常信息採集 + ajax信息採集 + 性能指標 = 監控平臺。git

以前我寫過兩篇文章《前端性能優化交流》與《前端代碼質量優化交流》。也能夠看得出來，我是對比項目開發的流程來編寫文章的。監控平臺這一點對於大多公司來講並無那麼重要，可是對於一個完善的交付項目，這一點是必不可少的，相應的流量分析平臺、日誌採集平臺。可視化的數據會給客戶最直觀的展示。github

初衷：web

本身想了解一些從外部統計項目數據的知識，探究一下原理，配合本身原來作過的一些東西，串聯起來，沉澱出一些東西，本身作一個。ajax

爲何要有監控平臺

PV、UV、IP等指標，也是老生常談。數組

PV(訪問量)：Page View，即頁面瀏覽量或點擊量，用戶每次刷新即被計算一次。瀏覽器

UV(獨立訪客)：Unique Visitor，通常使用cookie標記，訪問您網站的一臺電腦客戶端(好比一臺電腦開多個瀏覽器訪問則爲多個UV)爲一個訪客，00:00-24:00內相同的客戶端只會被計算一次。安全

IP(獨立IP)：指獨立IP數。00:00-24:00內相同IP地址之被計算一次(多臺電腦可能共用一個ip)。性能優化

最終反映的都是產品整體狀況，數據的價值除了反映現狀，最重要的仍是反饋回來指導業務增加。bash

說點通俗的，好比：閱讀類項目，必然會有監控平臺。排行榜、閱讀量，就是經過監控平臺統計出的結果。

高速發展的時代對於數據分析需求的精細化程度愈來愈高

對於如今形式來講，就像上面那句話，精細化程度愈來愈高。

我不只要知道買產品的客戶有多少，我還想知道，客戶鼠標明明放在了購買按鈕上，而後鼠標移走了的客戶有多少。就差問問他爲何沒買了。

第三方平臺

這個相信你們也不陌生，每每這個時候老闆讓你一天就搭建一個監控平臺。

老闆：「前端美男子，我須要咱們項目的訪問量，最受歡迎的文章等全部數據，按期生成報表(省略6000字)...」

直接採用，百度統計，友盟+等第三方流量統計平臺。

好處也不用多說，人家專門作這個的。這裏要注意：註冊帳號用老闆的，不然很差離職。

很差的地方，有些功能要花錢，有不少咱們不須要的數據，定製化太差，不能維護。最最重要的一點，不是咱們本身的。固然個人目的是本身玩一個小demo，簡單探究一下監控平臺的原理。

流量分析平臺能作到的功能

這裏我以百度統計爲例，看一下他們官網上給本身的自我介紹。

能夠統計一些歸納上的表現，頁面上下游，訪客屬性，訪客地域，pv，uv，跳出率等等。還有一些百度獨有的功能，好比是經過什麼關鍵字從百度找到的你的網站。等等。

DIY

咱們參照上面的功能列表，抽取一些咱們能作到的信息，抓取這些數據。

首先咱們先看看咱們能抓取哪些數據。

採集的內容包括：

當前頁URL，標題來源頁的URL（若是有）。
用戶身份識別信息：cookieID 等。
用戶停留時間
客戶端/瀏覽器信息和屏幕分辨率。
當前業務的識別編碼，用戶操做的編碼
DIY一些信息。

這裏注意一下：

咱們提交後臺上述的信息，後臺同窗能夠記錄用戶的ip、根據ip獲取地址、訪問離開的時間。每一條數據即爲一個pv，而後分組查詢ip便可查出天天的ip數，經過ip地址也能夠查出用戶地域等信息。

咱們來參照一下掘金髮送統計數據的方式

上面咱們能夠看出，掘金用的百度統計平臺發送日誌，先無論掘金用的什麼吧。發送日誌的方式是一個空gif圖。下面參數也能夠隱約猜到一些表面上的意思。剩下的就看你是怎麼約定的了。

分辨率

ds: 1920x1080

當前觸發的DOM元素，後面是即將跳轉的URL？？不太肯定

ep:-257.5*28*51*41*0*#juejin>div[2]>div>header>div>nav>ul>li[1]>ul>li[2]>a*31*21*a*https%3A%2F%2Fjuejin.im%2Factivities

瀏覽器使用的語言

ln: zh-cn

版本

v: 1.2.43

那咱們就開始吧，首先封裝一個插入的monitor.js

這裏聲明瞭一個_map數組，用來存放抓取的數據，以二維數組的方式存儲。

而後又動態插入了一個analytics.js，在這個js中專門抓取數據，monitor文件中還能夠加入一些其餘操做，咱們後續來說。

analytics.js

咱們在這裏抓取了一些簡單的數據，存放在_maq數組中，而且經過encode轉義以後經過一個1x1大小的gif發出請求。按照項目的需求，能夠自定義添加不少參數進去，你們自我發揮。

這裏固然也能夠不走gif的模式發送數據請求，咱們也能夠經過普通的ajax請求發送，由於這個東西要封裝成組件單獨維護，這裏推薦Zepto $.Ajax 模塊。

看一下效果。

咱們就給百度統計接口發送了一條日誌，由於沒有惟一識別的id，人家確定是不會收的。估計百度會默默的把個人ip記下來看看我要幹什麼。

咱們還須要在後臺進行一些參數的添加，就我像上面所說的的ip等參數。而後咱們就能夠經過這些數據作一些可視化界面（echarts, charts, bizcharts等）。好比這種炫酷的圖表。作一個本身的分析平臺，而後慢慢拓展。這個圖表是我經過bizcharts作的。

日誌採集平臺

上面的流量分析平臺抓取了一些歸納性的數據，然而，咱們須要業務上具體的數據，好比說用戶搜索了什麼內容，點擊了哪些按鈕，下了什麼單，等等。

咱們統計這些數據的時候就須要埋點，是一個費時費力的活兒，可是，仍是那句話，一個完善的交付項目，這些都是必須有的。

我這邊就簡單給你們介紹一下阿里的埋點解決方案。而且將日誌與上述流量分析方法進行結合。

SPM(Super Position Model)

SPM(Super Position Model)全稱超級位置模型。用來跟蹤頁面模塊位置的編碼，標準spm編碼採用a.b.c.d.e的格式（各個位置編碼只能由數字、小寫字母、連字符/減號組成），其中a, b位是必須具有的. 各位的含義和部署規範以下:

a標識站點ID，站點ID是指包含特定業務含義的一類頁面的集合，好比女裝市場，就能夠看爲是一個站點。在部署時, SPM-a的聲明必須放在<head></head>閉合標籤內, 經過一個獨立的<meta>標籤聲明. 以下:

<head> ... <meta name="data-spm" content="申請的A位編碼"> ... </head>
複製代碼

b 標識頁面ID，頁面ID是指某一特定業務下的某一具體頁面，好比女裝市場下的女裝首頁。SPM編碼的前兩位a.b標識了惟一指定的一個頁面，而且跟頁面url的靜態部分（即url中?以前的部分）一一對應。在部署時, SPM-b的須要以標籤的一個擴展屬性(data-spm)的方式聲明, 以下:

<body data-spm="註冊的B位編碼">
複製代碼

特別注意: 若aplus.js的部署位置位於head部分，或因某些緣由致使body屬性不能修改，則spm-AB位的聲明，只能經過在head部分使用spm-id元標籤(位置在aplus.js腳本引用代碼以前) 來實現，以下:

<head> ... <meta name="spm-id" content="申請的A位編碼.註冊的B位編碼"> ... </head>
複製代碼

c標識頁面上某一具體的區域或模塊，通常頁面發佈時，源碼中一個table區域或一個div區域包含的部分能夠看作一個模塊。好比女裝首頁的左側導航欄，就能夠看作一個區塊。C位不強制要求聲明，能夠根據需求指定(但若是須要統計頁面具體的坑位點擊數據，則必須聲明C位)，通常被用來監測頁面上具備相對獨立功能的區域。在部署時，SPM-c通常以對應的div容器的擴展屬性(data-spm)來聲明，以下:

<div data-spm="自定義或註冊的C位編碼">
複製代碼

d標識位置ID，是指頁面某一具體的模塊中，一個對應的連接或者圖片，是數據統計的最細粒度。 SPM-d通常不須要註冊或申請, 也通常不須要特別聲明. 系統會自動計算和編碼(前提是C位必須正確聲明). 若是必須, 則也能夠自助聲明, 以下:

<a href="" data-spm="d開頭的自定義編碼串">
複製代碼

e 標識當前日誌的logid, 用以區分訪問日誌時序和回溯用戶的完整訪問路徑。此id由日誌採集腳本自動賦值，不須要且禁止人爲構造和賦值(修改)。

埋點流程

埋點申請：在平臺上申請埋碼，並記錄埋點信息
埋點配置：埋碼分爲可視化自動埋碼，和非可視化手動埋碼
埋點驗證：sdk 自動觸發點擊事件，和平臺上提交的埋點信息作驗證
數據監控：監控埋碼質量
採集管理：採集數據管理

DIY

咱們參考spm埋點流程，以及埋點規則。咱們就這麼埋下了點，可是，怎麼獲取到這些a.b.c.d編碼而且發送日誌請求呢？

咱們仍是以本身diy本身的日誌採集平臺，從中學習到一些東西。

首先，看到attribute方式埋下參數，第一反應就是想到了事件代理，

咱們先在項目中，埋好點，例如：

上面這個是個簡易的埋點，只是個例子，你們能夠在本身的業務組件中隨意撒點，注意順序，注意寫好對應埋點功能文檔便可。

寫一個spm.js

上面的備註我寫的很詳細，相信你們仔細看看就能看得懂，有一行我須要解釋一下

_maq.push(['_trackEvent', spmArray]);

這一行是把日誌數據push到流量統計裏 monitor.js 中 _maq參數中。

而後咱們定義一種解析方法叫，_trackEvent（跟蹤事件），你們能夠回頭看一下，上面的截圖中有寫到。

而後咱們在monitor.js中添加監聽_maq參數變化的方法，觸發變化，便可發送日誌出去。監聽參數變化的方法：

看一下效果：

這樣咱們就能夠經過spm這種方式進行埋點，這種方法須要點擊方式觸發，有人就會問了，若是hover事件怎麼辦，還有一些別的事件。

首先，能夠開放出來一個改變_maq數組的方法。在非click事件的時候主動觸發。

其次，配合analytics文件中的這裏

case裏自定義一些解析規則便可。

Hiper

這裏直接介紹一個插件，個人想法是把這個插件集成到咱們的監控平臺上，首先看一下，這個插件是什麼。

傳送門：Hiper

它能夠統計一些，網站的「速度」。對優化項目，優化壓縮，挺有幫助的，這些數據也能夠集成到咱們的監控平臺中。

END

監控平臺下一篇，目前構思想寫一下如下幾點

異常信息抓取
ajax請求抓取
性能信息抓取

仍是以DIY的形式，封裝本身的抓取方法，將異常信息，請求信息集成到咱們的監控平臺上，仍是以從外部注入項目的方式，這種方式的好處就是，不會影響業務邏輯，不會摻雜在一塊兒，便於維護。

最近仍是有一些時間的吧，反思了一下本身，寫文章的時候都會構思好久，不像之前想怎麼寫怎麼寫，哎。明天發個沸點給大家看看，個人構思筆記。

謝謝你們。回見。

我這邊3月底以前會寫4篇文章，分別爲

《前端性能優化交流》
《前端代碼質量優化交流》《DIY一個前端監控平臺（上）》（本篇）《DIY一個前端監控平臺（下）》（可能會拖到下個月寫）《前端安全問題交流》沉澱一下去年在開發流程方面的一些知識。謝謝各位。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。