https://blog.csdn.net/qq_27623337/article/details/53206685

對于任何應(yīng)用服務(wù)和組件，都需要一套完善可靠譜監(jiān)控方案。

尤其redis這類敏感的純內(nèi)存、高并發(fā)和低延時的服務(wù)，一套完善的監(jiān)控告警方案，是精細化運營的前提。

本文分幾節(jié)，細說Redis的監(jiān)控和告警：

1.Redis監(jiān)控告警的價值

2.Redis監(jiān)控的數(shù)據(jù)采集

3.Redis告警策略

4.基于Open Falcon的Redis監(jiān)控告警方案

Redis監(jiān)控告警的價值

Redis監(jiān)控告警的價值對每個角色都不同，重要的幾個方面：

• redis故障快速通知，定位故障點；對于DBA，redis的可用性和性能故障需快速發(fā)現(xiàn)和定位解決。
• 分析redis故障的Root cause
• redis容量規(guī)劃和性能管理
• redis硬件資源利用率和成本

redis故障快速發(fā)現(xiàn)，定位故障點和解決故障

當(dāng)redis出現(xiàn)故障時，DBA應(yīng)在盡可能短時間內(nèi)發(fā)現(xiàn)告警；如果故障對服務(wù)是有損的(如大面積網(wǎng)絡(luò)故障或程序BUG)，需立即通知SRE和RD啟用故障預(yù)案(如切換機房或啟用emergency switch）止損。

如果沒完善監(jiān)控告警;假設(shè)由RD發(fā)現(xiàn)服務(wù)故障，再排查整體服務(wù)調(diào)用鏈去定位；甚于用戶發(fā)現(xiàn)用問題，通過客服投訴，再排查到redis故障的問題；整個redis故障的發(fā)現(xiàn)、定位和解決時間被拉長，把一個原本的小故障被”無限”放大。

分析redis故障的Root cause

任何一個故障和性能問題，其根本“誘因”往往只有一個，稱為這個故障的Root cause。

一個故障從DBA發(fā)現(xiàn)、止損、分析定位、解決和以后規(guī)避措施；最重要一環(huán)就是DBA通過各種問題表象，層層分析到Root cause；找到問題的根據(jù)原因，才能根治這類問題，避免再次發(fā)生。

完善的redis監(jiān)控數(shù)據(jù)，是我們分析root cause的基礎(chǔ)和證據(jù)。

備注：Troubleshtooing定位Root cause，就像醫(yī)生通過病人的病歷和檢查報告找到“真正的病灶”，讓病人康復(fù)和少受苦，一樣有意思和復(fù)雜；或像刑警通過案件的證據(jù)分析和推理，尋找那個唯一的真相，一樣驚心動魄。(快看DBA又在吹牛了），其實在大型商業(yè)系統(tǒng)中，一次故障輕松就達直接損失數(shù)十萬（間接損失更大），那“抓住元兇”，避免它再次“作案”，同樣是“破案”。

問題表現(xiàn)是綜合情的，一般可能性較復(fù)雜，這里舉2個例子：

• 服務(wù)調(diào)用Redis響應(yīng)時間變大的性能總是；可能網(wǎng)絡(luò)問題，redis慢查詢，redis QPS增高達到性能瓶頸，redis fork阻塞和請求排隊，redis使用swap, cpu達到飽和(單核idle過低),aof fsync阻塞，網(wǎng)絡(luò)進出口資源飽和等等
• redis使用內(nèi)存突然增長，快達到maxmemory; 可能其個大鍵寫入，鍵個數(shù)增長，某類鍵平均長度突增，fork COW, 客戶端輸入/輸出緩沖區(qū),lua程序占用等等

Root cause是要直觀的監(jiān)控數(shù)據(jù)和證據(jù)，而非有技術(shù)支撐的推理分析。

• redis響應(yīng)抖動，分析定位root casue是bgsave時fork導(dǎo)致阻塞200ms的例子。而不是分析推理：redis進程rss達30gb,響應(yīng)抖動時應(yīng)該有同步，fork子進程時，頁表拷貝時要阻塞父進程，估計頁表大小xx，再根據(jù)內(nèi)存copy連續(xù)1m數(shù)據(jù)要xx 納秒，分析出可能fork阻塞導(dǎo)致的。（要的不是這種分析）

  說明：糧廠有個習(xí)慣，在分析root cause盡量能拿到直觀證據(jù)。因為一旦引入推理步驟，每一步的推理結(jié)果都可能出現(xiàn)偏差，最終可能給出錯誤root cause. “元兇”又逃過一劫，它下次作案估計就會更大。所以建議任何小的故障或抖動，至少從個人或小組內(nèi)部，深入分析找到root cause；這樣個人或組織都會成長快； 形成良好的氛圍。

Redis容量規(guī)劃和性能管理

通過分析redis資源使用和性能指標(biāo)的監(jiān)控歷史趨勢數(shù)據(jù)；對集群進行合理擴容(Scale-out)、縮容(Scale-back)；對性能瓶頸優(yōu)化處理等。

Redis資源使用飽和度監(jiān)控，設(shè)置合理閥值；

一些常用容量指標(biāo)：redis內(nèi)存使用比例，swap使用，cpu單核的飽和度等；當(dāng)資源使用容量預(yù)警時，能及時擴容，避免因資源使用過載，導(dǎo)致故障。

另一方面，如果資源利用率持續(xù)過低，及時通知業(yè)務(wù)，并進行redis集群縮容處理，避免資源浪費。

進一步，容器化管理redis后，根據(jù)監(jiān)控數(shù)據(jù)，系統(tǒng)能自動地彈性擴容和縮容。

Redis性能監(jiān)控管理，及時發(fā)現(xiàn)性能瓶頸，進行優(yōu)化或擴容，把問題扼殺在”萌芽期“，避免它”進化“成故障。

Redis硬件資源利用率和成本

從老板角度來看，最關(guān)心的是成本和資源利用率是否達標(biāo)。

如果資源不達標(biāo)，就得推進資源優(yōu)化整合；提高硬件利用率，減少資源浪費。砍預(yù)算，減成本。

資源利用率是否達標(biāo)的數(shù)據(jù)，都是通過監(jiān)控系統(tǒng)采集的數(shù)據(jù)。

這一小節(jié)，扯了這么多； 只是強調(diào)redis不是只有一個端口存活監(jiān)控就可以了。

下面進入主題，怎么采集redsis監(jiān)控數(shù)。

老板曾說：監(jiān)控告警和數(shù)據(jù)備份，是對DBA和SRE最基礎(chǔ)也是最高的要求；

當(dāng)服務(wù)和存儲達到產(chǎn)品規(guī)模后，可認(rèn)為“無監(jiān)控，不服務(wù)；無備份，不存儲”。

Redis監(jiān)控數(shù)據(jù)采集

redis監(jiān)控的數(shù)據(jù)采集，數(shù)據(jù)采集1分鐘一次，分為下面幾個方面：

• 服務(wù)器系統(tǒng)數(shù)據(jù)采集
• Redis Server數(shù)據(jù)采集
• Redis響應(yīng)時間數(shù)據(jù)采集
• Redis監(jiān)控Screen

服務(wù)器系統(tǒng)監(jiān)控數(shù)據(jù)采集

服務(wù)器系統(tǒng)的數(shù)據(jù)采集，這部分包含數(shù)百個指標(biāo). 采集方式現(xiàn)在監(jiān)控平臺自帶的agent都會支持

如Zabbix和Open Falcon等，這里就不介紹采集方法。

我們從redis使用資源的特性，分析各個子系統(tǒng)的重要監(jiān)控指標(biāo)。

服務(wù)器存活監(jiān)控

• ping監(jiān)控告警

CPU

• 平均負(fù)載?(Load Average): 綜合負(fù)載指標(biāo)(暫且歸類cpu子系統(tǒng))，當(dāng)系統(tǒng)的子系統(tǒng)出現(xiàn)過度使用時，平均負(fù)載會升高。可說明redis的處理性能下降(平均響應(yīng)時間變長、吞吐量降低)。
• CPU整體利用率或飽和度?(cpu.busy): redis在高并發(fā)或時間復(fù)雜度高的指令，cpu整體資源飽和，導(dǎo)致redis性能下降，請求堆積。
• CPU單核飽和度?(cpu.core.idle/core=0): redis是單進程模式，常規(guī)情況只使用一個cpu core, 單某個實例出現(xiàn)cpu性能瓶頸，導(dǎo)致性能故障，但系統(tǒng)一般24線程的cpu飽和度卻很低。所以監(jiān)控cpu單核心利用率也同樣重樣。
• CPU上下文切換數(shù)?(cpu.switches)：context swith過高xxxxxx

內(nèi)存和swap

• 系統(tǒng)內(nèi)存余量大小?(mem.memfree)：redis是純內(nèi)存系統(tǒng)，系統(tǒng)內(nèi)存必須保有足夠余量，避免出現(xiàn)OOM，導(dǎo)致redis進程被殺，或使用swap導(dǎo)致redis性能驟降。
• 系統(tǒng)swap使用量大小?(mem.swapused)：redis的”熱數(shù)據(jù)“只要進入swap,redis處理性能就會驟降； 不管swap分區(qū)的是否是SSD介質(zhì)。OS對swap的使用材質(zhì)還是disk store. 這也是作者早期redis實現(xiàn)VM,后來又放棄的原因。

說明：系統(tǒng)內(nèi)存余量合理，給各種緩沖區(qū)，fork cow足夠的內(nèi)存空間。

另一個問題：我的系統(tǒng)使用Redis緩存集群，”不怕掛，就怕慢“，或redis集群高可用做得厲害；這樣redis的服務(wù)器是否能關(guān)閉swap呢？

磁盤

• 磁盤分區(qū)的使用率?（df.bytes.used.percent)：磁盤空間使用率監(jiān)控告警，確保有足磁盤空間用AOF/RDB, 日志文件存儲。不過 redis服務(wù)器一般很少出現(xiàn)磁盤容量問題
• 磁盤IOPS的飽和度(disk.io.util)：如果有AOF持久化時，要注意這類情況。如果AOF持久化，每秒sync有堆積，可能導(dǎo)致寫入stall的情況。 另外磁盤順序吞吐量還是很重要，太低會導(dǎo)致復(fù)制同步RDB時，拉長同步RDB時間。（期待diskless replication）

網(wǎng)絡(luò)

• 網(wǎng)絡(luò)吞吐量飽和度(net.if.out.bytes/net.if.in.bytes)：如果服務(wù)器是千兆網(wǎng)卡（Speed: 1000Mb/s），單機多實例情況，有異常的大key容量導(dǎo)致網(wǎng)卡流量打滿。redis整體服務(wù)等量下降，苦于出現(xiàn)故障切換。
• 丟包率?：Redis服務(wù)響應(yīng)質(zhì)量受影響

Redis Server監(jiān)控數(shù)據(jù)采集

通過redis實例的狀態(tài)數(shù)據(jù)采集，采集監(jiān)控數(shù)據(jù)的命令

ping,info all, slowlog get/len/reset/cluster info/config get

Redis存活監(jiān)控

• redis存活監(jiān)控?(redis_alive):redis本地監(jiān)控agent使用ping，如果指定時間返回PONG表示存活，否則redis不能響應(yīng)請求，可能阻塞或死亡。
• redis uptime監(jiān)控?(redis_uptime)：uptime_in_seconds

Redis 連接數(shù)監(jiān)控

• 連接個數(shù)?(connected_clients)：客戶端連接個數(shù)，如果連接數(shù)過高，影響redis吞吐量。常規(guī)建議不要超過5000.參考?官方benchmarks

• 連接數(shù)使用率(connected_clients_pct): 連接數(shù)使用百分比，通過(connected_clients/macclients)計算；如果達到1，redis開始拒絕新連接創(chuàng)建。

  127.0.0.1:6380> set mykey myvalue (error) ERR max number of clients reached 127.0.0.1:6380>

• 拒絕的連接個數(shù)(rejected_connections): redis連接個數(shù)達到maxclients限制，拒絕新連接的個數(shù)。

• 新創(chuàng)建連接個數(shù)?(total_connections_received): 如果新創(chuàng)建連接過多，過度地創(chuàng)建和銷毀連接對性能有影響，說明短連接嚴(yán)重或連接池使用有問題，需調(diào)研代碼的連接設(shè)置。
• list阻塞調(diào)用被阻塞的連接個數(shù)?(blocked_clients): BLPOP這類命令沒使用過，如果監(jiān)控數(shù)據(jù)大于0，還是建議排查原因。

Redis內(nèi)存監(jiān)控

• redis分配的內(nèi)存大小?(used_memory): redis真實使用內(nèi)存，不包含內(nèi)存碎片；單實例的內(nèi)存大小不建議過大，常規(guī)10~20GB以內(nèi)。

• redis內(nèi)存使用比例(used_memory_pct): 已分配內(nèi)存的百分比，通過(used_memory/maxmemory)計算；對于redis存儲場景會比較關(guān)注，未設(shè)置淘汰策略(maxmemory_policy)的，達到maxmemory限制不能寫入數(shù)據(jù)。

  127.0.0.1:6380> setmykey myvalue (error) OOM commandnot allowed when used memory >'maxmemory'. 127.0.0.1:6380>

• redis進程使用內(nèi)存大小(used_memory_rss): 進程實際使用的物理內(nèi)存大小，包含內(nèi)存碎片；如果rss過大導(dǎo)致內(nèi)部碎片大，內(nèi)存資源浪費，和fork的耗時和cow內(nèi)存都會增大。

• redis內(nèi)存碎片率?(mem_fragmentation_ratio): 表示(used_memory_rss/used_memory)，碎片率過大，導(dǎo)致內(nèi)存資源浪費；

  說明：

  1、如果內(nèi)存使用很小時，mem_fragmentation_ratio可以遠大于1的情況，這個告警值不好設(shè)置，需參考used_memory大小。

  2、如果mem_fragmentation_ratio小于1，表示redis已使用swap分區(qū)

Redis綜合性能監(jiān)控

Redis Keyspace

redis鍵空間的狀態(tài)監(jiān)控

• 鍵個數(shù)?(keys): redis實例包含的鍵個數(shù)。建議控制在1kw內(nèi)；單實例鍵個數(shù)過大，可能導(dǎo)致過期鍵的回收不及時。
• 設(shè)置有生存時間的鍵個數(shù)?(keys_expires): 是純緩存或業(yè)務(wù)的過期長，都建議對鍵設(shè)置TTL; 避免業(yè)務(wù)的死鍵問題. （expires字段）
• 估算設(shè)置生存時間鍵的平均壽命?(avg_ttl): redis會抽樣估算實例中設(shè)置TTL鍵的平均時長，單位毫秒。如果無TTL鍵或在Slave則avg_ttl一直為0
• LRU淘汰的鍵個數(shù)?(evicted_keys): 因used_memory達到maxmemory限制，并設(shè)置有淘汰策略的實例；（對排查問題重要，可不設(shè)置告警）
• 過期淘汰的鍵個數(shù)?(expired_keys): 刪除生存時間為0的鍵個數(shù)；包含主動刪除和定期刪除的個數(shù)。

Redis qps

• redis處理的命令數(shù)?(total_commands_processed): 監(jiān)控采集周期內(nèi)的平均qps,?
  redis單實例處理達數(shù)萬，如果請求數(shù)過多，redis過載導(dǎo)致請求堆積。
• redis當(dāng)前的qps?(instantaneous_ops_per_sec): redis內(nèi)部較實時的每秒執(zhí)行的命令數(shù)；可和total_commands_processed監(jiān)控互補。

Redis cmdstat_xxx

這小節(jié)講解，redis記錄執(zhí)行過的所有命令； 通過info all的Commandstats節(jié)采集數(shù)據(jù).

• 每類命令執(zhí)行的次數(shù)?(cmdstat_xxx): 這個值用于分析redis抖動變化比較有用

以下表示：每個命令執(zhí)行次數(shù)，總共消耗的CPU時長(單個微秒)，平均每次消耗的CPU時長（單位微秒）

# Commandstats cmdstat_set:calls=6,usec=37,usec_per_call=6.17 cmdstat_lpush:calls=4,usec=32,usec_per_call=8.00 cmdstat_lpop:calls=4,usec=33,usec_per_call=8.25

Redis Keysapce hit ratio

redis鍵空間請求命中率監(jiān)控，通過此監(jiān)控來度量redis緩存的質(zhì)量，如果未命中率或次數(shù)較高，可能因熱點數(shù)據(jù)已大于redis的內(nèi)存限制，導(dǎo)致請求落到后端存儲組件，可能需要擴容redis緩存集群的內(nèi)存容量。當(dāng)然也有可能是業(yè)務(wù)特性導(dǎo)致。

• 請求鍵被命中次數(shù)?(keyspace_hits): redis請求鍵被命中的次數(shù)
• 請求鍵未被命中次數(shù)?(keyspace_misses): redis請求鍵未被命中的次數(shù)；當(dāng)命中率較高如95%，如果請求量大，未命中次數(shù)也會很多。可參考Baron大神寫的?Why you should ignore MySQL’s key cache hit ratio
• 請求鍵的命中率?(keyspace_hit_ratio):使用keyspace_hits/(keyspace_hits+keyspace_misses)計算所得，是度量Redis緩存服務(wù)質(zhì)量的標(biāo)準(zhǔn)

Redis fork

redis在執(zhí)行BGSAVE,BGREWRITEAOF命令時，redis進程有?fork?操作。而fork會對redis進程有個短暫的卡頓,這個卡頓redis不能響應(yīng)任務(wù)請求。所以監(jiān)控fork阻塞時長，是相當(dāng)重要。

如果你的系統(tǒng)不能接受redis有500ms的阻塞，那么就要監(jiān)控fork阻塞時長的變化，做好容量規(guī)劃。

• 最近一次fork阻塞的微秒數(shù)?(latest_fork_usec): 最近一次Fork操作阻塞redis進程的耗時數(shù)，單位微秒。

redis network traffic

redis一般單機多實例部署，當(dāng)服務(wù)器網(wǎng)絡(luò)流量增長很大，需快速定位是網(wǎng)絡(luò)流量被哪個redis實例所消耗了； 另外redis如果寫流量過大，可能導(dǎo)致slave線程“客戶端輸出緩沖區(qū)”堆積，達到限制后被Maser強制斷開連接，出現(xiàn)復(fù)制中斷故障。所以我們需監(jiān)控每個redis實例網(wǎng)絡(luò)進出口流量，設(shè)置合適的告警值。

說明：網(wǎng)絡(luò)監(jiān)控指標(biāo) ，需較高的版本才有，應(yīng)該是2.8.2x以后

• redis網(wǎng)絡(luò)入口流量字節(jié)數(shù)?(total_net_input_bytes)
• redis網(wǎng)絡(luò)出口流量字節(jié)數(shù)?(total_net_output_bytes)
• redis網(wǎng)絡(luò)入口kps?（instantaneous_input_kbps）
• redis網(wǎng)絡(luò)出口kps?(instantaneous_output_kbps)

前兩者是累計值，根據(jù)監(jiān)控平臺1個采集周期(如1分鐘)內(nèi)平均每秒的流量字節(jié)數(shù)。

Redis慢查詢監(jiān)控

redis慢查詢?是排查性能問題關(guān)鍵監(jiān)控指標(biāo)。因redis是單線程模型(single-threaded server),即一次只能執(zhí)行一個命令，如果命令耗時較長，其他命令就會被阻塞，進入隊列排隊等待；這樣對程序性能會較大。

redis慢查詢保存在內(nèi)存中，最多保存slowlog-max-len(默認(rèn)128）個慢查詢命令，當(dāng)慢查詢命令日志達到128個時，新慢查詢被加入前，會刪除最舊的慢查詢命令。因慢查詢不能持久化保存，且不能實時監(jiān)控每秒產(chǎn)生的慢查詢個數(shù)。

我們建議的慢查詢監(jiān)控方法：

設(shè)置合理慢查詢?nèi)罩鹃y值,slowlog-log-slower-than, 建議1ms(如果平均1ms, redis qps也就只有1000)

設(shè)置全理慢查詢?nèi)罩娟犃虚L度，slowlog-max-len建議大于1024個，因監(jiān)控采集周期1分鐘，建議，避免慢查詢?nèi)罩颈粍h除；另外慢查詢的參數(shù)過多時，會被省略，對內(nèi)存消耗很小

每次采集使用slowlog len獲取慢查詢?nèi)罩緜€數(shù)

每次彩集使用slowlog get 1024 獲取所慢查詢，并轉(zhuǎn)存儲到其他地方，如MongoDB或MySQL等，方便排查問題；并分析當(dāng)前慢查詢?nèi)罩咀铋L耗時微秒數(shù)。

然后使用slowlog reset把慢查詢?nèi)罩厩蹇?#xff0c;下個采集周期的日志長度就是最新產(chǎn)生的。

redis慢查詢的監(jiān)控項：

• redis慢查詢?nèi)罩緜€數(shù)?（slowlog_len):每個采集周期出現(xiàn)慢查詢個數(shù)，如1分鐘出現(xiàn)10次大于1ms的慢查詢
• redis慢查詢?nèi)罩咀铋L耗時值?(slowlog_max_time)：獲取慢查詢耗時最長值，因有的達10秒以下的慢查詢，可能導(dǎo)致復(fù)制中斷，甚至出來主從切換等故障。

Redis持久化監(jiān)控

redis存儲場景的集群，就得?redis持久化?保障數(shù)據(jù)落地，減少故障時數(shù)據(jù)丟失。這里分析redis rdb數(shù)據(jù)持久化的幾個監(jiān)控指標(biāo)。

• 最近一次rdb持久化是否成功?(rdb_last_bgsave_status):如果持久化未成功，建議告警，說明備份或主從復(fù)制同步不正常。或redis設(shè)置有”stop-writes-on-bgsave-error”為yes，當(dāng)save失敗后，會導(dǎo)致redis不能寫入操作
• 最近一次成功生成rdb文件耗時秒數(shù)?(rdb_last_bgsave_time_sec):rdb生成耗時反應(yīng)同步時數(shù)據(jù)是否增長； 如果遠程備份使用redis-cli –rdb方式遠程備份rdb文件，時間長短可能影響備份線程客戶端輸出緩沖內(nèi)存使用大小。
• 離最近一次成功生成rdb文件，寫入命令的個數(shù)?（rdb_changes_since_last_save):即有多少個寫入命令沒有持久化，最壞情況下會丟失的寫入命令數(shù)。建議設(shè)置監(jiān)控告警
• 離最近一次成功rdb持久化的秒數(shù)?(rdb_last_save_time): 最壞情況丟失多少秒的數(shù)據(jù)寫入。使用當(dāng)前時間戳 - 采集的rdb_last_save_time(最近一次rdb成功持久化的時間戳)，計算出多少秒未成功生成rdb文件

Redis復(fù)制監(jiān)控

不論使用何種redis集群方案，?redis復(fù)制?都會被使用。

復(fù)制相關(guān)的監(jiān)控告警項：

• redis角色?(redis_role):實例的角色，是master or slave
• 復(fù)制連接狀態(tài)?(master_link_status): slave端可查看它與master之間同步狀態(tài)；當(dāng)復(fù)制斷開后表示down,影響當(dāng)前集群的可用性。需設(shè)置監(jiān)控告警。
• 復(fù)制連接斷開時間長度?(master_link_down_since_seconds):主從服務(wù)器同步斷開的秒數(shù)，建議設(shè)置時長告警。
• 主庫多少秒未發(fā)送數(shù)據(jù)到從庫?(master_last_io_seconds):如果主庫超過repl-timeout秒未向從庫發(fā)送命令和數(shù)據(jù)，會導(dǎo)致復(fù)制斷開重連。詳細分析見文章：?Redis復(fù)制中斷和無限同步問題?。 在slave端可監(jiān)控，建議設(shè)置大于10秒告警
• 從庫多少秒未向主庫發(fā)送REPLCONF命令?(slave_lag): 正常情況從庫每秒都向主庫，發(fā)送REPLCONF ACK命令；如果從庫因某種原因，未向主庫上報命令，主從復(fù)制有中斷的風(fēng)險。通過在master端監(jiān)控每個slave的lag值。
• 從庫是否設(shè)置只讀?(slave_read_only)：從庫默認(rèn)只讀禁止寫入操作，監(jiān)控從庫只讀狀態(tài)；?
  如果關(guān)閉從庫只讀，有寫入數(shù)據(jù)風(fēng)險。關(guān)于主從數(shù)據(jù)不一致,見文章分析：?Redis復(fù)制主從數(shù)據(jù)不-致
• 主庫掛載的從庫個數(shù)?(connected_slaves):主庫至少保證一個從庫，不建議設(shè)置超過2個從庫。
• 復(fù)制積壓緩沖區(qū)是否開啟?(repl_backlog_active):主庫默認(rèn)開啟復(fù)制積壓緩沖區(qū)，用于應(yīng)對短時間復(fù)制中斷時，使用?部分同步?方式。
• 復(fù)制積壓緩沖大小?(repl_backlog_size):主庫復(fù)制積壓緩沖大小默認(rèn)1MB,因為是redis server共享一個緩沖區(qū)，建議設(shè)置100MB.

  說明： 關(guān)于根據(jù)實際情況，設(shè)置合適大小的復(fù)制緩沖區(qū)。可以通過master_repl_offset指標(biāo)計算每秒寫入字節(jié)數(shù)，同時乘以希望多少秒內(nèi)閃斷使用“部分同步”方式。

Redis集群監(jiān)控

這里所寫?redis官方集群方案?的監(jiān)控指標(biāo)

數(shù)據(jù)基本通過cluster info和info命令采集。

• 實例是否啟用集群模式?(cluster_enabled): 通過info的cluster_enabled監(jiān)控是否啟用集群模式。
• 集群健康狀態(tài)?（clusster_state):如果當(dāng)前redis發(fā)現(xiàn)有failed的slots，默認(rèn)為把自己cluster_state從ok個性為fail, 寫入命令會失敗。如果設(shè)置cluster-require-full-coverage為NO,則無此限制。
• 集群數(shù)據(jù)槽slots分配情況?(cluster_slots_assigned):集群正常運行時，默認(rèn)16384個slots
• 檢測下線的數(shù)據(jù)槽slots個數(shù)?(cluster_slots_fail):集群正常運行時，應(yīng)該為0. 如果大于0說明集群有slot存在故障。
• 集群的分片數(shù)?(cluster_size）：集群中設(shè)置的分片個數(shù)
• 集群的節(jié)點數(shù)?（cluster_known_nodes）：集群中redis節(jié)點的個數(shù)

Redis響應(yīng)時間監(jiān)控

響應(yīng)時間?是衡量一個服務(wù)組件性能和質(zhì)量的重要指標(biāo)。使用redis的服務(wù)通常對響應(yīng)時間都十分敏感，比如要求99%的響應(yīng)時間達10ms以內(nèi)。

因redis的慢查詢?nèi)罩局挥嬎忝畹腸pu占用時間，不會考慮排隊或其他耗時。

• 最長響應(yīng)時間?（respond_time_max):最長響應(yīng)時間的毫秒數(shù)
• 99%的響應(yīng)時間長度?(respond_time_99_max):
• 99%的平均響應(yīng)時間長度?(respond_time_99_avg):
• 95%的響應(yīng)時間長度?（respond_time_95_max):
• 95%的平均響應(yīng)時間長度?(respond_time_95_avg):

響應(yīng)時間監(jiān)控的方式建議，最簡單方法，使用?Percona tcprstat

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/8992306.html

總結(jié)

以上是生活随笔為你收集整理的细说Redis监控和告警的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。