redis监控命令

  

前言

redis是一款非常流行的kv数据库，以高性能著称，其高吞吐、低延迟等特性让广大开发者趋之若鹜，每每看到别人发出的redis故障报告都让我产生一种居安思危，以史为鉴的危机感，恰逢今年十一西安烟雨不断，抽时间学习了几个redis监控命令，和大家分享一波。

redis-cli --stat【连续统计】

 连续统计可能是实时监控 Redis 实例的鲜为人知但非常有用的功能之一，要启用此功能，请使用redis-cli --stat。

redis-cli --stat 默认每秒输出一条新行，其中包含有用信息和每个采集点的请求次数差异。使用此命令可以轻松了解内存使用情况、客户端连接计数以及有关已连接 Redis 数据库的各种其他统计信息。

可以使用-i修改采样频率，默认值为1秒，如下面这个命令代表每2s采集一次数据：

1 2 3 4 5 6 7 8 9 10 11 12 13

redis-cli --stat -i 2 ------- data ------ --------------------- load -------------------- - child - keys       mem      clients blocked requests            connections          8890       131.89M  47      0       1705992846 (+0)     2595        8890       131.93M  47      0       1705992897 (+51)    2595        8890       131.93M  47      0       1705992954 (+57)    2595        8890       131.97M  47      0       1705992991 (+37)    2595        8890       131.89M  47      0       1705993043 (+52)    2595        8890       131.97M  47      0       1705993088 (+45)    2595        8890       132.01M  47      0       1705993122 (+34)    2595        8890       132.01M  47      0       1705993168 (+46)    2595        8890       132.01M  47      0       1705993194 (+26)    2595        8890       131.93M  47      0       1705993267 (+73)    2595

　

redis-cli --bigkeys【统计大key】

这个命令用作键空间分析器，它扫描数据集中的大键，但也提供有关数据集所包含的数据类型的信息。

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

# redis-cli --bigkeys   # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec # per 100 SCAN commands (not usually needed).   [00.00%] Biggest hash   found so far '"hash_big"' with 6 fields [00.00%] Biggest set    found so far '"set_big"' with 6 members [00.00%] Biggest string found so far '"string_big"' with 979 bytes [00.00%] Biggest string found so far '"string_big_2"' with 1365 bytes   -------- summary -------   Sampled 5 keys in the keyspace! Total key length in bytes is 38 (avg len 7.60)   Biggest   hash found '"hash_big"' has 6 fields Biggest string found '"string_big_2"' has 1365 bytes Biggest    set found '"set_big"' has 6 members   0 lists with 0 items (00.00% of keys, avg size 0.00) 1 hashs with 6 fields (20.00% of keys, avg size 6.00) 3 strings with 2420 bytes (60.00% of keys, avg size 806.67) 0 streams with 0 entries (00.00% of keys, avg size 0.00) 1 sets with 6 members (20.00% of keys, avg size 6.00) 0 zsets with 0 members (00.00% of keys, avg size 0.00)

在输出的第一部分中，将报告遇到的每个大于前一个较大key（相同类型）的新key。摘要部分提供有关 Redis 实例内数据的一般统计信息。

该程序使用 SCAN 命令，因此它可以在繁忙的服务器上执行而不会影响操作，当然也可以使用-i选项来限制每个 SCAN 命令的指定秒数部分的扫描过程。

例如，redis-cli --bigkeys  -i 1 代表每次SCAN执行之后sleep 1s。

可以看到--bigkeys给出了每种数据结构的top 1 bigkey，同时给出了每种数据类型的键值个数以及平均大小。　

redis-cli monitor【监控命令执行】

 与“发布/订阅”模式类似，使用 MONITOR 命令后，将自动进入监视模式， Redis 实例接收的所有命令都将打印到标准输出中：

1 2 3 4 5 6 7 8 9 10

redis-cli monitor 1665128881.578949 [0 127.0.0.1:46046] "COMMAND" "DOCS" 1665128885.870333 [0 127.0.0.1:46046] "get" "a" 1665128891.200705 [0 127.0.0.1:46046] "set" "a" "asdfasdfasd" "asdfasdf" 1665128897.234390 [0 127.0.0.1:46046] "sadd" "test" "aaa" 1665128902.439247 [0 127.0.0.1:46046] "smembers" "test" 1665128906.257225 [0 127.0.0.1:46046] "smembers" "test" 1665128910.073980 [0 127.0.0.1:46046] "smembers" "test" 1665128914.688753 [0 127.0.0.1:46046] "hget" "all" "hello" 1665128918.006031 [0 127.0.0.1:46046] "hget" "all" "hello"

可以看到目前smembers和hget命令执行的比较频繁，可能是异常流量导致，需要引起我们的注意了。

更方便的是redis-cli monitor可以和管道配合使用，比如redis-cli monitor | grep goods_test_001

1 2 3 4 5 6 7 8 9 10 11

redis-cli monitor |grep goods_test_001 1665129150.063322 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129150.935202 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129151.486148 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129152.012097 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129152.550077 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129153.059130 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129153.595023 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129154.166608 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129154.687753 [0 127.0.0.1:46046] "get" "goods_test_001" 1665129155.204012 [0 127.0.0.1:46046] "get" "goods_test_001"

结合grep goods_test_001可以发现goods_test_001这个key当前有大量的读请求。　　

Pub/sub mode【发布订阅模式】

redis-cli可以用来发布/订阅消息，如果你的系统中使用了redis的发布订阅功能，可以使用redis-cli的这一特性来进行一些调试工作。

比如，使用redis-cli发布一条消息到mychannel

1	redis-cli publish mychannel helloworld

同样的，使用redis-cli订阅mychannel发来的消息

 

1 2 3 4 5 6 7 8

redis-cli subscribe mychannel Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "mychannel" 3) (integer) 1 1) "message" 2) "mychannel" 3) "helloworld"

Monitoring the latency of Redis instances【监控延迟】

 redis常用来构建延迟敏感的应用，延迟涉及多个环节，客户端到网络层之间，网络层到redis之间，redis自身处理等。

redis-cli提供了多种工具帮助我们发现延迟，涉及的指标有最小值、最大值、平均值、延迟分布情况等。

基本的延迟检查工具是redis-cli --latency。使用--latency，redis-cli 运行一个循环，以每秒100次的速度向redis发送PING命令，并测量收到回复的时间，统计信息在控制台中实时更新。

1 2	# redis-cli --latency min: 0, max: 3, avg: 0.28 (536 samples)

统计数据以毫秒为单位，上面的测试一共发了536个PING命令，最小响应时间为0毫秒（0不代表没有延迟，只是说毫秒统计不到），最大为3毫秒，平均值为0.28毫秒。

有时我们更希望看到redis延迟变化的趋势，这时--latency-history就可以派上用场，它的工作机制和--latency相同，只是每15秒（默认）重新开启一个测试会话。

1 2 3 4 5 6 7 8 9 10 11

redis-cli --latency-history min: 0, max: 7, avg: 0.25 (1432 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.24 (1435 samples) -- 15.00 seconds range min: 0, max: 15, avg: 0.27 (1429 samples) -- 15.01 seconds range min: 0, max: 5, avg: 0.28 (1431 samples) -- 15.01 seconds range min: 0, max: 5007, avg: 7.71 (839 samples) -- 15.01 seconds range min: 1, max: 18, avg: 3.58 (1092 samples) -- 15.01 seconds range min: 0, max: 13, avg: 3.56 (1093 samples) -- 15.01 seconds range min: 1, max: 15, avg: 3.61 (1090 samples) -- 15.00 seconds range min: 1, max: 17, avg: 3.60 (1091 samples) -- 15.01 seconds range min: 0, max: 26, avg: 2.57 (1178 samples) -- 15.00 seconds range

可以看到，上面每隔15秒输出一组数据，在第5个15秒开始时耗时明显增加。

内部还实现了另一个非比寻常的延迟检测工具，它不检查 Redis 实例的延迟，而是检查运行的计算机的延迟，此延迟是内核计划程序、虚拟机管理程序（如果是虚拟化