圖示：Redis熱度排名

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

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

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

本文內容將圍繞如下幾個問題展開討論：

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

圖示：Redis集群架構與應用架構示意圖

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

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

監(jiān)控的目的不僅僅是監(jiān)控Redis本身，而是為了更好的使用Redis。傳統(tǒng)的監(jiān)控一般比較單一化，沒有系統(tǒng)化，但對于Redis來說，個人認為至少包括：一是服務端，二是應用端，三是服務端與應用端聯合分析。

服務端：

應用端：

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

聯合分析：

聯合分析結合服務端的運行與應用端使用的行為，如：一些造成服務端突然阻塞的原因，可能是應用端設置了一個很大的緩存鍵值，或者使用的鍵值列表，數據量超大造成阻塞。

為什么會選擇Elastic-Stack技術棧呢？

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

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

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

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

圖示：metrcibeat示意圖

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

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

info獲取的信息包括如下：

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

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

圖示：Redis服務端運行信息采集架構示意圖

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

圖示：服務端日志采集過程

Redis運行日志采集配置：

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

圖示：Redis應用端行為采集架構圖

應用端采集的數據格式如下：

圖示：應用端采集的數據案例

jedis修改：

jedis改造記錄的信息如下：

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

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

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

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

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

圖示：類JedisClusterCommand文件埋點代碼

logback修改：

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

自定義一個Layout，自動獲取應用端的IP地址與服務器名稱：

圖示：自定義Logback的Layout

app配置：

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

圖示：配置應用端日志文件logback.xml

日志采集：

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

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

圖示：應用端使用Redis一些行為圖表

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

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

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

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

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

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