小東西快快學快快記，大知識按計劃學，不拖延
我現在是有參與到團隊的日誌系統的開發維護，所以今後打算把 前端監控 做成一個系列，把整個前端監控鏈路給總結一遍
幫助自己鞏固知識，也幫助想了解這方面內容的同學
這篇文章將是一個序篇，總覽地說一下 前端監控，大概分爲5個部分
1、監控典型例子
2、爲什麼需要監控
3、監控上報什麼內容
4、監控上報的完整鏈路
5、完整的上報系統包含什麼
說真的，我之前沒怎麼看重監控這個東西，只覺得徒增我的工作量，甚至有點牴觸，直到我遇到了問題。
有些東西就是這樣，不等到問題找上你，你都根本不會重視
下面講幾個真實我碰到的例子
1、偶現bug，無法復現
運營側反饋說現網有一個偶現的bug，需要我解決一下。我反覆排查，就是沒復現出來。
代碼邏輯沒有問題，根本無從下手，但是這個bug的的確確是存在的
偏偏這個項目又沒有接監控日誌上報，無奈之下，我只好接了監控重新發布，等到有bug 復現的時候，再查看日誌從而定位到問題。
最後bug 如願復現，查看日誌，是因爲接口失敗，從而導致用戶操作了產生錯誤數據的bug
幸好這是管理後臺，只是給產品運營同學用，如果是用戶使用，估計我都溜溜球了從此我深刻體會到日誌的重要性
大佬笑了笑沒有回答，深藏功與名
到現在，我才明白，看前端監控啊，TMD 查監控日誌啊
頁面白屏肯定是報錯啊，錯誤肯定是要上報的，一查不就知道了
而且前端報錯這種東西，服務端哪裏會有日誌啊，大部分就是頁面js 報錯
就像這種多級取值操作沒有判空導致的 render 錯誤
如果你沒有監控錯誤上報，謝謝，你可以溜溜球了
看了上面的例子，大家應該也體會到 前端監控的重要性了吧，再詳細說，就是3個點
1、被動爲主動，及時發現問題，以免造成損失
問題是不可避免的，但是我們可以儘早發現儘早解決，而不是等到用戶發現
用戶一般出現問題的時候，是不會和你反饋的，你也只會白白流失一個用戶並收穫親切的問候，“做的什麼垃圾東西”
一般如果頁面的 bug 頻率很高，我們會有一個告警機制，我們就可以緊急處理這個問題
2、清晰瞭解運營情況，評估運營成本和質量
我們上線一個活動，要知道有多少用戶訪問，有多少用戶參與，沉澱的用戶有多少
這樣我們才知道活動的價值，是否對我們增長用戶有幫助
可以幫助我們的產品同學指明方向
比如我們的日誌監控圖是這樣的
就這樣可以很清晰瞭解上線的活動的數據
3、輔助日誌，排查偶現的問題
就像我說的例子，日誌重在幫助你排查偶現的問題，有時你可能排查到明年都搞不清楚這個問題的
有可能是用戶的問題，有可能是你代碼處理的問題，有可能是接口的問題
幫助你定位問題，減輕你排查的壓力，少浪費時間做無用功
所以一款合格成熟的應用，一定是可控的，出問題我要知道，流量情況我要知道，成功率我要知道
這樣才能把應用越做越好，完善用戶體驗，把控產品方向。
那麼我們前端監控，需要上報什麼東西，才能對應用有一個完整的監控呢？
分了兩個部分
1、上報的類型
2、上報的具體內容
1上報類型
對於頁面，我們通常將監控 分爲 3個大類型
1、測速類監控
2、穩定性監控
3、計量類監控
1、測速類監控
顧名思義就是速度，包括 接口請求的響應速度，頁面首屏速度，或者自定義測速，比如某段複雜算法代碼的執行速度
2、穩定性監控
評估一個應用的穩定性，當然是看 成功率 和 錯誤率
比如 頁面的錯誤上報，資源加載錯誤，接口請求計算成功率和失敗率
還包括自定義上報數據，比如在代碼關鍵節點手動上報數據，保存用戶操作關鍵的數據，就類似於你在開發時 console 一樣，主要是用於定位問題
3、計量類監控
一般是用於運營方面的數據
1、頁面的 PV（page view）UV（user view）
2、關鍵操作的自定義上報。比如視頻點擊量，視頻觀看量，分享量 等等從上面這些指標，就可以知道一個活動的有效性，如果pv 和 uv 都很小，說明這個活動推廣不夠
如果pv 還可以，但是裏面點擊量 分享 很少，說明這個活動不夠吸引用戶
2上報的具體內容
我們上報的請求中，具體需要包含哪些內容？
我們團隊是制定了一套字段規範，一部分是針對用戶端信息的，一部分是針對請求信息，一部分是自定義數據
用戶端信息。包括 ip ，手機類型，瀏覽器，訪問的頁面鏈接，日誌時間，域名 等
請求信息。就是接口請求一般包含的信息，接口名 cgi，method，query，body，statuscode，response，header
自定義數據。就是給你手動上報的時候保存你需要的數據，比如其中一個字段就是 message
比如你監聽了一個按鈕點擊事件，你想知道這個按鈕的點擊量，所以就在事件回調中進行了上報
然後查詢日誌的時候，就只要查 message ="xxx按鈕點擊量" 這個條件，就能知道有多少點擊量了
用戶操作鏈路跟蹤。我們需要對用戶當時所有的操作日誌，串成一條鏈路，這樣才知道用戶是什麼樣的操作纔會觸發bug
所以我們需要一個 鏈路字段 trace_id，這個id在頁面初始化的時候生成存進 sessionStorage，之後每次上報都會讀取並加上這個字段。因爲 sessionStorage 只會在當前會話中有效，用戶關掉之後就會清空
所以我們利用它來進行用戶單次訪問的日誌串聯
來看下我們整個上報的流程
主要分爲3個部分，如下圖
其中第二步保存日誌，我們不僅需要實時上傳，還需要保存用戶端本地。
其中考慮有網絡情況導致關鍵日誌丟失，所以會保存本地一份。如果用戶有反饋問題的時候，我們可以引導他上傳本地的日誌。
比如我們會在頁面綁定一些操作，用來給用戶上傳日誌使用
一個完整的上報系統是怎麼樣的
通過上面這個上報的流程，我們應該可以簡單瞭解到上報系統的組成
大致可以分爲 5 個部分
1、頁面引入的上報SDK
2、上報數據的存儲系統
3、上報數據的查詢系統
4、可視化配置系統
5、用戶行爲追蹤系統
所以看起來內容還是挺多的，但是我們當然是以業界現有的工具爲主，其次纔是自己開發。
下面就來簡單說下每個部分都是怎麼做的，後面我會對這些部分都做一個詳細的文章說明
上報SDK。上報 sdk 是我們自己開發的，具體就是一個npm 包，直接在項目中 import 引入。主要是爲了針對業務開發一套上報更加便捷的sdk。最大化減少手動上報，減少代碼入侵，做到無感上報，比如請求抓取、 測速，頁面錯誤方面都是 sdk 自動抓取上報的，只有 自定義上報點，才需要手動加入。
存儲系統。我們使用了 Elasticsearch 作爲日誌存儲的解決方案，Elasticsearch 是一個開源、分佈式、高擴展、高實時的搜索與數據分析引擎。它能很方便的使大量數據具有搜索、分析和探索的能力
查詢系統。採用 Kibana。Kibana 是 Elasticsearch 團隊推出的一個搜索，告警的ui工具，配合上面的 Elasticsearch 使用。
可視化配置系統。採用 Grafana。Grafana是一款用Go語言開發的開源數據可視化工具，可以做數據監控和數據統計，帶有告警功能。就是對日誌數據進行各種可視化預覽，柱狀圖，餅圖，曲線圖等等，對日誌有一個清晰的預覽。
用戶行爲追蹤系統。採用 jaeger。前面說了每次用戶訪問都會初始化生成一個 trace_id，然後日誌上報都會帶上這個id，然後形成一條完成的用戶操作日誌鏈路，方便排查bug。但是我們也只是保存一個 字段而已，直接查出來，並不能很好幫助我們排查，還需要一個系統幫我們把這個日誌完美地串起來，讓我們方便查看。
如果你沒有接觸過日誌，可能你真的無法體會到日誌的重要性，希望我的文章能帶給你啓發。
可能別人苦口婆心和你說多重要多重要，你沒有自己真的踩過坑的時，還是無法深刻體會的。
但是你要記住啊，小坑踩無損失可以，大坑一踩你可能就溜溜球了
鑑於本人能力有限，難免會有疏漏錯誤的地方，請大家多多包涵， 如果有任何描述不當的地方，歡迎後臺聯繫本人，領取紅包
本文分享自微信公衆號 - 神仙朱（skying-zhu）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。