本文由 dbaplus 社羣授權轉載。
序言
Redis當下很流行，也很好用，無論是在業務應用系統，還是在大數據領域都有重要的地位；但Redis也很脆弱，用不好，問題多多。2012年以前都是以memcached爲主，之後轉到Redis陣營，經歷過單實例模式、主從模式、哨兵模式、代理模式，集羣模式，真正公司層面用得好的很少，對於Redis掌控都很片面，導致實際項目中問題不少。
Redis要想用得好，需要整體掌握3個層面：
- 開發層面
- 架構層面
- 運維層面
其中架構與運維至關重要，多數中小型企業僅在開發層面滿足常用功能，數據規模稍微大些，業務複雜度高些，就容易出現各種架構與運維問題。本文主旨是探討Redis監控體系，目前業界當然也有很多成熟的產品，但個人覺得都很常規，只做到一些粗粒度的監控， 沒有依據業務需求特點因地制宜去細化，從而反向的提供架構開發優化方案。
本文內容將圍繞如下幾個問題展開討論：
- Redis監控體系有哪些方面？
- 構建Redis監控體系我們做了哪些工作？
- Redis監控體系應該細化到什麼程度？
- 爲什麼使用ELK構建監控體系？
需求背景
項目描述
公司業務範圍屬於車聯網行業，有上百萬級的真實車主用戶，業務項目圍繞車主生活服務展開，爲了提高系統性能，引入了Redis作爲緩存中間件，具體描述如下：
- 部署架構採用Redis-Cluster模式；
- 後臺應用系統有幾十個，應用實例數超過二百個；
- 所有應用系統共用一套緩存集羣；
- 集羣節點數幾十個，加上容災備用環境，節點數量翻倍；
- 集羣節點內存配置較高。
問題描述
系統剛開始關於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中創建已有的系統監控面板，非常簡單快速，一般運維就可以搞定。
系統指標信息收集配置樣例如下：
服務端集羣
收集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。
服務端日誌
Redis服務端運行日誌採集很簡單，直接通過Elastic-Stack家族的Filebeat產品，其中有Redis模塊，配置一下Elastic服務端，日誌文件地址即可。
Redis運行日誌採集配置：
應用端
應用端信息採集是整個Redis監控體系最重要的部分，也是實現最麻煩、鏈路最長的。首先是修改jedis（技術棧Java）源碼，增加埋點代碼，重新編譯並引用到應用項目中，應用端對於Redis集羣的任何命令操作，都會被捕捉，並記錄下關鍵信息，之後寫入到本地文件。
應用端採集的數據格式如下：
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處：
類JedisClusterCommand文件埋點代碼.java文件中有1處：
logback修改：
應用端都會使用logback寫入日誌文件，同時爲了更加精準，應用端寫入日誌時還需要獲取應用端的一些信息，如下：
- app_ip：應用端部署在服務器上的IP地址；
- app_host：應用端部署在服務器上的服務器名稱。
自定義一個Layout，自動獲取應用端的IP地址與服務器名稱：
app配置：
app配置屬於最後收尾工作，主要是輸出埋點的日誌數據，配置日誌logback.xml文件即可：
日誌採集：
應用端日誌採集採用Logstash，配置日誌目錄，指向Elastic集羣，這樣整體的監控日誌採集部分就結束了。
日誌分析
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項目，最暴力的大數據分析應用，最複雜的業務系統應用。
原文鏈接：