监控Redis的关键指标
Redis 也是一个对外服务，所以 Google 的四个黄金指标同样适用于 Redis。
1、延迟
在软件工程架构中，之所以选择 Redis 作为技术堆栈的一员，大概率是想要得到更快的响应速度和更高的吞吐量，所以延迟数据对使用 Redis 的应用程序至关重要。
- 客户端应用程序埋点。比如某个 Java 或 Go 的程序在调用 Redis 的时候，计算一下各个命令花费了多久，然后把耗时数据推给监控系统即可。这种方式好处是非常灵活，想要按照什么维度统计就按照什么维度统计，缺点自然是代码侵入性。
- 使用 redis-cli 的 --latency 命令，这个原理比较简单，就是客户端连上 redis-server，然后不断发送 ping 命令，统计耗时。
Redis 是单线程顺序执行的模型，如果某个请求执行得慢，其他所有客户端都得等着，所以我们使用 ping 命令对 redis-server 做探测，理论上探测结果是可以反映 redis-server 的真实工况的。Redis 默认的配置是 10 毫秒。
2、流量
Redis 每秒处理多少请求，每秒接收多少字节、返回多少字节，在 Redis 里都内置了相关指标，通过 redis-cli 连上 Redis，执行 info all 命令可以看到很多指标，绝大部分监控系统，都是从 info 命令的返回内容中提取的指标。正常来讲，一个 Redis 实例每秒处理几万个请求都是很正常的。
ops_per_sec 表示每秒执行多少次操作，input_kbps 表示每秒接收多少 KiB，output_kbps 表示每秒返回多少 KiB。如果把 Redis 当做缓存来使用，我们还需关注 keyspace_hits 和 keyspace_misses 两个指标。这两个指标都是 Counter 类型，单调递增，即 Redis 实例启动以来，统计的所有命中的数量和未命中的数量。如果要统计总体的命中率，使用 hits 除以总量即可。
3、错误
Redis 在响应客户端请求时，通常不会有什么内部错误产生，毕竟只是操作内存，依赖比较少，出问题的概率就很小了。如果客户端操作 Redis 返回了错误，大概率是网络问题或命令写错了导致的。最好是做客户端埋点监控，自己发现了然后自己去解决。
Redis 对客户端的数量也有一个最大数值的限制，默认是 10 万，如果超过了这个数量，rejected_connections 指标就会 +1。和 MySQL 不一样的是，Redis 使用过程中，应该很少遇到超过最大连接数（maxclients） 的情况，不过谨慎起见，也可以对 rejected_connections 做一下监控。
4、饱和度
Redis 重度使用内存，内存的使用率、碎片率，以及因为内存不够用而清理的 Key 数量，都是需要重点关注的。我们通过 info memory 命令查看一下这几个关键指标。
used_memory 顾名思义就是使用了多少内存，是从 Redis 自身视角来看的，human 后缀表示用人类易读的方式来表示。used_memory_rss 表示从操作系统视角来看分配了多少内存给 Redis。used_memory_rss 除以 used_memory 就是内存碎片率，即 mem_fragmentation_ratio。
此文章为8月Day7学习笔记，内容来源于极客时间《运维监控系统实战笔记》，推荐该课程。