您好,登錄后才能下訂單哦!
本篇內容主要講解“怎么用ES做Redis監(jiān)控”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“怎么用ES做Redis監(jiān)控”吧!
序言
圖示:Redis熱度排名
Redis當下很流行,也很好用,無論是在業(yè)務應用系統(tǒng),還是在大數(shù)據(jù)領域都有重要的地位;但Redis也很脆弱,用不好,問題多多。2012年以前都是以memcached為主,之后轉到Redis陣營,經(jīng)歷過單實例模式、主從模式、哨兵模式、代理模式,集群模式,真正公司層面用得好的很少,對于Redis掌控都很片面,導致實際項目中問題不少。
Redis要想用得好,需要整體掌握3個層面:
開發(fā)層面
架構層面
運維層面
其中架構與運維至關重要,多數(shù)中小型企業(yè)僅在開發(fā)層面滿足常用功能,數(shù)據(jù)規(guī)模稍微大些,業(yè)務復雜度高些,就容易出現(xiàn)各種架構與運維問題。本文主旨是探討Redis監(jiān)控體系,目前業(yè)界當然也有很多成熟的產(chǎn)品,但個人覺得都很常規(guī),只做到一些粗粒度的監(jiān)控, 沒有依據(jù)業(yè)務需求特點因地制宜去細化,從而反向的提供架構開發(fā)優(yōu)化方案。
本文內容將圍繞如下幾個問題展開討論:
Redis監(jiān)控體系有哪些方面?
構建Redis監(jiān)控體系我們做了哪些工作?
Redis監(jiān)控體系應該細化到什么程度?
為什么使用ELK構建監(jiān)控體系?
需求背景
項目描述
公司業(yè)務范圍屬于車聯(lián)網(wǎng)行業(yè),有上百萬級的真實車主用戶,業(yè)務項目圍繞車主生活服務展開,為了提高系統(tǒng)性能,引入了Redis作為緩存中間件,具體描述如下:
部署架構采用Redis-Cluster模式;
后臺應用系統(tǒng)有幾十個,應用實例數(shù)超過二百個;
所有應用系統(tǒng)共用一套緩存集群;
集群節(jié)點數(shù)幾十個,加上容災備用環(huán)境,節(jié)點數(shù)量翻倍;
集群節(jié)點內存配置較高。
圖示:Redis集群架構與應用架構示意圖
問題描述
系統(tǒng)剛開始關于Redis的一切都很正常,隨著應用系統(tǒng)接入越來越多,應用系統(tǒng)子模塊接入也越來越多,開始出現(xiàn)一些問題,應用系統(tǒng)有感知,集群服務端也有感知,如下描述:
集群節(jié)點崩潰;
集群節(jié)點假死;
某些后端應用訪問集群響應特別慢。
其實問題的根源都是架構運維層面的欠缺,對于Redis集群服務端的運行監(jiān)控其實很好做,本身也提供了很多直接的命令方式,但只能看到服務端的一些常用指標信息,無法深入分析,治標不治本,對于Redis的內部運行一無所知,特別是對于業(yè)務應用如何使用Redis集群一無所知:
Redis集群使用的熱度問題?
哪些應用占用的Redis內存資源多?
哪些應用占用Redis訪問數(shù)最高?
哪些應用使用Redis類型不合理?
應用系統(tǒng)模塊使用Redis資源分布怎么樣?
應用使用Redis集群的熱點問題?
監(jiān)控體系
監(jiān)控的目的不僅僅是監(jiān)控Redis本身,而是為了更好的使用Redis。傳統(tǒng)的監(jiān)控一般比較單一化,沒有系統(tǒng)化,但對于Redis來說,個人認為至少包括:一是服務端,二是應用端,三是服務端與應用端聯(lián)合分析。
服務端:
服務端首先是操作系統(tǒng)層面,常用的CPU、內存、網(wǎng)絡IO,磁盤IO,服務端運行的進程信息等;
Redis運行進程信息,包括服務端運行信息、客戶端連接數(shù)、內存消耗、持久化信息 、鍵值數(shù)量、主從同步、命令統(tǒng)計、集群信息等;
Redis運行日志,日志中會記錄一些重要的操作進程,如運行持久化時,可以有效幫助分析崩潰假死的程序。
應用端:
應用端、獲取應用端使用Redis的一些行為,具體哪些應用哪些模塊最占用 Redis資源、哪些應用哪些模塊最消耗Redis資源、哪些應用哪些模塊用法有誤等。
聯(lián)合分析:
聯(lián)合分析結合服務端的運行與應用端使用的行為,如:一些造成服務端突然阻塞的原因,可能是應用端設置了一個很大的緩存鍵值,或者使用的鍵值列表,數(shù)據(jù)量超大造成阻塞。
解決方案
為什么會選擇Elastic-Stack技術棧呢?
多數(shù)的第三方只監(jiān)控一些指標,對于明細日志還是采用ELK(Elasticsearch、Logstash、Kibana),也就是說用第三方監(jiān)控指標之后,還得再搭建一個ELK集群看明細日志。
再就是說Elastic-Stack技術棧整合的優(yōu)勢,指標也可以、日志文件也可以,從采集開始到存儲、到最終報表面板都整合得非常好,門檻很低。
下面詳細聊聊我們具體怎么做的,做了哪些工作?
服務端系統(tǒng)
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獲取的信息包括如下:
server:Redis服務器的一般信息
clients:客戶端的連接部分
memory:內存消耗相關信息
persistence:RDB和AOF相關信息
stats:一般統(tǒng)計
replication:主/從復制信息
cpu:統(tǒng)計CPU的消耗command
stats:Redis命令
統(tǒng)計cluster:Redis集群信息
keyspace:數(shù)據(jù)庫的相關統(tǒng)計
Elastic-Stack家族的Metricbeat產(chǎn)品也支持Redis模塊,也是采用info命令獲取的,但是有一些實現(xiàn)的局限性,如下描述:
Redis集群的主從關系信息,Metricbeats表達不出來;
Redis集群的一些統(tǒng)計信息,永遠是累計增加的,如命令數(shù),如果要獲取命令數(shù)的波峰值,則無法得到;
Redis集群狀態(tài)信息變化,Metricbeats是無法動態(tài)的,如集群新增節(jié)點、下線節(jié)點等。
所以這里參考了CacheCloud產(chǎn)品(搜狐團隊開源),我們自定義設計開發(fā)了 Agent,定時從Redis集群采集信息,并在內部做一些統(tǒng)計數(shù)值的簡單計算,轉換成Json,寫入到本地文件,通過Logstash采集發(fā)送到Elasticsearch。
圖示:Redis服務端運行信息采集架構示意圖
服務端日志
Redis服務端運行日志采集很簡單,直接通過Elastic-Stack家族的Filebeat產(chǎn)品,其中有Redis模塊,配置一下Elastic服務端,日志文件地址即可。
圖示:服務端日志采集過程
Redis運行日志采集配置:
應用端
應用端信息采集是整個Redis監(jiān)控體系最重要的部分,也是實現(xiàn)最麻煩、鏈路最長的。首先是修改jedis(技術棧Java)源碼,增加埋點代碼,重新編譯并引用到應用項目中,應用端對于Redis集群的任何命令操作,都會被捕捉,并記錄下關鍵信息,之后寫入到本地文件。
圖示:Redis應用端行為采集架構圖
應用端采集的數(shù)據(jù)格式如下:
圖示:應用端采集的數(shù)據(jù)案例
jedis修改:
jedis改造記錄的信息如下:
r_host:訪問Redis集群的服務器地址與端口,其中某一臺ip:port;
r_cmd:執(zhí)行命令類型、如get、set、hget、hset等各種;
r_start:執(zhí)行命令開始時間;
r_cost:時間消耗;
r_size:獲取鍵值大小或者設置鍵值大小;
r_key:獲取鍵值名稱;
r_keys:鍵值的二級拆分,數(shù)組的長度不限制。這里有必要強調一下,所有應用系統(tǒng)共用的是一套集群,所以應用系統(tǒng)的鍵值都是有規(guī)范的,按照特殊符號分割,如:"應用名稱_系統(tǒng)模塊_動態(tài)變量_xxx“,主要便于我們區(qū)分。
在jedis改造有幾處地方,如下:
類Connection.java文件,統(tǒng)計開始,記錄命令執(zhí)行開始時間;統(tǒng)計結束,記錄命令結束時間、時間消耗等,并寫入到日志流中;
類JedisClusterCommand文件,獲取鍵的地方key,方便之后分析應用鍵的行為。
在類Connection.java文件中有2處:
圖示:類Connection.java文件埋點代碼的地方
圖示:類Connection.java文件埋點代碼的地方
類JedisClusterCommand文件埋點代碼.java文件中有1處:
圖示:類JedisClusterCommand文件埋點代碼
logback修改:
應用端都會使用logback寫入日志文件,同時為了更加精準,應用端寫入日志時還需要獲取應用端的一些信息,如下:
app_ip:應用端部署在服務器上的IP地址;
app_host:應用端部署在服務器上的服務器名稱。
自定義一個Layout,自動獲取應用端的IP地址與服務器名稱:
圖示:自定義Logback的Layout
app配置:
app配置屬于最后收尾工作,主要是輸出埋點的日志數(shù)據(jù),配置日志logback.xml文件即可:
圖示:配置應用端日志文件logback.xml
日志采集:
應用端日志采集采用Logstash,配置日志目錄,指向Elastic集群,這樣整體的監(jiān)控日志采集部分就結束了。
日志分析
Redis服務端的日志分析比較簡單,常規(guī)的一些指標而已,創(chuàng)建好關鍵的圖表,容易看出問題。重點討論應用端的日志分析。
圖示:應用端使用Redis一些行為圖表
ELK監(jiān)控體系上線之后,我們連續(xù)觀察分析兩周,獲得了一些監(jiān)控成果,如:
應用端部分鍵值太大,居然超過1MB,這種鍵值訪問一次消耗時間很大,會嚴重造成阻塞;
部分應用居然使用Redis當成數(shù)據(jù)庫使用;
有將List類型當成消息隊列使用,一次存取幾十萬的數(shù)據(jù);
某些應用對于集群的操作頻次特別高,幾乎占用了一半以上;
還有很多,就不一一描述了。
后續(xù)方案
監(jiān)控體系相當于架構師的眼睛,有了這個,Redis方面的優(yōu)化改造方案就很好制定了:
應用端、誤用的使用全部要改掉;
服務端,按照應用的數(shù)據(jù),進行一些拆分,拆分出一些專用的集群,特定為一些應用使用或者場景;
開發(fā)者,后續(xù)有新業(yè)務模塊需要接入Redis需要告知架構師們評審。
到此,相信大家對“怎么用ES做Redis監(jiān)控”有了更深的了解,不妨來實際操作一番吧!這里是億速云網(wǎng)站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續(xù)學習!
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內容。