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

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

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

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

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

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

3.Redis告警策略

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

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

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

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

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

當(dāng)redis出現(xiàn)故障時(shí)，DBA應(yīng)在盡可能短時(shí)間內(nèi)發(fā)現(xiàn)告警；如果故障對(duì)服務(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故障的問題；整個(gè)redis故障的發(fā)現(xiàn)、定位和解決時(shí)間被拉長(zhǎng)，把一個(gè)原本的小故障被”無(wú)限”放大。

分析redis故障的Root cause

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

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

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

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

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

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

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

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

  說(shuō)明：糧廠有個(gè)習(xí)慣，在分析root cause盡量能拿到直觀證據(jù)。因?yàn)橐坏┮胪评聿襟E，每一步的推理結(jié)果都可能出現(xiàn)偏差，最終可能給出錯(cuò)誤root cause. “元兇”又逃過一劫，它下次作案估計(jì)就會(huì)更大。所以建議任何小的故障或抖動(dòng)，至少?gòu)膫€(gè)人或小組內(nèi)部，深入分析找到root cause；這樣個(gè)人或組織都會(huì)成長(zhǎng)快； 形成良好的氛圍。

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

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

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

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

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

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

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

Redis硬件資源利用率和成本

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

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

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

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

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

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

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

Redis監(jiān)控?cái)?shù)據(jù)采集

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

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

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

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

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

我們從redis使用資源的特性，分析各個(gè)子系統(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)過度使用時(shí)，平均負(fù)載會(huì)升高?？烧f(shuō)明redis的處理性能下降(平均響應(yīng)時(shí)間變長(zhǎng)、吞吐量降低)。
• CPU整體利用率或飽和度?(cpu.busy): redis在高并發(fā)或時(shí)間復(fù)雜度高的指令，cpu整體資源飽和，導(dǎo)致redis性能下降，請(qǐng)求堆積。
• CPU單核飽和度?(cpu.core.idle/core=0): redis是單進(jìn)程模式，常規(guī)情況只使用一個(gè)cpu core, 單某個(gè)實(shí)例出現(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處理性能就會(huì)驟降； 不管swap分區(qū)的是否是SSD介質(zhì)。OS對(duì)swap的使用材質(zhì)還是disk store. 這也是作者早期redis實(shí)現(xiàn)VM,后來(lái)又放棄的原因。

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

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

磁盤

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

網(wǎng)絡(luò)

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

Redis Server監(jiān)控?cái)?shù)據(jù)采集

通過redis實(shí)例的狀態(tài)數(shù)據(jù)采集，采集監(jiān)控?cái)?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，如果指定時(shí)間返回PONG表示存活，否則redis不能響應(yīng)請(qǐng)求，可能阻塞或死亡。
• redis uptime監(jiān)控?(redis_uptime)：uptime_in_seconds

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

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

• 連接數(shù)使用率(connected_clients_pct): 連接數(shù)使用百分比，通過(connected_clients/macclients)計(jì)算；如果達(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>

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

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

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

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

• redis內(nèi)存使用比例(used_memory_pct): 已分配內(nèi)存的百分比，通過(used_memory/maxmemory)計(jì)算；對(duì)于redis存儲(chǔ)場(chǎng)景會(huì)比較關(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)程實(shí)際使用的物理內(nèi)存大小，包含內(nèi)存碎片；如果rss過大導(dǎo)致內(nèi)部碎片大，內(nèi)存資源浪費(fèi)，和fork的耗時(shí)和cow內(nèi)存都會(huì)增大。

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

  說(shuō)明：

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

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

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

Redis Keyspace

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

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

Redis qps

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

Redis cmdstat_xxx

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

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

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

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

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

Redis fork

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

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

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

redis network traffic

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

說(shuō)明：網(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ì)值，根據(jù)監(jiān)控平臺(tái)1個(gè)采集周期(如1分鐘)內(nèi)平均每秒的流量字節(jié)數(shù)。

Redis慢查詢監(jiān)控

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

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

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

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

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

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

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

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

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

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

Redis持久化監(jiān)控

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

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

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

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

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

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

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

Redis集群監(jiān)控

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

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

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

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

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

因redis的慢查詢?nèi)罩局挥?jì)算命令的cpu占用時(shí)間，不會(huì)考慮排隊(duì)或其他耗時(shí)。

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

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

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

總結(jié)

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

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