Categories
程式開發

我為什麼用ES做Redis監控,不用Prometheus或Zabbix?


本文由 dbaplus 社群授權轉載。

序言

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 1

圖示:Redis熱度排名

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

Redis要想用得好,需要整體掌握3個層面:

  • 開發層面
  • 架構層面
  • 運維層面

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

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

  • Redis監控體係有哪些方面?
  • 構建Redis監控體系我們做了哪些工作?
  • Redis監控體系應該細化到什麼程度?
  • 為什麼使用ELK構建監控體系?

需求背景

項目描述

公司業務範圍屬於車聯網行業,有上百萬級的真實車主用戶,業務項目圍繞車主生活服務展開,為了提高系統性能,引入了Redis作為緩存中間件,具體描述如下:

  • 部署架構採用Redis-Cluster模式;
  • 後台應用系統有幾十個,應用實例數超過二百個;
  • 所有應用系統共用一套緩存集群;
  • 集群節點數幾十個,加上容災備用環境,節點數量翻倍;
  • 集群節點內存配置較高。

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 2

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

問題描述

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

  • 集群節點崩潰;
  • 集群節點假死;
  • 某些後端應用訪問集群響應特別慢。

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

  • Redis集群使用的熱度問題?
  • 哪些應用佔用的Redis內存資源多?
  • 哪些應用佔用Redis訪問數最高?
  • 哪些應用使用Redis類型不合理?
  • 應用系統模塊使用Redis資源分佈怎麼樣?
  • 應用使用Redis集群的熱點問題?

監控體系

監控的目的不僅僅是監控Redis本身,而是為了更好的使用Redis。傳統的監控一般比較單一化,沒有系統化,但對於Redis來說,個人認為至少包括:一是服務端,二是應用端,三是服務端與應用端聯合分析。

服務端

  • 服務端首先是操作系統層面,常用的CPU、內存、網絡IO,磁盤IO,服務端運行的進程信息等;
  • Redis運行進程信息,包括服務端運行信息、客戶端連接數、內存消耗、持久化信息 、鍵值數量、主從同步、命令統計、集群信息等;
  • Redis運行日誌,日誌中會記錄一些重要的操作進程,如運行持久化時,可以有效幫助分析崩潰假死的程序。

應用端

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

聯合分析

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

解決方案

為什麼會選擇Elastic-Stack技術棧呢?

多數的第三方只監控一些指標,對於明細日誌還是採用ELK(Elasticsearch、Logstash、Kibana),也就是說用第三方監控指標之後,還得再搭建一個ELK集群看明細日誌。

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

下面詳細聊聊我們具體怎麼做的,做了哪些工作?

服務端系統

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 3

圖示:metrcibeat示意圖

系統指標信息收集配置樣例如下:

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 4

服務端集群

收集Redis集群運行信息,業界通常做法都是採用Redis提供的info命令,定期收集。

info獲取的信息包括如下:

  • server:Redis服務器的一般信息
  • clients:客戶端的連接部分
  • memory:內存消耗相關信息
  • persistence:RDB和AOF相關信息
  • stats:一般統計
  • replication:主/從復制信息
  • cpu:統計CPU的消耗command
  • stats:Redis命令
  • 統計cluster:Redis集群信息
  • keyspace:數據庫的相關統計

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

  • Redis集群的主從關係信息,Metricbeats表達不出來;
  • Redis集群的一些統計信息,永遠是累計增加的,如命令數,如果要獲取命令數的波峰值,則無法得到;
  • Redis集群狀態信息變化,Metricbeats是無法動態的,如集群新增節點、下線節點等。

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 5

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

服務端日誌

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 6

圖示:服務端日誌採集過程

Redis運行日誌採集配置:

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 7

應用端

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 8

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

應用端採集的數據格式如下:

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 9

圖示:應用端採集的數據案例

jedis修改

jedis改造記錄的信息如下:

  • r_host:訪問Redis集群的服務器地址與端口,其中某一台ip:port;
  • r_cmd:執行命令類型、如get、set、hget、hset等各種;
  • r_start:執行命令開始時間;
  • r_cost:時間消耗;
  • r_size:獲取鍵值大小或者設置鍵值大小;
  • r_key:獲取鍵值名稱;
  • r_keys:鍵值的二級拆分,數組的長度不限制。這裡有必要強調一下,所有應用系統共用的是一套集群,所以應用系統的鍵值都是有規範的,按照特殊符號分割,如:”應用名稱_系統模塊_動態變量_xxx“,主要便於我們區分。

在jedis改造有幾處地方,如下:

  • 類Connection.java文件,統計開始,記錄命令執行開始時間;統計結束,記錄命令結束時間、時間消耗等,並寫入到日誌流中;
  • 類JedisClusterCommand文件,獲取鍵的地方key,方便之後分析應用鍵的行為。

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 10

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 11

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

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 12

圖示:類JedisClusterCommand文件埋點代碼

logback修改

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

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

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 13

圖示:自定義Logback的Layout

app配置

app配置屬於最後收尾工作,主要是輸出埋點的日誌數據,配置日誌logback.xml文件即可:

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 14

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

日誌採集

應用端日誌採集採用Logstash,配置日誌目錄,指向Elastic集群,這樣整體的監控日誌採集部分就結束了。

日誌分析

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

我為什麼用ES做Redis監控,不用Prometheus或Zabbix? 15

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

ELK監控體系上線之後,我們連續觀察分析兩週,獲得了一些監控成果,如:

  • 應用端部分鍵值太大,居然超過1MB,這種鍵值訪問一次消耗時間很大,會嚴重造成阻塞;
  • 部分應用居然使用Redis當成數據庫使用;
  • 有將List類型當成消息隊列使用,一次存取幾十萬的數據;
  • 某些應用對於集群的操作頻次特別高,幾乎佔用了一半以上;
  • 還有很多,就不一一描述了。

後續方案

監控體系相當於架構師的眼睛,有了這個,Redis方面的優化改造方案就很好制定了:

  • 應用端、誤用的使用全部要改掉;
  • 服務端,按照應用的數據,進行一些拆分,拆分出一些專用的集群,特定為一些應用使用或者場景;
  • 開發者,後續有新業務模塊需要接入Redis需要告知架構師們評審。

結語

監控體系項目前後經歷過幾個月,服務端部分短期內就完成的,應用端是隨著應用發布逐步完成的。上線完成之後又經歷幾週的跟踪分析,才確定下來整體的優化方案。

監控體系本身並不是為了監控,而是發現問題、預見問題,最終提前解決問題,監控做得好,下班下得早。

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

Q&A

Q1:請問單台機器一般部署幾個Redis實例呢?

A: 依據服務器資源設置:

1、CPU核數,Redis是單線程工作模型,實際運行並非進程只有一個線程,這個要搞清楚;

2、內存,一個Redis進程配置部分內存,需要至少對等的內存閒置,fork子進程使用, 所以配置多實例要簡單計算下;

3、網絡,網絡IO超過網卡限制,會出問題。

Q2:直播中講到的大key,hash要改成什麼?分片嗎?

A: 1、比如,一個車子的基本信息,包括很多區塊部分,用hash確實非常好理解,但是過期之後整個hash都刪除了,其實很多信息是固定的,不用定時過期的;2、拆分成小的string更合適。

Q3:在客戶端打印key和value,如果是bigkey的話,qps有個1000,打印日誌就佔用很高的機器負載了吧?

A: 1、打印的key,不包括value值內容,只有key以及value的大小;2、logback這些框架其實支持的性能相當不錯的,可以配置成異步的方式,如果還不夠,可以直接輸出到Kafka隊列等。

Q4:請問ES怎麼部署MongoDB慢查詢報表平台呢?

A: 1、沒有深度使用過MongoDB;2、基於Elastic-Stack做慢查詢報表平台思路與Redis一樣的,不管什麼指標+日誌全部都採集到ES完事。

Q5:info all執行頻繁,會經常阻塞服務器,怎麼平衡它的性能呢?

A: 1、因為採集的是服務端運行的快照信息,定時採集,可以設定時間間隔大一些,比如5s;2、執行info all,是在java客戶端,可以修改jedis,在其中捕獲info命令,採集數據,觀察分析一段時間。

Q6:請問應用端jedis要怎麼埋點呢?

A: 1、原有jedis版本基於2.9,在2個類中修改埋點,參考了CacheCloud產品。最新版本的程序最近沒有關注,思路一樣;2、詳細見本文中貼出的代碼。

Q7:監控的話,個人覺得放在K8S裡面,不是最優方案,您對這個怎麼看?

A: 1、本人未使用過K8S部署產品;2、Redis監控體系,整體服務端,應用端,在Docker中也僅服務端可以,將metrcibeats這些集成在一起,但也有一些服務端監指標計算,需要自己編寫Agent來完成,也是可以到Docker中去。應用端的就沒有辦法了,這個屬於前端的行為統計。

Q8:請問您的ES有多少節點?要用ssd盤嗎?

A: 1、標準集群,起步3個實例節點;2、固態硬盤應用看場景,業務系統用用可以,日誌系統一般不需要,即使需要也可以做冷熱隔離,少量的數據使用ssd,歷史的數據全部hdd足矣。

Q9:如果公司缺乏足夠的人力物力,是用ES、Prometheus還是Zabbix做監控比較適合呢?能分別說一下它們各自最適用的情況嗎?

A: 1、ES,Elastic-Stack,首選考慮,ES擅長的領域很多,應用系統查詢加速、大數據領域、監控領域;2、其它兩個產品主要是做指標型的監控,但實際項目中,僅僅指標監控是不夠的,需要一個整體型的監控體系,便於聯合分析。 ES其實很多方面比時序數據庫做得更好,騰訊有資深專家做過詳細的ES與TSDB對比的測試,性能與功能都完全超過專門的時序數據庫。

作者介紹

李猛,數據技術專家

  • Elastic-Stack產品深度用戶,ES認證工程師,對Elastic-Stack開發、架構、運維有深入體驗;
  • 實踐過多種ES項目,最暴力的大數據分析應用,最複雜的業務系統應用。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650788187&idx=1&sn=9363cc47966b4464e82f84904ac0b4b8&chksm=f3f964cec48eedd840c922263bfe39f31a8223d530cfac3a6bebd8b7bb0c0569712f087a65eb&scene=27#wechat_redirect