圖示：Redis熱度排名

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

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

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

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

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

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

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

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

監(jiān)控的目的不僅僅是監(jiān)控Redis本身，而是為了更好的使用Redis。傳統(tǒng)的監(jiān)控一般比較單一化，沒有系統(tǒng)化，但對于Redis來說，個人認為至少包括：一是服務(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īng)用端使用的行為，如：一些造成服務(wù)端突然阻塞的原因，可能是應(yīng)用端設(shè)置了一個很大的緩存鍵值，或者使用的鍵值列表，數(shù)據(jù)量超大造成阻塞。

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

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

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

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

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

圖示：metrcibeat示意圖

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

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

info獲取的信息包括如下：

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

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

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

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

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

Redis運行日志采集配置：

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

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

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

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

jedis修改：

jedis改造記錄的信息如下：

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

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

圖示：類Connection.java文件埋點代碼的地方

圖示：類Connection.java文件埋點代碼的地方

類JedisClusterCommand文件埋點代碼.java文件中有1處：

圖示：類JedisClusterCommand文件埋點代碼

logback修改：

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

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

圖示：自定義Logback的Layout

app配置：

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

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

日志采集：

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

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

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

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

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

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

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

Redis集群是個好東西，完全掌握還是需要很長的時間，特別是架構(gòu)、運維層面，如果沒有，請做好監(jiān)控。

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