config set loglevel仅对单个redis节点临时生效，重启后还原为配置文件值；永久生效需逐节点修改redis.conf中的loglevel和logfile，并重启服务；sentinel须用sentinel loglevel单独设置，且不支持批量操作。
CONFIG SET loglevel 只对单个节点临时生效
在某个 Redis 节点上执行 CONFIG SET loglevel verbose，确实能立刻看到更详细的连接、命令、复制状态等日志，但仅限该进程——重启就还原为 redis.conf 里的值。生产环境里刚收到报警、怀疑是某次批量写入触发了超时，可以快速连上去切一次 verbose 看几秒日志流；但别指望它“设完就一劳永逸”。
常见踩坑点：
-
CONFIG SET不影响 Sentinel 进程，Sentinel 日志照旧安静 - 改完没配
logfile，日志仍打到 stdout —— systemd 或容器环境下容易被截断或直接丢弃 - 集群有 6 个 shard（12 个节点），只改了其中 1 个 master，其他节点仍是
notice，关键错误根本没记录
redis.conf 中必须逐节点修改 loglevel 和 logfile
Redis 没有集群级统一日志配置机制，每个 master、slave、Sentinel 实例都得单独改自己的配置文件。漏掉任何一个，排查时就可能卡在“明明设了 verbose，怎么日志还是空的”。
实操要点：
- 先确认每个节点实际加载的配置路径：
systemctl cat redis@7001或redis-cli INFO server | grep config_file - 修改时必须同时设
loglevel verbose和logfile /var/log/redis/redis-7001.log，否则日志不落地 - 改完别忘了
sudo systemctl restart redis@7001（或对应实例名），单纯 reload 不生效 - 验证：
tail -f /var/log/redis/redis-7001.log看是否真有新日志输出
Sentinel 节点要用 SENTINEL loglevel 单独调
Sentinel 是独立进程，不读 redis.conf，也不响应 CONFIG SET。你在 Sentinel 的 CLI 里敲 CONFIG SET loglevel debug，会直接报错 (error) ERR unknown command 'CONFIG'。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
正确做法是：
- 连上 Sentinel 实例：
redis-cli -p 26379 - 对每个 monitored master 单独设置：
SENTINEL loglevel mymaster verbose - 没有批量语法，master 多的时候得循环执行，比如用 shell 脚本遍历
SENTINEL masters输出结果 - 注意：这个设置只影响该 Sentinel 对
mymaster的监控上下文，不影响它对其他 master 的日志输出
debug 级别不记录命令，采样靠 slowlog 和 monitor
很多人以为把 loglevel 设成 debug 就能“抓到所有请求”，其实不是。Redis 的 debug 日志主要记录内部状态变更（如 cluster slot 迁移、replication buffer 切换），并不记录客户端发来的每条命令。
真正要做请求采样，得靠：
-
slowlog-log-slower-than 10000（单位微秒）：记录 >10ms 的命令，配合SLOWLOG GET 10查看 -
MONITOR命令：实时输出所有命令流，但性能开销大，只适合短时间诊断 - 生产环境推荐组合：
loglevel notice+slowlog-log-slower-than 5000，比盲目开debug更可控、更可持续
集群节点多、配置分散，最容易忽略的是 Sentinel 日志和 logfile 路径一致性——哪怕所有 Redis 实例都设对了，Sentinel 静默不报，故障定位就缺了一块拼图。
