溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

怎么用ES做Redis監(jiān)控

發(fā)布時間:2022-01-15 17:18:12 來源:億速云 閱讀:116 作者:iii 欄目:安全技術

本篇內容主要講解“怎么用ES做Redis監(jiān)控”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“怎么用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é)點內存配置較高。

怎么用ES做Redis監(jiān)控

圖示: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)控面板,非常簡單快速,一般運維就可以搞定。

怎么用ES做Redis監(jiān)控

圖示:metrcibeat示意圖

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

怎么用ES做Redis監(jiān)控

服務端集群

收集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。

怎么用ES做Redis監(jiān)控

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

服務端日志

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

怎么用ES做Redis監(jiān)控

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

Redis運行日志采集配置:

怎么用ES做Redis監(jiān)控

應用端

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

怎么用ES做Redis監(jiān)控

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

應用端采集的數(shù)據(jù)格式如下:

怎么用ES做Redis監(jiān)控

圖示:應用端采集的數(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處:

怎么用ES做Redis監(jiān)控

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

怎么用ES做Redis監(jiān)控

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

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

怎么用ES做Redis監(jiān)控

圖示:類JedisClusterCommand文件埋點代碼

logback修改:

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

  • app_ip:應用端部署在服務器上的IP地址;

  • app_host:應用端部署在服務器上的服務器名稱。

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

怎么用ES做Redis監(jiān)控

圖示:自定義Logback的Layout

app配置:

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

怎么用ES做Redis監(jiān)控

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

日志采集:

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

日志分析

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

怎么用ES做Redis監(jiān)控

圖示:應用端使用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ù)學習!

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內容。

AI