Redis怎么记日志才能快速找到问题根源，实操分享给你

基于多位资深运维工程师和开发者的实践经验分享，综合自技术社区讨论、内部案例以及《Redis设计与实现》等资料中的相关理念）

Redis出问题了，比如突然变慢、内存暴涨，或者干脆连不上了，这时候最头疼的就是怎么快速找到原因，你不能干着急，得有的放矢地去查日志，但Redis的日志文件如果不做任何设置，它就像一本流水账，什么都记，真出了问题，你可能得在成千上万行日志里大海捞针，关键不是等出了问题再去看日志，而是提前把日志“调教”好，让它能主动、清晰地告诉你问题在哪。

第一步：别让日志变成“哑巴”或“话痨”——设置合适的日志级别

Redis的日志级别有四种：debug、verbose、notice、warning，默认是notice,这个设置很重要。

• debug：话最多，几乎什么都记，包括每一个命令的执行细节，这东西只在开发调试的时候有用，在生产环境开启它，你的磁盘会被瞬间写满，而且会让你在排查问题时彻底迷失。生产环境绝对不要用debug级别。
• verbose：话也比较多，但比debug好点，会记录一些比较详细的信息,一般也很少在生产环境用。
• notice（推荐）：这是默认级别，也是最适合生产环境的，它会记录一些正常运行时的关键信息，比如服务启动、关闭、与客户端的连接断开等，这些信息不多不少，既能让你了解Redis的健康状态,又不会产生太多噪音。
• warning：话最少，只记录非常严重的错误和警告，如果你把级别设成warning，可能会错过一些问题的早期征兆，比如内存快满了的时候，Redis会在notice级别下发出一条警告，但如果设成warning，这条警告可能就不会记录,等你发现的时候可能已经因为内存不足而宕机了。

通常就保持默认的notice级别，这样，当有异常情况（比如客户端异常断开、持久化出错）时,日志里会有清晰的记录。

第二步：给日志打上精确的时间戳——定位问题的“尺子” 还不够，你必须知道问题发生在“什么时候”，Redis默认的日志格式只有日期和时间，没有更精确到毫秒或微秒的时间戳，当你在处理高并发请求时，一个秒内可能发生很多事情，没有精确时间戳，你很难把Redis的异常和业务系统其他组件（比如应用服务器、数据库）的日志对应起来。

你需要在redis.conf配置文件里找到这一行： logfile "" 通常我们是把日志输出到文件，所以这里会指定一个文件路径，/var/log/redis/redis-server.log。

更重要的是，找到这一行并修改： # timestamp-output no 把它改成： timestamp-output yes 这样，每一条日志前面都会带上一个精确到毫秒的时间戳，格式像 [1741234567.789]，这样，当你从监控系统发现业务接口在某个时间点响应变慢时，你就可以拿着这个精确的时间点，直接去Redis日志里搜索这个时间点附近发生了什么,效率大大提高。

第三步：重点关注“慢查询日志”——性能问题的照妖镜

很多时候问题不是Redis挂了，而是它“慢”了，哪个命令执行得慢，就是最直接的嫌疑犯，Redis提供了一个专门的功能叫“慢查询日志”（slow log），它就像一个“黑匣子”,会记录下所有执行时间超过你设定阈值的命令。

这个配置也在redis.conf里：

• slowlog-log-slower-than 10000：这个单位是微秒（1秒=1000000微秒），默认是10000微秒，也就是10毫秒，意思是，任何执行时间超过10毫秒的命令都会被记录下来，对于大多数场景，10毫秒可能太宽松了，你可以根据你的业务要求把它设得更小，比如5000微秒（5毫秒）甚至1000微秒（1毫秒），如果你追求极致的性能,可以设得更低。
• slowlog-max-len 128：这个慢查询日志列表最多能存多少条记录，默认128条可能有点少，在高并发下，慢命令可能会被很快挤掉，建议设大一点，比如1024条,确保你有足够的时间来查看。

当感觉Redis变慢时，第一时间不是去翻庞大的普通日志文件，而是用Redis命令行工具直接查询慢日志： SLOWLOG GET 10 这个命令会列出最近10条慢查询命令，包括它的执行时间、耗时、具体的命令和参数，你可能会发现，罪魁祸首可能是一个没有设置超时时间的KEYS *命令（这个命令在生产环境是禁止使用的），或者是一个对超大集合执行的HGETALL命令，找到这个具体命令,你就找到了问题的根源。

第四步：结合监控和日志，形成闭环

日志不是孤立的，你要把Redis的日志和你现有的监控系统（比如Prometheus+Grafana）结合起来，监控图表显示内存使用率在某个时间点飙升，那么你就拿着这个时间点,去Redis日志里看：

1. 有没有生成RDB快照或AOF重写的记录？（这些操作会暂时占用更多内存和CPU）
2. 有没有大量的客户端连接和断开？
3. 去慢查询日志里看,是不是在那个时间点附近出现了大量的慢查询？

通过这种交叉验证，你就能很快判断出，内存飙升是因为正常的持久化操作,还是因为某个邪恶的命令吃光了内存。

实操小技巧：日志文件管理

日志文件会越来越大，需要定期处理，不要直接用rm命令删除正在写入的日志文件，这样可能导致日志丢失,正确的方法是：

1. 使用logrotate这样的工具来轮转日志，它可以帮你压缩旧日志,并通知Redis重新打开新的日志文件。
2. 或者，如果你手动操作，可以先重命名当前日志文件（比如mv redis.log redis.log.old），然后发送一个CONFIG SET logfile new_path命令给Redis，或者直接发送KEYS *命令（不推荐）让Redis重新打开日志（更优雅的方式是发送SIGHUP信号给Redis进程，让它重新加载配置）。

快速定位Redis问题根源的日志实操心法就是：用notice级别保证信息量，开启精确时间戳方便关联，善用慢查询日志直击性能瓶颈，再结合监控系统进行交叉分析。 提前把这些配置做好，就相当于给Redis装上了高精度的诊断仪器，问题发生时你就能从容应对,快速找到根源。