李猛

數(shù)據(jù)技術(shù)專家

Elastic-Stack產(chǎn)品深度用戶，ES認(rèn)證工程師，對(duì)Elastic-Stack開發(fā)、架構(gòu)、運(yùn)維有深入體驗(yàn);

實(shí)踐過多種ES項(xiàng)目，最暴力的大數(shù)據(jù)分析應(yīng)用，最復(fù)雜的業(yè)務(wù)系統(tǒng)應(yīng)用。

序言

 

圖示：Redis熱度排名

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

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

• 開發(fā)層面
• 架構(gòu)層面
• 運(yùn)維層面

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

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

Redis監(jiān)控體系有哪些方面?

構(gòu)建Redis監(jiān)控體系我們做了哪些工作?

Redis監(jiān)控體系應(yīng)該細(xì)化到什么程度?

為什么使用ELK構(gòu)建監(jiān)控體系?

需求背景

項(xiàng)目描述

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

• 部署架構(gòu)采用Redis-Cluster模式;
• 后臺(tái)應(yīng)用系統(tǒng)有幾十個(gè)，應(yīng)用實(shí)例數(shù)超過二百個(gè);
• 所有應(yīng)用系統(tǒng)共用一套緩存集群;
• 集群節(jié)點(diǎn)數(shù)幾十個(gè)，加上容災(zāi)備用環(huán)境，節(jié)點(diǎn)數(shù)量翻倍;
• 集群節(jié)點(diǎn)內(nèi)存配置較高。

 

圖示：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ù)端也有感知，如下描述：

• 集群節(jié)點(diǎn)崩潰;
• 集群節(jié)點(diǎn)假死;
• 某些后端應(yīng)用訪問集群響應(yīng)特別慢。

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

• Redis集群使用的熱度問題?
• 哪些應(yīng)用占用的Redis內(nèi)存資源多?
• 哪些應(yīng)用占用Redis訪問數(shù)最高?
• 哪些應(yīng)用使用Redis類型不合理?
• 應(yīng)用系統(tǒng)模塊使用Redis資源分布怎么樣?
• 應(yīng)用使用Redis集群的熱點(diǎn)問題?

監(jiān)控體系

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

服務(wù)端：

• 服務(wù)端首先是操作系統(tǒng)層面，常用的CPU、內(nèi)存、網(wǎng)絡(luò)IO，磁盤IO，服務(wù)端運(yùn)行的進(jìn)程信息等;
• Redis運(yùn)行進(jìn)程信息，包括服務(wù)端運(yùn)行信息、客戶端連接數(shù)、內(nèi)存消耗、持久化信息 、鍵值數(shù)量、主從同步、命令統(tǒng)計(jì)、集群信息等;
• Redis運(yùn)行日志，日志中會(huì)記錄一些重要的操作進(jìn)程，如運(yùn)行持久化時(shí)，可以有效幫助分析崩潰假死的程序。

應(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)，也就是說用第三方監(jiān)控指標(biāo)之后，還得再搭建一個(gè)ELK集群看明細(xì)日志。

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

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

服務(wù)端系統(tǒng)

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

 

圖示：metrcibeat示意圖

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

 

服務(wù)端集群

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

info獲取的信息包括如下：

• server：Redis服務(wù)器的一般信息
• clients：客戶端的連接部分
• memory：內(nèi)存消耗相關(guān)信息
• persistence：RDB和AOF相關(guān)信息
• stats：一般統(tǒng)計(jì)
• replication：主/從復(fù)制信息
• cpu：統(tǒng)計(jì)CPU的消耗command
• stats：Redis命令
• 統(tǒng)計(jì)cluster：Redis集群信息
• keyspace：數(shù)據(jù)庫的相關(guān)統(tǒng)計(jì)

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

• Redis集群的主從關(guān)系信息，Metricbeats表達(dá)不出來;
• Redis集群的一些統(tǒng)計(jì)信息，永遠(yuǎn)是累計(jì)增加的，如命令數(shù)，如果要獲取命令數(shù)的波峰值，則無法得到;
• Redis集群狀態(tài)信息變化，Metricbeats是無法動(dòng)態(tài)的，如集群新增節(jié)點(diǎn)、下線節(jié)點(diǎn)等。

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

 

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

服務(wù)端日志

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

 

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

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

 

應(yīng)用端

應(yīng)用端信息采集是整個(gè)Redis監(jiān)控體系最重要的部分，也是實(shí)現(xiàn)最麻煩、鏈路最長的。首先是修改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改造記錄的信息如下：

• r_host：訪問Redis集群的服務(wù)器地址與端口，其中某一臺(tái)ip:port;
• r_cmd：執(zhí)行命令類型、如get、set、hget、hset等各種;
• r_start：執(zhí)行命令開始時(shí)間;
• r_cost：時(shí)間消耗;
• r_size：獲取鍵值大小或者設(shè)置鍵值大小;
• r_key：獲取鍵值名稱;
• r_keys：鍵值的二級(jí)拆分，數(shù)組的長度不限制。這里有必要強(qiáng)調(diào)一下，所有應(yīng)用系統(tǒng)共用的是一套集群，所以應(yīng)用系統(tǒng)的鍵值都是有規(guī)范的，按照特殊符號(hào)分割，如："應(yīng)用名稱_系統(tǒng)模塊_動(dòng)態(tài)變量_xxx“，主要便于我們區(qū)分。

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

• 類Connection.java文件，統(tǒng)計(jì)開始，記錄命令執(zhí)行開始時(shí)間;統(tǒng)計(jì)結(jié)束，記錄命令結(jié)束時(shí)間、時(shí)間消耗等，并寫入到日志流中;
• 類JedisClusterCommand文件，獲取鍵的地方key，方便之后分析應(yīng)用鍵的行為。

在類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)用端的一些信息，如下：

• app_ip：應(yīng)用端部署在服務(wù)器上的IP地址;
• app_host：應(yīng)用端部署在服務(wù)器上的服務(wù)器名稱。

自定義一個(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ù)端的日志分析比較簡單，常規(guī)的一些指標(biāo)而已，創(chuàng)建好關(guān)鍵的圖表，容易看出問題。重點(diǎn)討論應(yīng)用端的日志分析。

 

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

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

• 應(yīng)用端部分鍵值太大，居然超過1MB，這種鍵值訪問一次消耗時(shí)間很大，會(huì)嚴(yán)重造成阻塞;
• 部分應(yīng)用居然使用Redis當(dāng)成數(shù)據(jù)庫使用;
• 有將List類型當(dāng)成消息隊(duì)列使用，一次存取幾十萬的數(shù)據(jù);
• 某些應(yīng)用對(duì)于集群的操作頻次特別高，幾乎占用了一半以上;
• 還有很多，就不一一描述了。

后續(xù)方案

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

• 應(yīng)用端、誤用的使用全部要改掉;
• 服務(wù)端，按照應(yīng)用的數(shù)據(jù)，進(jìn)行一些拆分，拆分出一些專用的集群，特定為一些應(yīng)用使用或者場景;
• 開發(fā)者，后續(xù)有新業(yè)務(wù)模塊需要接入Redis需要告知架構(gòu)師們?cè)u(píng)審。

結(jié)語

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

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

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

本文轉(zhuǎn)載自微信公眾號(hào)「 DBAplus社群」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系DBAplus社群公眾號(hào)。

新聞標(biāo)題：我為什么用ES做Redis監(jiān)控，不用Prometheus或Zabbix？
鏈接URL：http://uogjgqi.cn/article/dppcpho.html