Redis 當(dāng)下很流行，也很好用，無論是在業(yè)務(wù)應(yīng)用系統(tǒng)，還是在大數(shù)據(jù)領(lǐng)域都有重要的地位;但 Redis 也很脆弱，用不好，問題多多。

[[330258]]

 

圖片來自 Pexels

2012 年以前都是以 Memcached 為主，之后轉(zhuǎn)到 Redis 陣營，經(jīng)歷過單實(shí)例模式、主從模式、哨兵模式、代理模式，集群模式，真正公司層面用得好的很少，對(duì)于 Redis 掌控都很片面，導(dǎo)致實(shí)際項(xiàng)目中問題不少。

 

Redis 熱度排名

Redis 要想用得好，需要整體掌握三個(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 作為緩存中間件。

 

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

具體描述如下：

• 部署架構(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)存配置較高。

問題描述

系統(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)勢(shì)，指標(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 文件中有兩處：

 

類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)控。

作者：李猛

簡介：數(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)用。

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號(hào) DBAplus 社群(ID：dbaplus)，本文根據(jù)李猛老師在〖deeplus 直播第 220 期〗線上分享演講內(nèi)容整理而成。