1、理解Redis監控

Redis運維和監控的意義不言而喻，可以以下三個方面入手

1.首先是Redis自身提供了哪些狀態信息，以及有哪些常見的命令可以獲取Redis的監控信息;
2.一些常見的UI工具可以可視化的監控Redis;
3.理解Redis的監控體系;

2、Redis自身狀態及命令

狀態信息 - info
Redis提供的INFO命令不僅能夠查看實時的吞吐量(ops/sec)，還能看到一些有用的運行時信息。

127.0.0.1:6379> info
# Server
redis_version:3.2.3 #redis版本號
redis_git_sha1:00000000 #git sha1摘要值
redis_git_dirty:0  #git dirty標識
redis_build_id:443e50c39cbcdbe0 #redis構建id
redis_mode:standalone  #運行模式：standalone、sentinel、cluster
os:Linux 3.10.0-514.16.1.el7.x86_64 x86_64 #服務器宿主機操作系統
arch_bits:64 服務器宿主機CUP架構（32位/64位）
multiplexing_api:epoll #redis IO機制
gcc_version:4.8.5  #編譯 redis 時所使用的 GCC 版本
process_id:1508  #服務器進程的 PID
run_id:b4ac0f9086659ce54d87e41d4d2f947e19c28401 #redis 服務器的隨機標識符 （用于 Sentinel 和集群）
tcp_port:6380  #redis服務監聽端口
uptime_in_seconds:520162 #redis服務啟動以來經過的秒數
uptime_in_days:6 #redis服務啟動以來經過的天數
hz:10  #redis內部調度（進行關閉timeout的客戶端，刪除過期key等等）頻率，程序規定serverCron每秒運行10次
lru_clock:16109450 #自增的時鐘，用于LRU管理,該時鐘100ms(hz=10,因此每1000ms/10=100ms執行一次定時任務)更新一次
executable:/usr/local/bin/redis-server
config_file:/data/redis-6380/redis.conf 配置文件的路徑# Clients
connected_clients:2   #已連接客戶端的數量（不包括通過從屬服務器連接的客戶端）
client_longest_output_list:0 #當前連接的客戶端當中，最長的輸出列表
client_biggest_input_buf:0 #當前連接的客戶端當中，最大輸入緩存
blocked_clients:0 #正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客戶端的數量# Memory
used_memory:426679232 #由 redis 分配器分配的內存總量，以字節（byte）為單位
used_memory_human:406.91M   #以可讀的格式返回 redis 分配的內存總量（實際是used_memory的格式化）
used_memory_rss:443179008 #從操作系統的角度，返回 redis 已分配的內存總量（俗稱常駐集大小）。這個值和 top 、 ps等命令的輸出一致
used_memory_rss_human:422.65M # redis 的內存消耗峰值(以字節為單位) 
used_memory_peak:426708912
used_memory_peak_human:406.94M
total_system_memory:16658403328
total_system_memory_human:15.51G
used_memory_lua:37888   # Lua腳本存儲占用的內存
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.04 # used_memory_rss/ used_memory
mem_allocator:jemalloc-4.0.3# Persistence
loading:0 #服務器是否正在載入持久化文件，0表示沒有，1表示正在加載
rdb_changes_since_last_save:3164272  #離最近一次成功生成rdb文件，寫入命令的個數，即有多少個寫入命令沒有持久化
rdb_bgsave_in_progress:0 #服務器是否正在創建rdb文件，0表示否
rdb_last_save_time:1559093160  #離最近一次成功創建rdb文件的時間戳。當前時間戳 - rdb_last_save_time=多少秒未成功生成rdb文件
rdb_last_bgsave_status:ok  #最近一次rdb持久化是否成功
rdb_last_bgsave_time_sec:-1  #最近一次成功生成rdb文件耗時秒數
rdb_current_bgsave_time_sec:-1 #如果服務器正在創建rdb文件，那么這個域記錄的就是當前的創建操作已經耗費的秒數
aof_enabled:0 #是否開啟了aof
aof_rewrite_in_progress:0 #標識aof的rewrite操作是否在進行中
aof_rewrite_scheduled:0  #rewrite任務計劃，當客戶端發送bgrewriteaof指令，如果當前rewrite子進程正在執行，那么將客戶端請求的bgrewriteaof變為計劃任務，待aof子進程結束后執行rewrite
aof_last_rewrite_time_sec:-1 #最近一次aof rewrite耗費的時長
aof_current_rewrite_time_sec:-1 #如果rewrite操作正在進行，則記錄所使用的時間，單位秒
aof_last_bgrewrite_status:ok #上次bgrewriteaof操作的狀態
aof_last_write_status:ok #上次aof寫入狀態# Stats
total_connections_received:10   #服務器已經接受的連接請求數量
total_commands_processed:9510792   #redis處理的命令數
instantaneous_ops_per_sec:1   #redis當前的qps，redis內部較實時的每秒執行的命令數
total_net_input_bytes:1104411373   #redis網絡入口流量字節數
total_net_output_bytes:66358938 #redis網絡出口流量字節數
instantaneous_input_kbps:0.04  #redis網絡入口kps
instantaneous_output_kbps:3633.35  #redis網絡出口kps
rejected_connections:0  #拒絕的連接個數，redis連接個數達到maxclients限制，拒絕新連接的個數
sync_full:0  #主從完全同步成功次數
sync_partial_ok:0  #主從部分同步成功次數
sync_partial_err:0  #主從部分同步失敗次數
expired_keys:0   #運行以來過期的key的數量
evicted_keys:0  #運行以來剔除(超過了maxmemory后)的key的數量
keyspace_hits:87  #命中次數
keyspace_misses:17   #沒命中次數
pubsub_channels:0  #當前使用中的頻道數量
pubsub_patterns:0  #當前使用的模式的數量
latest_fork_usec:0   #最近一次fork操作阻塞redis進程的耗時數，單位微秒
migrate_cached_sockets:0   #是否已經緩存了到該地址的連接# Replication
role:master  #實例的角色，是master or slave
connected_slaves:0  #連接的slave實例個數
master_repl_offset:0 #主從同步偏移量,此值如果和上面的offset相同說明主從一致沒延遲，與master_replid可被用來標識主實例復制流中的位置
repl_backlog_active:0   #復制積壓緩沖區是否開啟
repl_backlog_size:1048576  #復制積壓緩沖大小
repl_backlog_first_byte_offset:0  #復制緩沖區里偏移量的大小
repl_backlog_histlen:0   #此值等于 master_repl_offset - repl_backlog_first_byte_offset,該值不會超過repl_backlog_size的大小# CPU
used_cpu_sys:507.00  #將所有redis主進程在核心態所占用的CPU時求和累計起來
used_cpu_user:280.48   #將所有redis主進程在用戶態所占用的CPU時求和累計起來
used_cpu_sys_children:0.00  #將后臺進程在核心態所占用的CPU時求和累計起來
used_cpu_user_children:0.00  #將后臺進程在用戶態所占用的CPU時求和累計起來# Cluster
cluster_enabled:0# Keyspace
db0:keys=5557407,expires=362,avg_ttl=604780497
db15:keys=1,expires=0,avg_ttl=0

查看某個section的信息

127.0.0.1:6379> info memory
# Memory
used_memory:1067440
used_memory_human:1.02M
used_memory_rss:9945088
used_memory_rss_human:9.48M
used_memory_peak:1662736
used_memory_peak_human:1.59M
total_system_memory:10314981376
total_system_memory_human:9.61G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:9.32
mem_allocator:jemalloc-4.0.3

監控執行命令 - monitor
monitor用來監視服務端收到的命令。有一定的性能損耗，但是個人認為是值得的。

127.0.0.1:6379> monitor
OK
1616045629.853032 [10 192.168.0.101:37990] "PING"
1616045629.858214 [10 192.168.0.101:37990] "PING"
1616045632.193252 [10 192.168.0.101:37990] "EXISTS" "test_key_from_app"
1616045632.193607 [10 192.168.0.101:37990] "GET" "test_key_from_app"
1616045632.200572 [10 192.168.0.101:37990] "SET" "test_key_from_app" "1616045625017"
1616045632.200973 [10 192.168.0.101:37990] "SET" "test_key_from_app" "1616045622621"

3、Redis可視化監控工具

只能可視化指標不能監控： redis-stat、RedisLive、redmon 等工具。
用于生產環境： 基于redis_exporter以及grafana可以做到指標可視化，持久化，監控以及報警等。

redis-stat
是一個比較有名的redis指標可視化的監控工具，采用ruby開發，基于redis的info和monitor命令來統計，不影響redis性能。

它提供了命令行彩色控制臺展示模式

和web模式

RedisLive
采用python開發的redis的可視化及查詢分析工具。

docker運行

docker run --name redis-live -p 8888:8888 -d snakeliwei/redislive

訪問http://192.168.99.100:8888/index.html

redmon
redmon提供了cli、admin的web界面，同時也能夠實時監控redis。

docker運行

docker run -p 4567:4567 -d  vieux/redmon -r redis://192.168.99.100:6379

監控

cli

動態更新配置

redis_exporter
redis_exporter在新窗口打開為Prometheus提供了redis指標的exporter，支持Redis 2.x, 3.x, 4.x, 5.x, and 6.x，配合Prometheus以及grafana的Prometheus Redis插件，可以在grafana進行可視化及監控

二、redis的監控體系

redis這類敏感的純內存、高并發和低延時的服務，一套完善的監控告警方案，是精細化運營的前提。

什么樣的場景會用到redis監控體系？
一個大型系統引入了Redis作為緩存中間件：

1.部署架構采用Redis-Cluster模式;
2.后臺應用系統有幾十個，應用實例數超過二百個;
3.所有應用系統共用一套緩存集群;
4.集群節點數幾十個，加上容災備用環境，節點數量翻倍;
5.集群節點內存配置較高。

Redis監控體系具備什么價值？

1.redis故障快速通知，定位故障點；
2.分析redis故障的Root cause。//任何一個故障和性能問題，其根本“誘因”往往只有一個，稱為這個故障的Root cause
3.redis容量規劃和性能管理
4.redis硬件資源利用率和成本