程序員如何擺脫“系統(tǒng)又卡了”的騷擾

2019.08.27

這篇是「分布式系統(tǒng)理論」系列的第21篇，也是最后一篇。我們來聊聊分布式系統(tǒng)中的最后一道保障——監(jiān)控。

監(jiān)控這個(gè)事情，有點(diǎn)像我們平時(shí)對(duì)人的健康體檢。想要效果好、結(jié)果靠譜，就得“全面體檢”，每一項(xiàng)都做，否則哪怕檢查報(bào)告都是正常，也不代表沒有問題。下面這個(gè)景象是不是很熟悉？

運(yùn)營小姐姐問：現(xiàn)在系統(tǒng)好卡啊。
程序員小哥哥答：我這里不卡啊，而且從數(shù)據(jù)來看很正常。
運(yùn)營小姐姐問：[一張截圖]，你看一直在加載。
程序員小哥哥答：你的本地網(wǎng)絡(luò)不好吧，打開別的網(wǎng)站試試。
……

監(jiān)控里的“全面體檢”有個(gè)高大上的叫法，「立體化監(jiān)控」。

但是，越全面，成本越高。所以，根據(jù)所處的時(shí)期從中挑選合適的監(jiān)控方式更加重要。

接下去，Z哥來和你一起梳理一下那些有必要做監(jiān)控的地方。最后再給你一個(gè)普適性的建議。

監(jiān)控的三個(gè)層次

從監(jiān)控的目標(biāo)來看，監(jiān)控可以分為三個(gè)層次。分別是「環(huán)境指標(biāo)」、「程序指標(biāo)」、「業(yè)務(wù)指標(biāo)」。

環(huán)境指標(biāo)

環(huán)境指標(biāo)主要是網(wǎng)絡(luò)I/O、網(wǎng)絡(luò)延遲、磁盤I/O、磁盤占用大小、CPU使用率、內(nèi)存使用率、交換分區(qū)等等。

它們的目的是觀測程序所在的環(huán)境，是不是穩(wěn)定。就好比「水培綠籮」，再怎么好養(yǎng)的植物，你把下面的水煮一會(huì)，都得掛。

做環(huán)境指標(biāo)的監(jiān)控很簡單。Z哥建議你二選一就好了。

無腦用的話，就Zabbix吧。非常成熟的企業(yè)級(jí)監(jiān)控產(chǎn)品。網(wǎng)上安裝教程有很多，隨便搜一下就是。

如果服務(wù)器多的話，將Zabbix打包到進(jìn)操作系統(tǒng)，做成一個(gè)鏡像。這樣一來，一臺(tái)新服務(wù)器只要是從鏡像安裝的，就會(huì)自動(dòng)加入到監(jiān)控中。

如果愿意折騰，想二次開發(fā)的話可以使用小米開源的open-falcon。項(xiàng)目的活躍度還不錯(cuò)，可以了解一下：https://github.com/open-falcon/falcon-plus。

雖然功能的豐富度上比Zabbix差一些，但是畢竟是國人的產(chǎn)品，更加符合中國國情。國內(nèi)有不少互聯(lián)網(wǎng)企業(yè)也在用，或者基于它進(jìn)行了二次開發(fā)，最有名的是美團(tuán)二次開發(fā)的mt-falcon的。如果決定進(jìn)行二次開發(fā)的話，可以借鑒一些mt-falcon在網(wǎng)上的公開信息。

程序指標(biāo)

程序指標(biāo)除了和環(huán)境指標(biāo)一樣的CPU使用率、內(nèi)存使用率這種“外部“表現(xiàn)的指標(biāo)之外，還有應(yīng)用程序錯(cuò)誤數(shù)、應(yīng)用程序請(qǐng)求量、應(yīng)用平均響應(yīng)時(shí)間這種”內(nèi)部“表現(xiàn)的指標(biāo)。

其實(shí)做監(jiān)控的時(shí)候有一個(gè)痛點(diǎn)，是不是「無侵入」的？

因?yàn)橐坏┬枰秩氲骄唧w的程序中去編寫「埋點(diǎn)」代碼，就很麻煩，畢竟涉及到更多的人一起配合嘛，推進(jìn)更困難。

CPU使用率、內(nèi)存使用率的監(jiān)控比較簡單，可以直接通過shell或者cmd調(diào)用系統(tǒng)API獲取，和前面的環(huán)境指標(biāo)一樣。

但對(duì)于應(yīng)用程序錯(cuò)誤數(shù)、應(yīng)用程序請(qǐng)求量、應(yīng)用平均響應(yīng)時(shí)間的監(jiān)控，這里是一個(gè)分水嶺，因?yàn)檫@里想要做到「無侵入」的效果，需要做一些額外的工作，否則只能編寫大量的“埋點(diǎn)”代碼。

比如，是不是有一個(gè)網(wǎng)關(guān)來統(tǒng)一進(jìn)行流量分發(fā)？是不是有一個(gè)統(tǒng)一的RPC框架、數(shù)據(jù)庫訪問框架等等。如果有這樣的統(tǒng)一模塊就好辦了，直接在這些模塊里增加監(jiān)控功能。

舉個(gè)例子，你的rpc框架是統(tǒng)一的，那么只要在每次方法調(diào)用前和調(diào)用后記錄好相應(yīng)的數(shù)據(jù)，就可用于后續(xù)統(tǒng)計(jì)出結(jié)果。

關(guān)于采集到的數(shù)據(jù)如何存儲(chǔ)，主流的選擇是將數(shù)據(jù)寫入到一個(gè)「時(shí)序數(shù)據(jù)庫」中。比如Prometheus，這是一個(gè)專門做監(jiān)控報(bào)警的開源框架，在全球都比較火，github上有23K的star。當(dāng)然你也可以選擇其他的時(shí)序數(shù)據(jù)庫，如InfluxDB、OpenTSDB之類。

再配合以一個(gè)可視化框架，比如grafana，將其中的數(shù)據(jù)展示出來，就完成了整個(gè)監(jiān)控系統(tǒng)的搭建。網(wǎng)上的搭建教程也有很多，就不多說了。

如果沒有統(tǒng)一框架的話，可以優(yōu)先考慮通過AOP的方式，以此盡量降低埋點(diǎn)代碼的編寫量。

數(shù)據(jù)采集就在AOP切入的位置進(jìn)行。

特別注意一點(diǎn)，由于監(jiān)控產(chǎn)生的日志數(shù)量龐大，不建議直接與遠(yuǎn)程數(shù)據(jù)庫交互。所以需要借助一些專門的日志采集和傳輸框架。比如flume、logstash。

怎么感覺一下子引入了好多新框架～，沒辦法，真要做好監(jiān)控是挺繁瑣的。

業(yè)務(wù)指標(biāo)

在典型的程序員思維里，認(rèn)為業(yè)務(wù)指標(biāo)關(guān)我什么事。其實(shí)恰恰業(yè)務(wù)指標(biāo)的監(jiān)控更加的“有效”。因?yàn)闃I(yè)務(wù)指標(biāo)出問題了，說明必然哪出問題了，不會(huì)像前面聊的兩個(gè)層面的指標(biāo)，可能看著好好的，但是實(shí)際業(yè)務(wù)卻出了問題。

最近這2年在運(yùn)營圈里被“爆炒”的「增長黑客」概念，本質(zhì)上就是通過數(shù)據(jù)驅(qū)動(dòng)的方式來做運(yùn)營工作。而這背后依賴的就是一個(gè)業(yè)務(wù)指標(biāo)監(jiān)控系統(tǒng)。

每一個(gè)業(yè)務(wù)會(huì)經(jīng)過的關(guān)鍵狀態(tài)，都可以作為「業(yè)務(wù)指標(biāo)」來監(jiān)控。但是由于業(yè)務(wù)指標(biāo)往往不具有「通用性」，所以，需要手動(dòng)在程序里「埋點(diǎn)」。

因此，對(duì)業(yè)務(wù)指標(biāo)的監(jiān)控必然是「侵入性」的。

能不能不要埋點(diǎn)？也不是沒有辦法。

如果在一個(gè)系統(tǒng)的初期，比如日PV在百萬以下的，直接通過業(yè)務(wù)數(shù)據(jù)庫拉數(shù)據(jù)也不失為一個(gè)取巧的辦法。這樣就不用寫什么埋點(diǎn)代碼，簡單粗暴。

到了成長期，直接拉業(yè)務(wù)數(shù)據(jù)庫行不通了，因?yàn)闀?huì)對(duì)正常的業(yè)務(wù)處理產(chǎn)生顯著的性能影響。不過，此時(shí)還可以通過數(shù)據(jù)庫層面做二次分發(fā)，將數(shù)據(jù)實(shí)時(shí)地復(fù)制到一個(gè)單獨(dú)的庫中，從這個(gè)庫拉數(shù)據(jù)也能“撐”一段時(shí)間。

當(dāng)然了，這些辦法只能解決一部分問題。如果需要監(jiān)控的業(yè)務(wù)指標(biāo)不存在于業(yè)務(wù)流轉(zhuǎn)的數(shù)據(jù)中（比如用戶行為數(shù)據(jù)），那就沒辦法了，只能老老實(shí)實(shí)的寫「埋點(diǎn)」代碼。

總體來看，這三層指標(biāo)恰好構(gòu)成一個(gè)金字塔結(jié)構(gòu)。從監(jiān)控價(jià)值來看業(yè)務(wù)指標(biāo) > 程序指標(biāo) > 環(huán)境指標(biāo)。從實(shí)施的一個(gè)成本來看，也是業(yè)務(wù)指標(biāo) > 程序指標(biāo) > 環(huán)境指標(biāo)。