我為什么用ES做Redis監(jiān)控，不用Prometheus或Zabbix？

圖示：Redis熱度排名

Redis當(dāng)下很流行，也很好用，無(wú)論是在業(yè)務(wù)應(yīng)用系統(tǒng)，還是在大數(shù)據(jù)領(lǐng)域都有重要的地位；但Redis也很脆弱，用不好，問(wèn)題多多。2012年以前都是以memcached為主，之后轉(zhuǎn)到Redis陣營(yíng)，經(jīng)歷過(guò)單實(shí)例模式、主從模式、哨兵模式、代理模式，集群模式，真正公司層面用得好的很少，對(duì)于Redis掌控都很片面，導(dǎo)致實(shí)際項(xiàng)目中問(wèn)題不少。

Redis要想用得好，需要整體掌握3個(gè)層面：

其中架構(gòu)與運(yùn)維至關(guān)重要，多數(shù)中小型企業(yè)僅在開(kāi)發(fā)層面滿足常用功能，數(shù)據(jù)規(guī)模稍微大些，業(yè)務(wù)復(fù)雜度高些，就容易出現(xiàn)各種架構(gòu)與運(yùn)維問(wèn)題。本文主旨是探討Redis監(jiān)控體系，目前業(yè)界當(dāng)然也有很多成熟的產(chǎn)品，但個(gè)人覺(jué)得都很常規(guī)，只做到一些粗粒度的監(jiān)控， 沒(méi)有依據(jù)業(yè)務(wù)需求特點(diǎn)因地制宜去細(xì)化，從而反向的提供架構(gòu)開(kāi)發(fā)優(yōu)化方案。

本文內(nèi)容將圍繞如下幾個(gè)問(wèn)題展開(kāi)討論：

公司業(yè)務(wù)范圍屬于車聯(lián)網(wǎng)行業(yè)，有上百萬(wàn)級(jí)的真實(shí)車主用戶，業(yè)務(wù)項(xiàng)目圍繞車主生活服務(wù)展開(kāi)，為了提高系統(tǒng)性能，引入了Redis作為緩存中間件，具體描述如下：

圖示：Redis集群架構(gòu)與應(yīng)用架構(gòu)示意圖

系統(tǒng)剛開(kāi)始關(guān)于Redis的一切都很正常，隨著應(yīng)用系統(tǒng)接入越來(lái)越多，應(yīng)用系統(tǒng)子模塊接入也越來(lái)越多，開(kāi)始出現(xiàn)一些問(wèn)題，應(yīng)用系統(tǒng)有感知，集群服務(wù)端也有感知，如下描述：

其實(shí)問(wèn)題的根源都是架構(gòu)運(yùn)維層面的欠缺，對(duì)于Redis集群服務(wù)端的運(yùn)行監(jiān)控其實(shí)很好做，本身也提供了很多直接的命令方式，但只能看到服務(wù)端的一些常用指標(biāo)信息，無(wú)法深入分析，治標(biāo)不治本，對(duì)于Redis的內(nèi)部運(yùn)行一無(wú)所知，特別是對(duì)于業(yè)務(wù)應(yīng)用如何使用Redis集群一無(wú)所知：

監(jiān)控的目的不僅僅是監(jiān)控Redis本身，而是為了更好的使用Redis。傳統(tǒng)的監(jiān)控一般比較單一化，沒(méi)有系統(tǒng)化，但對(duì)于Redis來(lái)說(shuō)，個(gè)人認(rèn)為至少包括：一是服務(wù)端，二是應(yīng)用端，三是服務(wù)端與應(yīng)用端聯(lián)合分析。

服務(wù)端：

應(yīng)用端：

應(yīng)用端、獲取應(yīng)用端使用Redis的一些行為，具體哪些應(yīng)用哪些模塊最占用 Redis資源、哪些應(yīng)用哪些模塊最消耗Redis資源、哪些應(yīng)用哪些模塊用法有誤等。

聯(lián)合分析：

聯(lián)合分析結(jié)合服務(wù)端的運(yùn)行與應(yīng)用端使用的行為，如：一些造成服務(wù)端突然阻塞的原因，可能是應(yīng)用端設(shè)置了一個(gè)很大的緩存鍵值，或者使用的鍵值列表，數(shù)據(jù)量超大造成阻塞。

為什么會(huì)選擇Elastic-Stack技術(shù)棧呢？

多數(shù)的第三方只監(jiān)控一些指標(biāo)，對(duì)于明細(xì)日志還是采用ELK（Elasticsearch、Logstash、Kibana），也就是說(shuō)用第三方監(jiān)控指標(biāo)之后，還得再搭建一個(gè)ELK集群看明細(xì)日志。

再就是說(shuō)Elastic-Stack技術(shù)棧整合的優(yōu)勢(shì)，指標(biāo)也可以、日志文件也可以，從采集開(kāi)始到存儲(chǔ)、到最終報(bào)表面板都整合得非常好，門檻很低。

下面詳細(xì)聊聊我們具體怎么做的，做了哪些工作？

Elastic-Stack家族有Metricbeat產(chǎn)品，支持系統(tǒng)層面的信息收集，簡(jiǎn)單的配置下Elastic集群地址和系統(tǒng)指標(biāo)模塊即可上線，并且會(huì)在Kibana中創(chuàng)建已有的系統(tǒng)監(jiān)控面板，非常簡(jiǎn)單快速，一般運(yùn)維就可以搞定。

圖示：metrcibeat示意圖

系統(tǒng)指標(biāo)信息收集配置樣例如下：

收集Redis集群運(yùn)行信息，業(yè)界通常做法都是采用Redis提供的info命令，定期收集。

info獲取的信息包括如下：

Elastic-Stack家族的Metricbeat產(chǎn)品也支持Redis模塊，也是采用info命令獲取的，但是有一些實(shí)現(xiàn)的局限性，如下描述：

所以這里參考了CacheCloud產(chǎn)品（搜狐團(tuán)隊(duì)開(kāi)源），我們自定義設(shè)計(jì)開(kāi)發(fā)了 Agent，定時(shí)從Redis集群采集信息，并在內(nèi)部做一些統(tǒng)計(jì)數(shù)值的簡(jiǎn)單計(jì)算，轉(zhuǎn)換成Json，寫入到本地文件，通過(guò)Logstash采集發(fā)送到Elasticsearch。

圖示：Redis服務(wù)端運(yùn)行信息采集架構(gòu)示意圖

Redis服務(wù)端運(yùn)行日志采集很簡(jiǎn)單，直接通過(guò)Elastic-Stack家族的Filebeat產(chǎn)品，其中有Redis模塊，配置一下Elastic服務(wù)端，日志文件地址即可。

圖示：服務(wù)端日志采集過(guò)程

Redis運(yùn)行日志采集配置：

應(yīng)用端信息采集是整個(gè)Redis監(jiān)控體系最重要的部分，也是實(shí)現(xiàn)最麻煩、鏈路最長(zhǎng)的。首先是修改jedis（技術(shù)棧Java）源碼，增加埋點(diǎn)代碼，重新編譯并引用到應(yīng)用項(xiàng)目中，應(yīng)用端對(duì)于Redis集群的任何命令操作，都會(huì)被捕捉，并記錄下關(guān)鍵信息，之后寫入到本地文件。

圖示：Redis應(yīng)用端行為采集架構(gòu)圖

應(yīng)用端采集的數(shù)據(jù)格式如下：

圖示：應(yīng)用端采集的數(shù)據(jù)案例

jedis修改：

jedis改造記錄的信息如下：

在jedis改造有幾處地方，如下：

在類Connection.java文件中有2處：

圖示：類Connection.java文件埋點(diǎn)代碼的地方

圖示：類Connection.java文件埋點(diǎn)代碼的地方

類JedisClusterCommand文件埋點(diǎn)代碼.java文件中有1處：

圖示：類JedisClusterCommand文件埋點(diǎn)代碼

logback修改：

應(yīng)用端都會(huì)使用logback寫入日志文件，同時(shí)為了更加精準(zhǔn)，應(yīng)用端寫入日志時(shí)還需要獲取應(yīng)用端的一些信息，如下：

自定義一個(gè)Layout，自動(dòng)獲取應(yīng)用端的IP地址與服務(wù)器名稱：

圖示：自定義Logback的Layout

app配置：

app配置屬于最后收尾工作，主要是輸出埋點(diǎn)的日志數(shù)據(jù)，配置日志logback.xml文件即可：

圖示：配置應(yīng)用端日志文件logback.xml

日志采集：

應(yīng)用端日志采集采用Logstash，配置日志目錄，指向Elastic集群，這樣整體的監(jiān)控日志采集部分就結(jié)束了。

Redis服務(wù)端的日志分析比較簡(jiǎn)單，常規(guī)的一些指標(biāo)而已，創(chuàng)建好關(guān)鍵的圖表，容易看出問(wèn)題。重點(diǎn)討論應(yīng)用端的日志分析。

圖示：應(yīng)用端使用Redis一些行為圖表

ELK監(jiān)控體系上線之后，我們連續(xù)觀察分析兩周，獲得了一些監(jiān)控成果，如：

監(jiān)控體系相當(dāng)于架構(gòu)師的眼睛，有了這個(gè)，Redis方面的優(yōu)化改造方案就很好制定了：

監(jiān)控體系項(xiàng)目前后經(jīng)歷過(guò)幾個(gè)月，服務(wù)端部分短期內(nèi)就完成的，應(yīng)用端是隨著應(yīng)用發(fā)布逐步完成的。上線完成之后又經(jīng)歷幾周的跟蹤分析，才確定下來(lái)整體的優(yōu)化方案。

監(jiān)控體系本身并不是為了監(jiān)控，而是發(fā)現(xiàn)問(wèn)題、預(yù)見(jiàn)問(wèn)題，最終提前解決問(wèn)題，監(jiān)控做得好，下班下得早。

Redis集群是個(gè)好東西，完全掌握還是需要很長(zhǎng)的時(shí)間，特別是架構(gòu)、運(yùn)維層面，如果沒(méi)有，請(qǐng)做好監(jiān)控。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝