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

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

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

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

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

3.Redis告警策略

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

[[255758]]

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ù)案(如切換機(jī)房或啟用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)中，一次故障輕松就達(dá)直接損失數(shù)十萬(間接損失更大)，那“抓住元兇”，避免它再次“作案”，同樣是“破案”。

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

服務(wù)調(diào)用Redis響應(yīng)時間變大的性能總是;可能網(wǎng)絡(luò)問題，redis慢查詢，redis QPS增高達(dá)到性能瓶頸，redis fork阻塞和請求排隊，redis使用swap, cpu達(dá)到飽和(單核idle過低),aof fsync阻塞，網(wǎng)絡(luò)進(jìn)出口資源飽和等等

redis使用內(nèi)存突然增長，快達(dá)到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進(jìn)程rss達(dá)30gb,響應(yīng)抖動時應(yīng)該有同步，fork子進(jìn)程時，頁表拷貝時要阻塞父進(jìn)程，估計頁表大小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ù);對集群進(jìn)行合理擴(kuò)容(Scale-out)、縮容(Scale-back);對性能瓶頸優(yōu)化處理等。

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

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

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

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

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

Redis硬件資源利用率和成本

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

如果資源不達(dá)標(biāo)，就得推進(jìn)資源優(yōu)化整合;提高硬件利用率，減少資源浪費?？愁A(yù)算，減成本。

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

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

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

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

當(dāng)服務(wù)和存儲達(dá)到產(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ù)載會升高?？烧f明redis的處理性能下降(平均響應(yīng)時間變長、吞吐量降低)。

CPU整體利用率或飽和度 (cpu.busy): redis在高并發(fā)或時間復(fù)雜度高的指令，cpu整體資源飽和，導(dǎo)致redis性能下降，請求堆積。

CPU單核飽和度 (cpu.core.idle/core=0): redis是單進(jìn)程模式，常規(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進(jìn)程被殺，或使用swap導(dǎo)致redis性能驟降。

系統(tǒng)swap使用量大小 (mem.swapused)：redis的”熱數(shù)據(jù)“只要進(jìn)入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)，單機(jī)多實例情況，有異常的大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)計算;如果達(dá)到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ù)達(dá)到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)的，達(dá)到maxmemory限制不能寫入數(shù)據(jù)。

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

redis進(jìn)程使用內(nèi)存大小(used_memory_rss): 進(jìn)程實際使用的物理內(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可以遠(yuǎn)大于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達(dá)到maxmemory限制，并設(shè)置有淘汰策略的實例;(對排查問題重要，可不設(shè)置告警)

過期淘汰的鍵個數(shù) (expired_keys): 刪除生存時間為0的鍵個數(shù);包含主動刪除和定期刪除的個數(shù)。

Redis qps

redis處理的命令數(shù) (total_commands_processed): 監(jiān)控采集周期內(nèi)的平均qps,

redis單實例處理達(dá)數(shù)萬，如果請求數(shù)過多，redis過載導(dǎo)致請求堆積。

redis當(dāng)前的qps (instantaneous_ops_per_sec): redis內(nèi)部較實時的每秒執(zhí)行的命令數(shù);可和total_commands_processed監(jiān)控互補(bǔ)。

Redis cmdstat_xxx

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

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

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

# Commandstatscmdstat_set:calls=6,usec=37,usec_per_call=6.17cmdstat_lpush:calls=4,usec=32,usec_per_call=8.00cmdstat_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)致請求落到后端存儲組件，可能需要擴(kuò)容redis緩存集群的內(nèi)存容量。當(dāng)然也有可能是業(yè)務(wù)特性導(dǎo)致。

請求鍵被命中次數(shù) (keyspace_hits): redis請求鍵被命中的次數(shù)

請求鍵未被命中次數(shù) (keyspace_misses): redis請求鍵未被命中的次數(shù);當(dāng)命中率較高如95%，如果請求量大，未命中次數(shù)也會很多?？蓞⒖糂aron大神寫的 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進(jìn)程有 fork 操作。而fork會對redis進(jìn)程有個短暫的卡頓,這個卡頓redis不能響應(yīng)任務(wù)請求。所以監(jiān)控fork阻塞時長，是相當(dāng)重要。

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

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

redis network traffic

redis一般單機(jī)多實例部署，當(dāng)服務(wù)器網(wǎng)絡(luò)流量增長很大，需快速定位是網(wǎng)絡(luò)流量被哪個redis實例所消耗了; 另外redis如果寫流量過大，可能導(dǎo)致slave線程“客戶端輸出緩沖區(qū)”堆積，達(dá)到限制后被Maser強(qiáng)制斷開連接，出現(xiàn)復(fù)制中斷故障。所以我們需監(jiān)控每個redis實例網(wǎng)絡(luò)進(jìn)出口流量，設(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í)行一個命令，如果命令耗時較長，其他命令就會被阻塞，進(jìn)入隊列排隊等待;這樣對程序性能會較大。

redis慢查詢保存在內(nèi)存中，最多保存slowlog-max-len(默認(rèn)128)個慢查詢命令，當(dāng)慢查詢命令日志達(dá)到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)罩厩蹇?，下個采集周期的日志長度就是最新產(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)：獲取慢查詢耗時最長值，因有的達(dá)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ù)制同步不正常?；騬edis設(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ù)是否增長; 如果遠(yuǎn)程備份使用redis-cli –rdb方式遠(yuǎn)程備份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ù)制斷開重連。詳細(xì)分析見文章： 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)時間達(dá)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