Redis日志那些事儿，怎么看运行状态才能用得溜点

要玩转Redis,把日志看明白是顶顶重要的一步，日志就像是Redis的“体检报告”和“心里话”，它默默地记录着所有好事儿和糟心事儿，你要是看不懂，那Redis对你来说就是个黑盒子，出了问题只能干瞪眼，咱们今天就不扯那些高深的术语，就用大白话聊聊怎么把这日志给用溜了。

你得知道Redis的日志在哪,以及怎么让它“说”得更详细，默认情况下，Redis的日志级别是“notice”，这个级别会记录一些比较重要的信息，比如服务器启动、关闭、有客户端连接断开等，但光看这些是不够的，尤其是当你感觉Redis有点“慢”或者出问题时，这时候，你需要把日志级别调到“verbose”甚至“debug”，怎么调呢？在Redis的配置文件redis.conf里，找到loglevel这一行，改掉然后重启Redis就行了，不过要注意，“debug”级别日志会非常详细，信息量巨大，可能会影响性能，一般只在排查问题时临时开启。（来源：Redis官方文档关于loglevel的配置说明）

日志文件本身,你可以通过配置logfile来指定一个路径，比如/var/log/redis/redis-server.log，如果不设置，默认就会打印到标准输出，如果你是用Docker跑的，那就得用docker logs命令来看了。

咱们看看日志里哪些是重点,看到什么信息你得心里有数。

关注“慢查询”日志（Slow Log） 这个不是指普通的日志文件，是Redis专门记录执行时间超过一定阈值的命令的一个特殊日志，它超级有用，是排查性能问题的首选，你会在日志里看到类似这样的记录：

1) 1) (integer) 14          # 这条慢查询的唯一ID
   2) (integer) 1633045678   # 命令执行时的时间戳
   3) (integer) 12000        # 命令执行的耗时，单位是微秒（这里是12毫秒）
   4) 1) "KEYS"              # 执行的命令和参数
      2) "user:*:cart"

看到这个,你就要警惕了！KEYS命令在生产环境是出了名的“性能杀手”，它会遍历所有键，如果数据量一大，必然慢，这时候你就得考虑用SCAN命令来替代，或者检查一下业务代码是不是写得有问题，慢查询的阈值可以通过slowlog-log-slower-than来设置，比如设置为5000，就是超过5毫秒的命令都记下来。（来源：Redis官方文档关于Slow Log的说明）

普通日志里的关键信号 在普通的日志文件里，你要像侦探一样寻找线索：

• 警告（WARNING）：看到这个词就要打起精神了。

  • # WARNING overcommit memory is set to 0! 这是在说操作系统内存分配策略可能有问题，万一Redis需要更多内存时系统不给，可能导致崩溃。
  • # WARNING: The TCP backlog setting of 511 cannot be enforced because... 这是网络连接方面的警告，可能会影响高并发下的连接性能。
  • Slow fork: unable to fork warning 这个特别重要！当Redis做持久化（RDB快照或AOF重写）时需要创建子进程，如果创建过程太慢，说明系统可能内存压力巨大，或者CPU非常繁忙，这会严重影响Redis的稳定性。

• 连接相关的信息：

  

  • Accepted 127.0.0.1:58934 和 DB closed connection 这些是正常的连接和断开，但如果短时间内出现大量连接和断开，可能就是客户端有异常，或者遇到了连接池配置问题。
  • Client id=5 addr=127.0.0.1:12345 idle=1000 flags=S db=0 sub=0 psub=0 ... 这种是客户端连接的具体信息，idle表示空闲时间，可以用来排查哪些客户端占着连接不干活。

• 持久化相关的信息：

  • Background saving started by pid 12345 和 Background saving terminated with success 这是Redis在后台成功创建RDB快照的记录，看到这个说明备份正常。
  • 但如果看到 Background AOF rewrite terminated with error 或者 Fatal error: can't open the append-only file 那就出大事了！说明AOF持久化失败了，可能会丢数据，必须立刻检查磁盘空间和文件权限。

• 内存相关的信息：

  • 如果日志里出现了 OOM command not allowed when used memory > 'maxmemory'，这说明Redis已经达到了你设置的最大内存上限，并且你配置的淘汰策略（eviction policy）在这种情况下不允许写入新数据了，这时候客户端会收到错误，你得赶紧去排查是不是有内存泄漏，或者是否需要调整maxmemory-policy（比如设置为LRU淘汰）来腾出空间。

养成好习惯 看日志不能等出了问题才去翻，那叫“事后诸葛亮”，你得养成主动监控的习惯。

• 定期翻看：每天上班第一件事，花五分钟扫一眼日志的最后几十行，看看有没有新的警告或错误。
• 使用工具：别傻乎乎地用肉眼一行行看，用grep、tail -f、less这些命令行工具，你想专门看警告信息，就grep -i "warning" /var/log/redis/redis-server.log，想实时监控新日志，就tail -f /var/log/redis/redis-server.log。
• 结合监控系统：更高级的做法是使用Prometheus、Grafana这类监控系统，把Redis的指标（包括日志中提取的关键错误）可视化出来，设置报警规则，一旦有异常马上就能收到通知。

Redis日志不是天书,它用最直白的方式告诉你系统内部发生了什么，你多看看，多想想“这条信息背后可能是什么问题”，慢慢地，你就能预判问题、快速定位故障，真正把Redis用得溜起来，一个合格的Redis玩家，都是从读懂它的“心里话”开始的。（来源：基于常见的Redis运维实践和问题排查经验总结）