slowlog-log-slower-than： 慢查询时间阈值，超过这个阈值的查询将会被记录，默认值10000，但是微妙，也即10毫秒。

slowlog-max-len：慢查询日志最大条数，默认值128，先进先出的队列的形式记录在内存中。

slowlog-get n：获取前n条慢查询日志

2.Memory metrics

2.1需要注意的指标: used_memory

内存使用是Redis性能的关键组成部分。
如果实例超过可用内存(used_memory > total available memory)，操作系统将开始交换老的/未使用的部分内存(pages)，将该部分pages写入磁盘，为较新/活动页腾出内存空间。
每个交换的部分都写入磁盘，严重影响性能。从磁盘写入或读取速度比写入或从存储器读取速度慢5个数量级（100,000）（内存为0.1μs，磁盘为10 ms）。
可以将Redis配置为仅限于指定的内存量。在redis.conf文件中设置maxmemory指令可以直接控制Redis的内存使用情况。
启用maxmemory需要您为Redis配置驱逐（过期）策略以确定它应如何释放内存。
当Redis用作缓存时，这种“扁平线”模式很常见;消耗掉所有可用内存，并以与插入新数据相同的速率清理旧数据。

　　译者注：关于Redis的内存参数 info memory
　　used_memory和used_memory_human都是Redis使用到的内存，used_memory_human是一更加可读性的方式展示Redis的内存使用
　　used_memory_rss和used_memory_rss_human 表示操作系统为Redis进程分配的内存总量，两者的含义类似如上。
　　为什么会出现Redis使用的内存大于操作系统给Redis分配的内存，参考https://*.com/questions/44385820/redis-used-memory-is-largger-than-used-memory-rss
　　used_memory being < used_memory_rss意味着内存碎片的存在。
　　used_memory > used_memory_rss 意味着物理内存不足，发生了内存swap。

2.2 需要告警的指标: mem_fragmentation_ratio

mem_fragmentation_ratio度量标准给出了操作系统看到的内存与Redis分配的内存的比率。
MemoryFragmentationRatio =Used_Memory_RSS（Used_Memory）
操作系统负责为每个进程分配物理内存。操作系统的虚拟内存管理器处理由内存分配器调解的实际映射。
如果Redis实例的内存占用为1GB，内存分配器将首先尝试找到一个连续内存段来存储数据。如果没有找到连续的段，分配器必须将进程的数据划分为多个段，从而导致内存开销的增加。
跟踪碎片比率对于了解Redis实例的性能非常重要。
碎裂率大于1表示发生碎片。比率超过1.5表示碎片过多，Redis实例占用了所请求的物理内存的150％。
碎片率低于1会告诉您Redis需要的内存比系统上可用的内存多，这会导致交换。交换到磁盘将导致延迟显着增加（请参阅已用内存）。
理想情况下，操作系统会在物理内存中分配一个连续的段，碎片比率等于1或稍大一些。
1，如果您的服务器的碎片率高于1.5，则重新启动Redis实例将允许操作系统恢复以前因碎片而无法使用的内存。在这种情况下，作为通知的警报可能就足够了。
2，如果Redis服务器的碎片比率低于1，则可能需要以发出告警，以便快速增加可用内存或减少内存使用量。
从Redis 4开始，当Redis配置为使用包含的jemalloc副本时，可以使用新的活动碎片整理功能。
可以将此工具配置为在碎片达到特定级别时启动，并开始将值复制到连续的内存区域并释放旧副本，从而减少服务器运行时的碎片。

译者注，info memory可以查看内存碎片信息

配置文件中增加activedefrag yes选项，不用重启的方式自动重整内存碎片。

2.3需要告警的指标：evicted_keys（仅限缓存）

如果您使用Redis作为缓存，可能将其配置为在达到maxmemory限制时（按照某种方式）自动清除key值。
如果您使用Redis作为数据库或队列，可能需要交换而不是清除key值，在这种情况下，因此可以跳过此指标。
跟踪key值清理指标非常重要，因为Redis按顺序处理每个操作，这意味着驱逐大量key可以降低命中率，从而增加延迟时间。
如果您使用TTL，您可能不会期望清理key值。在这种情况下，如果此指标始终高于零，您可能会看到实例中的延迟增加。
大多数不使用TTL的其他配置最终会耗尽内存并开始清理key值。只要您的响应时间可以接受，就可以接受稳定的清除率。
您可以使用以下命令配置key值过期策略：
config set maxmemory-policy = ***

其中policy是以下之一：
noeviction-----------------------当达到内存限制并且用户尝试添加其他键时，将返回错误（也就是说达到内存限制之后不允许写入）
volatile-lru-----------------------在已过期的key值中，删除最近最少使用的key值
volatile-ttl------------------------在已过期的key值中，删除最短过期时间的key值
volatile-random-----------------在已过期的key值中，随机删除key值
allkeys-lru-----------------------从所有key值中删除最近最少使用的key
allkeys-random-----------------从所有key值中随机删除
volatile-lfu-----------------------在Redis 4中新增选项，在已过期的key值中，“最近最不常用”的key值
allkeys-lfu-----------------------在Redis 4中新增选项，从所有key值中，删除“最近最不常用”的key值

注意：出于性能原因，当使用LRU，TTL或Redis 4的LFU策略时，Redis实际上不会从整个key值集进行采样。
Redis首先对key值集的随机子集进行采样，然后对样本应用清理策略。
通常，Redis的较新（> = 3）版本采用LRU采样策略，该策略更接近真实LRU。
例如，可以通过设置必须经过多少时间而无需访问项目在排名中向下移动来调整LFU策略。有关更多详细信息，请参阅Redis的文档。

译者注：
关于LRU和LFU，分别是最近最少使用和最近最不频繁使用，LFU理论上是比LRU更加合理的算法，清理key的时候，LFU认为“最近最不频繁”使用要比“最近最少”使用更加合理。
LRU和LFU的区别：
LRU是最近最少使用页面置换算法(Least Recently Used),也就是首先淘汰最长时间未被使用的页面!
LFU是最近最不常用页面置换算法(Least Frequently Used),也就是淘汰一定时期内被访问次数最少的页!

3. 基本活动指标

3.1 需要告警的指标: connected_clients

由于对Redis的访问通常由应用程序发起（用户通常不直接访问数据库），因此对于大多数场景，连接客户端的数量将有合理的上限和下限。
如果数字偏离正常范围，这表示可能存在问题。
如果它太低，表示客户端连接可能已经丢失，如果它太高，大量的并发客户端连接可能会打垮服务器处理请求的能力。
无论如何，客户端连接始终是有限的资源 - 无论是通过操作系统，Redis的配置还是网络限制。
监视客户端连接可帮助您确保有足够的可用资源用于新客户端或管理会话。

译者注：查看Redis的最大连接数，这个配置相当于MySQL的变量（show variables ***），是一个不随Redis服务负载改变的值，因此不在info中查看。

3.2需要告警的指标: connected_slaves

如果您的数据库是大量读取的，那么您可能正在使用Redis中提供的主从数据库复制功能。
在这种情况下，监控连接的从站数量是关键。如果连接的从站数量意外更改，则可能表示主机已关闭或从站实例出现问题。

注意：在上图中，Redis Master将显示它有两个连接的slave，并且每个slave都有两个slave。
由于slave的slave不直接连接到Redis Master，因此它们不包含在Redis Master的connected_slaves中。

3.3需要告警的指标: master_last_io_seconds_ago

使用Redis的复制功能时，slave会定期检查其主服务器。主从长时间没有通信的可能表示主从Redis实例之间存在问题。并且冒着slave中数据在master中已经发生了变化危险。
由于Redis执行同步的方式，最大限度地减少主从通信的中断至关重要。当从设备在中断后重新连接到master时，它会发送PSYNC命令以尝试仅同步中断期间丢失的命令。
如果无法做到这一点，则从站将请求完整的SYNC，这会迫使master立即开始执行background save命令，同时新增加的命令会被缓冲起来。
当background save命令执行完成时，数据与缓冲的命令一起发送到客户端。每次从机执行SYNC时，都会导致主实例上的延迟显着增加。

3.4需要注意的指标: keyspace

跟踪数据库中的键数通常是个好主意。作为内存数据存储，key值集合空间越大，为了确保性能，Redis需要的物理内存越多。
Redis将继续添加key值，直到它达到maxmemory limit，然后它开始以相同的速率清理key值。这会产生一个“扁平线”图，如上图所示。
如果您使用Redis作为缓存并查看key值空间饱和度 - 如上图所示 - 加上命中率较低，您可能会让客户端请求旧的或已逐出的数据。随着时间的推移跟踪keyspace_misses数量将帮助您查明原因。
或者，如果使用Redis作为数据库或队列，则可能不选择volatile策略。
随着key值空间的增长，如果可能的话，您可能需要考虑在添加物理内存或在主机之间拆分数据集。
添加更多内存是一种简单有效的解决方案。如果单机资源有限，则对数据进行分区或分片可以合并许多计算机的资源。
有了分区计划，Redis可以存储更多key值集合而无需清理或swap。但是，分片比增加内存要困难得多。
值得庆幸的是，Redis文档中有一个关于使用Redis实例实现分区方案的重要部分，请在此处阅读更多内容。

　　译者注：Redis的keyspace信息

4.持久化指标

Redis需要启用持久性配置，尤其是在使用Redis的复制功能时。
如果您使用Redis作为缓存，或者在数据丢失无关紧要的用例中，则可能不需要持久性。

4.1 需要注意的指标: rdb_last_save_time and rdb_changes_since_last_save

通常，关注数据集的波动性是个好主意。写入磁盘之间的时间间隔过长可能会在服务器发生故障时导致数据丢失。
在上次保存时间和故障时间之间对数据集所做的任何更改都将丢失。
监控rdb_changes_since_last_save可让您更深入地了解数据的波动性。如果您的数据集在该间隔内没有太大变化，则写入之间的长时间间隔不是问题。
跟踪这两个指标可以让您清楚地了解在给定时间点发生故障时您将丢失多少数据。

译者注：如何查看Redis的rdb_last_save_time and rdb_changes_since_last_save

info Persistence

5．Error metrics

Redis错误指标可以提醒您注意异常情况。以下指标可跟踪常见错误：

5.1需要告警的指标: rejected_connections

Redis能够处理许多活动连接，默认情况下可以使用10,000个客户端连接。
可以通过更改redis.conf中的maxclient指令将最大连接数设置为不同的值。
如果您的Redis实例当前处于其最大连接数，则将断开任何新的连接尝试。

请注意，Redis可能不支持使用maxclient指令请求的连接数。
Redis检查内核以确定可用文件描述符的数量。如果可用文件描述符的数量小于maxclient + 32（Redis为其自己使用保留32个文件描述符），则忽略maxclient指令并使用可用文件描述符的数量。
有关Redis如何处理客户端连接的更多信息，请参阅有关redis.io的文档。

译者注：rejected_connections可以通过查看Info stat

5.2需要告警的指标: keyspace_misses

每次Redis查找key时，只有两种可能的结果：key存在，或key不存在。
查找不存在的键会导致keyspace_misses计数器递增，因此keyspace_misses意味着客户端尝试在数据库中查找不存在的密key。
如果您不使用Redis作为缓存，则keyspace_misses应该为零或接近零。请注意，调用阻塞的任何阻塞操作（BLPOP，BRPOP和BRPOPLPUSH）都将导致keyspace_misses递增。

译者注：keyspace_misses可以通过查看Info stat

5.3需要告警的指标: master_link_down_since_seconds

该指标仅在主从之间的连接丢失时可用。
理想情况下，此值不应超过零-主从之间保持持续通信，以确保slave不提供过时数据。
应该解决连接之间的大的时间间隔。请记住，重新连接后，您的主Redis实例将需要投入资源来更新从站上的数据，这可能会导致延迟增加。

总结

在这篇文章中，我们提到了一些最有用的指标，您可以监控这些指标以密切关注您的Redis服务器。
如果您刚刚开始使用Redis，那么监控下面列表中的指标将提供对数据库基础结构的运行状况和性能的良好可见性：
Number of commands processed per second
Latency
Memory fragmentation ratio
Evictions
Rejected clients
最终，您将认识到与您自己的设备和用例特其他指标。当然，您监控的内容取决于您拥有的工具和可用的指标。有关收集Redis指标的分步说明，请参阅随附文章。