互聯(lián)網(wǎng)系統(tǒng)運(yùn)維實(shí)踐

1、 互聯(lián)網(wǎng)系統(tǒng)運(yùn)維實(shí)踐前言隨著互聯(lián)網(wǎng)的高速發(fā)展，企業(yè)經(jīng)歷的數(shù)據(jù)量越來(lái)越大、越來(lái)越重，運(yùn)維也越來(lái)越重要。希望通過(guò)本文分享B站運(yùn)維監(jiān)控系統(tǒng)的發(fā)展歷程以及我的思考。一、自動(dòng)發(fā)布按過(guò)往經(jīng)驗(yàn)，掐指一算：要尋找破局點(diǎn)、盡早做出第一個(gè)改變！當(dāng)時(shí)最耗精力的就是發(fā)布，沒(méi)多久我們看準(zhǔn)了從發(fā)布著手，先把勞動(dòng)力解放出來(lái)。于是做了簡(jiǎn)單的發(fā)布系統(tǒng)：基于OpenLDAP和谷歌的“身份驗(yàn)證器”作為認(rèn)證，Gitlab作為代碼托管，按需接入Jenkins構(gòu)建，在堡壘機(jī)上包裝Ansible（腳本也在Gitlab上），用命令行完成批量部署上線。初見(jiàn)成效后，簡(jiǎn)單包裝了一個(gè)頁(yè)面、加了發(fā)布時(shí)間的控制就開(kāi)心的用起來(lái)了。二、必須做監(jiān)控我們服務(wù)端

2、典型的應(yīng)用場(chǎng)景如下圖：用戶(hù)訪問(wèn)到邊緣的CDN節(jié)點(diǎn)，然后通過(guò)二級(jí)緩存最后傳到核心機(jī)房的四層負(fù)載均衡LVS集群，再通過(guò)七層Tengine的SLB集群按規(guī)則分流到各個(gè)應(yīng)用里。典型的應(yīng)用后端會(huì)有緩存、隊(duì)列，然后再到數(shù)據(jù)庫(kù)。開(kāi)發(fā)語(yǔ)言有Go、Java、PHP、Python、C/C+等（排名不分先后）那么問(wèn)題來(lái)了：“監(jiān)控呢？”B站工程師氣氛很濃，熱愛(ài)開(kāi)源。連DNS都自研、CDN自建，鏈路長(zhǎng)、監(jiān)控少，隨業(yè)務(wù)增多定位問(wèn)題變得非常困難。三、第一個(gè)報(bào)警：ELK很多人心里都有一套運(yùn)維自動(dòng)化系統(tǒng)，而且是閉環(huán)的。在有效資源里，從哪里開(kāi)始呢？原計(jì)劃本是打算自下而上，從主機(jī)監(jiān)控一步步往上走。而后發(fā)現(xiàn)不少用戶(hù)反饋的問(wèn)題，后端無(wú)

3、感知。鑒于CDN日志都在手上，用戶(hù)最開(kāi)始接觸的就是CDN。索性把錯(cuò)誤日志給收回來(lái)，錯(cuò)誤多了就報(bào)警。于是ELK誕生了：我們僅收錯(cuò)誤日志，塞到ElasticSearch里，按域名、CDN節(jié)點(diǎn)、用戶(hù)IP以及錯(cuò)誤碼進(jìn)行分類(lèi)排序。這樣當(dāng)收到報(bào)警短信時(shí)，基本第一眼都可以鎖定一個(gè)故障區(qū)域了。隨后稍加流程，接入微信完美收工。以下是報(bào)警短信的代碼片段，計(jì)劃任務(wù)第分鐘執(zhí)行（很土很有效）。另外還有個(gè)腳本監(jiān)控錯(cuò)誤日志的數(shù)量，但數(shù)量為零時(shí)也會(huì)報(bào)警（你懂的）。四、可惜還是你：Zabbix做完CDN監(jiān)控，我們想回頭把基礎(chǔ)監(jiān)控做起來(lái)。經(jīng)過(guò)開(kāi)源、自研各種討論，綜合下來(lái)還是選擇了Zabbix。因?yàn)樗鼘?shí)施快、報(bào)警策略靈活、會(huì)用它的

4、人多容易招。五、監(jiān)控交給你：Statsd好，CDN前端的錯(cuò)誤監(jiān)控，應(yīng)用底層的系統(tǒng)監(jiān)控都有了。應(yīng)用自身的監(jiān)控怎么做呢？根據(jù)當(dāng)時(shí)同事的過(guò)往經(jīng)驗(yàn)看，怎么熟怎么來(lái)。那就Statsd吧！Statsd用起來(lái)比較簡(jiǎn)單，只需要開(kāi)發(fā)在他關(guān)注的代碼前后加上錨點(diǎn)就可以了。默認(rèn)是UDP協(xié)議上報(bào)數(shù)據(jù)（天生自帶異步光環(huán)），不容易出現(xiàn)由于監(jiān)控影響到程序本身。下圖是在Shell腳本里做Statsd監(jiān)控的示例代碼：搭好一套Statsd收集器，配置一下Graphite就能出圖了：前端用Grafana包裝一下，一個(gè)完整的APM監(jiān)控閃亮登場(chǎng)。以下圖例為某接口的平均響應(yīng)耗時(shí)：六、百花齊放：Grafana網(wǎng)傳Grafana有插件可以直接

5、通過(guò)API讀取Zabbix的監(jiān)控?cái)?shù)據(jù)，然而沒(méi)多久新版本的Grafana就默認(rèn)自帶了此光環(huán)。然后我們就開(kāi)心的給Zabbix裝上了Grafana套件，和Statsd的監(jiān)控?cái)?shù)據(jù)整合在一起、易用性加一分。此時(shí)結(jié)合CDN錯(cuò)誤監(jiān)控、應(yīng)用層APM監(jiān)控、底層數(shù)據(jù)監(jiān)控，聯(lián)運(yùn)查問(wèn)題某些時(shí)候感覺(jué)很舒適。下圖為一次故障過(guò)程的追蹤：我們并沒(méi)有因此滿(mǎn)足，基礎(chǔ)架構(gòu)的同學(xué)參考谷歌的文獻(xiàn)實(shí)現(xiàn)了內(nèi)部的Drapper鏈接追蹤系統(tǒng)。請(qǐng)求從CDN入口開(kāi)始就會(huì)攜帶TrackID，甚至不忘在SQL的查詢(xún)語(yǔ)句里把TrackID帶上。以至于追蹤得很細(xì)致，哪里什么原因耗時(shí)最長(zhǎng)一目了然。圖示：七、突破壁壘：Misaka做完如上監(jiān)控，發(fā)現(xiàn)仍然有用戶(hù)

6、反饋問(wèn)題時(shí)我們束手無(wú)策。因?yàn)槲覀儧](méi)有收到任何與此用戶(hù)相關(guān)的錯(cuò)誤信息可能網(wǎng)路過(guò)程出現(xiàn)了未知原因，比如“被加速”、“功能問(wèn)題”、“異常退出”等等。于是我們的輿情監(jiān)測(cè)系統(tǒng)Misaka上線，和CDN錯(cuò)誤日志思路相同；不同的是客戶(hù)端是真客戶(hù)端，突破了服務(wù)端的壁壘。由于Misaka上線的受眾群體更廣，我們簡(jiǎn)單包裝了一下界面（雖然我覺(jué)得ELK更漂亮）、添加了歷史數(shù)據(jù)的比較。更利于分析，下圖示例：八、報(bào)警整合隨著人員的加入和系統(tǒng)的逐步完善，定制化的監(jiān)控和系統(tǒng)也越來(lái)越多。比如，支持多種集群模式的Redis集群監(jiān)控：還有隊(duì)列的監(jiān)控，以及把Kafka隊(duì)列包裝成支持Redis協(xié)議的Databus中間件的監(jiān)控。下圖示例

7、：隨即Docker的監(jiān)控也來(lái)了，下圖示例：那么問(wèn)題又來(lái)了，這么多監(jiān)控，眼不花嗎？會(huì)不會(huì)查問(wèn)題的時(shí)候得開(kāi)N個(gè)窗口，拼經(jīng)驗(yàn)看誰(shuí)定位問(wèn)題更快痛定思痛，我們走訪了幾家互聯(lián)網(wǎng)公司。然后默默的做了一次整合，將報(bào)警和事件以時(shí)間軸的方式展現(xiàn)了出來(lái)。用過(guò)都說(shuō)好，下圖示例：九、在路上：Prometheus經(jīng)歷約一年時(shí)間的洗禮，我們又回到了監(jiān)控系統(tǒng)的選型。為什么？因?yàn)樵絹?lái)越多的花樣監(jiān)控需求，已經(jīng)無(wú)法很快得到滿(mǎn)足、而且維護(hù)工作日漸繁瑣。嗯，可能不同階段需要不同的解決方案。那為什么是Prometheus？因?yàn)榭蛇x的開(kāi)源產(chǎn)品并不多，新潮前衛(wèi)的現(xiàn)代化監(jiān)控就OpenFlaon和Prometheus啦。Prometheus不止是監(jiān)控工具，它是一套完整的監(jiān)控解決方案。除了前端，其它都好。很快Prometheus就上線了，逐步取代了Zabbix。前端仍然是熟悉的Gr