監控之道 — 產品生死存亡之道

背景

在當下互聯網蓬勃發展的勢頭之下，能夠說一個產品的生死是由用戶決定，由於用戶口碑的傳遞就像互聯網產品通常也是病毒式、爆發式的傳播。那麼保證一個產品全部調整都能隨時迎合用戶的體驗將是任何產品生存的惟一道路，而鋪平這條道路的基石就是監控。

監控之道是一條艱辛之道，由於監控系統的搭建須要不斷的精益求精。對於監控點的選擇須要不斷的提煉，監控系統的框架通用性、實效性以及對定製化需求的支撐程度都直接決定了一套監控系統的好壞。監控的系統的採集數據從時效上大體爲兩類：一、實時監控數據；二、上報統計數據。這兩類數據根據其時效性分別具備不一樣的用途,下面將分別進行介紹。

實時監控數據

實時監控數據。這類數據通常多爲服務監控數據。該類數據主要反映的是服務的實時情況。這個須要提供一套完備的監控數據實時採集系統，以及業務方可定製監控點的策略。業務方定製監控點，通常咱們俗稱爲埋點。就是在咱們比較關注的服務關鍵指標上加上監控點。這些關鍵指標點通常包括這幾類：
請求總量：經過這個量一方面能夠分析用戶對該產品的一個使用習慣，分析流量，另外一方面能夠得出最佳的運維時間點和得出服務是否須要擴容的數據依據。將請求總量經過渠道或者平臺等不一樣維度進行劃分，經過這個能夠得出不一樣通道對整個服務的影響。後續能夠利用該數據指標做爲試新或者AB test的流量劃分依據。

超時量：經過這個數據能夠反映出服務的容量是否知足現階段的需求，是否須要擴容。同時也能夠反映在相似秒殺狀況下服務對突發流量的承載能力，爲臨時服務擴容的數量提供數據依據。

成功返回量：這個數據不用多說，必要的監控點，反饋出當前的服務質量。

服務各個錯誤的發生量：服務的總請求量減去服務的成功量，中間的差值就是失敗的量。那麼問題來了，你的服務哪出問題了。這個從代碼上是沒法直觀分析的，服務的每一個階段都有可能出問題，這就須要咱們在每一個退出服務的地方加上不一樣的監控點。這樣就能夠統計處不一樣錯誤的發生量，再結合代碼看爲何這個錯誤比較多，這樣纔能有的放矢地對服務的成功率進行改造。

服務的存儲使用量：這個指標也不用多說，若是服務提供的是存儲服務的話，那麼須要標識出來目前存儲了多少條數據，佔用了多少存儲空間。若是是緩存服務最好標識出緩存的命中量，沒有命中的量。能夠經過這個分析緩存的的有效利用率，以及緩存服務是否須要提供擴容。

除了上述根據業務進行定製的監控以外，還須要對服務運行的物理機器的一些通用指標進行監控。這些指標包括CPU利用率、磁盤使用率、IO調用頻次等關鍵指標。經過對這些數據的監控，能夠幫助開發人員對一些服務異常抖動狀況進行分析。尤爲是在由服務混跑的物理機器上尤爲容易出現這種問題。
當一個工做量很大的定時做業啓動時，直接吃光CPU，致使機器上其餘服務的成功率降低。另一些最簡單也是最容易忽略的錯誤，也能夠依賴這些數據對問題進行快速定位。好比磁盤已滿致使日誌文件寫入不了，而後整個服務進程卡死在日誌寫入上，這種錯誤要是沒有這些監控幫助分析可能會一時間聯想不到這個問題而致使問題處理時間過長。另外有了這些監控也能夠有效的幫助運維提高工做效率。

上報統計數據

上報統計數據，這類數據主要包括了用戶操做數據的上報，客戶端crash日誌，用戶請求服務的記錄等。這類數據主要反饋了產品的策略和客戶端的穩定性。

用戶操做數據： 這類數據主要是記錄了用戶對APP的操做行爲。經過這些行爲能夠分析出用戶的操做鏈。直接能夠直接反饋出用戶對APP上的那些功能使用頻率比較高，新用戶對於引導理解能力等等。

對於高頻功能咱們須要減小用戶操做的步驟數，儘量提升APP的可用性。好比支付寶最經常使用的兩個功能一個是掃碼支付，一個是付碼，因此這兩個功能一打開APP就可使用，對於用戶來講操做成本只有一步，十分便捷。

而對於新手指引來講，這個監控更重要。能夠經過分析用戶的操做行爲，能得出用戶在新手指引的每一步的停留時間以及中斷在哪一步。若是多數用戶在其中某一步停留時間比較常，那麼說明咱們的新手指引讓用戶產生疑惑了，用戶開始思考這個步湊的含義，這是須要咱們改造的。若是用戶在某一步中斷了，那麼這就是用戶的流失點，這是APP的致命點，須要咱們能儘快進行改造。不然等到產品被用戶拋棄時悔之晚矣。

用戶請求參數：經過對用戶請求參數的抓取分析，能夠分析出用戶的使用習慣以及高頻場景。能爲後續產品運營提供數據支持。

推薦閱讀：

精心整理 | 2017下半年文章目錄
CAP 定理的含義
Python學習思惟導圖（附下載地址）
2018年5、六月技術文章目錄（附所有文章目錄）
圖說TCP之滑動窗口和擁塞窗口

專一服務器後臺技術棧知識總結分享

歡迎關注交流共同進步

碼農有道 coding

碼農有道，爲您提供通俗易懂的技術文章，讓技術變的更簡單！