Redis监控

作者：郭晓冬
时间：2018-04-19

---

Redis 监控

Redis监控告警的价值

• 是Redis故障快速通知，快速定位的前提
• 监控指标为分析Redis故障提供最直接的证据
• redis容量规划和性能管理
• redis硬件资源利用率和成本

1. Redis这类敏感的纯内存、高并发和低延时的服务,如果没有完善的监控告警，从用户侧或RD的角度去发现问题，从定位到排查将是非常耗时的，完善的监控告警可以缩短故障的相应时间
2. 良好的监控数据能够实时的反映Redis对资源的利用占比，Redis的性能监控，可以帮助我们及时发现性能瓶颈

Redis监控维度

参照Google标准，监控分为两大类：

• 黑盒监控
• 功能监控
• 白盒监控
• 容量监控
• 延时监控
• 错误监控
• 流量监控

功能监控

• 核心功能： 读、写
• 监控方案： 定期写入固定的Key:Value到Redis中，再读取内容是否正确
• 优化方案：
  ·过期时间：对写入的Key设置TTL，且时间小于定期写入的频率
  如果Key永不过期，那么只能验证Get无法验证Set
  Value体积：从固定的较小的Size变为不同梯度的Size分布
  如通过1K、10K、100K等不同Size的写入进行细粒度监控
  Value内容：从固定字符串改为可变字符串，推荐是timestamp
  通过timestamp可以精准判断写入和读取的时延

核心指标监控

• 容量
  • CPU
  • 平均负载（Load Average)
  • CPU整体利用率和饱和度(cpu.busy)
  • CPU单核饱和度（cpu.core.idle/core=0)
  • CPU上下文切换数（cpu.switches)

Redis是单进程实例，默认只使用单个核心，所以Redis对CPU资源的监控要监控到单个核心的资源使用率

• 内存和Swap
  • 系统内存余量大小（mem.memfree)
  • 系统swap使用量大小（mem.swapused)
  • Redis实例内存使用率
  • redis内存碎片率 (mem_fragmentation_ratio)

Redis是纯内存系统，必须要保证系统有足够的内存余量，以免出现OOM导致Redis进程被杀，同时Redis一旦使用swap，会导致性能骤降

• 磁盘
  • 磁盘分区的使用率（df.bytes.used.percent)
  • 磁盘IOPS的饱和度（disk.io.util)

Redis如果用到AOF/RDB时，需要监控到磁盘的容量问题，同时，IOPS的饱和度是需要重点关注的地方， 如果磁盘吞吐率过低，会导致RDB同步时间增长

• 网络
  • 网络吞吐量饱和度（net.if.out.bytes/net.if.in.bytes)
  • 丢包率

Redis一般是单机多实例部署， 当网络流量上升太多时，需要快速定位到是哪个实例在占用网卡带宽，当写流量过大时， 可能引起slave线程“客户端输出缓冲区”堆积，达到限制后被强制断开连接，出现复制中断故障。

• 错误
  慢查询监控

  • 设置合理的慢查询日志阈值(slowlog-log-slower-than)
  • 设置合理慢查询日志队列长度(slowlog-max-len)

redis是单线程模型(single-threaded server),即一次只能执行一个命令，如果命令耗时较长，其他命令就会被阻塞，进入队列排队等待, 因此需要关注Redis慢查询日志个数，以及慢查询日志的最长耗时

• 流量

  • redis网络入口流量字节数 (total_net_input_bytes)
  • redis网络出口流量字节数 (total_net_output_bytes)
  • redis网络入口kps （instantaneous_input_kbps）
  • redis网络出口kps (instantaneous_output_kbps)
  • total_commands_processed
  • total_connections_received
  • Redis QPS(instantaneous_ops_per_sec)

• 延时

  • redis-cli –intrinsic-latency 60
    虽然Redis是一种内存系统，但是它会以不同的方式处理操作系统，例如，在将数据持久化至磁盘中时。除此之外，Redis还实现了一组丰富的命令。某些命令运行速度很快，时间复杂度为O(1)或O(logN)；其他命令运行速度较慢，时间复杂度为O(N)，它们可能会导致延迟飙升。
    Redis 2.8.13引入了一个新特性，叫做延迟监控（Latency Monitoring），它可以帮助用户检查和定位可能的延迟问题。延迟监控由下面的几个组件构成：

• 延迟挂钩：这个组件会对延迟敏感的各种代码路径进行采样。

• 时间序列：这个组件会记录由各种事件造成的延迟飙升。

• 报告引擎：这个组件会从时间序列中取出原始数据。

• 分析引擎：这个组件会根据测量方法向用户提供易读的报告和提示信息。

通过这些组件来得出延时相关的信息。具体请参考[redis latency monitoring framework]:{https://redis.io/topics/latency-monitor}

几个厂商Redis监控项对比

阿里云 Redis 监控

基础监控组	实例信息的基本监控信息	包含 QPS、带宽及内存使用情况等。
Keys 监控组	使用键值阿里云 Redis 监控相关命令的监控统计	删除 key，判断 key 是否存在等命令的调用次数。
String 监控组	使用 string 数据类型相关命令的监控统计	append，mget 操作字符串数据类型命令的调用次数。
Hashes 监控组	使用 hash 数据类型相关命令的监控统计	调用 hget，hdel 等操作hash数据类型的命令调用次数统计。
Lists 监控组	使用 list 数据类型相关命令的监控统计	调用 blpop、brpop 等操作 list 数据类型的命令调用次数统计。
Sets 监控组	使用 set 数据类型相关命令的监控统计	调用 saadd、scard 等操作set数据类型的命令调用次数统计。
Zset 监控组	使用 zset 数据类型相关命令的监控统计	调用 zadd、zcard 等操作 set 数据类型的命令调用次数统计。
HyperLog 监控组	使用 HyperLogLog 数据类型相关命令的监控统计	调用 pfadd、pfcount 等操作 HyperLogLog 数据类型的命令调用次数统计。
Pub/Sub 监控组	使用 pub/sub 功能相关命令的监控统计	调用 publish、subscribe 等操作 pub/sub 功能的相关命令统计。
Transaction 监控组	使用事务相关命令的监控统计	调用 watch、multi、exec 等事务相关命令的调用次数统计。

青云 Redis 监控

• 节点资源监控

  • 带宽监控： 监控缓存节点的网卡出/入流量。
  • 基础资源监控： 包括 CPU、内存、硬盘等监控

• 缓存服务监控

  • 内存监控： 缓存服务的实际内存使用率，对应 used_memory 字段。
  • Get操作： Get 相关操作的总数。
  • Set操作： Set 相关操作的总数。
  • Key类型操作数： Key类型操作数的总数。
  • String类型操作数： String类型操作数的总数。
  • List类型操作数： List类型操作数的总数。
  • String类型操作数： String类型操作数的总数。
  • Hash类型操作数： Hash类型操作数的总数。
  • Set类型操作数： Set类型操作数的总数。
  • Sorted Set类型操作数： Sorted Set类型操作数的总数。
  • 总连接数： 建立总连接数，对应 total_connections_received 字段。
  • 当前连接数： 活跃的连接数，对应 connected_clients 字段。
  • 查询命中数： 查询的命中个数，对应 keyspace_hits 字段。
  • 查询未命中数： 查询的未命中个数，对应 keyspace_misses 字段。
  • 查询命中率： 查询命中率，对应 keyspace_hits / ( keyspace_hits + keyspace_misses )。
  • 总Key个数： 缓存中总的 key 个数，所有 db 的 key 个数总和。
  • 已过期Key个数： 缓存中已过期 Key 个数，对应 expired_keys 字段。
  • 被拒绝Key个数： 缓存中被拒绝 Key 个数，对应 evicted_keys 字段。当缓存内存不足时，会根据用户配置的 maxmemory-policy 来选择性地删除一些 key 来保护内存不溢出。

监控宝 Redis 监控

• 链接客户数
• 链接从库数：此指标反映Redis的从库链接数。
• 链接数每分钟: 此指标反映Redis的请求频率。
• 阻塞客户数 :当并发请求数过高时触发阻塞。此指标反映Redis的并发请求状况。
• Pub/Sub通道数
• Pub/Sub模式数
• 命中率 ：即单位总命中次数除以总命中次数与未命中次数之和。
• 使用内存：此指标反映Redis当前占用内存量。
• 执行命令数每分钟：此指标反映Redis执行命令频率。

腾讯云 Redis 监控

• 内网流量
• 连接数
• Get数
• Set数
• KEY总数
• 容量使用率
• CPU负载
• QPS
• 命中率

Redis-Cli 命令产生的info信息

info

info server 服务端信息
redis_version #Redis服务器版本
redis_git_sha1 #Git SHA1
redis_git_dirty #Git脏标志
os #Redis服务器的宿主操作系统
arch_bits #架构（32或64位）
multiplex_api #Redis所使用的事件处理机制
gcc_version #编译Redis时所使用的GCC版本
process_id #服务器进程的PID
run_id #Redis的服务器的随机标识符（用于前哨和集群）
tcp_port #TCP / IP监听端口
uptime_in_seconds #自动Redis服务器启动以来，经过的秒数
uptime_in_days #自动Redis服务器启动以来，经过的天数
lru_clock #以分钟为单位进行自增的时钟，用于LRU管理

info clients 客户端信息
connected_clients #已连接客户端的数量（不包括通过从属性服务器连接的客户端）
client_longest_output_list #当前连接的客户端当中，最长的输出列表
client_longest_input_buf #当前连接的客户端当中，最大输入缓存
blocked_clients #正在等待阻塞命令（BLPOP，BRPOP，BRPOPLPUSH）的客户端的数量

info memory 内存信息
used_memory #由Redis分配器分配的内存总量，以字节（byte）为单位
used_memory_human #以人类可读的格式返回Redis分配的内存总量
used_memory_rss #从操作系统的角度，返回Redis已分配的内存总量（俗称常驻集大小）。这个值和 top， ps等命令的输出一致。
used_memory_peak #Redis的内存消耗峰值（以字节为单位）
used_memory_peak_human #以人类可读的格式返回Redis的内存消耗峰值
used_memory_lua #Lua引擎所使用的内存大小（以字节为单位）
mem_fragmentation_ratio # used_memory_rss和 used_memory之间的比率
mem_allocator #在编译时指定的，Redis所使用的内存分配器。可以是libc，jemalloc或者tcmalloc。

info persistence RDB和AOF的持久化相关信息
loading:0 #服务器是否正在载入持久化文件
rdb_changes_since_last_save:28900855 #离最近一次成功生成rdb文件，写入命令的个数，即有多少个写入命令没有持久化
rdb_bgsave_in_progress:0 #服务器是否正在创建rdb文件
rdb_last_save_time:1482358115 #离最近一次成功创建rdb文件的时间戳。当前时间戳 – rdb_last_save_time=多少秒未成功生成rdb文件
rdb_last_bgsave_status:ok #最近一次rdb持久化是否成功
rdb_last_bgsave_time_sec:2 #最近一次成功生成rdb文件耗时秒数
rdb_current_bgsave_time_sec:-1 #如果服务器正在创建rdb文件，那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_enabled:1 #是否开启了aof
aof_rewrite_in_progress:0 #标识aof的rewrite操作是否在进行中
aof_rewrite_scheduled:0
​
info 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写入状态
aof_current_size:4201740 #aof当前尺寸
aof_base_size:4201687 #服务器启动时或者aof重写最近一次执行之后aof文件的大小
aof_pending_rewrite:0 #是否有aof重写操作在等待rdb文件创建完毕之后执行?
aof_buffer_length:0 #aof buffer的大小
aof_rewrite_buffer_length:0 #aof rewrite buffer的大小
aof_pending_bio_fsync:0 #后台I/O队列里面，等待执行的fsync调用数量
aof_delayed_fsync:0 #被延迟的fsync调用数量

info stats 一般统计信息
total_connections_received:209561105 #新创建连接个数,如果新创建连接过多，过度地创建和销毁连接对性能有影响，说明短连接严重或连接池使用有问题，需调研代码的连接设置
total_commands_processed:2220123478 #redis处理的命令数
instantaneous_ops_per_sec:279 #redis当前的qps，redis内部较实时的每秒执行的命令数
total_net_input_bytes:118515678789 #redis网络入口流量字节数
total_net_output_bytes:236361651271 #redis网络出口流量字节数
instantaneous_input_kbps:13.56 #redis网络入口kps
instantaneous_output_kbps:31.33 #redis网络出口kps
rejected_connections:0 #拒绝的连接个数，redis连接个数达到maxclients限制，拒绝新连接的个数
sync_full:1 #主从完全同步成功次数
sync_partial_ok:0 #主从部分同步成功次数
sync_partial_err:0 #主从部分同步失败次数
expired_keys:15598177 #运行以来过期的key的数量
evicted_keys:0 #运行以来剔除(超过了maxmemory后)的key的数量
keyspace_hits:1122202228 #命中次数
keyspace_misses:577781396 #没命中次数
pubsub_channels:0 #当前使用中的频道数量
pubsub_patterns:0 #当前使用的模式的数量
latest_fork_usec:15679 #最近一次fork操作阻塞redis进程的耗时数，单位微秒
migrate_cached_sockets:0 #

info replication 主从信息，master上显示的信息
role:master #实例的角色，是master or slave
connected_slaves:1 #连接的slave实例个数
slave0:ip=192.168.64.104,port=9021,state=online,offset=6713173004,lag=0 #lag从库多少秒未向主库发送REPLCONF命令
master_repl_offset:6713173145 #主从同步偏移量,此值如果和上面的offset相同说明主从一致没延迟
repl_backlog_active:1 #复制积压缓冲区是否开启
repl_backlog_size:134217728 #复制积压缓冲大小
repl_backlog_first_byte_offset:6578955418 #复制缓冲区里偏移量的大小
repl_backlog_histlen:134217728 #此值等于 master_repl_offset – repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小

info replication 主从信息，slave上显示的信息
role:slave #实例的角色，是master or slave
master_host:192.168.64.102 #此节点对应的master的ip
master_port:9021 #此节点对应的master的port
master_link_status:up #slave端可查看它与master之间同步状态,当复制断开后表示down
master_last_io_seconds_ago:0 #主库多少秒未发送数据到从库?
master_sync_in_progress:0 #从服务器是否在与主服务器进行同步
slave_repl_offset:6713173818 #slave复制偏移量
slave_priority:100 #slave优先级
slave_read_only:1 #从库是否设置只读
connected_slaves:0 #连接的slave实例个数
master_repl_offset:0
repl_backlog_active:0 #复制积压缓冲区是否开启
repl_backlog_size:134217728 #复制积压缓冲大小
repl_backlog_first_byte_offset:0 #复制缓冲区里偏移量的大小
repl_backlog_histlen:0 #此值等于 master_repl_offset – repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小

info CPU CPU计算量统计信息
used_cpu_sys:96894.66 #将所有redis主进程在核心态所占用的CPU时求和累计起来
used_cpu_user:87397.39 #将所有redis主进程在用户态所占用的CPU时求和累计起来
used_cpu_sys_children:6.37 #将后台进程在核心态所占用的CPU时求和累计起来
used_cpu_user_children:52.83 #将后台进程在用户态所占用的CPU时求和累计起来

info commandstats 各种不同类型的命令的执行统计信息
cmdstat_get:calls=1664657469,usec=8266063320,usec_per_call=4.97 #call每个命令执行次数,usec总共消耗的CPU时长(单位微秒),平均每次消耗的CPU时长(单位微秒)

info cluster 集群相关信息
cluster_enabled:1 #实例是否启用集群模式

info keyspace 数据库相关的统计信息
db0:keys=194690,expires=191702,avg_ttl=3607772262 #db0的key的数量,以及带有生存期的key的数,平均存活时间

redis性能查看与监控常用工具

Redis 自带了一个叫 redis-benchmark 的工具来模拟 N 个客户端同时发出 M 个请求。 （类似于 Apache ab 程序）。你可以使用 redis-benchmark -h 来查看基准参数。

redis-benchmark

redis基准信息，redis服务器性能检测

redis-benchmark -h localhost -p 6379 -c 100 -n 100000

100个并发连接，100000个请求，检测host为localhost 端口为6379的redis服务器性能

详细信息请查看How fast is Redis http://www.redis.cn/topics/benchmarks.html

参考链接

细说Redis监控和告警 https://blog.csdn.net/qq_27623337/article/details/53206685
官方的Redis Cluster 监控方案 https://redis.io/topics/cluster-spec
Redis 延迟分析 https://zhongfox.github.io/2016/01/31/redis-latency/
redis latency monitoring framework https://redis.io/topics/latency-monitor
How fast is Redis? https://redis.io/topics/benchmarks