当前位置：首页 > 问答 > 正文

Redis监控那些事儿，怎么多角度盯着它不出问题，告警又该咋弄才靠谱

Redis监控那些事儿，怎么多角度盯着它不出问题，告警又该咋弄才靠谱

想把Redis伺候好,不让它关键时刻掉链子，你得学会从多个角度盯着它，这就像照顾一个宝贝，不能等它发烧了才知道生病，得平时就看看脸色、摸摸体温、问问胃口，下面就来聊聊怎么多角度监控Redis，以及怎么设置告警才算靠谱。

第一方面：先看基本生命体征——性能和资源

这是最基础的,也是最直接的，你得确保Redis本身是“活蹦乱跳”的，没被累趴下。

内存使用情况：这是头等大事。 Redis是内存数据库，内存满了可就真卡住了，你不能只看用了百分之多少，关键要看两点：
- 内存使用量： 看看是不是在平稳增长，有没有突然飙升，突然变大可能是有个大Key被写入了，或者某个功能出了问题在疯狂写数据。
- 是否触发了内存淘汰策略： 如果你设置了maxmemory，当内存快满时，Redis会根据你设定的策略（比如LRU）淘汰一些键，监控有没有发生淘汰事件很重要，如果淘汰很频繁，说明内存真的紧张了，要么需要扩容，要么得看看是不是有没必要的数据一直占着地方。（参考来源：Redis官方文档关于maxmemory和INFO命令的说明）
CPU使用率： Redis是单线程工作的，意味着它只有一个核心在干主要的活儿，如果这个核心的CPU使用率持续很高，比如长时间超过80%，那就要警惕了，说明Redis正在拼命处理命令，可能遇到了复杂的命令（比如排序、聚合）、或者请求量实在太大了，这时候服务响应就会变慢。
连接数： 看看有多少个客户端连着你的Redis，连接数如果异常高，可能是客户端有bug，连接没正常关闭，导致“僵尸连接”堆积，这会耗光Redis的资源，也要监控连接被拒绝的数量，这表示已经达到了最大连接数限制，新的客户端连不进来了。

第二方面：再看看它干活儿的速度和质量——时延和命中率

光活着还不够,得干得好、干得快。

操作延迟（Latency）： 这是衡量Redis响应速度的核心指标，一次简单的SET或GET命令应该是在微秒级别完成的，你可以使用Redis自带的redis-cli --latency命令来测试，或者用监控工具来持续追踪，如果延迟突然增高，用户就会感觉到“卡”，原因可能有很多：比如执行了慢查询、网络问题、服务器负载太高、或者发生了持久化导致的瞬间阻塞。
- 慢查询日志： 一定要开启慢查询日志（slowlog），设置一个合理的阈值（比如10毫秒），定期检查慢查询日志，看看是哪些命令执行得慢，然后去优化它，可能是没用好索引，或者命令本身太复杂。（参考来源：Redis官方文档关于slowlog的说明）
缓存命中率（Cache Hit Ratio）： 如果你的Redis是当作缓存用的，这个指标极其重要，它计算的是：请求的数据在缓存中找到的次数占总请求次数的比例，命中率越高，说明缓存效果越好，大部分请求都无需去查后面更慢的数据库，如果命中率持续很低（比如低于90%），那就得看看缓存策略是不是有问题：是不是缓存的数据很快过期了？或者缓存的空间太小，根本存不下热点数据？

第三方面：最后看看它的“后台任务”是否顺畅——持久化和复制

Redis为了保证数据不丢失和高可用,会有一些后台操作，这些操作搞不好会惹麻烦。

持久化监控：
- 如果你用RDB（快照），要监控最近一次快照是否成功，以及耗时多久，如果快照失败，数据就有丢失的风险，如果快照时间太长，可能会影响性能。
- 如果你用AOF（日志），要监控AOF文件的大小，如果AOF重写（压缩日志）失败，或者频率不正常，AOF文件可能会变得巨大，影响恢复速度。
主从复制监控： 如果你用了主从架构来实现高可用，必须盯紧复制链路。
- 主从连接状态： 确保从节点（slave）和主节点（master）是连接状态的。
- 复制延迟（Replication Lag）： 这是关键中的关键，主节点写入数据后，从节点需要时间来同步，这个时间差就是复制延迟，如果延迟很大，比如积压了几万甚至几十万个命令，那么一旦主节点宕机，你切换到从节点就会丢失很多数据，必须监控这个延迟量，并设置告警。（参考来源：Redis官方文档关于复制的说明）

告警又该咋弄才靠谱？

监控数据有了,告警不能乱设，否则整天被无关紧要的消息轰炸，真正出问题时反而忽略了，告警要遵循“准”和“狠”的原则。

告警要有层次，分轻重缓急：
- 致命告警（PagerDuty/电话级别）： 这类问题需要马上处理，Redis进程宕机、主从复制连接断开了、内存使用率达到95%以上且触发了OOM（内存溢出）。
- 重要告警（即时通讯软件/邮件级别）： 这类问题需要尽快关注，否则可能演变成致命问题，内存使用率超过80%、CPU使用率持续5分钟高于90%、复制延迟超过1分钟、连接数接近上限。
- 警告信息（只需记录，无需立即处理）： 出现了慢查询（但频率不高）、缓存命中率有所下降但仍可接受，这些信息用于日常优化和分析。
避免“狼来了”，设置智能阈值：
- 不要只设一个静态阈值,内存使用率在业务高峰期达到85%可能是正常的，但在凌晨低峰期达到85%就不正常，可以尝试设置动态基线告警，即偏离正常波动范围才告警。
- 采用持续时长来判断。“CPU使用率连续5分钟高于90%”才告警，而不是偶尔 spike 一下（比如持续10秒钟）就告警，这样可以避免很多干扰。
告警信息要清晰有用：

告警消息不能光说“Redis内存高了”，而要包含关键信息：“哪个实例的”、“当前值是多少”、“阈值是多少”、“可能的原因或排查建议（检查是否有大Key）”，这样收到告警的人能立刻明白问题严重性并开始排查。