Redis運行時的10大重要指標

Redis運行時的10大重要指標

 

 

存活狀況

 

全部指標中最重要的固然是檢查redis是否還活着，能夠經過命令PING的響應是不是PONG來判斷。

 

鏈接數

 

鏈接的客戶端數量，可經過命令src/redis-cli info Clients | grep connected_clients獲得，這個值跟使用redis的服務的鏈接池配置關係比較大，因此在監控這個字段的值時須要注意。另外這個值也不能太大，建議不要超過5000，若是太大多是redis處理太慢，那麼須要排除問題找出緣由。

另外還有一個拒絕鏈接數（rejected_connections）也須要關注，這個值理想狀態是0。若是大於0，說明建立的鏈接數超過了maxclients，須要排查緣由。是redis鏈接池配置不合理仍是鏈接這個redis實例的服務過多等。

 

阻塞客戶端數量

 

blocked_clients，通常是執行了list數據類型的BLPOP或者BRPOP命令引發的，可經過命令src/redis-cli info Clients | grep blocked_clients獲得，很明顯，這個值最好應該爲0。

 

使用內存峯值

 

監控redis使用內存的峯值，咱們都知道Redis能夠經過命令config set maxmemory 10737418240設置容許使用的最大內存（強烈建議不要超過20G），爲了防止發生swap致使Redis性能驟降，甚至因爲使用內存超標緻使被系統kill，建議used_memory_peak的值與maxmemory的值有個安全區間，例如1G，那麼used_memory_peak的值不能超過9663676416（9G）。

 

另外，咱們還能夠監控maxmemory不能少於多少G，好比5G。由於咱們之前生產環境出過這樣的問題，運維不當心把10G配置成了1G，從而致使服務器有足夠內存卻不能使用的悲劇。

 

內存碎片率

 

mem_fragmentation_ratio=used_memory_rss/used_memory，這也是一個很是須要關心的指標。若是是redis4.0以前的版本，這個問題除了重啓也沒什麼很好的優化辦法。而redis4.0有一個主要特性就是優化內存碎片率問題（Memory de-fragmentation）。在redis.conf配置文件中有介紹即ACTIVE DEFRAGMENTATION：碎片整理容許Redis壓縮內存空間，從而回收內存。

 

這個特性默認是關閉的，能夠經過命令CONFIG SET activedefrag yes熱啓動這個特性。

1. 當這個值大於1時，表示分配的內存超過實際使用的內存，數值越大，碎片率越嚴重。

2. 當這個值小於1時，表示發生了swap，便可用內存不夠。

 

另外須要注意的是，當內存使用量（used_memory）很小的時候，這個值參考價值不大。因此，建議used_memory至少1G以上才考慮對內存碎片率進行監控。

 

緩存命中率

 

keyspace_misses/keyspace_hits這兩個指標用來統計緩存的命令率，keyspace_misses指未命中次數，keyspace_hits表示命中次數。keyspace_hits/(keyspace_hits+keyspace_misses)就是緩存命中率。視狀況而定，建議0.9以上，即緩存命中率要超過90%。若是緩存命中率太低，那麼要排查對緩存的用法是否有問題！

 

OPS

 

instantaneous_ops_per_sec這個指標表示緩存的OPS，若是業務比較平穩，那麼這個值也不會波動很大，不過國內的業務比較特性，若是不是全球化的產品，夜間是基本上沒有什麼訪問量的，因此這個字段的監控要結合本身的具體業務，不一樣時間段波動範圍可能有所不一樣。

 

持久化

 

rdb_last_bgsave_status/aof_last_bgrewrite_status，即最近一次或者說最後一次RDB/AOF持久化是否有問題，這兩個值都應該是"ok"。

另外，因爲redis持久化時會fork子進程，且fork是一個徹底阻塞的過程，因此能夠監控fork耗時即latest_fork_usec，單位是微妙，若是這個值比較大會影響業務，甚至出現timeout。

 

失效KEY

 

若是把Redis當緩存使用，那麼建議全部的key都設置了expire屬性，經過命令src/redis-cli info Keyspace獲得每一個db中key的數量和設置了expire屬性的key的屬性，且expires須要等於keys：

# Keyspace
db0:keys=30,expires=30,avg_ttl=0
db0:keys=23,expires=22,avg_ttl=0

 

慢日誌

經過命令slowlog get獲得Redis執行的slowlog集合，理想狀況下，slowlog集合應該爲空，即沒有任何慢日誌，不過，有時候因爲網絡波動等緣由形成set key value這種命令執行也須要幾毫秒，在監控的時候咱們須要注意，而不能看到slowlog就想着去優化，簡單的set/get可能也會出如今slowlog中。